[skylarking]

Hi, i just registered after trying out XBMC v12.2 on my Win7 desktop and so far so good

Now I am rarely connected to the internet because i use unreliable 3G wireless, so i didn't bother with metadata (cover-art, fan-art, synopsis, actor bio's, etc).
However after downloading some metadata, it must be said that the confluence interface is much nicer when cover-art and fan-art is displayed as one flicks through their titles.
So congrads to those that designed this application and the default interface

The end result is i downloaded all cover-art, etc for my currently encoded movies without much thought.
Now with XBMC i no longer need to get up of the couch to flick through my physical disk collection

However, i have yet to understand where/how the database is stored/structured with respect to the database files and metadata files.
The reason i want to know is that when i am happy with how XBMC works on my desktop, i want to build a dedicated XBMC machine.
As such i will move all my movie files from my external usb backup drive to the local drive on the new XBMC machine.
Then i want to move the metadata from the desktop to the new XBMC machine (rather than re-download again).
In essence, the movie files location will change from E:/movies to C:/movies while the DB file will need to be somehow rejigged to reflect this change.
I thought it should be simple find & replace in a text file... but it seems not so simple...

So does anyone have any suggestions on where i can find details about the database structure itself and how best to accomplish this 'metadata migration'?

Cheers..

[Ned Scott]

Settings -> Video -> Library -> Export, choose "multiple files"

This will create offline metadata files that XBMC (and other programs) can read. The files are saved right along side the media, so no matter where you move the files to, XBMC can create an offline database from scratch. To scan them back in you just set XBMC up as if you were going to use the internet, but XBMC will detect and use the local files instead.

[whitebelly]

^what he said.

And if you still want to know more about the databases and thumbnail cache, there is plenty of info here.

[skylarking]

Ned, thanks for outlining this method as it is OS independent and i don't have to worry about the DB files themselves
But i vaguely remember reading that exporting the database can impact future thumbnail updates, or was this only when exporting as a single file?

whitebelly, thanks for the link, i'm still making my way through it but i didn't find any info regarding the internal structure for the DB files themselves. I know nothing about SQL but don't you need to know the structure to be able to read and write to the database? In part it's not so important given an 'export' method but i'd still like to know the internal structure.

[mal2]

XBMC can use one of several database backends to store information. It defaults to using SQLite, a self contained one-file database designed for use by a single process at a time. Optionally, you can instead use a MySQL server running anywhere on your network, so that multiple XBMC installations can share a single database.

In either case, you shouldn't need to know the structure of the underlying file that contains the data. You just use a client that knows how to either read the SQLite file, or how to communicate with the MySQL database server. From there you manipulate the contents of the database using SQL statements, just like with any other relational database.

[Ned Scott]

You only have to worry about the thumbnail issue when exporting as "single file". Under "single file", the path for the thumbnails get updated to the folder that contains the single XML file, so if you lose that folder (most people delete it after importing), XBMC won't know where to download thumbs if it needs to reload them for some reason (such as a MySQL set up).

[whitebelly]

^regarding the "single file" thumbnail location, that is true for the video library, not the music library....correct?

[Ned Scott]

I believe it only applies to the video library, yes.

[skylarking]

Ned, thanks for the explanation.

If i now understand correctly, when performing a single file export of my library, a name.nfo (xml) file, the art files and other metadata files related to the movie name itself are saved within my 'movies' directory. Hence the recommendation to have each movie in it's own directory though i have a flat directory with all movies contained within This will be a little tedious to handle the many files but not overly so.

My MKV files already contains basic cover-art within but i prefer the cover-art i have downloaded via XBMC scrapers and would prefer such metadata to be saved within the MKV file itself from an ease of handling perspective. Pity that the MKV file, which is a container format in itself, does not handle such metadata and associated cover-art files as used by XBMC. It would be an ideal solution for single file library exports to save the metadata and associated cover-art within the MKV container file itself... Any hope of this happening ??

[Ned Scott]

Single file = artwork in a special folder not along side the media

Multiple files = artwork along side media. This will work even if all movies are in one folder, as they will simply be named after the video file.

I'm not sure, but I think embedded artwork support is coming. It works now with Gotham development builds (wiki) and mp4 file containers, but I have not tested mkv file containers.

[skylarking]

Thanks Ned for the clarification.

I think i got my terminology a little mixed up in my previous post as i should have said "when performing a multiple file export" which i knew to create a single nro file for each movie

I am slowly getting it, and now looking at MythTV backend with mariaDB database and XBMC running on my HTPC but still some things to understand and trial first...

I hope MKV can be extended to include embedding the nro file and associated artwork that is used by XBMC when exporting into the MKV itself. Then XBMC can check if an MKV file has embedded nro & associated artwork (from an export), otherwise check if only conventional embedded artwork exists, otherwise check if nro files within the directory exist otherwise do a scrap for artwork, etc... One can only hope