Store only relative paths from sources to media in SQL database
#1
Lightbulb 
XBMC has evolved to allow use of a shared MySQL database to store library metadata for media files. However, it currently stores absolute paths to each entry, which makes it cumbersome for users to successfully configure clients that use different paths or protocols to reach those files and match them with the database information.

It seems to me that it would be better if, instead of absolute paths, the database could instead contain source names/aliases or numbers for each entry, along with relative paths. Then, clients could define (in sources.xml) what the base paths should be on that client for each source name/alias or number. This would allow much easier configuration of multiple clients that share a library while accessing the media files via different means.

For example, the database could contain and entry like this:
  • Movie name: Some Movie
  • Source: movies1
  • Relative path: Some Movie series/Some Movie.avi

...and then one client could have this definition of movies1 in sources.xml:
Code:
<source>
  <name>Movies</name>
  <alias>movies1</alias>
  <path>/mnt/otherbox/shared/movies/</path>
</source>

...while another client can define the base path for movies1 differently:
Code:
<source>
  <name>Movies</name>
  <alias>movies1</alias>
  <path>smb://otherbox/shared/movies/</path>
</source>

This eliminates any confusion when the clients scan for new media to add to the library, as they see the same files and directory structure relative to the movies1 alias. This is much cleaner than using pathsubstitution (which is currently not working properly for me anyways: http://forum.xbmc.org/showthread.php?tid=140536) because it keeps the database completely agnostic with regards to what protocol, mount point, etc. is used on a particular client to reach the shared media location.

With XBMC now supporting shared database libraries and multiple file sharing protocols (SMB, NFS, UPnP, FTP, local paths, OS mount points, etc.), it really makes sense to take this next logical step towards freeing users to more easily configure a diverse network of clients that access the same media and library of metadata via these various different means.
Reply
#2
I think it is a very good idea, although the transition for existing databases can ve really complex and cumbersome.
Reply
#3
This would be a really valuable feature.
I have my media library mirrored to two different locations: the internal drives of my Linux workstation and an external hard drive which I can plug into my notebook to watch videos in a room with bad network coverage (and to have a backup, of course). The MySQL database is replicated to both machines, which works fine.
However, when I try to mount the external hard drive to an NTFS folder on my Windows notebook and rewrite the NFS paths to my Linux workstation via path substitution to that folder, XBMC happily rescans the whole library and creates duplicate entries for each movie.
Reply
#4
I found a workaround for my problem. I just created a symbolic link "library" on both Linux and Windows inside my XBMC settings folder (i.e. ~/.xbmc and %appdata%\XBMC) and then added special://home/library as a source to my library.
Works quite well.
Reply
#5
I've been thinking about using symbolic links for this as well, but then why have path substitution as an XBMC feature in the first place if it's not even as powerful as OS linking (with the exception of redirecting "special://" paths)?
Reply
#6
Yeah, that's what I asked myself, too. I have no idea why path substitution works on a higher level than special:// URL resolution.
Reply
#7
Pathsubs originally were only meant to be used for playlists. They're not really meant for other things, so their use in other areas is just considered experimental.
Reply

Logout Mark Read Team Forum Stats Members Help
Store only relative paths from sources to media in SQL database0