Choppy playback: asked for new data packet, with nothing available about pvr.hts HOT 33 CLOSED

Radio channels have been problematic with all PVR addons for a while, it has something to do with the way Kodi buffers the data. I'm afraid there's not much we can do about it in the addon.

from pvr.hts.

That's such a shame, is there any other way to fix this? Can we bring it to someones attention?

from pvr.hts.

already adressed in new videoplayer.

from pvr.hts.

@FernetMenta I was hoping you'd say that :-)

from pvr.hts.

I hope I was not too fast. @joshuisman can you provide a debug log?

from pvr.hts.

http://pastebin.com/3ZS1EQGu

Problem was there a few times with the 2nd radio channel; "Love Songs"

from pvr.hts.

Why does this radio channel have a video stream?

21:35:26 T:123145314263040   ERROR: ffmpeg[700000B66000]: [mpeg2video] Invalid frame dimensions 0x0.
21:35:26 T:123145314263040   ERROR: Decode - avcodec_decode_video returned failure

@Jalle19 looks like a tvheadend issue. It opens an invalid video stream.

from pvr.hts.

Since Ziggo was acquired by UPC they started showing video with these "stingray music" channels. It is a static image with the album art and song info.

from pvr.hts.

@joshuisman any chance you could make a mux dump in tvheadend and upload it somewhere? I want to be sure whether this is something we're handling incorrectly in the addon or if it's a tvheadend issue.

from pvr.hts.

@ksooo a semi-ugly workaround could be to ignore any video streams for channels marked as radio. I'm not sure if we have that information available in the demuxer though.

from pvr.hts.

@Jalle19 Sure, here it is: http://we.tl/2B0Pj1z0uB

Shoot, wrong button; re-opened

from pvr.hts.

@joshuisman the file doesn't seem to work (doesn't play in VLC), did you use "Save link as" from the mux link in tvheadend or did you do something else?

from pvr.hts.

I used https://tvheadend.org/projects/tvheadend/wiki/Muxdump

Is it maybe because the stream is encrypted?

from pvr.hts.

Yeah that's definitely it. Can you grab the dump using the channel URL instead so it gets decrypted?

from pvr.hts.

http://we.tl/9dshuGs6SG

from pvr.hts.

Thanks, that one works.

from pvr.hts.

And it works without any issues on VideoPlayer branch. Does it show issues on mainline?

from pvr.hts.

Not sure (just tested in VLC), @joshuisman?

from pvr.hts.

Just tested the file in Kodi RC2, and indeed no issues.

That's the tricky thing about it, sometimes such channels play fine from the very beginning, sometimes not. It is even possible that I start playback and it is fine, I go to the next channel and that one's also playing fine, going back to the previous channel... choppy.

Let me try to make some bigger samples, I'll double it in size, and let's hope there's one that will show the issue.

from pvr.hts.

Just made multiple dumps from different channels. The dumps play fine on both Kodi RC2 and VLC. So it seems the problem doesn't occur when the pvr part of Kodi isn't involved?

I also just tried live playback with url of a radio station in VLC, flawless and I kept it in the background playing. Next I opened Kodi and started playing the same channel; flawless. Stopped playback on Kodi, restarted the same channel; choppy and showing buffering...

from pvr.hts.

@joshuisman the code paths are different when playing a standard file than when playing a PVR channel, that's why it may seem to work when you play a dump file. I don't think there's much we can do about this until @FernetMenta finishes his video player rewrite.

By the way does Kodi display the channel's static image when you play this radio channel or does it show the visualization?

from pvr.hts.

It shows the static image, the video stream. No visualization.

from pvr.hts.

Okay, then the issue is probably the same as other PVR radio related issues. This has been reported earlier at http://forum.kodi.tv/showthread.php?tid=222764 and since it seems to work in the new video player rewrite I'm closing this as a bug in Kodi.

from pvr.hts.

There is more than a single issue and the tvheadend related one should be fixed now. The demuxer must not expose streams with invalid dimensions: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxPVRClient.cpp#L312

from pvr.hts.

@FernetMenta https://github.com/kodi-pvr/pvr.hts/blob/master/src/HTSPDemuxer.cpp#L530 that scenario shouldn't be possible anymore. Are you sure it's not ffmpeg being fooled by the still frame?

from pvr.hts.

Well I was just trying some other radio channels and it seems the affected channels all seem to have one thing in common, encrypted content. Though some channels seem to be more affected than others.

For example RNE Radio is very choppy, both in Kodi and VLC. So I made a dump of that channel. Guess what, perfect playback in VLC. And RNE Radio is an audio stream only, no video.

from pvr.hts.

During my limited testing earlier I think the culprit is channels with very low bitrate. Radio channels that have ~100 kbps or more in bitrate seem to work without buffering.

from pvr.hts.

Are you sure it's not ffmpeg being fooled by the still frame?

@Jalle19 yes I am. I played the sample through vnsi parsers and don't get the decoding error. I am not saying that this is the root cause of this issue but it is an issue that needs to be fixed as well.

from pvr.hts.

The dump file of 60 seconds from RNE Radio is indeed a very small file, 1.3 MB. So that's a low bitrate.

from pvr.hts.

does pressing pause and starting again work for you?

from pvr.hts.

@L-S-D I tried a few times and it seems that "solves" the problem. I'm not sure though, as the playback often picks up the right playback by itself.

from pvr.hts.

Not sure what to do with this one, I'm tempted to close it since radio stuttering has been widely reported as a Kodi issue.

from pvr.hts.

Yeah, definitely closing this, it's been lingering here for too long.

from pvr.hts.