jmarshall Wrote:1. I was merely pointing out that the data in the 3 current libraries is primarily independent, thus the only reason to join them is convenience rather than to cross-query.
I think we all concur on this point, it is a convenience rather than necessity. A convenience which can yield some nice side effects.
jmarshall Wrote:Perhaps the solution is to ignore it and force everything to be on a network drive that allows the same URL format for everything, or perhaps we just tag those paths that will be the same for all machines (i.e. network) - I don't know the best way to handle it.
Building on this idea a little further, would giving each XBMC instance in the network a unique name (resolvable by some means) of which becomes part of the URI.
For example -----
I have 3 XBMCs in my network, named XBMC-A, XBMC-B and XBMC-C respectively. I have also have a 'nix server, named MEDIA-SRV, which hosts a samba share and is serving a common mysql database.
XBMC-A is the only instance with local media on "E" drive, which consists of a couple of movies wrapped up in a rar archive as well as some individual music files. All XBMCs are configured to use the common media repository at smb://MEDIA-SRV/media/
Now, let's say that XBMC-B browses the database and wants to play a movie that's contained in the rar archive. The database indicates the URI for the path is "rar://XBMC-A/E/movies.rar/movie1.avi"
End example -----
This would indicate an absolute URI with protocol/type (eg. file, smb, rar), host (eg. hostname, devicename, or even static IP) and the path.
jmarshall Wrote:At a broader scale, the whole idea of which client updates the database for scans etc. is something to think about. It doesn't really make a lot of sense for each client connected to a central db to run checks for new content - this is a role the central server should take, right?
Yes multiple clients do not want be updating a single database at once. I see two reasonable ways of dealing with this.
1. The ability to configure a master database updater of which only they can update the database and scraping is simply disabled on other instances. This could be a little limiting.
2. Have a pseudo lock table in the database that indicates when the database is being updated and by whom, other fields such as last updated could also be warranted. When an XBMC instance wishes to update the database they would have to obtain a lock before proceeding. This would allow all instances in a network to potentially update the database provided they have the lock.
ZIOLele Wrote:Uhm, is the video db schema complete? Where are stored the scraped information?
If you are referring to the picture the "cXX" fields in "movie", "tvshow", "episode" and "musicvideo" tables actually represents the fields "c00" through to about "c20" in the real tables. It was merely compressed to aid layout.
Hopefully you're not too confused.