This used to play on OSMC 2018.07-1 using Kodi 17.6. With later versions it stutters so badly it is unwatchable. When I first noticed the problem I still had an old SD card with 2018.07-1 installed, so I was able to test the problem happened only on the newer version with no other changes in the environment. It may have worked on some later versions of OSMC as I did not test every one; I think it was some time after after the move to Kodi 18 that I first noticed the problem.
Does anyone know of something that might have changed to make this happen, either in OSMC on in Kodi?
What Sam posted there was hardware specific so it would not apply to a RBPi. I’m sure Google could find a list of hardware decoding specs for your pi. As for your video file that doesn’t play I would recommend turning on debug logging, reboot twice, play this video until it starts to stutter, stop playback, and then upload full logs and post the given url in this thread.
It might be a while before I can get around to doing this. With everyone at home at present, I don’t have much access to the machine and I’ll get complained at if I try to run diagnostics on it. I will get around to it, I just don’t have a timetable at present.
In the current version of OSC (I did an update just before getting these logs) the file stutters right from the start. Here are the logs for this version (OSMC 2020.03-01 Kodi 18.6): https://paste.osmc.tv/yisiyinode.
I also tried again on the old version of OSMC where the file is watchable. Here are the logs from that version (OSMC 2018.07-1 Kodi 17.6): https://paste.osmc.tv/cakosebile.
I had the same problem. Since a recent update, the video playback stuttered and the video paused every few seconds as the buffers ran out. I saw that a kodi process was maxing out one CPU in my Raspberry Pi.
The solution for me was to switch from SMB to NFS. As SMB encrypts the data transfer, maybe that is too much burden for the Pi, but I’m just guessing here.
OMX helps with the video but the audio is output through HDMI instead of HiFi Berry which is the system setting. Is there any way to make OMX use the system setting for audio output?
As the disk containing the files is formatted as HPS+ NFS is not an option. As far as I can tell HFS+ is not compatible with NFS. I’d like to change to NFS, but I’d have to buy a new disk to do that and that is not an option at present.
How does that explain why it works in 2018.07-01 and not in 2020.03-01? Has the system changed in some way which makes it less effective in processing SMB files from an HFS+ disk? All other files work OK; only this one fails to run.
This is probably an indication of my limited understanding of networking, but I don’t see what FUSE has to do with an SMB server. The server might use FUSE (it doesn’t as FUSE is not installed there), but does the SMB client use it to access files from the server?
The first log shows you’re using NFS and the second is using SMB. If NFS doesn’t work properly, surely it makes no sense to use it. Or am I missing something?
No clue, but you were using OMXPlayer on the old version and not the new one and that is why I recommended trying it. If it is only this one file that you have problems with then perhaps you have a problem with this particular encode. You could try remuxing it and if that doesn’t work try reencoding.
The NFS connection is used for the backup script provided by grahamh. Since that doesn’t work over SMB I use an NFS connection to a usb stick formatted as ext4 for those backups.
The wonders of networking! It seems not long ago that I had everything connected using Apple File Protocol (AFP). Now that’s only used for Time Machine backups from an old Mac Mini. The server runs AFP, SMB and NFS for file sharing.
# we search mounts for filesystem types which understand
# linux owners/permissions - add yours if not listed
# !! smb/cifs does not support hard links so cannot be used
# !! even if the backup destination is ext formatted
FSTYPES=(ext xfs reiserfs nfs autofs)
I don’t remember if I tried adding smb/cifs to FSTYPES, but I finished up using NFS because that worked.