Kodi Community Forum

Full Version: Problems with official and paid and NOT pirated rtp:// IPTV Sources since Kodi 17
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi guys Smile

A while ago i updated my second SD Card to Kodi 17. Meanwhile i went through various Libreelec Alpha Builds and also some Milhouse Builds.
On each of these builds i encountered the same problems with iptv simple PVR.

The IPTV content from my local (official and paid) IPTV Provider which is spread using RTP:// Urls, is
- starting playback a lot slower than on Kodi 16 (doesn't matter if channel is first started or switching from one to another channel) and
- producing green artifacts and stuttering sound from time to time

Each channel source looks like: rtp://@999.9.9.9:8888

I already read that there are significant changes going on regarding librtmp but so far i don't really get it ...
Do my problems have something to do with these changes and/or is there anything i could do, to improve RTP:// playback on Kodi 17?
Or should i just wait for the final stable release?

At the moment my RPi2 is running Libreelec Alpha 7.90.007 and the problems i mentioned don't occur on the same Pi with a Kodi 16 microSD.

I'd also like to share codec info of a HD Source from my local IPTV Provider and some logs. Perhaps this helps in some way?
http://imgur.com/a/wxPFC

ffmpeg component specific log: http://pastebin.com/Eiatp2d2 (sry, had to cut a lot because of pastebin's size maximum)
debug log: http://pastebin.com/iMpN01n3

I'd also like to add, that HLS and other sources are running fine, no matter if Kodi 16 (Libreelec 7.0.2) or Kodi 17 (Libreelec 7.90.007/7.90.008)
It's just the RTP Sources on Kodi 17 Builds, which are producing the issues mentioned above. Kodi 16 (Libreelec 7.0.2) playback of the RTP sources from my provider is fine too.

Thank you very much and keep up the great work, greets Smile
Today i updated to libreelec alpha 7.90.008 and i'm still having the problems mentioned above.
Therefore i'd like to push the topic hoping somebody can give advice Smile

Thanks
Perhaps if you submitted a link to your http://kodi.wiki/view/Debug_log you may get a better response to your problem.
Hello,

I have the same problem with my Raspberry PI 2. The problem can be generated synonymous with the current Windows nightly version. I have a debug log attached.

http://pastebin.com/0SM68iHt
@Dangelus: Good Idea, i'll also perform a debug log and post it here ...
@os299: I'm sorry to hear about you also having problems like that, hopefully the issue can be fixed Smile

edit:
here are my logs:

ffmpeg component specific: http://pastebin.com/Eiatp2d2 (sry, had to cut a lot because of pastebin's size maximum)
debug log: http://pastebin.com/iMpN01n3

Thanks Smile
Moved to OS independent forum as it affects windows and pi platforms.

Have you enabled the inputstream.rtmp add-on?
By default kodi now uses ffmpeg for rtmp but its features are limited.
Using the inputstream.rtmp add-on should give features similar to Jarvis.

A public stream that shows the problem would be useful for devs to look into.
@popcornmix:
First of all it's great to read from you. I didn't expect much focus on this issue any more ...

Unfortunately the streams are paired with the public IP. Only people who purchased the iptv package are able to playback the content.
But i'm able to access the streams also using PC or notebook or any other device within my local network.
So probably i could provide any information which is needed?
----------------------------
I'd like to try your hint regarding rtmp Addon, but i'm not sure which one to install.
Within Libreelec repo there are:
- InputStream MPEG DASH
- InputStream SmoothStreamingMedia
- RTMP Input

I'm not sure which one, but i'll try RTMP Input first ...

Thank you for your help
(2016-11-13, 22:38)nokodemus Wrote: [ -> ]I'm not sure which one, but i'll try RTMP Input first ...

That sounds most likely.
First i tried it with just RTMP Input installed and activated. No success, same problems as before.
Meanwhile i activated all three InputStream related Addons (MPEG Dash, SmootStreaming and RTMP Input) and unfortunately the problems are the same.
I also rebooted after installing the InputStream Addons.

I'm not an expert in log-reading but it isn't it still ffmpeg handling the RTP Streams?
http://pastebin.com/D9jmUiSq

Thank you very much for advice Smile
Can you provide complete log files? There is often relevant information at the start.
Sry, here's another complete debug log starting at boot: http://www.xup.in/dl,14733174/kodi_log
Too big for pastebin ...
first of all. it has nothing to do with rtmp!

second. are you sure your streams have rtp headers ? try udp:// instead of rtp://
I had a closer look and it seems that the issue is related to the iptv simple addon. This addon does not cache the stream. Not caching multicast streams results in packet loss.
Thank you for your thoughts guys Smile

(2016-11-14, 10:38)stefansaraev Wrote: [ -> ]first of all. it has nothing to do with rtmp!

second. are you sure your streams have rtp headers ? try udp:// instead of rtp://
I tried that and streams are accessible using UDP protocol. But playback gets even worse and is also producing artifcats in Kodi 16, which playbacks the RTP sources fine.

(2016-11-14, 11:12)FernetMenta Wrote: [ -> ]maybe related: http://trac.kodi.tv/ticket/17001
(2016-11-14, 11:35)FernetMenta Wrote: [ -> ]I had a closer look and it seems that the issue is related to the iptv simple addon. This addon does not cache the stream. Not caching multicast streams results in packet loss.

Thank you for this hint. Is this the reason, why the PVR advancedsettings "minvideocachelevel" and "minaudiocachelevel" have been dropped since Kodi 17?
Could there be any other way to enforce PVR to do a little caching or should i hope for @afedchin to look after it?

You also wrote that you've tested udp/rtp sources on your own using another addon. Which one did you use?
So i could also test and check if another addon's playback is running fine.

Thank you very much
Pages: 1 2