Advice on diagnosing PVR playback issues on some videos

I’m using osmc with the mythtv pvr add on and most of the time things work very well indeed. I have a couple of recordings that will not play on the RP3 frontend running osmc, but play fine on kodi with the same version on other platforms like my laptop running linux.

Is there any general process someone can point me at to run through to try and diagnose these types of problem? I’m hapyy enough looking and trying stuff out, but I’m not sure where to start. At the moment when I play one of these recordings, I get ‘Working’ but that persists and never comes back.

Are they using the same encodings?
Provide mediainfo of the files that don’t work.

It would be good if we could find out more about the file you are having issues playing. Please see the mediainfo section in How to submit a useful support request - General - OSMC.

You can also create the mediainfo-output of the affected media file on the OSMC device:

  1. login via SSH, user osmc, password osmc
  2. if not already installed: sudo apt-get update && sudo apt-get install mediainfo
  3. cdto the directory containing the video/audio material in question
  4. since mediainfoonly needs to read the header information of the file data, copy the first 4 Mbytes of the media file to a new file:
    dd if="<media file>" of=purgeme.bin bs=1024 count=4096
  5. upload the decoded media information using
    mediainfo purgeme.bin|paste-log
  6. publish the returned URL here in this topic
  7. remove the created media file snippet
    rm purgeme.bin

Thx for your help.

Thanks for the very fast response - a great starting point for me. With the mythtv server serving up the recordings to osmc, these are not quite like playing regular files. But I know how to track down the files that myth stores the recordings in and for one of these problem recordings, the paste-log is here:

another problematic one is here:

A good one that plays fine (and 99% of the recordings play OK) is here:

So if you copy the files to the Pi and play them locally instead of stream via myth does it work?

Overall the video codec info seems identical. The only difference I see is the missing “menu” entry from the two problematic ones. Not sure what this is about seems that myth adds.

I thin next step is to enable debug logs in kodi and myth addon and upload logs.

I have similar issues with TVheadend. My profile is set to passthrough so my central server stores .ts files. Most of the time they are fine. Occasionally there will be a random recording that will not play on an OSMC Pi but it will play on a Vero (my Pi uses MMAL as OMX has issues). The playback seems to be corrupt on start and then it does not recover.

But then last night I found the opposite. A .ts file (a BBC1 HD recording) would not play properly on a Vero but it was fine on the Pi. On the Vero the audio was ok but the video was a series of choppy still frames. However, I dropped the .ts file into MKVToolNix and remux’d it to mkv, and it played perfectly on the Vero. All my OSMC boxes are running the latest official OSMC.

I suppose I could change my TVHeadend profile to record to mkv directly and see if these issues go away. But there does seem to be an inherent fragility with .ts recordings where occasionally playback with trip up at the start and not recover, and I can’t see a pattern in terms of when it will trip up a Pi vs when it will trip up a Vero.

I mounted the remote drive mythtv uses onto the osmc PI3 and played the files from that and they work just fine. So it sounds to be something about the way the mythtv addon tries to deliver the stream to osmc.

I will enable the debug logs as suggested and turn on the same in the myth addon and see what I can get. I’m out for a couple of days, so I’ll crack on when I get back.

I am not alone then :slight_smile:

I have this very same problem on my vero4k+

Also reported here along with a debug log:

I looked into this a little yesterday, and in my case the problem is that kodi fails to read the fps rate from the file and ends up passing along a hint of 90000fps to the aml decoder.

I managed to fix this yesterday with an adjustment to one of the existing osmc patches…which makes it fallback to the monitor refreshrate if it does not get a sensible hint (i.e if it receives a hint >120fps). Happy to share my vero patch if anyone is interested? Dont know about the rpi problems. I have an rpi3 myself but dont have same problems, even with a ‘problematic’ recording.

There is a fallback frame rate already for some instances. It’s possible that needs tweaking

I noticed that the framerate mediainfo for the recording that tripped up my Vero the other day changes after the .ts file is remux’d to mkv.


Frame rate                               : 25.000 FPS


Frame rate mode                          : Variable
Frame rate                               : 29.880 FPS
Original frame rate                      : 25.000 FPS

The mkv version plays perfectly with a reported playback framerate according to Kodi of 25fps (correct for a UK Freeview recording).

I think only around 5% of recordings have this problem - it’s not rare, but definitely just common enough to be annoying. At least remuxing seems to salvage them.

I guess the root cause is not the fault of OSMC but if anything can be done to build in further resilience that would be great.

That’s presicesly what I found.

Over the past few weeks I’ve kept hold of a few tvheadend recordings (.ts files) which don’t playback properly on the vero4k+, but play fine on other platforms.

An example debug log can be found here:

For all the recordings which don’t playback I can see the following from a kodi debug logfile:

Kodi fails to read the framerate:

DEBUG: ffmpeg[DF8822F0]: [mpegts] Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified size
DEBUG: ffmpeg[DF8822F0]: [mpegts] Consider increasing the value for the 'analyzeduration' and 'probesize' options
DEBUG: Open - av_find_stream_info finished
INFO: ffmpeg[DF8822F0]: Input #0, mpegts, from '/mnt/mediapc/tvshows/Emmerdale_2019-02-07_sample.ts':
INFO: ffmpeg[DF8822F0]:   Duration: 00:01:00.42, start: 1.400000, bitrate: 7894 kb/s
INFO: ffmpeg[DF8822F0]:   Program 1
INFO: ffmpeg[DF8822F0]:     Metadata:
INFO: ffmpeg[DF8822F0]:       service_name    : Service01
INFO: ffmpeg[DF8822F0]:       service_provider: FFmpeg
INFO: ffmpeg[DF8822F0]:     Stream #0:0[0x100]: Video: h264 ([27][0][0][0] / 0x001B), none, 90k tbr, 90k tbn, 180k tbc
INFO: ffmpeg[DF8822F0]:     Stream #0:1[0x101](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 192 kb/s

