The service can stop/start Kodi instead of pausing/unpausing it, but that adds ~5sec for Kodi to start back up. It would be better to figure out what the cause of the video playback issues was.
I don’t see any video playback problems even after multiple suspend/resumes. I’m primarily using PlexKodiConnect for video streaming. How are you playing back your content? If it’s a smb, nfs vs https issue, there might be a related service that can be restarted instead of restarting Kodi altogether.
This is the suspend service with kodi restarting. Replace the old service and either reboot or ssh in and run systemctl daemon-reload for the change to take effect. systemd-suspend.service (912 Bytes)
grab the kodi logs after waking from suspend and playing a video
CoreELEC:~ # cat /storage/.kodi/temp/kodi.log | paste
Copy a video file to your CE USB, and play the video locally, to see if playback is smooth. This way we can see if it’s a network-related problem after waking.
Yes that works for restarting Kodi after suspend-to-ram This version of the suspend-to-idle service does stop/start Kodi (restart Kodi), but a restart isn’t as fast as pause/unpause.
I don’t see any playback problems on wakeup, so pause/unpause is doable. If we can narrow down the cause of the video playback problem for those experiencing it, then there may be a cleaner, faster solution than issuing a full kodi restart.
I am using the JellyFin addon and DirectPath, i.e. the files are coming over WiFi via NFS v3. Chunksize is 1M, Buffer 128M, and read speed 4x.
Also I enabled “always” hardware support for all supported codecs (also h.264).
I found that a way to mitigate the stuttering is stopping the video and starting it anew.
I believe that the stuttering is not(!) related to reading the file because I can see that there is plenty of filled buffer available, i.e. the video is not choked by missing video data.
NFS vs HTTP is one difference. Try playing back a local file (from the CE USB), to see if the video playback is smooth compared to the Jellyfin share. That would help verify that it’s a networking problem after wakeup.
Maybe there’s a way to reset the CE Jellyfin connection or restart the addon.
Ok will copy some videos to the SDcard and play directly from there, bypassing the library.
Again, the buffer is solidly filled while the video is stuttering. The player is not(!) waiting for video data to load from the network to be able to play the next frame.
That could only mean that the network activity for keeping the buffer filled is somehow interfering with the playback activity.
I will come back with the results when I had time to do this…
Before you stopped using suspend, were you streaming your videos over SMB, NFS, or HTTP? Trying to narrow down why some see video stuttering after waking from suspend.
A hdd I don’t see slowdowns with that I remember
My iptv service and smb I’ve seen the stutter with
Let me do a series of tests to try to narrow it down if I can
I copied a few videos to /storage/videos. watched a video from there, stopped it, suspended CE, woke up, watched same video → stuttering. stopped video, started it again → no stuttering.
here is no difference in that described behavior, no matter if I watch from NFS or if I watch from local SDcard.
@YadaYada From those experiments on my end nothing points towards some network stuff as the culprit for the stuttering. Maybe we are talking about different things when we say “stuttering”. If i had to describe this in more detail I’d say the player is skipping frames.
Maybe it isn’t related to the suspend idle. I am running the latest -ne nightly on Kinhank G1.
I will now just reboot and watch videos. If the stuttering occurs then it should be unrelated to your service script, right?
Hello, how do I use this script on the Kinhank G1?
I placed the systemd-suspend.service in the correct location, but the machine freezes every time it wakes up from suspend.
If you are having playback problems for local and streamed videos then I think you’re right, it’s not a network issue. How about if you leave the G1 on for +5 hours with no suspend. Do videos eventually begin to show this stuttering behavior?
use the following command to check for frame skipping or frames dropping
CoreELEC:~ # kodi-send --action "PlayerDebug"
The G1 on CE-NE is a different kernel, a different SOC family and a different board configuration, so there’s a lot to account for as possible causes. Does rebooting the G1, waiting a minute, suspending it and waking it 30sec later, still exhibit the same video playback problem? Or is it something that takes time?
Does your kodi log show any errors
CoreELEC:~ # cat /storage/.kodi/temp/kodi.log | paste
But I have a very interesting result: When the player is stuttering (more correctly: it is skipping) and I enable the player debug overlay while it is skipping, then the skipping stops and replay is smooth. When I stop the player debug overlay the skipping continues.
How can this be explained?
(What also helps for a while is stopping the video and starting replay again, but the skipping may come back.)