Move OSMC/Kodi from Pi3B to Pi4B

If this has been asked and answered before, sorry, just point me to the posting…

I just freed up a Raspberry Pi 4B with 4GB memory. I’m currently running OSMC./Kodi on a Raspberry Pi3B. I’d like to transfer this function to the Pi4B.

What is the process? OS? Media libs? Are there any issues? The Pi3 is working fine and I don’t want to make my wife unhappy by breaking it :slight_smile:


As long as the Pi3 is on the latest OSMC version you can use the backup/restore function under MyOSMC.

ok, Thanks, I look into that.

hmmm… Do I first install OSMC on the Pi and then restore the settings, etc from the Backup file?

Can you point me to the documentation?..RDK

Yes you install first a clean OSMC on the Pi4.
you then do a Backup on the PI3 writing it to either a NAS or USB Stick and then you restore on the Pi4 from that NAS/USB Stick

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.

Thanks for your input!

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:

ffmpeg -hide_banner -referer ${VIDEOURL} -i \"${M3U8URL}\" -r 30 -vf scale=w=-4:h=480 -c:v libx264 -preset fast -crf 26 -x264-params keyint=30:scenecut=0:open-gop=0 -c:a aac -t ${CAPTURETIME} ${TARGETFILE}

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. :smiley:
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:

$ df -h
Filesystem                             Size  Used Avail Use% Mounted on
/dev/mmcblk0p2                         3.7G  1.5G  2.1G  42% /
/dev/mmcblk0p1                         316M   91M  225M  29% /boot
/dev/mmcblk0p3                          25G   28K   24G   1% /media/media
//                259G  181G   66G  74% /mnt/ubuntusrv         7.2T  4.6T  2.6T  64% /mnt/synology  259G  181G   66G  74% /mnt/ubuntusrv

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:

/dev/mmcblk0p1  /boot    vfat     defaults,noatime,noauto,x-systemd.automount    0   0 /mnt/ubuntusrv nfs tcp,noexec,intr 0 0 /mnt/synology nfs tcp,noexec,intr 0 0

So where is the // 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.


My guess would be you configured it via autofs and forgot to comment out the old mount in fstab.

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.

Kernel based mount points have no relation with what KODI does.
Suggest to provide the URL of grab-logs -A as a starting point to support you.

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?

For removable devices the automount function is suggested to allow secure mounting

Yes, for removables…

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.