I have same issue (without wireguard) like in this thread with a RPi4: Raspberry pi 3b hangs with Libreelec 11.0.4 and Wireguard
After Libreelec 11.0.3 version when I start a second video from NFS share the interface freeze and not respond anymore.
I have attached the debug log.
RPi4 NFS playing hangs after 11.0.3
-
aiyyo -
February 1, 2024 at 11:32 AM -
Thread is Unresolved
-
-
Try the latest LE 12 nightly.
-
updated to the latest version (LibreELEC 12.0), but the problem still persists.
-
Thanks. Disable DRM Prime.
-
If I turn it off, then every movie stutters.
-
Code
2024-02-01 12:10:59.082 T:867 debug <general>: ActiveAE - start sync of audio stream 2024-02-01 12:10:59.208 T:867 debug <general>: ActiveAE::SyncStream - average error of 18.539941, start adjusting 2024-02-01 12:10:59.208 T:867 debug <general>: ActiveAE::SyncStream - average error 0.539941 below threshold of 30.000000 2024-02-01 12:10:59.579 T:996 warning <general>: OutputPicture - timeout waiting for buffer 2024-02-01 12:11:07.902 T:997 info <general>: Skipped 154 duplicate messages.. 2024-02-01 12:11:07.902 T:997 info <general>: CVideoPlayerAudio::Process - stream stalled
Do you have the issue with and without audio pass-through?
-
Yes I have. Passthrough was off. I switched on but same problem.
-
LE12 now supports configuration of the NFS chunk size; see if adjusting it up/down makes a difference?
-
I tried it a bit, and it turned out that there is no such freezing with the default Estuary skin. I use Estuary Mod v2.
Something with the skin and the LE above version 11.0.3 is causing the problem. -
The default skin probably uses less RAM, resulting in more RAM for NFS chunk/cache (use top on SSH to find out).
You can play around with NFS chunk/cache size, or you can create a swap file to emulate more RAM.
I think there is something wrong with the new default settings for NFS. It now uses too much RAM:
-
That's best reported to the skin developers via Kodi forums. I'd guess there's something not updated in the skin for Omega final.
-
If it works in one skin and not the other, it's a skin problem. Swapfiles will not be the solution.
-
I'd guess there's something not updated in the skin for Omega final.
I'm the maintainer of the skin. As I can say the skin is up to date for omega . But the skin itself is indeed more memory invasive then the plain estuary. Maybe reducing the chunk size can solve this problem. The relevant code snippets from log are already posted here in this thread (#6, #10)
-
I tried to reduce the chunk size, but it didn't help. I think something has changed in Kodi or LE, because I can reproduce the error with every version above 11.0.3, while using the same skin version.
-
Small cache (64MB) and ‘Adaptive’, small chunk size (32kb) and NFS version 4 seems to solve my network problems with two Synology NAS (and I need to have both on, although that may have been fixed during betas).
-
I haven't made any progress with this, despite adjusting the cache/nfs settings. I've created two new logs with LE 12. One uses the standard Estuary skin, the other the Estuary Mod v2 skin. Just search for the term '409.mkv'.
The same issue is discussed in this thread: RE: RPI4 - Constant freezing/crashing after upgrade from LE 11.0.1 to 11.0.6 -
You still have a memory problem on the Estuary Mod log:
Code
Display More2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] V4L2 poll output empty 2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] In pkt PTS=792000, DTS=792000, track=22, n=22 2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] --- output pre VIDIOC_QBUF: index 0, ts=0.000022 count=0 2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] --- output VIDIOC_QBUF: index 0, ts=0.000022 count=1 2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] V4L2 poll capture ret=1, timeout=5, events=0x41, revents=0x41 2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] Out frame PTS=250000/-9223372036854775808, DTS=209000, track=8, n=8 2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] pts_stats_add: decoder: New interval: 42000->41000/1=41000 2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] Out PTS=250000/250000, DTS=250000 2024-05-12 12:01:20.800 T:1153 debug <general>: ffmpeg[0x9ef7b50]: [h264_v4l2m2m] Pending=11, src_rv=0, req_pkt=3 2024-05-12 12:01:20.840 T:1048 debug <general>: ffmpeg[0x0]: [h264_v4l2m2m] capture: Buffer requeue 2024-05-12 12:01:20.841 T:1048 debug <general>: ffmpeg[0x0]: [h264_v4l2m2m] --- capture VIDIOC_QBUF: index 0, ts=0.000001 count=14 2024-05-12 12:01:20.847 T:1055 debug <general>: ActiveAE::SyncStream - average error of 26.704124, start adjusting 2024-05-12 12:01:20.847 T:1055 debug <general>: ActiveAE::SyncStream - average error 0.704124 below threshold of 30.000000
Please try the swap file.
-
-