what is "channel movement detection"? (1 Viewer)

[chrik]

MediaPortal Version: 1.2 BETA
MediaPortal Skin: StreamedMP newest version
Windows Version: Windows 7 Ultimate SP1 X64
CPU Type: AMD X4 955 BE OC 3.6GHz
HDD: 1.5GB
Memory: 2x2GB 1666 corsair
Motherboard: Gigabyte
Video Card: Onboard HD4200 ATI
Video Card Driver: 11.8
Sound Card: onboard
Sound Card AC3: optical out
Sound Card Driver: newest
1. TV Card: Tevii S660 USB
1. TV Card Type: DVB-S/S2
1. TV Card Driver: Newest available on Tevii.com
2. TV Card: Hauppauge NOVA HD PCI
2. TV Card Type: DVB-S/S2
2. TV Card Driver: Newest
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: FFDSHOW
MPEG2 Audio Codec:
h.264 Video Codec: divx
Satelite/CableTV Provider:
HTPC Case:
Cooling:
Power Supply:
Remote: Microsoft
TV: Samsung LCD 40" LE40F86
TV - HTPC Connection: HDMI->HDMI


Just noticed the option "enable channel movement detection" in the "Tv server config" when tuning DVB-S/S2 channels.

Could someone tell me exactly what it is good for and when to use it?

 

[mm1352000]

Hi chrik

It is good if your provider(s) constantly move your channels to different frequencies. When you enable the option, TV Server uses the following logic:

0. Scan finds a channel.
1. Check: do we already know about a channel with this network ID + service ID combination?
- if YES, update the existing tuning details
- if NO, create a new channel

The default logic (when you don't enable the option) is only slightly different:

0. Scan finds a channel.
1. Check: do we already know about a channel with this network ID + transport stream ID + service ID combination?
- if YES, update the existing tuning details
- if NO, create a new channel

The option won't work for everyone (as we found out in MP 1.2.0b) because some providers have different channels with the same network ID + service ID combination. In those cases, the provider differentiates between the two channels using the transport stream ID. That is technically bad behaviour by the providers, but it caused so much trouble when we added and enabled the option by default in MP 1.2.0b that we have changed the wording and disabled it by default in 1.2.0rc.

Hope that makes sense

mm

PS: I note that our wiki is *very* out of date for the scanning sections. I apologise - hopefully we can get around to updating this info in the next few weeks.

 

[velis]

I'd like to add that this functionality is also not sufficient for all users:
IPTV users usually have issues because any or all three parameters change. The only thing that remains the same is channel name.
You really should just allow the user to freely click any of the three attributes thus disabling equality check for checked attribute.

While at it, does the TV engine really have to be so rigid about PIDs and SIDs? For UDP IPTV to successfully connect to TV stream, IP and port are sufficient. MP then reads the resulting stream and makes an unnecessary check for EVERY subsequent tune-in for all those attributes.

Last, but not least, this option wreaks havoc on IPTV tuning: because PID and SID are equal for a great many channels, tuning then mixes and matches totally different channels just because PID and SID are the same...

 

[mm1352000]

Hi velis

Obviously we listened to the feedback that we received from you and others when 1.2.0b was released. In MP 1.2.0rc the default channel identification for DVB-IP channels is the URL. You can enable channel movement detection to use ONID + SID, but I don't imagine many people will actually do that.

You really should just allow the user to freely click any of the three attributes thus disabling equality check for checked attribute.

There is always a trade-off between flexibility, code complexity and usability. We have decided not to do this as although it is the ultimate in flexibility, it makes TV Server configuration more complex to understand. Instead, we intend to follow the DVB standards as closely as possible. I freely acknowledge that there are aspects of DVB-IP that we have not implemented at all - we intend to improve support in the next version of TV Server. However, we are not going to bend over backwards to accommodate badly behaving providers.

While at it, does the TV engine really have to be so rigid about PIDs and SIDs? For UDP IPTV to successfully connect to TV stream, IP and port are sufficient. MP then reads the resulting stream and makes an unnecessary check for EVERY subsequent tune-in for all those attributes.

As I've already said, we intend to improve support for DVB-IP. I will keep that in mind when we go to deal with that code. Having said that, you make the assumption - perhaps rightly, but technically not guaranteed - that there is only one channel in each DVB-IP stream. TV Server supported DVB-S, T and C standards first where that is almost never the case. I'm sure reusing the existing code made it much easier to add support originally...

Last, but not least, this option wreaks havoc on IPTV tuning: because PID and SID are equal for a great many channels, tuning then mixes and matches totally different channels just because PID and SID are the same...

As I've said, we listened to your feedback and made the URL the default identifier for 1.2.0rc.

mm

 

[octessence]

Sorry to drag up an old thread. I'd like some clarifications if possible and this seems like the best place to ask.

Assuming I don't know whether my provider moves channels to different frequencies which option should I first try first? Then what results should I expect to see if I have picked the correct option vs the wrong option?

So there are 4 different cases that might occur:

Don't enable the flag + Provider has moved a channel => Something will be wrong. What exactly should I look for. e.g. I will get a new channel and will have to delete the old one and redo any EPG configuration?
Don't enable the flag + Provider has not moved any channels => Everything fine?
Enable the flag + Provider has moved a channel => Everything fine?
Enable the flag + Provider has not moved any channels => Everything fine?

So using the above I should always enable it, but when will this lead to a screwed up configuration and what should I check for?

Thanks.