MySQL sharing: Confused about one part of config
#1
I thought I understood this well enough and previously had it configured nicely. However, recently I created a new RaspberryPi XBMC client and I'm confused about one part of the configuration (as it's explained in the wiki): Why do I need to "scan" all of my network video sources on the client? When properly configured with the correct advancedsettings and sources files, shouldn't all of the media info now be available in MySQL?

Following the instructions, I copied over the advancedsettings.xml file, and I copied the sources.xml as well so that the video sources are all configured properly. All of the sources are network shares. In one of the last steps it says that I need to "import" my media on the new XBMC client by "scanning" the video sources just like I would do if I wasn't using MySQL at all. However this takes hours because it's looking at each NFO file (and the Raspi is pretty slow).

Just a little confused about why the traditional "scan" is still necessary.

Thanks!
Reply
#2
You only need to export and import when you're migrating from a local sqlite database to mysql. If your mysql db is properly setup and all the information is already scanned and stored from .nfo files to the database it should be safe to do normal library updating from Rpi, it won't store them again.
Reply
#3
Hmmm, weird. So, does the Pi (the "client" in this configuration) need to have the sources specified in sources.xml, or does it just grab the media info straight from MySQL? MySQL is fully populated right now.

I must have something misconfigured on the client, because the media never appeared after I added the advancedsettings pointing it to MySQL.

Although, come to think of it, maybe I never did a scan, and instead added all the sources into the sources file (effectively duplicating them?). I'll need to troubleshoot more.
Reply
#4
Your Pi will still need to cache artwork locally, even when using MySQL, and this can take a while, particularly if you're using artwork hosted remotely on the internet, and tends to take the edge of the user experience, at least initially.

Fortunately, there's a script for that. Download the single file required, run it with the "c" option, leave it running for a an hour or so (maybe longer with internet content) and when it's complete the user experience on the Pi will be buttery smooth.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#5
Excellent, thanks MilhouseVH. This looks great. I'll give it a try as soon as I get back home.
Reply
#6
(2013-03-29, 16:32)awp0 Wrote: Hmmm, weird. So, does the Pi (the "client" in this configuration) need to have the sources specified in sources.xml, or does it just grab the media info straight from MySQL? MySQL is fully populated right now.

I must have something misconfigured on the client, because the media never appeared after I added the advancedsettings pointing it to MySQL.

Although, come to think of it, maybe I never did a scan, and instead added all the sources into the sources file (effectively duplicating them?). I'll need to troubleshoot more.

You can connect to your mysql library and even play them, but you won't be able to update your library if you don't have exactly same sources setup on your Raspberry. I think Big Grin
Reply
#7
I think that's basically correct, you only need the sources.xml to be populated with sources on the client that performs the updates - the rest will just access the files via the urls in the database and have no "update library" capability, which may be just what you want. A passwords.xml might be required on each client if sources require a password though.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#8
Thanks guys, this is kiiiind of starting to make more sense. Though it still feels a little awkward and unnecessary. I'd love it if it was *all* managed in MySQL, and didn't require local sync'd files. You can still have a smart cache that operates behind the scenes for images and stuff. But I do understand that MySQL represents an unnecessary complexity for most users and could potentially lead to instability. Probably not worth changing the world for a few of us multiple-instance guys.
Reply

Logout Mark Read Team Forum Stats Members Help
MySQL sharing: Confused about one part of config0