#15918 reopened Bugs

Channel start/change delay (PVR IPTV Simple Client)

Reported by: tomov Owned by: FernetMenta
Priority: 4 - Normal
Component: Video playback (inc. audio in video and codecs) Version: 14.2 "Helix" Final
Severity: Normal Keywords: PVR IPTV Simple channel change delay
Cc: negge, FernetMenta, afedchin Blocked By:
Blocking: Platform: All

Description

Instant channel (http stream) load or change on 13.2, up to 15 seconds delay on 14.x

Reproduced the issue on Mac OSX 64bit (13.2 vs 14.x), Openelec 4.0.7 vs 5.x.x x86_64 on Intel NUC and AMD Fusion, Openelec 4.2.1 vs 5.x.x on RPi.

Using http streams only, but the issue does not apply to all http streams.

Http stream with delay, log below (taken from Kodi 14.2)

http://xbmclogs.com/pdntgn7rp

Stream with no delay, log below (taken from Kodi 14.2)

http://xbmclogs.com/poxicso4l

Here are logs for both types of streams from Xbmc 13.2:

log with streams that cause delay in Kodi 14.x, no delay in 13.2

http://xbmclogs.com/pfpzlg9gh

log with streams that don't have delay in both 13.2 and 14.x

http://xbmclogs.com/pmivsthua

Change History (72)

comment:1 Changed at 2015-04-15T09:17:25+01:00 by negge

  • Cc FernetMenta added; xhaggi removed
  • Component changed from PVR (Personal Video Recoder) - core components to Video playback (inc. audio in video and codecs)
  • Owner changed from opdenkamp to FernetMenta

comment:2 Changed at 2015-04-15T19:09:12+01:00 by FernetMenta

please test with nightly. the issue may be fixed already. if not we need to investigate on 15.0 anyway. There won't be any fixes for 14.x

comment:3 Changed at 2015-04-16T08:54:21+01:00 by tomov

tested with kodi-20150416-26ad844-master-x86_64

similar findings as with 14.x:

streams with delay http://xbmclogs.com/p4affas7c

streams without delay http://xbmclogs.com/p3tjerkuk

comment:4 Changed at 2015-04-16T09:10:07+01:00 by negge

This seems to be the relevant part:

09:43:07 T:4576260096   ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for http://xxx.xxx.xxx:80/live?channelId=3&uid=5480&deviceUser=xxx&devicePass=xxx
09:43:07 T:4576260096   DEBUG: CCurlFile::GetMimeType - http://xxx.xxx.xxx:80/live?channelId=3&uid=5480&deviceUser=xxx&devicePass=xxx -> failed

comment:5 Changed at 2015-04-16T14:17:30+01:00 by tomov

thanks for pointing that out. any ideas on a fix ?

comment:6 Changed at 2015-04-17T19:48:38+01:00 by FernetMenta

  • Cc afedchin added
  • Status changed from new to assigned

I don't think the iptv source for HRT1 here is legal. If I am wrong, please provide the details.

comment:7 Changed at 2015-04-17T19:55:15+01:00 by tomov

bigtv.rs it is a paid service

comment:8 Changed at 2015-04-17T20:11:04+01:00 by FernetMenta

if the service is supposed to be accessed by a client like kodi, please asked for the specification. with the specification in hand we are able to fix the issue.

comment:9 Changed at 2015-04-17T20:25:20+01:00 by tomov

They support kodi. What specification should I ask ?

comment:10 Changed at 2015-04-17T20:35:58+01:00 by FernetMenta

as mentioned above, there is a timeout responsible for this issue. we request the http header in order to get mime type and got no response

09:42:51 T:4576260096 ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for http://xxx.xxx.xxx:80/live?channelId=2&uid=5480&deviceUser=xxx&devicePass=xxx

why do they not reply to this request?

comment:11 Changed at 2015-04-18T16:28:40+01:00 by tomov

will forward this

comment:12 Changed at 2015-04-29T13:23:04+01:00 by tomov

I still didn't get answer from them. Just for the info, is that the server misconfiguration problem ? Why wasn't that a problem with Gotham ?

