Kodi Community Forum

Hi to everyone.

Maybe someone had this problem too, and knows hot to solve it (i'm talking about Windows builds).

My ISP provides IPTV via http streams.

I have a playlist (.m3u) of approx. 100 channels, and it opens very hard in XBMC 10 and newer, around 2 mins. More channels the playlist contains, more time XBMC needs to open it.

In XBMC 9.11 there is no such problems

If the playlist contains udp streams it works fine in all versions, but if it's of http streams than it works fine only in 9.11, in version 10 and newer it takes too long to open the playlist.

If someone have also experienced this issue and found the solution, please post it here, thanks.

Try disabling the tag reading if you haven't already - I suspect, though, that it's trying to figure out the type of playlist by checking the content type of the streams.

A debug log might prove informative.

I created a small playlist, with only 7 channels. I opened XBMC and opened the playlist.
Here is a part from the log file

19:57:34 T:3768 M:4294967295 DEBUG: CGUIMediaWindow::GetDirectory (E:\Videos\TV Channels\tvbox_v5.m3u)
19:57:34 T:3768 M:4294967295 DEBUG: ParentPath = [E:\Videos\TV Channels\]
19:57:34 T:3768 M:4294967295 INFO: XCURL:llLibCurlGlobal::easy_aquire - Created session to http://web.tvbox.md
19:57:37 T:3768 M:4294967295 DEBUG: CFileCurl::GetMimeType - http://web.tvbox.md/iptv/1music -> application/octet-stream
19:57:40 T:3768 M:4294967295 DEBUG: CFileCurl::GetMimeType - http://web.tvbox.md/iptv/prime -> application/octet-stream
19:57:43 T:3768 M:4294967295 DEBUG: CFileCurl::GetMimeType - http://web.tvbox.md/iptv/2plus -> application/octet-stream
19:57:46 T:3768 M:4294967295 DEBUG: CFileCurl::GetMimeType - http://web.tvbox.md/iptv/accenttv -> application/octet-stream
19:57:49 T:3768 M:4294967295 DEBUG: CFileCurl::GetMimeType - http://web.tvbox.md/iptv/alttv -> application/octet-stream
19:57:52 T:3768 M:4294967295 DEBUG: CFileCurl::GetMimeType - http://web.tvbox.md/iptv/tvdixi -> application/octet-stream
19:57:55 T:3768 M:4294967295 DEBUG: CFileCurl::GetMimeType - http://web.tvbox.md/iptv/eurotv -> application/octet-stream
19:57:55 T:1672 M:4294967295 DEBUG: thread start, auto delete: 0
19:57:55 T:1672 M:4294967295 DEBUG: Thread 1672 terminating
19:57:55 T:4064 M:4294967295 DEBUG: CImageLoader:oWork - took 173 ms to load special://masterprofile/Thumbnails/8/88ed3607.jpg
19:57:59 T:3768 M:4294967295 DEBUG: SDLKeyboard: scancode: 0, sym: 274, unicode: 0, modifier: 0
19:57:59 T:3768 M:4294967295 DEBUG: CApplication::OnKey: 61480 pressed, action is Down

I noticed it does

"CFileCurl::GetMimeType" (i don't know what this means) to every channel in the playlist, it takes 3 second for one channel, if you have 100 channels you have to wait 5 minutes to open it.

When it finaly opened i select a channel to watch, and the want to return to the playlist, it's doing again the same operation "CFileCurl::GetMimeType", and again you have to wait.

EDIT: Nope, that's not it - will track further.

Ok, the problem is the IsAudio() check in CPlaylistM3U::Load() to see if we can add the duration into the tag. I don't see any reason whatsoever to do this - it provides essentially useless information that should be read by the (backgrounded) tag readers anyway.

Will do up some changes in a branch on my github.

Cheers,
Jonathan

Ok, the real problem is that whenever we do a listing, if you have the advancedsetting <playlistasfolders> enabled (the default), we check whether any playlists exist within the listing. As you are no doubt aware, some http:// URLs can be playlists themselves. Thus, XBMC tries to check the content type of those URLs to determine whether this is the case or not. This takes time, thus the problem you observe.

You could try turning <playlistasfolders> off via advancedsettings.xml - that should give you your speed back. What it will do, however, is make any .m3u or similar in a folder act as a playlist (i.e. immediately start playing) rather than acting as a virtual folder of items.

I shall start a wider discussion about this point - I'm not sure that there's any point in pre-resolving this information before displaying items in the UI.

Cheers,
Jonathan

I disabled the <playlistfolders>, the playlist starts playing immediately the first item and i can just go to the next or previous items, can't see the playlist itself and choose a specific channel.

In the 9.11 version the playlist acts as a folder, but it skips this "scanning thing" that versions starting from 10 do, and opens immediately. Maybe you can fix this. Thanks for you help. For now i'll just have to keep both versions. I found a temporary solution for this, i just create a separate playlist for each channel

Hi, in XBMC 11.0 Eden Beta 3 the issue still persists. Can it be fixed in the future releases?

It still exists in 11.0 final.

I have 200 IPTV streams in a M3U playlists so this is not good for me..

Any workaround? Even if it involves editing the source?