[phate89]

wasn't path substitution required to also share the thumbnails/artwork when using MySQL?

No since frodo xbmc handles it automatically:
http://wiki.xbmc.org/index.php?title=MyS...and_fanart
ANd it was never recommended...

[Milhouse]

wasn't path substitution required to also share the thumbnails/artwork when using MySQL?

Path substitution has never been recommend for thumbnail sharing as far as I'm aware (only got into this in Dharma times), mainly because it doesn't work - you also need to share TexturesXX.db, which isn't designed for sharing. You can path sub your thumbnails to the network for a single client if you don't have any local storage (eg. Apple TV), but don't then expect sharing of those thumbnails to work between multiple clients.

[Montellese]

@Tolriq: Why do you keep complaining about UPnP after I clearly stated that UPnP is not the final solution and only the easiset way into this system we envision? Have you read the code I've written so far? If so you would have realized that I've written the code in such a way that you could simply throw away the logic that imports items through UPnP (which is contained in a single class implementing a generic interface) and write something else that retrieves the files. You can even have multiple importers in parallel each one working over a different protocol. It's just that UPnP is already very much integrated into XBMC and therefore required the least amount of work to get access to the media library of another xbmc instance. We first have to figure out how the "merge remote media libraries into the local library" part of the system can work in detail before we will concentrate on how we actually get the media library from instance X to instance Y. Those are completely separate problems.

[da-anda]

It has to be as easy as install -> enable library sharing -> connect -> be done.

I'd have thought it should be possible to enable MySQL in the same way the webserver is enabled in Settings: ip address, port, username, password. The last three settings can all have sensible defaults.

This is not desired, because for a well working MySQL setup you need at least some technical knowledge - and if those credentials could be entered via GUI, every dumb user will mess with them and flood the support forum that XBMC crashed, won't start or whatever. So it has a reason why it's in advancedsettings. And no, even settings level expert would not hide it enough from dummies.

[da-anda]

wasn't path substitution required to also share the thumbnails/artwork when using MySQL?

Path substitution has never been recommend for thumbnail sharing as far as I'm aware (only got into this in Dharma times), mainly because it doesn't work - you also need to share TexturesXX.db, which isn't designed for sharing. You can path sub your thumbnails to the network for a single client if you don't have any local storage (eg. Apple TV), but don't then expect sharing of those thumbnails to work between multiple clients.

so, this is where UPNP would have a benefit - one central source for library and artwork

[Tolriq]

@Montellese : I did not read the code, but your last statement was not so clear And we all know that the in future it will be changed is often a very very far future as it works and no one wants to get with.
I'm just reporting end user wishes as I deal with a lot of them.

@da-anda : Displaying thumbs over upnp would be slow as hell

[Milhouse]

so, this is where UPNP would have a benefit - one central source for library and artwork

I could be wrong, but I don't think UPnP replaces the texture cache, does it? Artwork served over UPnP is still going to be cached on each local client otherwise performance will be miserable. Sharing thumbnails is going to be just as wrong/broken under UPnP as it is now.

[phate89]

wasn't path substitution required to also share the thumbnails/artwork when using MySQL?

Path substitution has never been recommend for thumbnail sharing as far as I'm aware (only got into this in Dharma times), mainly because it doesn't work - you also need to share TexturesXX.db, which isn't designed for sharing. You can path sub your thumbnails to the network for a single client if you don't have any local storage (eg. Apple TV), but don't then expect sharing of those thumbnails to work between multiple clients.

so, this is where UPNP would have a benefit - one central source for library and artwork

Actually if i'm not wrong artwork and thumbnails since frodo are in the database (url). So if you use a different xbmc client it will cache locally the same artwork. If the file is not manually selected from the disk xbmc will always keep it in sync downloading it everytime the user changes it.

[zag]

Having previously worked with software that had database add-ons and complete flexibility on the categories and data fields I would say be careful what you wish for

Having such an open schema can cause its own problems with performance and development.