comment:13 Changed at 2015-04-29T13:53:33+01:00 by negge

The log from Gotham says:

DEBUG: opening live stream on url 'http://xxx.dyndns.tv/stream/?ID=HRT1-xxx'

while the log from Helix says:

DEBUG: opening live stream on url 'http://xxx.dyndns.tv/stream/?ID='

Have you edited the logs manually or is the URL really different in the logs?

comment:14 Changed at 2015-04-29T13:57:18+01:00 by tomov

Editing mistake I guess. The streams are the same links.

comment:15 Changed at 2015-05-05T09:47:39+01:00 by NGC3144

There are my logs with the same issue

-v13.2 NO delay -> http://xbmclogs.com/p3bp24eig

-v14.2 WITH delay -> http://xbmclogs.com/pk3758oz7

Last edited at 2015-05-05T09:55:20+01:00 by NGC3144 (previous) (diff)

comment:16 Changed at 2015-05-05T10:05:57+01:00 by negge

Does the same delay occur if you play the stream directly in Kodi (using a .strm file) instead of going through pvr.iptvsimple?

comment:17 Changed at 2015-05-05T10:47:52+01:00 by NGC3144

yep, same error in logs also using strm files.

comment:18 Changed at 2015-05-05T10:49:15+01:00 by negge

@FernetMenta any more suggestions for these guys?

comment:19 Changed at 2015-05-07T07:55:03+01:00 by danyus

