Bug #2138
Unsuscribing to IPTV stream should do a IGMP leave
0%
Description
I tried the today git on IPTV, and after I got the stream and closed VLC, I had no more IPTV channels on my Orange STB. After some analysis, it turned out, the HD stream was still subscribed on DSLAM preventing me to get another HD IPTV stream (on ADSL more than one HD stream mean you have the DLSAM in your living room).
For me the way it actually works mean that as soon as watch an HD IPTV stream on one box, even if I quit, I will not be able to get later a different stream on another box. This is not acceptable.
Here are the traces that show the problem.
2014-06-14 16:40:29.591 [ INFO] subscription: "HTTP" subscribing on "FRANCE 3 HD", weight: 100, adapter: "IPTV", network: "Orange", mux: "rtp://232.0.2.142:8200", provider: "GlobeCast", service: "FRANCE 3 HD"
2014-06-14 16:40:57.146 [ ERROR] mkv: Live stream: Write failed -- Connexion ré-initialisée par le correspondant
2014-06-14 16:40:57.146 [WARNING] webui: Stop streaming /stream/channel/bb949c467260f5d57cd577288053e60e, muxer reported errors
2014-06-14 16:40:57.146 [ INFO] subscription: "HTTP" unsubscribing from "FRANCE 3 HD" <========== close vlc
^C2014-06-14 17:18:27.408 [ INFO] mpegts: 698000 (0x816750) - deleting <==== manually delete tvheadend via ^C
2014-06-14 17:18:27.408 [ INFO] mpegts: 498000 (0x8076f0) - deleting
2014-06-14 17:18:27.408 [ INFO] mpegts: 626000 (0x7e9b90) - deleting
2014-06-14 17:18:27.408 [ INFO] mpegts: 522000 (0x8055e0) - deleting
2014-06-14 17:18:27.408 [ INFO] mpegts: 474000 (0x7e5320) - deleting
2014-06-14 17:18:27.408 [ INFO] mpegts: 674000 (0x7e3260) - deleting
2014-06-14 17:18:27.408 [ INFO] mpegts: 746000 (0x730460) - deleting
2014-06-14 17:18:27.408 [ INFO] mpegts: 594000 (0x728ce0) - deleting
2014-06-14 17:18:27.408 [ INFO] mpegts: 554000 (0x7d6fd0) - deleting
2014-06-14 17:18:27.408 [ INFO] mpegts: 666000 (0x72fbd0) - deleting
2014-06-14 17:18:27.409 [ INFO] mpegts: rtp://232.0.2.142:8200 (0x7e1f30) - deleting <==== IGMP leave only done here I bet
2014-06-14 17:18:27.460 [ INFO] epgdb: saved
2014-06-14 17:18:27.460 [ INFO] epgdb: brands 0
2014-06-14 17:18:27.460 [ INFO] epgdb: seasons 0
2014-06-14 17:18:27.460 [ INFO] epgdb: episodes 7253
2014-06-14 17:18:27.460 [ INFO] epgdb: broadcasts 7253
2014-06-14 17:18:27.467 [ NOTICE] STOP: Exiting HTS Tvheadend
Files
History
Updated by Eric Valette over 10 years ago
Well the trace does not probably say anything but the fact that the FRANCE 3 HD channel was the only one I was able to see on the STB indicates the stream was still subscribed...
Updated by Nikolai L. over 10 years ago
- File 0001-properly-leave-multicast-group-on-udp-close.patch 0001-properly-leave-multicast-group-on-udp-close.patch added
hi,
I experience the same issue.
Can you test that patch?
It's a really quick and dirty hack but maybe it helps and points to the right direction.
Updated by Eric Valette over 10 years ago
Thanks for the patch. Tested it. No change. I watch a stream via VLC, quit but then the STB is dead until I kill tvheadend.
Updated by Nikolai L. over 10 years ago
- File 0001-Hack-implement-iptv-udp-handler-stop-in-order-to-lea.patch 0001-Hack-implement-iptv-udp-handler-stop-in-order-to-lea.patch added
Ok,
I think you might experience a different issue as killing tvheadend does not work for me.
Sorry for that.
I also don't have any streams open in tvheadends status view, but it seems (or I assume) that the provider continues to sends packets and floods the connection.
If you can go back to 0e720dc62bdd459480adce6127b3fc1e69a70a17 and apply the new patch, you could test again.
Of course this still is not a real solution, but a ugly workaround.
I also watch TV via IPTV, but its raw udp.
For me this workaround now actually works.
Now I can zap through channels without having to restart the router+pc and wait till the providers multicast router stops sending packets by itself.
But maybe I'm all wrong and this problem does not even exists and it was something completely else...
Updated by Eric Valette over 10 years ago
Nikolai Lontke wrote:
I also don't have any streams open in tvheadends status view, but it seems (or I assume) that the provider continues to sends packets and floods the connection.
I'm sure of that as the channel that has been opened by tvheadend it the only HD IPTV channel I can see on the STB until I kill tvheadend.
The Gateway has a IGMP snopping daemon that count the number of listener and close the stream on the DSLAM side when number of client drops to 0. The same algorithm should be used on tvheadend side as two cleint my choose to see the same IPTV channel and the IGMP leave shall be done only when all http client have disconnected.
Will try the other patch.
If you can go back to 0e720dc62bdd459480adce6127b3fc1e69a70a17 and apply the new patch, you could test again.
Of course this still is not a real solution, but a ugly workaround.I also watch TV via IPTV, but its raw udp.
For me this workaround now actually works.
Now I can zap through channels without having to restart the router+pc and wait till the providers multicast router stops sending packets by itself.But maybe I'm all wrong and this problem does not even exists and it was something completely else...
Updated by Nikolai L. over 10 years ago
Ok,
in that case this patch probably won't help you either because it explicitly tells the kernel to leave the multicast group, which, from my understanding, should result in an igmp leave message.
Updated by Sam Stenvall over 10 years ago
Check your router settings if there is an "IGMP Fast Leave" option. If so, tick it.
Updated by Eric Valette over 10 years ago
Sam Stenvall wrote:
Check your router settings if there is an "IGMP Fast Leave" option. If so, tick it.
It is enabled and used by the IP STB (not that I have an option for it in the router GUI but given my professional activity...). Note I did not recheck the code recently as it breaks not only theadend but my STB also!!!
And anyway this would be a regression compared to previous code. Again on ADSL, with HD stream you cannot physically have two streams at the same time (except when switching hence the fast leave trick). Here the stream stay subscribed forever...
Updated by Jaroslav Kysela over 10 years ago
- Status changed from New to Need feedback
Please, give a try with the last master. The patch is bad, because the close() call is sufficient to generate IGMP leave. See bellow. I fixed some IPTV stuff, but not sure, if yours.
http://www.tldp.org/HOWTO/Multicast-HOWTO-6.html
6.5 IP_DROP_MEMBERSHIP.
The process is quite similar to joining a group:
struct ip_mreq mreq;
setsockopt (socket, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
where mreq is the same structure with the same data used when joining the group. If the imr_interface member is filled with INADDR_ANY, the first matching group is dropped.
If you have joined a lot of groups to the same socket, you don't need to drop memberships in all of them in order to terminate. When you close a socket, all memberships associated with it are dropped by the kernel. The same occurs if the process that opened the socket is killed.
Finally, keep in mind that a process dropping membership for a group does not imply that the host will stop receiving datagrams for that group. If another socket joined that group in that same interface previously to this IP_DROP_MEMBERSHIP, the host will keep being a member of that group.
Both ADD_MEMBERSHIP and DROP_MEMBERSHIP are nonblocking operations. They should return immediately indicating either success or failure.
Updated by Eric Valette over 10 years ago
Jaroslav Kysela wrote:
Please, give a try with the last master. The patch is bad, because the close() call is sufficient to generate IGMP leave. See bellow. I fixed some IPTV stuff, but not sure, if yours.
Ok finally got time and a keyboard to test. So far, it seems the IGMP leave is issued. I have configured only a single ip channel on tvheadend but when I quit vlc, at least I can continue to watch other channels on my IP STB. Must see how to configure many ip channels (I have a distinct multicast address per channel).