Saying that, there is a need to extend the database to cover things like new metadata artwork types.

In terms of performance, adding any kind of layer is going to make it slower.

[zag]

If you want to measure MYSQL performance accurately, this is a great bit of software that finds slow queries.

http://www.jetprofiler.com/

Just open up the MYSQL port on your local network and connect from a windows machine.

[da-anda]

in my scenario having the URL to the artwork in the DB won't help, because my artwork is on my NAS, but my NAS is only on when I want to watch a movie. So if I'd start using MySQL with the database hosted on my home server (low power, active directory, exchange, tv-backend ...) and I'd try to connect a new client, I'd get the info but will never get any artwork unless I turn on my NAS and wait for the client to grab everything. To me this would suck. A shared library should also share and sync the artwork and not have every client to grab it on it's own. Local caching of artwork is fine, as long as it's also synced on change.
But we're getting off topic here.

As said earlier, the only way I see MySQL to stay supported is to abstract it into some sort of interface and then provide database connector addons. That way, even if we'll get the new library sharing feature in, one could still use MySQL as backend and either only use it as faster sql backend server side, or use it in current fashion. But for this to be accepted, IMO it must not have any hackish touch to it (no parsing + rewriting of SQL statements), but I'm no XBMC dev, nor team leader, so this is just my personal opinion.

[Milhouse]

I realise this is a little OT but perhaps this could once and for all be put to bed - the double network bandwidth issue when streaming from a UPnP source.

I've just run a test and can't find any evidence of this additional traffic.

I've got a Pi (OpenELEC Helix build, with MySQL library and nfs:// media both on the same NAS) and an x86-based Revo 3700 (OpenELEC Gotham 4.0.6 build, not configured for MySQL and no sources).

I have configured the Pi as a UPnP "server" with the following options enabled:

• Share video and music libraries through UPnP
  
• - Announce library updates via UPnP
  

The last option is crucial in order for UPnP sources to appear on the client - perhaps it could be worded more accurately? I thought it was referring to whether library updates were announced, when in fact this option appears to control the entire visibility of the library (which actually you'd think the first option was supposed to control).

Edit: I've just run some more tests and now I'm not so sure about how crucial the second option is - maybe a glitch when testing without it the first time.

I then configured the x86 as a UPnP "client" with the following option enabled:

• Allow control of XBMC via UPnP
  

With the above options enabled, on the x86 client I'm able to add video and music UPnP sources with the Pi as the UPnP source.

Whenever I play a file on x86 via either the video or music source I see no significant increase in Pi network traffic. The Pi does not appear to be streaming data from the NAS to x86, rather the x86 appears to be streaming data directly from the NAS using the nfs:// url.

So either I've not configured UPnP correctly (yet miraculously got it working in an efficient manner!), or this double-bandwidth overhead problem that has been mentioned previously is only a problem under very specific circumstances (or maybe it's not a problem at all?)

[Tolriq]

You are in a special case where you did add your sources everywhere so maybe a side effect.

But the goal of the central library from what I understood it is to avoid users to have to define the sources everywhere with password and such.

If you export your nfs source only to the main Xbmc or add sources to one Xbmc and do not want to share the password to other Xbmc instance like for sharing controlled media to room mates the media have to go through the main Xbmc as the client will not have access to it.

Having to define sources everywhere and define associated permissions is counter productive

[Milhouse]

You are in a special case where you did add your sources everywhere so maybe a side effect.

Yes, I thought of that so on the x86 I removed all the NAS-based sources from sources.xml and even removed the MySQL entries from advancedsettings.xml so that the only sources x86 "knew" about where the UPnP sources - still the x86 client played UPnP-based media without any noticeable network impact on the Pi.

Edit: I've updated my previous post with regard to the x86 client not being configured with MySQL and having no sources at the start of the test - at the end of the test it only has the UPnP sources.

[Tolriq]

Export your nfs share only to your rpi IP. And you'll know if the data goes through the rpi or not