I use LibreELEC running on an RPi 3 as my primary user interface/client. I have the recording drives mapped as SMB drives from my NextPVR server to the RPi and use advancedsettings.xml with path substitution to redirect the player to access the .ts files directly from the SMB drives rather than via NextPVR's HTTP streaming (in order to get .edl skipping support).
Recently I've been having problems with several recordings where the playback will stall for various lengths of time (from seconds to minutes). Sometimes Kodi will display a Buffering message. Other times it just stalls for a while before beginning playing again. Often this happens during/after a commercial skip or a manual skip forward during playback. So far, I haven't been able to track down the cause. I don't think that it is network/hardware related. It seems more like it is related to the contents of the .ts file because some files will exhibit this problem multiple times during playback and other files will play just fine.
I just updated to the latest LibreELEC Beta (v. 7.95.2) and am still having the problem. When the problem happens, the kodi.log file is showing some/all of these errors:WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
ERROR: Previous line repeats 73 times.
NOTICE: CVideoPlayerAudio::Process - stream stalledAnd when this situation just happened while playing a file, I turned on debugging (at 14:43:42 in the attached kodi-smb.log), continued waiting and watching through a couple of skips, and then zipped the attached logs.
To rule out the LibreELEC/RPi SMB client, I tried switching to NFS. Still the same problems. (see the kodi-nfs.log file)
I'm wondering if anyone else is seeing similar problems or has ideas about where I look next to try to fix the issue(s).
[hr]
I use LibreELEC running on an RPi 3 as my primary user interface/client. I have the recording drives mapped as SMB drives from my NextPVR server to the RPi and use advancedsettings.xml with path substitution to redirect the player to access the .ts files directly from the SMB drives rather than via NextPVR's HTTP streaming (in order to get .edl skipping support).Recently I've been having problems with several recordings where the playback will stall for various lengths of time (from seconds to minutes). Sometimes Kodi will display a Buffering message. Other times it just stalls for a while before beginning playing again. Often this happens during/after a commercial skip or a manual skip forward during playback. So far, I haven't been able to track down the cause. I don't think that it is network/hardware related. It seems more like it is related to the contents of the .ts file because some files will exhibit this problem multiple times during playback and other files will play just fine.
I just updated to the latest LibreELEC Beta (v. 1.95.2) and am still having the problem. When the problem happens, the kodi.log file is showing some/all of these errors:WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
ERROR: Previous line repeats 73 times.
NOTICE: CVideoPlayerAudio::Process - stream stalledAnd when this situation just happened while playing a file, I turned on debugging (at 14:43:42 in the attached kodi-smb.log), continued waiting and watching through a couple of skips, and then zipped the attached logs.To rule out the LibreELEC/RPi SMB client, I tried switching to NFS. Still the same problems. (see the kodi-nfs.log file)
I'm wondering if anyone else is seeing similar problems or has ideas about where I look next to try to fix the issue(s).
Another discovery: During automatic commercial skipping, if I display the timeline on the screen while playback is "stalled", it shows the current position proceeding through commercial section in real-time (while the audio and video are black). And then when it gets to the end of the commercial section, there is a brief "stutter" and then playback continues normally.