I want to report same situation as already reported by others. With xbmc 13.2 i start my iptv without any delay(this should be reproduced on android and OSX even if i'm testing in Windows).

It takes exactly 10 sec(in addition to normal timeload) to start on kodi while it's almost instant on XBMC 13.2. It's not a server side problem, cause i'm using many servers(private and public) to reproduce this annoying bug.

Here my logs:

XBMC 13.2 log WITHOUT delay http://xbmclogs.com/pwuxbrhei

KODI 14.2 log WITH delay http://xbmclogs.com/pv9yeb8up

KODI 15 (may 6 nightly) log WITH delay http://xbmclogs.com/psymoh7hi

If it should be useful to isolate the problem i found another addon from other developer, very similar to IPTV SIMPLE CLIENT (named pvr.ztv). It has 2 versions of addon (one for xbmc, other for kodi). None of them report this delay annoying problem. It's based off pvr demo client like as "iptv simple client", and it's open source(of course), so i guess it should be useful.

I don't want to spam so i don't give public links (for now), but if you want just google for pvr.ztv

Last edited at 2015-05-07T08:09:08+01:00 by danyus (previous) (diff)

comment:20 Changed at 2015-05-07T09:26:36+01:00 by tomov

pvr.ztv is unfortunately windows only so I can not test it myself. Hopefully it will help developers solve this annoying problem

comment:21 Changed at 2015-05-07T09:41:24+01:00 by negge

The only relevant difference I can see is that pvr.ztv sets PVR_CHANNEL::strInputFormat to "video/x-mpegts" while pvr.iptvsimple doesn't set it at all. The latter is the correct behavior since not everything is MPEG-TS, which would indicate that the problem is that the server that hosts the video doesn't set the Content-Type on responses.

comment:22 follow-up: Changed at 2015-05-07T09:48:27+01:00 by danyus

OK that should be why pvr.ztv doesn't have the problem. But how the problem should be server side if not present in xbmc?

comment:23 in reply to: ↑ 22 ; follow-up: Changed at 2015-05-07T10:08:17+01:00 by danyus

Analyzing logs, i see KODI 14(and 15) try to GetMimeType , but don't recognize the format server side, and after a timeout(of 10 sec) they go to default, USING CACHE and then start.

XBMC 13.2 doesn't try to GetMimeType so start the stream directly using cache and so without delay.

Could be a solution reduce timeout (for GetMimeType ) to 1 sec or less?

comment:24 in reply to: ↑ 23 Changed at 2015-05-07T10:22:51+01:00 by danyus

It should be SIMPLE and USEFUL if you just add something like this:

"checkMimeType = true|false" giving the chance to use the "getmimetype" or not

or even

"checkMimeTimeout = XXXms" setting the timeout to minimum for not impacting the start of a stream

i guess it should be simple and it should solve the problem.

comment:25 Changed at 2015-05-07T13:01:08+01:00 by negge

Looking at one of the logs from the first post again it looks like the servers you're using doesn't support the HEAD HTTP method, which is why CCurlFile::Stat fails.

comment:26 follow-up: Changed at 2015-05-07T14:50:51+01:00 by FernetMenta

We would need some API method to disable http HEAD requests.

comment:27 in reply to: ↑ 26 ; follow-up: Changed at 2015-05-07T15:29:26+01:00 by danyus

Replying to FernetMenta:

We would need some API method to disable http HEAD requests.

instead of disabling http head request (best solution for me), you should add a form or give user the choice of mime type. Just to let you understand me, if i had the chance to set mime type, i choose mpegts and it should work (other addon by other developer work with default set to mpegts), without reaching any kind of timeout, and avoiding delay. If there's no choice by user, the addon works like now (as default)

Last edited at 2015-05-07T15:32:42+01:00 by danyus (previous) (diff)

comment:28 in reply to: ↑ 27 Changed at 2015-05-07T15:48:00+01:00 by FernetMenta

Replying to danyus:

you should add a form or give user the choice of mime type.

This can be done by the addon itself but a mechanism to disable further HEAD requests is still required. HEAD requests are not solely for mime type.

comment:29 follow-up: Changed at 2015-05-07T15:54:06+01:00 by afedchin

@FernetMenta if addon specify mimetype, will the DVDPlayer not make a HEAD request? I understand correctly?

comment:30 Changed at 2015-05-07T16:08:21+01:00 by FernetMenta

Currently there will be a http HEAD request regardless if mime type is set. This is why I said that we would need some API method to instruct player not to do so. Then an addon can set mime type and set the "no HTTP request" flag

comment:31 in reply to: ↑ 29 ; follow-up: Changed at 2015-05-07T16:11:35+01:00 by danyus

Replying to afedchin:

@FernetMenta if addon specify mimetype, will the DVDPlayer not make a HEAD request? I understand correctly?

But for now setting mime type to mpegts(or other by user choice) should be a workaround.... this can be done in ADDON.... is it so?

comment:32 in reply to: ↑ 31 Changed at 2015-05-07T16:22:34+01:00 by afedchin

Replying to danyus:

But for now setting mime type to mpegts(or other by user choice) should be a workaround.... this can be done in ADDON.... is it so?

as FernetMenta said, adding mime type doesn't solve issue.

comment:33 follow-ups: Changed at 2015-05-08T08:02:07+01:00 by negge

If setting the MIME type is not enough then why does that other forked addon work without delay? As far as I can tell that's the only thing it's doing differently.

@afedchin either way it would probably be a good idea to add a "Force MPEG-TS MIME type" toggle option to pvr.iptvsimple since the majority of legit streams (which is the type of streams we want to support) is MPEG-TS.

comment:34 in reply to: ↑ 33 ; follow-up: Changed at 2015-05-08T08:06:23+01:00 by danyus

Replying to negge:

If setting the MIME type is not enough then why does that other forked addon work without delay? As far as I can tell that's the only thing it's doing differently.

@afedchin either way it would probably be a good idea to add a "Force MPEG-TS MIME type" toggle option to pvr.iptvsimple since the majority of legit streams (which is the type of streams we want to support) is MPEG-TS.

i totally agree to this. That's what i was trying to tell

You can call it solution, you can call it "WORKAROUND", but i guess it help most of the users using this addon.

comment:35 in reply to: ↑ 33 Changed at 2015-05-08T08:08:28+01:00 by afedchin

Replying to negge:

If setting the MIME type is not enough then why does that other forked addon work without delay? As far as I can tell that's the only thing it's doing differently.

@afedchin either way it would probably be a good idea to add a "Force MPEG-TS MIME type" toggle option to pvr.iptvsimple since the majority of legit streams (which is the type of streams we want to support) is MPEG-TS.

other forked addon has it's own network lib which it uses to read streams, pvr.iptvsimple doesn't use this functionality.

I'm going to extend #EXTINF and add a 'type' marker to it. The addom will parce it and if it exists add their value to PVR_CHANNEL::strInputFormat. But this will only for J*

comment:36 in reply to: ↑ 34 Changed at 2015-05-08T08:10:40+01:00 by afedchin

Replying to danyus:

i totally agree to this. That's what i was trying to tell

You are trying to tell but aren't trying to understand what this not solves issue.

comment:37 follow-up: Changed at 2015-05-08T08:12:52+01:00 by danyus

i'm sorry. maybe i didn't understand. i was only trying to help.

comment:38 in reply to: ↑ 37 Changed at 2015-05-08T08:21:24+01:00 by afedchin

Replying to danyus:

i'm sorry. maybe i didn't understand. i was only trying to help.

Thank you in any case. Your help is very important for us.

comment:39 Changed at 2015-05-08T08:31:29+01:00 by FernetMenta

@afedchin I think we should add some method to CFileItem to set a flag that request HEAD should be avoided. We can pass this info via a property set on LIstItem

comment:40 follow-up: Changed at 2015-05-08T09:03:33+01:00 by negge

Based on https://github.com/xbmc/xbmc/blob/master/xbmc/FileItem.cpp#L1287 it would seem that setting the "input format" in the addon would make Kodi skip the MIME type detection using CCurlFile::GetMimeType() (which uses Stat(), which fails).

comment:41 in reply to: ↑ 40 Changed at 2015-05-08T09:59:08+01:00 by afedchin

Replying to negge:

Based on https://github.com/xbmc/xbmc/blob/master/xbmc/FileItem.cpp#L1287 it would seem that setting the "input format" in the addon would make Kodi skip the MIME type detection using CCurlFile::GetMimeType() (which uses Stat(), which fails).

this is correct for pvr:// items but not for m_pOtherStream which used with pvr addons like iptvsimple. We need something like this:

diff --git a/xbmc/cores/dvdplayer/DVDInputStreams/DVDFactoryInputStream.cpp b/xbmc/cores/dvdplayer/DVDInputStreams/DVDFactoryInputStream.cpp
index 3bf1016..9dc8ad5 100644
--- a/xbmc/cores/dvdplayer/DVDInputStreams/DVDFactoryInputStream.cpp
+++ b/xbmc/cores/dvdplayer/DVDInputStreams/DVDFactoryInputStream.cpp
@@ -104,6 +104,8 @@ CDVDInputStream* CDVDFactoryInputStream::CreateInputStream(IDVDPlayer* pPlayer,
   {
     if (item.IsType(".m3u8"))
       return new CDVDInputStreamFFmpeg();
+    if (!content.empty() && content != "application/octet-stream")
+      item.SetMimeType(content);
     item.FillInMimeType();
     if (item.GetMimeType() == "application/vnd.apple.mpegurl")
       return new CDVDInputStreamFFmpeg();

in cooperation with setting mime type in addon. But I don't like this hackish way.

comment:42 Changed at 2015-05-08T10:12:30+01:00 by FernetMenta

Again and I mentioned this several times on other discussions too. Pre-setting mime type is no guarantee for skipping HEAD request. Even if you find some code path where this is the case, it might change tomorrow.

comment:43 Changed at 2015-05-08T10:29:09+01:00 by negge

@afedchin all addons use pvr:// URLs. Once the URL has been opened, m_pOtherStream is opened and the same code path is taken again. At least that's how I read it. If what you're saying is true then InputFormat() never had any relevance.

comment:44 Changed at 2015-05-15T06:54:32+01:00 by FernetMenta

@afedchin with this change you can instruct player not to request header: https://github.com/FernetMenta/xbmc/commit/d9f56cf0b5c4be8f28c11982d7a6e5825b024829

comment:45 Changed at 2015-05-15T08:40:03+01:00 by afedchin

@FernetMenta, great job! But I still have a couple questions:

  1. if addon doesn't specify mime type of PVR channel (current pvr.iptvsimple behavior) here https://github.com/FernetMenta/xbmc/blob/d9f56cf0b5c4be8f28c11982d7a6e5825b024829/xbmc/cores/dvdplayer/DVDInputStreams/DVDFactoryInputStream.cpp#L47 the content variable alway has "application/octet-stream" value. Setting mime type via item.SetMimeType(content) will cause the method item.FillInMimeType() to do nothing (doesn't matter the contentlookup's value).
  2. How can I instruct player from the addon to not request header? All what I can do are define properties of PVR_CHANNEL struct.

comment:46 Changed at 2015-05-15T08:58:57+01:00 by FernetMenta

1) item.FillMimeType will set will do the lookup dependent on contentlookups value. What exactly is the problem here?

2) there are various ways to do so. One could be to set m_contentLookup to false in CDVDInputStreamPVRManager::Open. MAybe it makes sense to add a method to PVRFile and call that from Open()

Note that I have updated the commit. It floats on top of my master branch.

comment:47 Changed at 2015-05-15T09:12:19+01:00 by afedchin

1) The problem is here https://github.com/FernetMenta/xbmc/blob/master/xbmc/FileItem.cpp#L1282. if mime type is already set, FillInMimeType will do nothing. Considering what I wrote above the call item.SetMimeType(content) method will cause the method item.FillInMimeType() to do nothing.

