Why not centralize media data where it resides ?
#1
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 ?
Reply
#2
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.
יונתן בן-חיים
Reply
#3
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.
Reply
#4
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!
Reply
#5
(2013-08-10, 23:38)Ned Scott Wrote: 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.

I guess what im trying to say is that XBMC can be a media manager in itself as it does everything those programs do... I just think there should be a way for XBMC to scrape all the data it needs for newly discovered media and export that data directly in the media's directory rather than storing it locally on the hardware hosting XBMC (this can be done manually by exporting the library anyways! so why cant it be done automatically when XBMC find new media?).

I understand XBMC needs an internal DB of some sort to categorize that media, but thats all it really needs, the rest could all reside on local directories...
Reply
#6
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).
Reply
#7
(2013-08-11, 15:35)kermyb123 Wrote: I should inform the Plex community about this lag...
And the mythtv people, they store metadata, including images, fanart etc on the backend and it works fine.

As far as lag is concerned I recall a talk at my local lug by the guy who wrote etherboot. In reply to a question "why etherboot" one of the answers was "it's often faster to boot over network than from local disk".
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
#8
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.
Reply
#9
(2013-08-12, 23:57)Ned Scott Wrote: 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.
As an avid user of XBMC with MySQL and several devices, its awesome to hear XBMC will be really pushing ahead in this area, rather than just dipping a toe in the water. So many people have more than one device these days. If its made easy, all of them will be running a shared XBMC setup Nod
If I have helped you or increased your knowledge please click the 'Thumb Up - Like' button to show me your appreciation :)
For YouTube questions see the official thread here.
Reply
#10
(2013-08-12, 23:57)Ned Scott Wrote: 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.
Yes perhaps I did misunderstand what we were discussing. Yes database is essential!
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
#11
(2013-08-12, 23:57)Ned Scott Wrote: 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

..and soon people will be asking "why doesn't Plex over a server/client combo setup?".

I really never understood why "XBMC talking to each other" feature is considered server/client thing. It really is like saying we don't need PVR backend we will have mythTV clients talk to each other and sharing channels.

...I really doubt they will. Firstly, they can already do that. Secondly, people tend to store media in one place not half a movies on bedroom pc and half on htpc in living room.

Let's leave Plex aside - you can have MythTv combo on every pc you use. Trouble is, in 95% of the cases it doesn't really provide efficient solution. So they made a split. Still wanna have both? Install backend and client on the same machine.
My skins:

Amber
Quartz

Reply
#12
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.
Reply
#13
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...
Reply
#14

I agree with Ned Scott that the whole point about a headless server is to optimize the ability to distribute a central databasde over the network, and that this is as well done by connecting XBMC to a proper networked RDBMS (MySQL, Maria, Firebird, you name it). But... There are so many hints ---or should I say whispers?--- in the XBMC community about XBMC's unsatisfactory database or networking performance (for the latter, go no further than a comment by one of the team in this thread) as to make one wonder whether the problem lies deep inside XBMC's inception as a beefed-up XBOX, and is, therefore, not rectifiable. We may not be developers or code hackers but we are all professionals used to work with data residing not on our desktop, and after so many years of this sort of experience without ever noticing the slightest drop in perfromance (as was usual in the old, Windows 3x days) we are very distrustful of statements attributing XBMC's slow response to network latencies or database imperfections.

Reply
#15
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.
Reply

Logout Mark Read Team Forum Stats Members Help
Why not centralize media data where it resides ?0