In turn, this causes a hint of 90,000fps to be passed along to the AML decoder:

CAMLCodec::OpenDecoder hints.width(1920), hints.height(1080), hints.codec(27), hints.codec_tag(27)
CAMLCodec::OpenDecoder hints.fpsrate(90000), hints.fpsscale(1), video_rate(1), hints.bitsperpixel(8)
CAMLCodec::OpenDecoder hints.aspect(1.777778), video_ratio.num(1), video_ratio.den(1)
CAMLCodec::OpenDecoder hints.orientation(0), hints.forced_aspect(0), hints.extrasize(44)

i.e. fpsrate=90000 fpsscale=1

The decoder then uses the following calculation:
am_private->video_rate = 0.5 + (float)UNIT_FREQ * hints.fpsscale / hints.fpsrate;

0.5 + 96000 * 90000 / 1

This results in a video_rate of 1! which basically leads to an unwatchable file. The exact same is true for all the dodgy tvheadend recordings which I’ve been keeping hold of (they all result in the decoder hint being set to 90000 fps).

It looks like there is indeed a fallback set by:

Which sets the decoder to 30fps in situations where no hints are being passed to the decoder.

However, the problem here is that an unreasonable hint (90,000fps) is being passed along.

I tried tweaking patch 112 over the weekend and this does the trick:

This modified version of the patch also uses the fallback when a hint >120fps is sent along (AFAIK that is the highest frame rate possible).

As the fallback, rather than using 30fps, it uses the current (gui) refresh rate.

This resolved the problem for me, and all the dodgy recordings I have stored up now playback perfect (Note: I have my GUI refresh rate set to 50fps).

@ac16161 if you could also post a debug log from playing back a problematic recording on the vero, then we’d be able to see whether you have the same problem as me.

A few logs in case helpful. This is a BBC1 HD recording of Would I Lie To You.

Failed playback of the source .ts file on the Vero (audio with choppy, unwatchable video)

Successful playback of the same file on an OSMC Pi (I’m not an expert, but it looks like problems are noted in the log but a workable fallback approach is found?)

Successful playback on the Vero of the .ts file remux’d to mkv

And here is an example of where .ts playback fails the other way round, I had an episode of Death in Paradise that fails to play on an OSMC Pi, there is just screen corruption and nothing thereafter, whereas on the Vero the episode plays fine.

Failed playback on Pi (Windows VLC player 3.0.6 also fails on this file):

Successful playback on Vero:

As with the other problem recording, remuxing to mkv enables playback on the devices that could not otherwise play the .ts file.

For this one

It’s exactly the same as the problem I’m seeing - i.e. the framerate hint is 90,000fps (180,000 / 2)

DEBUG: CAMLCodec::OpenDecoder hints.width(1920), hints.height(1080), hints.codec(28), hints.codec_tag(27)
DEBUG: CAMLCodec::OpenDecoder hints.fpsrate(180000), hints.fpsscale(2), video_rate(1), hints.bitsperpixel(8)
DEBUG: CAMLCodec::OpenDecoder hints.aspect(1.777778), video_ratio.num(1), video_ratio.den(1)
DEBUG: CAMLCodec::OpenDecoder hints.orientation(0), hints.forced_aspect(0), hints.extrasize(120)

With my pull request merged, the h/w decoder would have played back using your default (gui) refresh rate rather than 90,000fps.

I don’t have a test environment on which to further diagnose your Pi issue (I don’t use OSMC on my Pi), so I can only advise on the vero issue.

This looks like a TVHeadend bug, but there should be a suitable workaround.


I’m inclined to agree, though querying the file using standalone ffmpeg (v3.2.12-1~deb9u1) reports the correct fps rate:

Input #0, mpegts, from 'Emmerdale_2019-02-07.ts':
  Duration: 00:35:59.70, start: 79069.492711, bitrate: 7707 kb/s
  Program 21040
      service_name    : ITV HD
      service_provider: BSkyB
    Stream #0:0[0x906]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x909](NAR): Audio: mp3 ([4][0][0][0] / 0x0004), 0 channels
    Stream #0:2[0x91a](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
    Stream #0:3[0x907](eng): Audio: ac3 (0x05 / 0x35307830), 48000 Hz, stereo, fltp, 192 kb/s
    Stream #0:4[0x908](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006)

So equally, it could be an issue with the version of ffmpeg built-in to kodi.

Whatever the cause, it certainly looks like the AML codec code can be tightened up where it receives an invalid fps hint from ffmpeg.

Hopefully my pull request will at least serve as a decent starting point…

Yes – much obliged. I’ll re-work it for v18.


I actually developed it against v18 so should be good to go assuming it reads ok.

No idea if this is helpful, by my LE Pi (still on Krypton) behaves identically to my OSMC Pi - they fail on the same file that the Vero can play, and they can both play the file that the Vero cannot play.

Well this doesn’t sound “identically”. Did you maybe swapped the can and cannot?

I re-read and think it’s correct, but for completeness: among the random recordings that occasionally have playback issues on either a Pi or a Vero (can’t recall a file being a problem for both) I have the following:

an episode of Death in Paradise that will not play on an OSMC Pi or a LE Pi but it will play on a Vero
an episode of Would I Lie To You that won’t play on a Vero but will play on both OSMC and LE Pi’s (see logs above).