2) Yea, inside CDVDInputStreamPVRManager I can do that, but I have no access to it from the pvr addon.

P.S. maybe my english doesn't allow me to understand your comments in full and bring my point to you.

comment:48 Changed at 2015-05-15T09:37:28+01:00 by FernetMenta

1) ahh, I missed this. That condition should go away now

2) PVRFile can call a method of the addon like it does for i.e. CanRecord

But imo a cleaner way is to set ContentLookup in FileItem. Currently this returns always true. CPVRManager::PlayMedia could call pvrItem.SetConentLookup(false). Not sure how exactly channel switching worlks for your addon. We may need to add this to some other place as well.

comment:49 Changed at 2015-05-15T09:46:18+01:00 by afedchin

2) I think we must summon someone who knows pvr part better than we do

comment:50 Changed at 2015-05-18T07:38:16+01:00 by danyus

i report my new tests and feedback. Maybe it should be useful: I tested a iptv source with two extensions(mimetype) (same source - 2 differents way) If i use mpegsts in xbmc13(as all of you know) i have no delay, in kodi 14-15 it gives 10 sec delay(the famous TIMEOUT) If i use HLS(http live streaming i have the same results everywhere.... 3 sec delay, that means i have a delay vs xbmc(mpegts in xbmc starts immediately), but it starts almosts immediately if you compare it with kodi14-15(mpegts) So if someone has this error and the ticket is still unsolved you should try to change to HLS from MPEGTS(if you can, or ask your supplier)

Now i would like to ask a noob question(SORRY), cause i read your last posts but i didn't understand. Is this ticket still unsolved? It seems to me FernetMenta give addon author(afedchin) the key to solve, adding the chance to instruct the player to not request header. I only would like to know if this is solved(in kodi 15) or will it be unsolvable?

comment:51 Changed at 2015-05-18T13:18:33+01:00 by NGC3144

this is interesting;

-using Kodi 14/15 with a mpegts list there is the delay.

-using Kodi 14/15 with the same list but in HLS there isn't any delay!

Last edited at 2015-05-18T13:18:57+01:00 by NGC3144 (previous) (diff)

comment:52 Changed at 2015-05-18T13:22:02+01:00 by danyus

not exactly any delay.... there's a delay of 2-3sec instead 10sec(caused by timeout)

mpegts on xbmc has no delay at all(it starts immediately). so i prefer mpegts in xbmc cause of no delay at all, but hls should be used with a very small delay in kodi 14/15 if compared to the "10 sec delay" of mpegts

comment:53 Changed at 2015-05-19T12:09:24+01:00 by negge

The way I see it this is what should happen:

a) any stream provider should simply fix their servers so that it accepts and responds to HEAD requests. This is a basic HTTP feature.

