I run OSMC on an RPi2B.
Running ffprobe (from ffmpeg) on one of my films gives a description of the video stream as:
Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 2874 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
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?
In a separate topic for Vero 4K, Sam provided a list of specifications for video formats supported:
Are these relevant for RPi as well, or is there a separate list for that?
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.
I have now managed to get some logs.
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.
You might try settings>player>videos>
adjust display refresh rate> [on start/stop]
allow hardware acceleration OMXPlayer> [enabled]
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.
Using NFS makes the video playback smooth again.
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.
HFS+ uses FUSE. This will cause a performance impact and could contribute to the stuttering.
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?
I assume you’re talking about HPS+ that is network-attached over on a MacOS box, not on the Pi.
Can you explain this:
From your first log file (the one that’s stuttering):
172.16.1.5:/mnt/TimeMachine/Kodi /mnt/Backup nfs noauto,rw,hard 0 0
From your second log file:
//172.16.1.5/Movies /mnt/Movies cifs x-systemd.automount,nofail,ro,guest,vers=2.0 0 0
//172.16.1.5/Music /mnt/Music cifs x-systemd.automount,nofail,ro,guest,vers=2.0 0 0
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?
Kodi uses more resources with newer versions.
If you’re using a network share, the filesystem won’t matter.
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.
Sorry I meant HFS+ not HPS+.
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.
It should work over SMB. The important thing is the backup drive itself must be ext4.
Here’s an extract from your script:
# 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.
OK, just checked. I can create a hard link through samba so not sure why I said that. It was a while ago so things may have changed in samba.