[asavah]

Background:

My ISP provides IPTV via udp multicast streams.
I use an addon of my own to watch TV, before you ask - no the addon is not guilty of anything, proofs below.

Problem:
When getting streams via udpxy (udp-multicast-to-http proxy) https://github.com/pcherenkov/udpxy or
via msd_lite (same purpose) http://www.netlab.linkpc.net/wiki/en:software:msd:lite
I observed heavy stuttering, frame skips and 100% cpu usage on 1 of the cores, the 100% load seems to jump from one core to another.
I tried all tweaks and tricks known to me to no avail.

Stream url example:
http://nas.kv36.loc:1234/udp/239.2.44.122:1234
Average bitrate for this stream is around 2mbit/s, h264 + mp2 audio, ffprobe output for the streams below.

OMXplayer plays such streams just fine.
Software decoding plays such streams just fine, higher cpu usage, but no stutters or skips, perfectly watchable for SD channels.
MMAL stutters and skips frames, unwatchable.
However MMAL works perfect,like a charm, with "direct" udp mcast urls ie. udp://@239.2.44.122:1234
"Recorded" chunk of the stream plays fine with mmal.

I've played with http://kodi.wiki/view/HOW-TO:Modify_the_video_cache and all known combinations of settings, made no difference, sync to diplay, prefer pts and etc

---------------------------------------------------------------------------------------
Debug logs:

omxplayer http stream:
http://sprunge.us/HBJF

ffmpeg http stream:
http://sprunge.us/ZIUS

mmal http stream (its huge):
part1 http://xbmclogs.com/p1vzpf5kw
part2 http://xbmclogs.com/pna7gqer7

mmal udp multicast stream:
http://xbmclogs.com/pmbfkbfsh
----------------------------------------------------------------------------------------
ffprobe information about the streams:
http:
http://sprunge.us/BjWc

udp multicast:
http://sprunge.us/eJZH
----------------------------------------------------------------------------------------

Raspberry pi 2b, mpeg2 and vc1 codecs purchased.
Kodi was build 11/Jul/2015 from popcornmix/newclock4 branch.

I can use direct mcast with no problems at all, but I considered necessary to report this issue.
If needed I can provide access to proxied streams via PM and even ssh access to the pi.
I can build,patch and do whatever experiments are necessary, however I lack the skills necessary to further debug the issue.

[popcornmix]

A URL I can access to see the problem would be useful. If you can PM me a URL I'll take a look.

[asavah]

Links sent.

Thanks.

[popcornmix]

Can you try pausing for a couple of seconds as soon as playback starts?

I've been talking with FernerMenta and this seems to be a general dvdplayer limitation.
Apart from PVR dvdplayer does not work well with live streams.
There is no mechanism to pre-buffer the stream (as non-live sources can supply data faster than it is played to build up the buffer after playback starts).
It doesn't deal with the fact that the server's clock may run slightly faster/slower than the client's clock and in your case, the audio output buffer is continuously emptying.
Pausing allows some audio/video to buffer up.

The other workaround is to use the http://kodi.wiki/view/Add-on:IPTV_Simple_Client PVR add-on.
Create an m3u file with your streams in and that should handle the differing clocks better.

[asavah]

Thanks for looking into this.
I already have a workaround going, my server api supports a parameter for enabling/disabling the proxy while generating the playlist in JSON format for the addon.
With udp multicast dvdplayer/mmal works flawlessly, and with "sync to display" it's simply a beauty.
I thought there was a possible bug because of huge difference in performance http vs udp mcast so I reported this.

Hmm, just for the experiment's sake of it I think I can increase the buffers on the proxy server, but that would make channel switching slower.

I know about pvr-iptvsimple, was using it, but ran into some issues on pi1 b+ (oom and crash while updating EPG from HUGE xmltv archive),
so I decided to write an addon which actually mimics pvr window, but it's much lighter for the pi because EPG and some other stuff are processed on the beefed up x86 server,
the pi just has to play the content which it does very very well thanks to all the work you, guys, have invested into Kodi.

Thanks again for looking into this.