b) pvr.iptvsimple should have a global option (that can potentially be overridden per playlist item using tags) for the MIME type, which could even default to video/mp2t since that's what real TV streams use. If someone wants to use the addon with any random collection of streams from the internet that are not MPEG-TS then that's their problem.

comment:54 Changed at 2015-05-19T17:12:36+01:00 by FernetMenta

there are cases where head requests need explicitly disabled for a source. my linked patch allows this for file items. in addition we need a field in pvr channel struct to request this. this is a feature and aüi change, hence not in v15

comment:55 Changed at 2015-06-16T15:18:42+01:00 by tomov

It's been four weeks, what is the verdict guys ?

comment:56 Changed at 2015-06-16T17:04:31+01:00 by FernetMenta

we are working on release of v15 which has higher priority as v16 features

comment:57 Changed at 2015-06-16T17:06:00+01:00 by tomov

does it mean the fix for this problem will be included in v15 ?

comment:58 Changed at 2015-06-16T17:07:51+01:00 by FernetMenta

see comment 54

comment:59 Changed at 2015-06-16T17:09:13+01:00 by tomov

ok thanks, any workaround for 14 and 15 then ?

comment:60 Changed at 2015-06-16T17:10:34+01:00 by FernetMenta

I would fix the server

comment:61 Changed at 2015-06-16T17:11:47+01:00 by tomov

