I have questions regarding using path substitution. I have a Pi4 that is my media server, and a few other pis and a vero 4k+ that act as clients. I’m using Mysql as the database.
I had previously just entered the paths for my files, including on the media server, using samba. As indicated in the following old post, that’s not a good idea and I’m finally getting around to trying to solve it. My goal here is to have the media server access the files directly, and then use NFS (not samba) to connect to the server. Path substitution was proposed here:
My first addition to my advancedsetting.xml for path substitution (before I start work on NFS) on my server looks like this:
However, after doing this, my logs show that the files are still being accessed using Samba. Please see the following lines in the edited logs:
14373
15303
15909
If you’re concerned about network performance (and especially if you’re resigned to using path substitution anyway) you might want to look into using OS-level mounts by means of fstab or autofs.
Once the remote share is mounting correctly, you then set up the Kodi source as being in “root file system” - the remote folder behaves like a local one.
Thanks @angry.sardine for your suggestion. Can you clarify a bit for me about this? Is there a better way to do what I’m planning on doing without path substitution? Path substitution was suggested to me instead of changing the MySql database directly, which is what I was planning on doing (and I’ve altered the database directly in the past so I’m not adverse to doing it this way).
Thank you.
I don’t claim any real expertise, here; but, as I understand it, path substitution is basically just a way to avoid having to rebuild your entire library if the path to the files changes. So (for example) if you used to be accessing files via a Kodi-level SMB source, then a given file might be accessible as smb://192.168.1.13/movies/Citizen_Kane.mkv . If you switch to mounting the SMB share at OS level, it’s now behaving like a local folder from Kodi’s perspective, so the path to the same file might now be /mnt/video_server/movies/Citizen_Kane.mkv . If you create a new Kodi source (pointing to /mnt/video_server/movies instead of smb://192.168.1.13/movies/ ) and delete the old source then the library entry now points to a file path that is no longer accessible.
Path substitution basically says “Any time you are trying to access something with the path smb://192.168.1.13/movies/ actually access /mnt/video_server/movies/ instead” - that way you can keep the existing library intact, and it will automatically play all the files from the new location.
So, I suppose you could delete the old source, clean everything out of the library, and then reconstruct the entire library from scratch; but as all that scraping takes a long time for a large library, path substitution is probably less effort. Hacking around with the SQL DB directly is probably going to be painful.
The benefit of using autofs or fstab, is that the access to the SMB (or NFS) share is handled at the operating system level rather than at the application level, which tends to produce better network performance. What they do is mount a share on a remote machine in such a way that, to applications (e.g. Kodi) they appear to be folders within the local file system, and only the OS knows that they aren’t.
So, you could use path substitution to smooth the transition from an SMB Kodi source to an NFS Kodi source, or you could use it to smooth the transition from a using SMB at Kodi-level to accessing the files via an OS-level mount. Either way it’s probably less effort than the alternatives. Using an OS-level mount is likely to give better performance than Kodi’s SMB or NFS implementation, if network speed is critical.
Yep, because it was working the entire time. I did some testing on my end including adding the pointless port number and path substituting to a different video file entirely and playing it so I knew what file path was being used with certainty. After looking through my logs it would seem that Kodi is substituting the entire time but just isn’t logging it. After the OnPlayMedia the first time it actually shows the real file path it’s using is in the CFileCache::Open entry. Sorry, I should have looked closer the first time but on a quick glance it looked like the port number was getting truncated from the file path and I figured that adding a substitution without it would work around this. Turns out it wasn’t necessary.
As for the general topic of if using path substitution is the way go, the answer is yes in most cases if your moving file paths and not doing a clean install. In your particular case you have a shared MySQL library using SMB file paths. With this you can connect any Kodi client on any platform and it works. If you manually edit the database to switch it to a mount point you now have to duplicate this mount on every client. This now limits you to clients that you can create this new path to or use substitution on them. If you remove sources and rebuild you will very likely end up with broken file path links in your database (Kodi is not great about cleaning these) plus you will wind up with a thumbnail cache folder full of dead artwork that Kodi will not automatically clean up. This may also cause free space issues on devices with smaller amounts of internal storage. This is a bunch of headaches that can be solved by just using substitution on any clients you want to use a system mount on for performance reasons.
I’ve decided to do this using fstab. I’m in the process of changing the path in my mysql database, and then updating the sources. I have done this now with two of my hard drives across the main server (pi4) and two clients (vero4k+ and pi3). So far it is working well and I keep all the bookmarks (which are many) for my movies and tv shows.
Here is how i’m doing it:
I first back up my mysql databases using mysqldump (I use two different databases - one for the pi3 and one for the Vero4k+). these are currently MyVideos116 and MyVideos119
i installed nfs server on the server and nfs common on the clients.
on the server, i created a directory for each of the two hard drives in /mnt.
for each of the hard drives, i obtained the ID using blkid. those were entered in /etc/fstab as follows:
then I had to unmount the two hard drives:
sudo umount easystore4
sudo umount easystore3
then mount the hard drives:
sudo mount -a
then enter the following in /etc/exports
/mnt/easystore4 192.168.0.1/24(sync,no_subtree_check)
/mnt/easystore3 192.168.0.1/24(sync,no_subtree_check)
then “sudo exportfs -a”
then change /home/osmc/.kodi/userdata/sources.xml to go from:
now comes the mysql. if you do not know what you’re doing with databases, do not try this! one wrong keystroke could be very harmful. it has for me in the past.
the table that needs to be worked on is “path”.
to get an idea of what you’re working with here, i used the following sql statement:
select idpath, strpath from path;
there would be a number of entries in the column strpath which looked similar to this:
smb://192.168.0.15:445/easystore3/movies
those would need to be changed to this:
/mnt/easystore3/movies
I found the best way to do this for me was the following:
update path set strpath = replace (strpath, ‘smb://192.168.0.15:445/easystore3/’, ‘/mnt/easystore3/’);
On the clients, I edited the sources file as above.
I edited the /etc/fstab as following:
192.168.0.15:/mnt /mnt nfs noauto,x-systemd.automount 0 0
that’s all I can remember. if i think of anything else while going through the process with the other hard drives, i’ll try to update the post.
One thing of note. While I was hoping that this would speed up and allow UHD files to play on the vero4k+ without stuttering, it didn’t help. Even 1080p files were stuttering. I went through the settings on the Vero4k+ and found that H.264 hardware acceleration wasn’t on. I switched it to be on with 1080p and above. That seemed to do the trick.
Hope this helps someone else. If I’ve done something wrong here, please feel free to offer suggestions. I am no expert by any definition of the word!! It seems like a lot of work but it isn’t that bad once I figured out how to do it.
It does, so why not stick with the path sub approach? Did you find some advantage in this method (not snark, genuinely curious if there is a downside to path subs that I’m not aware of)?
The major advantage to me here is that it is cleaner IMO doing it this way and also it is something I understand better. When I check to see if it’s working, unlike the path substitution method, I get an error that does not allow me to play the movie or tv show. That actually helps.
In addition, when I add additional hard drive, I do not feel the need to enter it the same way as the previous one with the old path and then do path substitution with it. If I enter the new hard drive in the new way (without the need for path substitution), then some drives will be right in mysql and some won’t. That to me is confusing.
This to me is as close to a fresh install as I can get without losing the bookmarks and going through having to redo the thumbnails and everything else.
In the end, path substitution is most likely easier. I just didn’t prefer it given my situation and that I have at least some knowledge to do it my way.
Hope this helps. Thanks for asking and glad you put the “not snark” part in your question, lol. That helped me understand where you’re coming from.
You’ve been very helpful with my posts in the past and I appreciate it greatly.
In your situation where the original path is still valid you could always do something like a path sub to an invalid path to purposely break it for testing purposes which would give you the same kind of feedback.
As I explain in my how-to on the topic the file paths stored in in the database are derived from the Kodi sources that are configured and are not influenced by the substitution. As long as you don’t modify the source paths then the database stays 100% consistent. You also have freedom to change any part of the file path so if you wanted to sub something like “/easystore3/Movies/” to “/easystore4/Movies/” Kodi has no issue with that.
Thanks for the feedback. I can’t really respond to the ‘cleaner’ approach aspect as that is rather subjective. If your comfortable with the process of the database edits I don’t really see a downside to doing it that way other than the amount of effort involved.
@darwindesign Thanks for the response. I do have to add that while I don’t know a lot about kodi, osmc, and the overall software, I do have to contend that cleaner is not subjective here.
Path substitution seems to me to be in effect a workaround to fix either errors or when changes are made to paths. It may be an easier way to do it but now you’ve added a second location for data. You basically now have two tables which store the same data (in this case, paths), albeit one is a text file. In databases, that is very poor practice. In fact, I have fallen victim to this in the past when I’ve tried to go back to my tables to fix something and can’t figure it out b/c I’ve added data elsewhere that changes that data. I was simply being lazy before and it cost me more time in the end.
In my approach, there is only one location. With path substitution, there is another location that changes the first location. Quicker perhaps but it is definitely not clean.
You’re also right that I can change the path to an invalid path to purposely break it for testing purposes. However, that does certainly add to the effort.
I hope this helps clarify my thinking on this. Again, thanks for the time you’ve taken to help me in the past.
In my use case I have a MySQL db and have Kodi clients on RPi’s, a Vero, Windows PC’s, and an Android tablet. My kodi sources are all using Kodi SMB paths which allows all clients to work off the same database without anything other than than just using the same advancedsettings.xml, sources.xml, and passwords.xml files. However My Vero cannot play my largest 4K HDR files without a system mount which I added to my Vero and then redirected Kodi to use with a simple path substitution that is only on my Vero. To me this seems clean and not at all a workaround or hack.
Now for your example on having your data sources change I personally think it is cleaner to not have that be an issue in the first place and solve that on the network storage location itself. For Myself I originally started out with a single drive with a single share (video) and it had two folders (Movies and TV Shows). When I needed to expand I just moved the TV Shows folder to a new drive and then put a directory junction (this is a Windows PC) in place of where the folder originally was. The UNC paths never changed and Kodi’s database never needed to get touched. That later got expanded with another pair of drives that got the same directory junction treatment. Since that point I have switched over to a drive spaces pool with eight drives connected to it and I’m back to the files being inside of the same folder without the symlinks and all the while my paths as far as Kodi is concerned never changed. This to me is clean. Network file paths that never changed with storage expansion, a unified Kodi database across all platforms, and client configuration that is identical other than a few lines in an advancedsettings.xml.