HiassofT downloaded the file for me.
I've watched the first 5 minutes and it seems fine (given the approximate nature of checking a dubbed program for lip-sync).
A better sample would help, as well as a description of exactly what's wrong (e.g. at timecode 2m30 character X is seen speaking 2 seconds before audio is heard). But really need a non-dubbed example file.
Might be geo-blocked. I'm in UK and still get Access Denied.
So I give it another try:
Link gives access denied.
A sample file would be https://rodlzdf-a.akamaihd.net/dach/zdf/21/12/211221_2015_sendung_iat/5/211221_2015_sendung_iat_a1a2_3360k_p36v15.mp4
It is an episode of a german tv series "In 80 Tagen um die Welt" and can be downloaded for free from the mediathek of ZDF.
The delay immediately starts at the beginning of the file.
A link would be useful for someone who doesn't speak German and knows nothing of mediathek of ZDF.
I have an ArgonPi One Case (first one with still having two microHDMI instead of regular HDMI), and everything works fine when using LE 9.2.7 (even before with LE 8.X with the same TV, but that might also have been my former RPi3). So I doubt that the issue is hardware (case) related for me, but a kernel / software topic.
Can you confirm if issue still exists when not using the Argon case?
TomTom you log doesn't include the kodi.log or crashlog.
Can you try uploading again, with debug logging enabled, after the crash (and without rebooting).
I suppose it's a Tvheadend / Timeshift issue (currently using addon Tvheadend Server 4.3 (Alpha) 10.80.4.103 but the same with 4.2)
Can you run tvheadend server on a different device and connect tvh client to it over network.
That should narrow down if the issue is in the client or server end.
I find out that the problem only exists with some video files. One of the "bad" files has this parameter:
A sample (e.g. 2 minutes) of that file, assuming it still shows the issue may be useful.
I can't see anything obvious in the codec options.
Only strange thing is the problematic file was 50fps, and the converted file was 29.754fps.
I don't know if you specifically chose that in encode options, or if that was auto detected (which may suggest an issue with timestamps of frames).
Try without the argon case.
A debug log when it happens may be useful.
Identifying the exact nightly build it started would be very useful.
I have an Pi4 with LE9.2.8 and LE10.0.1.
Same TV , same settings.
Do you have any custom hdmi settings in config.txt?
I've been looking at hello_drmprime on GitHub, and it looks like it uses DRM planes instead of drawing to a surface. Should I rewrite my program to match the output process used in hello_drmprime, or is there something else I'm missing?
Outputting directly to a DRM frame is far more efficient and I'd say necessary for 4K performance.
I'd suggest you ask ThePiHut. Personally I'd be surprised if it just works.
All models of RPi2 are 1GB, so I think they will be fine.
Only the Pi0, Pi1 and Pi0 2 have less ram, and so aren't recommended for kodi.
Vimes can you confirm if the black screen shortly after boot issue only occurs with the nightly builds (which use kernel 5.15), or if they also occur with Matrix builds (using kernel 5.10).
I believe I've seen a similar issue on 5.15 kernel, but never on 5.10.
I've set up a LE nightly build to auto-reboot every 2 minutes and unfortunately it ran all day yesterday without showing the issue.
Any info on what makes it occur more often would be useful.
e.g. any non-default config.txt settings, display resolution and refresh rate. Whether it happens on a clean install, or only after libraries/addons are set up.
> Using a local USB HDD (3TB 7200rpm drive), when I jump forward 40min after starting the movie it takes 15 seconds to catch up.
What is the format of the file? For indexed files like mkv, I'd expect this to be much faster.
I typically seek around files with a 1 or 2 second delay (Pi4 using nfs, but I'd expect directly attached disk to typically be better than any network interface).
Non-indexed files (m2ts, dvd/bluray iso or folder structure) can be a lot slower to seek.
Work has just started on optimising VC-1. If anyone wants to provide a sample file (e.g. 1 minute section cut from a currently problematic file), then that will be checked when determining when performance is good enough.
Ideally a harder section from a BluRay (e.g. where bitrate peaks, or we lose audio sync fastest).
Technically this could be implemented by anyone. All relevant code is open source.
But the number of people who are willing and able is small.