tried to explain this to 2 providers but unfortunately didn't happen...

comment:62 follow-up: Changed at 2015-06-16T17:23:21+01:00 by FernetMenta

do you know how to compile from source? if so I might be able to give you instructions for a quick and dirty hack

comment:63 Changed at 2015-06-16T17:28:34+01:00 by tomov

Thanks but I'm not that proficient. And I would also need to compile Openelec for x86, for rpi, for rpi2 and Kodi for Mac OS X, that is just way too much hassle :(

comment:64 in reply to: ↑ description Changed at 2015-07-06T10:08:42+01:00 by bpalob

OK, take me as the most stupid "user" ever,... but would there be a way to use a content modification proxy to alter the HEAD request? Just a thought,...

comment:65 in reply to: ↑ 62 Changed at 2015-08-31T11:15:38+01:00 by tomov

Replying to FernetMenta:

do you know how to compile from source? if so I might be able to give you instructions for a quick and dirty hack

Hi, still offering help for implementing the hack ? I've set up an ubuntu VM and would like to include this hack in latest Openelec builds for Rpi2 and x86. Thanks in advance

comment:66 follow-up: Changed at 2015-08-31T11:41:30+01:00 by FernetMenta

All required bits are in master. Now addons can make use of: https://github.com/xbmc/xbmc/pull/7757

comment:67 in reply to: ↑ 66 Changed at 2015-08-31T12:06:35+01:00 by tomov

Replying to FernetMenta:

All required bits are in master. Now addons can make use of: https://github.com/xbmc/xbmc/pull/7757

Thanks for pointing that. That means no need for quick and dirty hack you mentioned earlier ? How do I proceed from here then ?

comment:68 Changed at 2015-10-03T21:15:02+01:00 by tomov

Any updates regarding this matter in Jarvis ? I see the feature is still not present in nightlies though

comment:69 Changed at 2015-10-10T09:12:37+01:00 by FernetMenta

  • Resolution set to Fixed
  • Status changed from assigned to closed

The remaining work needs to be done by the addon. Please file an issue there: https://github.com/kodi-pvr/pvr.iptvsimple/issues

comment:70 Changed at 2015-10-12T15:15:56+01:00 by afedchin

Fernet, the iptvsimple doesn't use file operation for channels, it provides a stream url only to the PVR manager through PVR_CHANNEL struct. What should the addon do to avoid header request?

comment:71 Changed at 2015-10-12T18:06:20+01:00 by FernetMenta

  • Resolution Fixed deleted
  • Status changed from closed to reopened

Sorry, my fault. Channels struct in pvr needs an update too.

comment:72 Changed at 2015-12-25T09:29:58Z by phantomfx

I use solution from iptvpanel.net (as iptv management software) and they have implemented HEAD requests. pvr.iptvsipmle works just great. ZAP time is <1s.

Note: See TracTickets for help on using tickets.