Im retesting 1.30 to see where it fails with The Hitmans Bodyguard
I’m testing 1.30.1 and minions didn’t fail. It just ran off the edge and died (which it would expect)
Would you like me to test 1.30.1 as well. Upon installing 1.30 I got the following error spammed in the log
Dec 19, 2022 23:05:08.768 [0x7fb577373b38] ERROR - [Req#8e62f/Transcode/32qdw1d05n7rzbxhykdnjr20/0ccf8c19-aa55-4587-a5f9-47a8d2b4a507] Error while decoding stream #0:1: No space left on device
I am using /dev/shm for my transcode directory and the system has 256 GB of RAM and is no where near capcity.
I started the movie on two devices my Pixel 7 Pro 1080@8Mbps and Firefox 1080@15 MBps both started buffering and stopped playing at the 11:00 minute mark.
I get that error on sample files which aren’t correctly remuxed.
The instant I remux the file and write proper markers at EOF - it no longer fails.
Also, If I use FFMPEG to cut a smaller sample – No failure.
I am not sure what your last answer implies but I confirm all the files I have been trying to watch recently have TrueHD.
These are mkv files created by saving my BDs with MakeMKV.
These are the full BDRIps ripped using MakeMKV and they dont die at the same area once restarted. The error isnt present in 1.29. Actually as I think about it a little more if the transcoder is haing issues with the EOF markers and the error message is the device is out of space is there an opportunity to make that message articulate a little better whats really going on. Im having a hard time correlating the two things.
I know the problem isn’t present in 1.29 but exists in 1.30 and above.
I apologize if sharing my thought process is confusing.
What I have discovered with one sample last night (which may not be the full root problem) – There was a bad timestamp in the file
I discovered it when I was remuxing the file
ffmpeg -i filename.mkv -c:v copy -c:a copy -c:s copy new-filename.mkv
I was warned of a null timestamp which won’t be supported in future FFMPEG versons.
Upon remuxing the file properly to a 3 minute sample – there was no PMS playback error.
However, using dd to chop off a 3 minute sample – there was an error.
Is this a regression in how it can handle null timestamps in the TrueHD code?
I don’t know.
The implication is that FFMPEG fixed the null timestamp in the sample file as it was writing it out to the new file.
This is where I’m at and trying to find something definitive.
I appreciate you looking into this.
In the meantime, could you please point me to where I could download the 1.29 pkg?
Thanks
Ive remuxed the entire file using ffmpeg as well and that didnt seem to fix the issue. I got the same null timestamp warning as well. I also re-ran it through the latest version of MakeMKV as a test to isolate where the issue was
Screenshots are inadmissible in court 
That’s the error I recreated.
Stay with 1.29.2 please until this is resolved.
For those needing 1.29.2
I’ve the same problem on my synology plex server. anyway to download v1.29 for synology dsm 7 with intel 64bit cpu?
For some reason, Plex doesn’t advertise older versions.
I have a QNAP with a 64-bit intel CPU so it is probably the same.
I was able to download the older version from https://downloads.plex.tv/plex-media-server-new/1.29.2.6364-6d72b0cf6/qnap/PlexMediaServer-1.29.2.6364-6d72b0cf6-x86_64.qpkg
just to be safe, double-check the extension of the package you get for the latest 1.30 and adjust the above url if needed.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
