Kodi Community Forum

Full Version: HOW-TO:Share libraries using MySQL: Wiki Edition
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Normally u dont have to, i made mistake, but its not the baddest to habe a Backup anyway ?Wink
(2014-05-22, 17:14)SchattenMann Wrote: [ -> ]
(2014-05-19, 20:54)Raytestrak Wrote: [ -> ]
(2014-05-19, 20:12)chewara Wrote: [ -> ]since 13.0 on all clients (win7 64bit, osx ML and raspbmc) the Movies are updated, but the tvseries not. any idea?

i had a <name> tag in advancedsetting, removed, and scraping to a new database now, will see if tv series will come back. but dontwanna loose all the "seen"marks

worked all well on 12.3

As long as you have an export (split files) and

<videolibrary>
<importwatchedstate>true</importwatchedstate>
</videolibrary>

in your advancedsettings.xml, you will no lose your "seen" marks.

Wait, i have to export the database before updating to 13? Because i have over 7000 Episodes and that will create a hole lot of files for each episode...

I'm also using mSQL and was under the impression one only needed to update XBMC and voilá...Advancedsettings.xml is pointing to mySQL database with all info etc...

Guess i'm wrong >.>

No, you don't. If you already have a sql database it will just be migrated to videos78 (Gotham), but it never hurts to have a backup. Personally, I do a backup now and then anyway. That's probably because I screw things up all the time, by trying nightlies or like I did last week, upgrade my MySQL installation Big Grin
As you're having problems with the TV part of the database it may have had a problem while migrating. Drop MyVideos78.db from MySql then start xbmc to allow it to remigrate from your old database version which should still be there.
I did not want to cross post this in help and the tips and tricks section, but I wanted to know if anyone knew the answer to this question:

