+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: XBMC "Server" - centralized XBMC management for multiple XBMC devices/platforms? (/showthread.php?tid=37315)
- bradvido88 - 2010-03-25
bradvido88 Wrote:That makes a lot of sense. I like the idea of once an image is downloaded, it should be stored locally in a way that all other clients can access it. Whether it actually gets stored in the database or not is up to team-xbmc, but it makes sense to me to have all my "client" xbmc's get the images quickly from a local site, and then store them in their own cache for ever faster access when using that client.
See here for a more detailed explanation of what i mean http://forum.xbmc.org/showthread.php?p=511623#post511623
- Corban987 - 2010-04-01
I love the sound of this idea, just concerned about storing the images in the data base. Example, I have too many movies, and too many TV Shows.
It takes 2 minutes now for XBMC to load my library on my XBOX's and windows takes about 30 seconds (on an AMD Quad Core 3GigHz Processor). On Windows when I scroll through the covers it can show the first 20-30, then it shows blank icons while the rest of the thumbs are loading. If this was streamed from a database this would be significantly worse. (Due to my library size I am unable to watch movies on my XBOX due to lack of memory)
I am already going to replace my 2 XBOX's and am considering a Intel Atom and the testing I am doing now indicates it will not be much faster than my XBOX's. Whatever solution is decided I would like it to be the fastest especially with large databases.
I just wanted to state that performance needs to be considered and I am sure the developers are considering this, but I think XBMC struggles with large databases now.
- bradvido88 - 2010-04-01
The solution i proposed would still read the images from the local hard-disk cache. However, the images would also be stored in the database, so any XBMC client that does not have them cached already can download them to it's local cache.
Therefore, there would be no performance considerations for reading images as they would not be read directly from the database, except for the initial read of course
- Swifty - 2010-04-01
jmarshall Wrote:In theory there'd be nothing stopping you storing the thumbs on the same server as the database - the database will contain a URL to the current thumb, so that URL certainly could be on the machine the database sits on, assuming that the URL makes sense to each of the clients. All the clients see, after all, is the URL. In this sense, it's identical to that URL pointing to a thumbnail next to the media file.
This sounds like the best solution so far, rather than storing the images inside the DB it-self.
I am running the DB on my NAS at the moment so I guess if we started chucking the images inside the DB it would probably get too large for the RAM on NAS type devices ?
I we can get them just locally stored on the disk and have a 'pointer' so that clients know where to pull them from that would seem to be the best choice.
- bradvido88 - 2010-04-01
True. However, the nice thing about storing them in the database is that the process of retrieving them is OS-independent. You don't have to worry about different OS path styles and structures, or if you should use a "/" or "\" etc.
That being said, I'm sure that it won't be terribly difficult to manage the paths across different operating systems.
Both choices are good solutions in my mind.
- rcoops - 2010-04-01
Putting the images in the database sounds like a good thing, but the main problem is that you will run into a lot of problems as mentioned with devices that are not able to handle this memory wise.
In the end it should not be that hard to send a file over a TCP line, paths only become interesting as long as one assumes the client to be initiating the transfer. But if the client requests the data and the server "stream" the data to the client there is no longer an issue all the server would have to know is where it stored the file locally and all the client would have to know is that it wants to have the image associated with file ID xxxxxxx.
Just my idea of course but I am sure that there is a better more memory and CPU friendly way to store and send the files then putting them in the DB.
- gbdesai - 2010-04-01
rcoops Wrote:Putting the images in the database sounds like a good thing, but the main problem is that you will run into a lot of problems as mentioned with devices that are not able to handle this memory wise.
In the end it should not be that hard to send a file over a TCP line, paths only become interesting as long as one assumes the client to be initiating the transfer. But if the client requests the data and the server "stream" the data to the client there is no longer an issue all the server would have to know is where it stored the file locally and all the client would have to know is that it wants to have the image associated with file ID xxxxxxx.
Just my idea of course but I am sure that there is a better more memory and CPU friendly way to store and send the files then putting them in the DB.
It'll be interesting to see how the Plex team chose to solve this problem, if they did it well, I may have to go back to Plex, it's a big issue for me... Here's a preview of what they are doing...
The Road to Alexandria Part 1 Introduction/
- jmarshall - 2010-04-01
They solve it by doing a closed source implementation. It's served using XML over http. Essentially it's similar to using UPnP, but is only useful with Plex and not with anything else.
I believe they allow streaming of the media file (just like upnp) over that same http connection.
Just using an existing standard like UPnP seems like a better idea to me. It can handle all the metadata you want, and the files are streamed over http so no problem with paths etc. No need to reinvent the wheel.
Cheers,
Jonathan
- gbdesai - 2010-04-02
jmarshall Wrote:They solve it by doing a closed source implementation. It's served using XML over http. Essentially it's similar to using UPnP, but is only useful with Plex and not with anything else.
I believe they allow streaming of the media file (just like upnp) over that same http connection.
Just using an existing standard like UPnP seems like a better idea to me. It can handle all the metadata you want, and the files are streamed over http so no problem with paths etc. No need to reinvent the wheel.
Cheers,
Jonathan
Yes, that makes sense. I guess I'd always prefer an XBMC option over Plex if all thing were equal. I only went to Plex when it had features (like Harmony remote support and a bunch of other things I couldn't get with XBMC). I am not switched back to XBMC with two Mac Minis and now an ACER Revo Win7 machine which works great. I'd love to see XBMC evolve to include a server component, mainly for centralized library management. I much prefer options when it comes to hardware (I really wanted to avoid the Mac route, but did it because of Plex). Anyway, maybe too much tangential information for the topic at hand.
Bottomline, I would love to see something beyond the MYSQL shared database support offered today by XBMC. Not a demand, just a wish (that'd I'd be willing to donate well for).
- vidkun - 2010-05-07
Not sure what the latest status is of this and I've seen a few suggestions that come close to mine. I wanted to give a bit of a more detailed suggested implementation though, so here it goes.
Using a SQL db, initial setup would go as such:
Open an XBMC instance and add a media source as normal. XBMC still using it's normal operation would scan the source and import all the data to its db which would be the central SQL db in this case. During this initial scrape, it would download all the fanart, info, cast photos, etc, etc and store them inside the SQL db as well (store the actual files and data instead of a URL pointer). However, when importing the files into the db it adds a timestamp field for each file/description as well. Just to clarify, it is only storing fanart, descriptions, etc in the database and not any of the media. The media would remain locations as is currently handled.
Then when a XBMC instance is run, it goes out to the SQL db, pulls down all the fanart, descriptions, and media locations, thumbnails, etc. and cache them locally. This way when running the XBMC it doesn't have to load the thumbnails from the db each time. It can pull the local cache much quicker. This way there are no individual files strewn across media folders and such. The media folders contain the media only and all this extra stuff is kept cleanly in a separate central location.
Then when a user initiates a rescrape from any of the XBMC instances that are connected to the SQL db, XBMC would compare the timestamp of the files in the db to what is available from the online source to see if it is newer. This may be an issue if there's no way to compare the timestamp of the online data. In that case, perhaps a rescrape just rescrapes all data regardless.
Similarly, an initiated update library would compare the timestamp of the files in the SQL db to the timestamp of the files in the local cache. If the SQL db file is newer than the local cache, then XBMC pulls down the new file and updates the local cache with it. Otherwise, it ignores it and moves to the next file.
A benefit to this method is that, with XBMC being open source and open about its methods, third party media managers such as Ember Media Manager or Media Center Master could hook into this same SQL db and write their files to it for you. Then you can keep your media collection and all related fanart, etc centrally managed and maintained using any media manager you choose. And bringing up a new XBMC instance is as simple as pointing it to use the SQL db and running an update library. It would then pull all the media locations (don't have to bother adding the media source in the new instance as it would pull it in from the db), fanart, thumbnails, etc down and cache them locally. And bam, you're up and running on your new instance in two easy steps.
Thoughts?
- TeknoJnky - 2010-05-07
I was wondering if something like was feasible...
a fat, high powered xbmc server
very lightwight clients
use VNC or some other remote desktop/remote app virtualization technique to render on the server and stream to thin client.
something similar to how they stream WOW to ipad
- tvdb-scott - 2010-05-08
TeknoJnky Wrote:I was wondering if something like was feasible...
a fat, high powered xbmc server
very lightwight clients
use VNC or some other remote desktop/remote app virtualization technique to render on the server and stream to thin client.
something similar to how they stream WOW to ipad
In case anyone hasn't seen it, the WOW on the iPad is similar to OnLive's upcoming service (http://www.onlive.com/), but more hacked together. Wouldn't work for a first person shooter nearly as well, and wouldn't work well for video. OnLive's service has some custom hardware they're using to achieve good results with shooters/video/etc. I'm guessing it's hardware and drivers that take output from GPU's and encodes it for streaming. The inputs would simply be passed through along with that.
Personally I'd be happy with a centralized database with web interface for everything, since hardware capable of playing even HD video isn't hard to come by these days.
- EGOvoruhk - 2010-07-27
+1
I would love something like this. I've got my home server, and I would love to just install a base install of XBMC on it, and then have all of the other XBMC units that are connected to TVs throughout the house grab settings and cached info from the main server. Bonus points if it were all automated, like if XBMC Live searched for an XBMC server on boot and loaded pre-set configs. It would make everything such a breeze, especially testing new releases
A man can dream, can't he?
- ringgh0st - 2010-07-28
EGOvoruhk Wrote:+1
I would love something like this. I've got my home server, and I would love to just install a base install of XBMC on it, and then have all of the other XBMC units that are connected to TVs throughout the house grab settings and cached info from the main server. Bonus points if it were all automated, like if XBMC Live searched for an XBMC server on boot and loaded pre-set configs. It would make everything such a breeze, especially testing new releases
A man can dream, can't he?
2 men are dreaming
- darkscout - 2010-07-28
jmarshall Wrote:They solve it by doing a closed source implementation.
http://github.com/elan/plex/commits/v0-8-5