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.
You can also create the mediainfo-output of the affected media file on the OSMC device:
login via SSH, user osmc, password osmc
if not already installed: sudo apt-get update && sudo apt-get install mediainfo
cdto the directory containing the video/audio material in question
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
upload the decoded media information using mediainfo purgeme.bin|paste-log
publish the returned URL here in this topic
remove the created media file snippet rm purgeme.bin
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: https://paste.osmc.tv/omisevorat
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 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.
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.
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.
The decoder then uses the following calculation: am_private->video_rate = 0.5 + (float)UNIT_FREQ * hints.fpsscale / hints.fpsrate;
i.e.
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: vero3-112-add-fallback-fps-when-hints-missing.patch
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.
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?)
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.
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.
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).