In the past if you wanted to share your thumbnails via a network share, you had to use path substitution. Now, everything says that as of Frodo (v12) you no longer have to do this. (see wiki article: http://wiki.xbmc.org/index.php?title=HOW...and_fanart), even the upgrade guide for XBMC states this is done automatically: (http://wiki.xbmc.org/index.php?title=MyS...Thumbnails)

My question is, where do you tell XBMC to store said thumbnails so it can automatically do this? If you are no longer using path substitution to redirect the files, where do you tell XBMC how to do this? I am probably missing something incredibly easy, but the way this is written does now make a lot of sense to me unfortunately =\

Thanks for any help!
(2014-05-25, 23:57)svenh Wrote: [ -> ]I did not want to cross post this in help and the tips and tricks section, but I wanted to know if anyone knew the answer to this question:

In the past if you wanted to share your thumbnails via a network share, you had to use path substitution. Now, everything says that as of Frodo (v12) you no longer have to do this. (see wiki article: http://wiki.xbmc.org/index.php?title=HOW...and_fanart), even the upgrade guide for XBMC states this is done automatically: (http://wiki.xbmc.org/index.php?title=MyS...Thumbnails)

My question is, where do you tell XBMC to store said thumbnails so it can automatically do this? If you are no longer using path substitution to redirect the files, where do you tell XBMC how to do this? I am probably missing something incredibly easy, but the way this is written does now make a lot of sense to me unfortunately =\

Thanks for any help!

Since Frodo, Thumbnail sharing isn't supported, period. You can use path substitution to store thumbnails on a network for a single client if you are short of local on-device storage (eg. Apple TV etc.) but actually sharing thumbnails between two or more XBMC clients using common network storage is not supported and will not work reliably - it will cause problems for one or more of the clients.

Since Frodo, It's not so much that you no longer "have to do this", it's actually that you shouldn't do this.

Unless you are short of local storage there is absolutely no reason to use the network (and path substitution) for Thumbnail storage, and you certainly should not be sharing thumbnails between clients under any circumstance.
(2014-05-26, 01:19)MilhouseVH Wrote: [ -> ]Since Frodo, Thumbnail sharing isn't supported, period. You can use path substitution to store thumbnails on a network for a single client if you are short of local on-device storage (eg. Apple TV etc.) but actually sharing thumbnails between two or more XBMC clients using common network storage is not supported and will not work reliably - it will cause problems for one or more of the clients.

Since Frodo, It's not so much that you no longer "have to do this", it's actually that you shouldn't do this.

Unless you are short of local storage there is absolutely no reason to use the network (and path substitution) for Thumbnail storage, and you certainly should not be sharing thumbnails between clients under any circumstance.

Thanks for clarifying that. I think the wording in the Wiki pages for this is very confusing and should be updated (maybe I can figure out how to do that). I played with it a bit and got it to work, even though like you said, it will probably not work very well. Having read the wiki page, I thought this had changed, so I will go back to syncing the thumbnail folder and texture.db using dropbox; I never had any problems doing it that way.

Thanks for the explanation, I am glad I wasn't totally derp...
(2014-05-26, 01:19)MilhouseVH Wrote: [ -> ]Unless you are short of local storage there is absolutely no reason to use the network (and path substitution) for Thumbnail storage, and you certainly should not be sharing thumbnails between clients under any circumstance.

I was hoping to use a network location for Thumbnails so that any thumbnails I had changed from the default would persist between updates. Is a way to backup/import a thumbnail db ? For me using a Raspberry Pi, using network storage would make it easier to avoid losing those preferences if the install gets corrupted.
Just copy your Thumbnails folder to your network location. The problem is that if you reinstall XBMC you will start with an empty Textures13.db that won't know about any previously cached artwork stored on your network, so it will be cached again (overwriting what is already there). To backup Textures13.db, just copy it somewhere then restore it when required.
Great, so its the thumbnails folder in combination with the Textures13.db that xbmc uses to determine the right thumbnail to show? That would explain why I've not been able to get the thumbnails to transfer from an old install to a new one - I wasn't aware of the database.
What is the command to see what permissions my user 'xbmc' has?

If I check the logs I get a 1045 permission denied for user 'xbmc @ homeserver' error even though I issued the GRANT ALL *.* TO 'xbmc' command
Dear all,

I have a question about performance improvements possible for the mysql db.

I have a working Video and Music mysql library on my Qnap TS-412 NAS (4 bays, low power Marvell ARM CPU, 512Mb RAM).
I have 600+GB of music (mainly FLACs bur also old mp3 which means probably more than or about 100 000 music files (Bach and Mozart "Complete Works" are BIG). XBMC is installed on a Raspi, a Bay Trail HTPC and an old Core2Duo desktop computer.

The library indexing is agonisingly slow and crashed a couple of times. But more than that I now have 10-30seconds lag after I click on "Music" to display the library or the directories.

I read this:
http://wiki.xbmc.org/index.php?title=MyS...nced_notes
And other tips telling me to switch the storage engines on my database tables to InnoDB.
I have done all this (except skip-name-resolve but will do soon).

What now? Is there a big benefit in increasing the amount stored in RAM ? (increasing buffer size of the InnoDB tables, like I read here:
http://dev.mysql.com/doc/refman/5.1/en/i..._pool_size
)
(note: I have no grasp on how big my 100000 songs table would take in my NAS RAM, It might just be unrealistic).

Other question: My HTPC has a bay trail CPU and 8GB RAM and is mostly-permanently-on, would it make a huge difference to use it to store the DB instead of my NAS?)

Thanks Smile

EDIT bonus question:
Reading http://wiki.xbmc.org/index.php?title=MyS...ng_up_XBMC
It looks like I could have a shared Video library (share Whatched status, thumbails, metadata ...) but a keep a separate Music library for each XBMC instance. For that I would just have to remove the <musicdatabase> part in the xml file.
Basically I would avoid all the headaches caused by the size of my music library and just use directory structure for browsing music, while keeping a nice and easy-to-use video library.
Will this work ?
If you enable debug log (wiki) you'll be able to see how long each SQL query is trading and determine if your QNAP is the problem. However 100K files is a *lot* and it could be other parts of XBMC that are bottlenecking after the query has competed - upload your debug log if you're not sure.

I would expect your Bay Trail with 8GB to perform better than the QNAP - relational databases tend to work better when more memory is available, not to mention the faster processor.

As for the shared video library/local music - that should work.
Debug log shows it takes a little more than 30s to display the Album view.
Fetching the "recently added" or things like that take 100-200ms each time. No problems on the video side.

I've done some changes to the mysql configuration, scrape the music database and it's re-indexing now. (I didn't need to do that I guess ?)
anyway, I'll report when finished.
(2014-06-27, 00:40)Aquarius Wrote: [ -> ]Debug log shows it takes a little more than 30s to display the Album view.

Yes, but some of that 30 seconds will be spent waiting for the SQL query to complete, with the rest spent caching the resulting data, before the UI displays the library. If the majority of the time is spent caching the query result then you're most likely wasting your time optimising the database further as it's not a db problem.

Edit: It appears that the CArchive timing information is somewhat inconsistent in Helix, which is a bit of a bummer.
the NAS mysqld process takes 100%CPU during the indexing, so I'll wait before it's complete to judge anything Smile
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40