Chipping in here because I have had video buffering issues on my OSMC on a RPi3B device, so I wanted to migrate the install to an RPi4B-8GB device I finally got hold of.
The OSMC box is connected by Ethernet cable to the router, no WiFi involved.
Will the move from RPi3B to RPi4B-8GB improve performance?
I have a 1000/1000 MBps fiber connection so the buffering should not be caused by limited bandwidth, hence I wonder if such a migration will help?
If so, next question:
Does the backup/restore procedure also handle the network connections, i.e. does it transfer the network mounts in /etc/fstab so the sources can be reached? Or do I have to do this manually?
I connect my sources via nfs mounts.
The UI is faster and it has more CPU for anything that is software decoded. It has hardware h.265 decoding that the earlier models don’t. Networking is faster but for playback from ethernet there should have been an issue with the 3B. What kind of encode are you having issues with on your current RPi?
In the My OSMC add-on there is a list of userdata files that can backed up and restored. Whatever is selected for those files is what will be backed up or restored and system mounts, both fstab and autofs are available options.
I regularly download news shows nightly using an Ubuntu server and ffmpeg processing (encoding and reformatting) into mp4 video files. These files play OK the next day, so that is not the issue.
The script line that does the download looks like this:
where I have loaded the variables with actual call parameters. It will re-encode into a specific geometry of 480p and with 1 s frames (in order to make later editing more precise).
But I also have created a set of strm files that are linking to the live sources of these news shows such that I can view the content of the on-line video players in full screen via KODI on OSMC in real life.
And here is where I get the buffering issues from time to time.
So what you are saying gives me the incentive to use an RPi4B-8GB as a replacement device. But I will probably not try to take a backup and restore on the new device since they are so far away in technology.
I can probably re-create the environment manually by copying a few of the kodi userdata files and set up /etc/fstab manually.
One thing I have noted when doing stuff on the command line on the RPi3B device is that there is mention of rpi2b in the list of packages installed, that is probably from an earlier “migration” I have done onto the RPi3B.
So better to have a clean slate here by getting the latest install SDcard and go from there.
The RPi3B is running the absolute latest OSMC, I just checked via MyOSMC and there is no later version available than the 2023-08 I am now running.
That rpi2 reference your seeing is probably just the package name and is making a distinction from the earliest model RPi hardware that are no longer supported due to hardware differences. As for backup/restore all those files are userdata and are platform agnostic with the exception of guisettings.xml. You can clean slate if you want obviously, but you likely have very little to nothing to gain in doing so.
As for the strm files issue with your 3B if your only getting an occasional buffer then that likely isn’t due to a limitation but rather a buffering issue and it may be able to be cured by tweaking Kodi to use a larger cache for video playback. If it was struggling to play back a difficult encode then the video would start dropping frames and act quite different than when it pops up the buffer timer and would be happening all the time and not just “from time to time.”
I have an rpi4b-4gb unit on which I had installed/configured osmc in the beginning of this summer for use in the summer home. When moving back home I apparently brought it along so I have an already working OSMC here to use.
I have let it upgrade to the latest release yesterday.
It seems to work pretty well even though it is not an 8GB RAM unit.
However, when I am now busy modifying its config to suit the home environment I found this to be rather confusing:
There seems to be two sources mounted on the same local mount point (/mnt/ubuntusrv) but using different protocols!
One looks like a samba share and the other is an nfs share.
My /etc/fstab file only contains these lines:
So where is the //192.168.119.216/VIDEO mount commanded from and how can I get rid of it?
It seems like it should not be possible to mount two different sources on the same mount point…
But maybe this mount is hidden inside the kodi config somewhere?
The userdata/sources.xml does not mention this mount AFAICT.
I don’t even know what autofs is…
I only ever use /etc/fstab to define my mounts, so I am still suspecting that KODI is caching the old way of connecting to the NAS via samba.
That is no longer used by me since I prefer NFS due to its simplicity of configuration.
Can KODI “remember” an old style mount protocol and still use it when it has been removed from fstab?
I seem to remember long time ago when one defined mounts from within the KODI GUI that one had to enter credentials and such, maybe this has been cached somehow somewhere?
I just want to get rid of any such config so I can manage my box sensibly from the command line.
So now I did this:
stopped Kodi: sudo systemctl stop mediacenter
twice manually: sudo umount /mnt/ubuntusrv
now no mount was shown in df -h
then sudo mount -a
Now only the expected mounts were present and Kodi worked as well.
Next I tested by rebooting OSMC from the Kodi menu.
When it came back up the mounts were not present anymore!
So I did: sudo mount -a
and now the expected mounts were present.
But whenever I reboot OSMC the mounts, which are configured in /etc/fstab, are not connected…
So this is the situation where the opposite of what I had before has happened…
Is there some place where /etc/fstab can be enabled on OSMC in order for it to work??
Meanwhile I have put this into crontab to make sure the mounts are done on boot: @reboot sleep 30 ; sudo /usr/bin/mount -a
Without the sleep it does not work, but now I have the mounts done.
Seems like a strange workaround since what is specified in /etc/fstab should always be used, right?
But these are not “removable” they are always present server network shares on the server handling the videos and on the NAS with archives of videos.
I know that “removable” drives like thumb drives etc are auto-mounted at a specific location and available in the KODI navigation. They are subject to manual plugging and thus not always there.
But the ones I am talking about are fixed shares on the network that are there 24/7. And should be handled via /etc/fstab.