Posts: 58
Joined: Oct 2008
Reputation:
2
I might not comprehend the entire backend side of the way XBMC stores movie/tv show data... but im wondering why cant it simply store that data (image, fanart, xml NFO, etc ) in the actual folder where the movie resides rather than locally on the hardware itself ?
I have a bunch of raspberry pi's and a computer running XBMC... setting up centralized MySQL databases or keeping local (per XBMC) libraries for every single movie/tv show makes no sense to me when everything could all be stored at the exact same place ...
wouldn't it be possible for XBMC to simply fetch the info from whatever site, and make individual files in the actual directory where the movie/tv show reside ? this can sort-of be done manually when extracting the data from the library itself (in settings) so the functionality is there... Wouldn't this make things much simpler when having multiple machines running XBMC ?
A background "updating" job or an application could be scheduled at night to check for new files... and simply create the files in the actual movie directories as it does when exporting libraries.
im sure someone already thought of this... so Im just wondering why this cant be done ?
Posts: 418
Joined: Oct 2010
Reputation:
13
You can store image, fanart, and NFO where the media is stored.
The library is just a link to this data and also stores information like actor info, and mainly resume points which can't be stored as a local file.
So maybe I am misunderstanding your question but you can store fanart and images in a central place for all devices to access but for search functions and resume points you need a shared db that all clients can access.
Posts: 31,445
Joined: Jan 2011
Well, more than a link, it actually loads all of the NFO data into the library. It would be too slow to access each file individually every time XBMC needed that data.
It sounds like Extraze is looking for a media manager (see
Supplemental tools (wiki)). These can be your "background" applications that can run right along side XBMC, automatically creating nfo and artwork files.
Posts: 12,706
Joined: Nov 2003
Reputation:
129
spiff
Team-Kodi Member
Posts: 12,706
even though you own a pi, you are allowed to think.
because loading this data live from a network would be stupidly slow, no matter the hw? even the beefiest of i7's would slug on just a few entries because a network is insanely slow in computer terms. latencies in the order of microseconds on a fast wired network, probably an order higher or more on wlans. comparable to nanos locally. or rather, it's not really comparable, different leagues, different uses.
how exactly were you gonna do queries against those spread out files again? give me all action flicks from 1983 please.
in fact, why don't you give me all movies? that should be challenging enough with your spread out files. to the search-mobile!
Posts: 24
Joined: Dec 2008
Reputation:
0
I should inform the Plex community about this lag...
I believe the better answer to this question is that XBMC was never developed to be a client server type of system. You have to remember that the original XBMC was a standalone media player on the original XBOX, which most of the time wasn't even connected to a network. I agree that the SQL server can harbor the meta files as well, however your client will still cache most of what it needs.
That being said, when you setup a SQL server you are basically tricking XBMC to use the SQL server to keep all meta data ect. I would love to see XBMC move to a server based/client based piece of software more like Plex (without the short comings and long times between updates).
Posts: 31,445
Joined: Jan 2011
2013-08-12, 23:57
(This post was last modified: 2013-08-13, 00:06 by Ned Scott.)
kermyb123, nickr, you misunderstand. The lag isn't that it's coming over the network (not significantly), but that it's not in a database vs being in a database. Even if all files were local, there would still be significant lag reading directly from .nfo files rather than a database. Though, separate files over a network would be a double hit.
As for XBMC being a server/client type setup, we already do this, just not the way you think. XBMC is lean enough to be both server and client, so any XBMC can be a server, and other XBMC installs can be clients. Lots of work is being done to expand this, and soon people will be asking "why doesn't Plex over a server/client combo setup?". A combination of UPnP, JSON-RPC, the ability to merge libraries, and some other stuff (even transcoding), is going to push us ahead in this area.
Posts: 31,445
Joined: Jan 2011
Huh? It's not about media storage. Until Plex server can run on any machine that Plex client can run on, I think what we have in store is going to leave Plex in the dust. Granted, we're not there yet, but I'd be willing to make a bet now.
For XBMC, we don't have to split anything up. It doesn't make it any more or less efficient as far as XBMC's performance or for code development. We would want a headless mode so we can run on machines without GPUs (and/or otherwise have the GUI turned completely off), but even that doesn't require two applications to be developed in parallel. For other projects it might be different. Remember that MythTV backend also has live TV abilities, and the front end is kind of a GUI nightmare, so I wouldn't say it's a comparable example. Even if it was, maybe they just do things differently.
Posts: 42
Joined: Apr 2013
Reputation:
0
Good to hear that the team is working on developing this feature set. That's good enough for me. I'm just pleased as punch with my multiple XBMC systems...
Posts: 31,445
Joined: Jan 2011
I don't believe there is much of any remaining xbox-era stuff left over in the networking parts of XBMC. Even most of the UPnP stuff has long since been revised. Poor MySQL performance, if that is what you are talking about, is because almost no one on the team wants to work on it, and it will eventually be replaced by better stuff. MySQL was always experimental anyways, and not really a prime-time feature.