Kodi Community Forum

Full Version: Opening TVH stream from m3u tries to open multiple streams
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I use a m3u playlist with TVH streams to watch TV on some Kodi devices. I use a m3u file, so I do not have to enable the complete LiveTV functionality, and since Kodi 15 TVH is discarded as video source type.

When I open an item from this m3u file, e.g.
Code:
#EXTINF:-1,4 - RTL 4
http://192.168.1.97:9981/stream/channelid/693426109?ticket=60CEC06F628CE5D8E5BC9B1E91173F46DBA2C251&profile=pass

It takes a long time to open the stream, after about 4 seconds it does open and plays fine. In the TVH log I can see that it tries to open the stream multiple times and closes all but one. In the log I see:
Code:
2015-07-04 22:57:34.824 mpegts: udp://239.192.4.104:6208 in IPTV network - tuning on IPTV

2015-07-04 22:57:34.824 subscription: 00D4: "HTTP" subscribing on channel "4 - RTL 4", weight: 100, adapter: "IPTV", network: "IPTV network", mux: "udp://239.192.4.104:6208", provider: "BCE", service: "RTL 4", profile="pass", hostname="192.168.1.105", client="Kodi/15.0-RC1 (Macintosh; Intel Mac OS X 10_10_3) App_Bitness/64 Version/15.0-RC1-Git:2015-07-02-9ff25f8"

2015-07-04 22:57:34.900 subscription: 00D4: "HTTP" unsubscribing from "4 - RTL 4", hostname="192.168.1.105", username="Kodi/15.0-RC1 (Macintosh; Intel Mac OS X 10_10_3) App_Bitness/64 Version/15.0-RC1-Git:2015-07-02-9ff25f8"

2015-07-04 22:57:34.908 mpegts: udp://239.192.4.104:6208 in IPTV network - tuning on IPTV

2015-07-04 22:57:34.908 subscription: 00D5: "HTTP" subscribing on channel "4 - RTL 4", weight: 100, adapter: "IPTV", network: "IPTV network", mux: "udp://239.192.4.104:6208", provider: "BCE", service: "RTL 4", profile="pass", hostname="192.168.1.105", client="Kodi/15.0-RC1 (Macintosh; Intel Mac OS X 10_10_3) App_Bitness/64 Version/15.0-RC1-Git:2015-07-02-9ff25f8"

2015-07-04 22:57:34.931 subscription: 00D6: "HTTP" subscribing on channel "4 - RTL 4", weight: 100, adapter: "IPTV", network: "IPTV network", mux: "udp://239.192.4.104:6208", provider: "BCE", service: "RTL 4", profile="pass", hostname="192.168.1.105", client="Kodi/15.0-RC1 (Macintosh; Intel Mac OS X 10_10_3) App_Bitness/64 Version/15.0-RC1-Git:2015-07-02-9ff25f8"

2015-07-04 22:57:34.963 subscription: 00D5: "HTTP" unsubscribing from "4 - RTL 4", hostname="192.168.1.105", username="Kodi/15.0-RC1 (Macintosh; Intel Mac OS X 10_10_3) App_Bitness/64 Version/15.0-RC1-Git:2015-07-02-9ff25f8"

2015-07-04 22:57:38.672 subscription: 00D6: "HTTP" unsubscribing from "4 - RTL 4", hostname="192.168.1.105", username="Kodi/15.0-RC1 (Macintosh; Intel Mac OS X 10_10_3) App_Bitness/64 Version/15.0-RC1-Git:2015-07-02-9ff25f8"
The final unsubscribe is me stopping the stream in Kodi.

When I load this .m3u file in VLC and start the same channel it starts within a second and I can see in the TVH log that it only subscribes once.
Code:
22:54:11.334 mpegts: udp://239.192.4.104:6208 in IPTV network - tuning on IPTV

2015-07-04 22:54:11.334 subscription: 00D3: "HTTP" subscribing on channel "4 - RTL 4", weight: 100, adapter: "IPTV", network: "IPTV network", mux: "udp://239.192.4.104:6208", provider: "BCE", service: "RTL 4", profile="pass", hostname="192.168.1.105", client="VLC/2.1.5 LibVLC/2.1.5"

2015-07-04 22:54:13.509 subscription: 00D3: "HTTP" unsubscribing from "4 - RTL 4", hostname="192.168.1.105", username="VLC/2.1.5 LibVLC/2.1.5"

The unsubscribe is me stopping the stream in VLC.

Do you guys understand what is going on and how to fix it?

If needed I can supply more logs from both Kodi and TVH.

Thnanks!
You'll have to post a debug log (wiki).
(2015-07-05, 10:12)negge Wrote: [ -> ]You'll have to post a debug log (wiki).

Debug log can be found here
http://pastebin.com/YF49P5Yp
What version of tvheadend are you using?
For the record, the fact that Kodi subscribes multiple times is normal. tvheadend returns bad video though which is why it takes a long time to start streaming something. Most of these issues should be fixed already if you use tvheadend 4.0.x.
(2015-07-06, 09:38)negge Wrote: [ -> ]For the record, the fact that Kodi subscribes multiple times is normal. tvheadend returns bad video though which is why it takes a long time to start streaming something. Most of these issues should be fixed already if you use tvheadend 4.0.x.

I am using HTS Tvheadend 4.1-167~g5cc3717, rather up to date I would say.

I have tried it using a different TVH server (also serving IPTV streams). Exactly the same behaviour: VLC starts playing within one second and only subscribes once. Kodi takes more than 3 seconds and subscribes multiple times.

Would a TVH debug log help?
The stream is broken in the beginning, that's why Kodi takes a long time to analyze the file (the resolution metadata is missing for example). I don't know how VLC copes with this, but the data from tvheadend is definitely broken. Can you file a bug report on tvheadend.org? This issue should have been fixed a long time ago.
(2015-07-06, 14:01)negge Wrote: [ -> ]The stream is broken in the beginning, that's why Kodi takes a long time to analyze the file (the resolution metadata is missing for example). I don't know how VLC copes with this, but the data from tvheadend is definitely broken. Can you file a bug report on tvheadend.org? This issue should have been fixed a long time ago.

Thanks for figuring this one out. Issue is created at the TVH forum:
https://tvheadend.org/issues/2998
If I create a test build for you tomorrow where the analyze duration is slightly increased, could you retry with HTTP pass and check if the delay is gone?
(2015-07-06, 23:10)negge Wrote: [ -> ]If I create a test build for you tomorrow where the analyze duration is slightly increased, could you retry with HTTP pass and check if the delay is gone?

Of course I'll try that, just let me know when you have the test version available.

Cheers
(2015-07-06, 23:10)negge Wrote: [ -> ]If I create a test build for you tomorrow where the analyze duration is slightly increased, could you retry with HTTP pass and check if the delay is gone?

@negge, any news on this? Can I try something?
Sorry, I won't be home until next week.