V2 why the jitter?

[User1]

Setting up a V2 atm and have the T4 running at the same time as a comparison for events, epg lookalike and file system.

.Anyway although I have the video settings as alike as they can be on 'auto' I am experiencing compared certainly to the T4 slower channel changing and a second or so of jitter upon changing to the new channel before it smooths out...I didn't expect this..

anyone know how can I improve it?

Thanks

[peteru]

You can't. At least not in a way the will not result in less acceptable behaviour - in particular extended periods of blackout when changing services.

There are two factors here that contribute to the different behaviour. Different architecture and different maturity of implementation. The T-series used Broadcom based hardware, which has pretty decent and mature software. The V2 uses Hi-Silicon hardware and they are relative newcomers to this market. Each vendor uses a different algorithm to achieve sync. The HiSi hardware tries to achieve some level of compatibility with the Broadcom platform, but it does so with limited success.

For the T-series, I had access to the driver source code and the SDK for the hardware, but this is not the case with the HiSi platform. The Chinese ODM has not been as co-operative as the Koreans were. As a result, I was able to make numerous fixes for the T-series, but I can not do this with the V2.

The upshot is that the way sync is achieved on the V2 is one of it's idiosyncrasies and short of the ODM providing improved drivers, possibly based on a newer SDK from the silicon vendor, we all have to live with it the way it is.

[User1]

Also a little more on the problem, before changing the screen stalls/freezes/pauses (peoples mouths might be noticeably stuck open for example) for a little while before switching to the new channel.

[User1]

Thanks Peteru

That's terrible news, really terrible actually, at least you saved me a chunk of fruitless time trying to improve it.

[User1]

You can't. At least not in a way the will not result in less acceptable behaviour - in particular extended periods of blackout when changing services.

There are two factors here that contribute to the different behaviour. Different architecture and different maturity of implementation. The T-series used Broadcom based hardware, which has pretty decent and mature software. The V2 uses Hi-Silicon hardware and they are relative newcomers to this market. Each vendor uses a different algorithm to achieve sync. The HiSi hardware tries to achieve some level of compatibility with the Broadcom platform, but it does so with limited success.

For the T-series, I had access to the driver source code and the SDK for the hardware, but this is not the case with the HiSi platform. The Chinese ODM has not been as co-operative as the Koreans were. As a result, I was able to make numerous fixes for the T-series, but I can not do this with the V2.

The upshot is that the way sync is achieved on the V2 is one of it's idiosyncrasies and short of the ODM providing improved drivers, possibly based on a newer SDK from the silicon vendor, we all have to live with it the way it is.

Hi again actually this has upset me somewhat, I have owned every BW since the early days and am a very heavy user via also the other people in my family but not a highly technical one I rely on the awesome number of tuners, the skip functions that defeat freeview and for this BW has been utterly awesome but this problem which to my mind reminds me of living with early and cheap digital set top boxs. Actually I think the set top box outside of loud glitches actually did a better job of channel changes.

Do you think this problem will be addressed in updates? The T4 is on it's last legs but consider now we might use the T4 as a set top box only for those times and switch to use the V2 for pre recorded program viewing of which it does really well possibly better than the T4.

Also I cannot yet get good sound...largely it sits midrange between the T4's output through the 7.1system
and the Panasonic TVs speakers all alone....this though is of lesser concern as a core expectation than the channel switching problem but still reminds me of say15 years ago.

cheers

[BigbobOz]

Interesting comments, I had noticed the 'jitter' as well but can live with it.

In some ways the V2 feels faster (moving through menus etc) than the T4 but in others slower (changing channels, skipping etc).

I've put this down to the V2 running over the network using the T4s HDD but perhaps not.

My T4 is still running well but if it did die, I'd prefer another T4 over a V2 but sadle that's no longer an option...

[sonicblue]

Just for completeness:

config.misc.zapmode =

ConfigSelection(default="mute", choices=[
("mute", _("Black screen")),
("hold", _("Hold screen")),
("mutetilllock", _("Black screen till locked")),
("holdtilllock", _("Hold till locked"))])

I tried them all, but as peteru has mentioned, none of them actually produce the desired result. I believe it's because the buffering jitter occurs after the service is already locked, and that config option only controls what happens before that.

It was the first thing I noticed when I got the V2, however I've become somewhat used to it and it doesn't seem to bother me anymore.

[prl]

The user config entry for zapmode is only visible in Menu>Setup>TV>Channel Selection if SystemInfo["ZapMode"] is true.

The code to set it (in Components/SystemInfo.py) is
SystemInfo["ZapMode"] = getImageDistro() != "beyonwiz" and (fileCheck("/proc/stb/video/zapmode") or fileCheck("/proc/stb/video/zapping_mode"))
so it will always be false on Beyonwiz boxes, even if they have /proc/stb/video/zapmode (like the V2) or /proc/stb/video/zapping_mode.

Have you tried changing /proc/stb/video/zapmode on the V2 to see what it does?

[prl]

In some ways the V2 feels faster (moving through menus etc) than the T4 but in others slower (changing channels, skipping etc).

The channel change speed difference may be due to deeper video processing buffers on the V2 (complete guess).

[sonicblue]

Have you tried changing /proc/stb/video/zapmode on the V2 to see what it does?

Yes, I tried them through telnet. The setting does respond such that you can have a black screen instead of holding the current image.

The mutetilllock setting resolves to mute for some reason, i.e cat zapmode returns mute after setting mutetilllock (the others all took their respective values). The default was hold.