[Pending] DVB-IP scanning improvements (1 Viewer)

AlexPlas

Portal Pro
August 24, 2006
231
41
Kyiv, Ukraine
Home Country
Ukraine Ukraine
Hello

I'd like to offer patch with few improvements in DVB-IP channel scanning. First I like to explain why this patch is done.

My ISP provides IPTV service with few different sets of channels which can be ordered separately. URL to the playlist is common (http://tv.ipnet.ua/ipnet.m3u) and content of the playlist depends on ISP user’s current subscription. So, first of all I cannot prepare the playlist for submitting to MP repository because I've not subscribed to all sets of channels, and second I have to change playlist for channel scanning every time when IPS adds new channels or I become subscribed for new channels set.

Second issue is a format of playlist. It contains additional control elements like the following:
Code:
#EXTINF:0,1+1
#EXTVLCOPT:audio-track-id=770
udp://@239.23.0.5:1234/
Current implementation cannot parse #EXTVLCOPT element properly.

Third issue is number of network adapters on my TV Server. I have three network adapters in my TV Server, so for correct scanning of multicast streams I have to change every URL and add there IP address of correct network adapter.

So, my patch offers next changes:
1) Parsing of M3U files is changed. Any elements starting with # are allowed, #EXTINF and #EXTVLCOPT will be parsed properly
2) M3U file can contain URL to another M3U file. Only one URL as the first element of M3U file is allowed, and only one level of nesting is allowed. Playlist which is pointed by URL will be downloaded and parsed. So, playlist for my ISP have the following format now:
Code:
#EXTM3U
#EXTVLCOPT:http-charset=utf-8
http://tv.ipnet.ua/ipnet.m3u
3) An ability to select network adapter is added to DVB-IP scanning section. Default behavior is not changed since default value of network interface combobox is Auto which doesn't change URLs.

Here is attached patch file against last SVN

Looking forward for any suggestions

Changelog:
 

Attachments

  • IPTV_Setup.patch
    22.2 KB

Stepko

Retired Team Member
  • Premium Supporter
  • September 29, 2007
    186
    152
    Hamburg/Wolfsburg
    Home Country
    Germany Germany
    AW: DVB-IP scanning improvements

    Hi AlexPlas,

    thanks for submitting the patch. I'll have a look at it as soon as I can.
    Regarding the issue of having multiple network adapters: This can be fixed with a static route in Windows. You just need to set a static IP for the network adapter and then add a static route so that all multicast join/leave commands will be sent over this adapter. Works good on my htpc.

    Stepko
     

    AlexPlas

    Portal Pro
    August 24, 2006
    231
    41
    Kyiv, Ukraine
    Home Country
    Ukraine Ukraine
    georgius, I have tested my changes with standard IPTV filter, with Stepko's filter and with your as well :)

    Stepko, I think the ability to select network interface directly in GUI is a bit simple then routing table editing, especially for users who isn't familiar enough with TCP/IP protocol
     

    georgius

    Retired Team Member
  • Premium Supporter
  • October 31, 2010
    1,376
    654
    Bratislava
    Home Country
    Slovakia Slovakia
    My provider doesn't use static IP addresses, I have to set my HTPC to set IP address through DHCP. So I can't use static routing and also hypothetical choosing from network interfaces in HTPC will don't work. I have solved this problem with dynamic change of routing table, but this isn't for users without knowledge of routing and TCP/IP.

    If you want to add some ability of choosing network interface in GUI than you'll need to remember users like me without static IP address on network interface - there have to be implemented some "protocol" how to instruct IPTV filter to use specific network interface. If I correctly remember, Stepko's version of filter uses only static IP adresses to specify network interface, my version should also work with url or static address.
     

    AlexPlas

    Portal Pro
    August 24, 2006
    231
    41
    Kyiv, Ukraine
    Home Country
    Ukraine Ukraine
    georgius, thanks for reminder, I really forget about dynamic IPs

    I see one simple solution at the first look. We can use broadcast IP address of network interface instead of unicast in the URL. As far as I know providers usually have some pool of IP addresses with some base address and network mask, so all these IP addresses have same broadcast address. On the channels scanning stage we insert in URLs broadcast address as udp://my.broadcast.address@239.23.0.5:1234/ on the channel tuning stage we just change in URL broadcast address to active IP address for network interface with same broadcast address. It gives an ability to select network adapter in GUI and sufficient flexibility to use it with dynamic IP addresses.

    Don't sure if I've explained it clear :oops:
     

    georgius

    Retired Team Member
  • Premium Supporter
  • October 31, 2010
    1,376
    654
    Bratislava
    Home Country
    Slovakia Slovakia
    It takes me longer to understand, but it can work. I assume that "my.broadcast.address" is broadcast address of network interface to use. I'll test this if it works with my filter's version.
     

    AlexPlas

    Portal Pro
    August 24, 2006
    231
    41
    Kyiv, Ukraine
    Home Country
    Ukraine Ukraine
    Yes, "my.broadcast.address" is broadcast address of network interface, but I have change something in TvCardDVBIPBuiltIn class to implement it, I'll make it this evening and update patch in the first post
     

    georgius

    Retired Team Member
  • Premium Supporter
  • October 31, 2010
    1,376
    654
    Bratislava
    Home Country
    Slovakia Slovakia
    Interesting idea, but I have some remarks. Routing network communication through specified network interface should be solved in general way. This problem should be solved not only for IP addresses in numeric format, but also for URLs (e.g. udp://myprovider:port, http://provider.com/channel). I think that we should not encode network interface into URL directly (or at least not into URL written in playlist, this URL should be sent to filter in unchanged form). We also should not use network interface IP address, because whole URL sent to filter will be written to database. Network interface IP address for users with DHCP will change (in worst case can change also network mask).

    Because filter is written in C++ we cannot use managed classes to exchange parameters between TV-Server Configuration, TvServer and filter :(

    So I think that we should use some kind of "protocol". I suggest to encode needed parameters for filter to URL in next way: param1=value1|param2=value2|...|paramN=valueN (if in some value have to be written pipe character, it will be doubled, e.g. needed value 'abc|123' will be written as 'abc||123'). The name of parameters should be defined somewhere in TvService source code, for begining we need url and interface. So, url in playlist "udp://@233.62.90.1:1234" and interface with name "Local Area Connection" will be encoded into this url: url=udp://@233.62.90.1:1234|interface=Local Area Connection; without specified interface: url=udp://@233.62.90.1:1234.

    What do you think about this?
     

    Users who are viewing this thread

    Top Bottom