[LINUX] xbmc server: possible quick implementation?

  Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
Targettio Offline
Senior Member
Posts: 160
Joined: Aug 2010
Reputation: 0
Post: #31
Hey, I have just tried to start it up for the first time and got this:

http://pastebin.com/0wKwUNV2

From what I understand of it, it is still trying to access a share config file which doesn't exist... It then just sits there stuck at that point.

Edit, d'oh, its actually working. I just need to turn the webui on and set the port to one that wasn't in use...

Now I just need to set up and auto start script and I am pretty much done Big Grin
(This post was last modified: 2011-12-22 17:38 by Targettio.)
find quote
Robotica Offline
Banned
Posts: 1,202
Joined: Aug 2010
Post: #32
bladesuk1 Wrote:i would imagine that they're busy putting the finishing touches to eden, so it might get some love later. but yeah, you'd think that there might be a bit more interest given the number of requests made for this functionality!

No, I don't think so. This feature has been discussed before and this topic is the best resource. It refers to a wiki-page with some related plans.

To go short: this is not the solution team-xbmc has in mind; they didn't bother to respond to this topic and your PR.. But I don't believe your PR has any change for inclusion. But as a temp. solution it has potential.

How I see the optimal solution (like Topfs described):
- Many of the wanted features (like VFS, database, scanning, scraping) should become libraries.
- Then only JSON API could be running and via i.e. HTTP-Post those libraries could be triggered with some parameters to invoke the functionality.
(This post was last modified: 2011-12-22 18:19 by Robotica.)
find quote
Targettio Offline
Senior Member
Posts: 160
Joined: Aug 2010
Reputation: 0
Post: #33
I have it up and running, but it seems to be using an older version (57) of the database schema to the lastest pre-eden version I am running (58).

Which means, things I change in the server version does not carry over to HTPC version (and visa versa).

Maybe it would be worth waiting for eden to get released and then work from there? (unless there is a way to fix this?)

Also, I am not sure how you set the scrappers via the xmls? The sources.xml just list the paths/names and the guisettings.xml only list the default scrappers. Any one able to help here?
find quote
vikjon0 Offline
---
Posts: 2,465
Joined: Apr 2009
Reputation: 7
Location: Sweden
Post: #34
Quote:but to me it looks like a poor man's solution.
Sure, as discussed a better solution would be to break out a set of functions from xbmc that can be used on the server. Scrape, webinterfase etc.
However, I do not see any rich men working on that?

Meanwhile, there seem to be no cost to "client XBMC" if this is added?

How much system resources is wasted with this solution compared to a better designed solution? As long as the target platform is intel servers memory is cheap.

Quote:Although, it would be nice to have some sort of GUI for this "mode"
Most stuff can easily be added to a webinterface such as editing guisettings. Only xbmc probably have to be restarted.
find quote
Targettio Offline
Senior Member
Posts: 160
Joined: Aug 2010
Reputation: 0
Post: #35
vikjon0 Wrote:Sure, as discussed a better solution would be to break out a set of functions from xbmc that can be used on the server. Scrape, webinterfase etc.
However, I do not see any rich men working on that?

Meanwhile, there seem to be no cost to "client XBMC" if this is added?

How much system resources is wasted with this solution compared to a better designed solution? As long as the target platform is intel servers memory is cheap.


Most stuff can easily be added to a webinterface such as editing guisettings. Only xbmc probably have to be restarted.

I am sure the devs will work on the full server mode in time, but it isn't likely to be a quick turn around (that's not a pop at the devs, just these things take time). As you say, this is a 'zero cost' temporary solution, which is why it is great.

Setting it up without any form of ui is a little more involved than normal, but a HOW-TO on wiki would solve that problem.
find quote
Fuwex Offline
Junior Member
Posts: 10
Joined: Oct 2009
Reputation: 1
Post: #36
This is a great idea! I'm planning to set up a distributed system with a central database. I'm interested in how CPU usage looks on my old and weak server.

I was initially looking into breaking the video/music library parts out from the XBMC source to create an external utility to update the XBMC library, but quickly found out that it was way too much work. This is a much simpler (though not optimal, as pointed out) temporary solution that, provided it's not too much of a system resource hog, works well until hopefully some day a better approach is in place.

Looking forward to testing it out! I'll report my findings on system resources once I've had the chance to test it out on my (linux) server.
find quote
bladesuk1 Offline
Junior Member
Posts: 32
Joined: Jul 2011
Reputation: 0
Post: #37
Fuwex Wrote:I was initially looking into breaking the video/music library parts out from the XBMC source to create an external utility to update the XBMC library, but quickly found out that it was way too much work. This is a much simpler (though not optimal, as pointed out) temporary solution that, provided it's not too much of a system resource hog, works well until hopefully some day a better approach is in place.

funnily enough, that was my initial thought process for this hack, too. and yes, i also abandoned that because of the amount of effort involved and because of my limited C++-fu skills Smile i think that if it had been architected as a service it would have been trivial to implement this, but for whatever reason the dev team didn't take that approach, and for me to refactor the volume of code involved just isn't realistic. equally, though, i didn't want to create another project that would have to maintained in parallel when the database code seems to change as regularly as it does. that really needs to be pulled into a separate library so it can be reused elsewhere. but, like i said, beyond my skill level and would take more time than i currently have to spare!
find quote
Odon Offline
Member
Posts: 74
Joined: Apr 2010
Reputation: 0
Post: #38
Hi, thanks a lot for the patch. Seems to be working correctly in a Debian virtual machine without GUI. But I have one issue. XBMC is taking 100% CPU :/ Probably a process loop, but any idea how to reduce CPU consumption in headless mode ?

edit: patch in latest Git (post 11b1)
(This post was last modified: 2012-01-08 15:16 by Odon.)
find quote
Robotica Offline
Banned
Posts: 1,202
Joined: Aug 2010
Post: #39
Odon Wrote:Hi, thanks a lot for the patch. Seems to be working correctly in a Debian virtual machine without GUI. But I have one issue. XBMC is taking 100% CPU :/ Probably a process loop, but any idea how to reduce CPU consumption in headless mode ?

edit: patch in latest Git (post 11b1)

Sorry, but which patch?
find quote
Odon Offline
Member
Posts: 74
Joined: Apr 2010
Reputation: 0
Post: #40
Robotica Wrote:Sorry, but which patch?

I've hand-patched xbmc latest git with bladesuk1 Repo commit.
find quote
Robotica Offline
Banned
Posts: 1,202
Joined: Aug 2010
Post: #41
great! Can you share that solution so it's easier for people to also try this? And did that reduce your CPU usage?
find quote
Odon Offline
Member
Posts: 74
Joined: Apr 2010
Reputation: 0
Post: #42
Sorry, you have misunderstood me. I still have Cpu issue. Regarding patch, I've just downloaded 11b1 source, patched then compile.
find quote
vikjon0 Offline
---
Posts: 2,465
Joined: Apr 2009
Reputation: 7
Location: Sweden
Post: #43
and if you run the patched version on a standard HTPC, does the CPU run normal? I mean you may want to isolate the issue since it is not a stable version. and how does the un-patched/patched run in virtual debian WITH GUI?

EDIT: The standard beta also run 1 CPU at 100% constantly on virtual ubtuntu (vmware). Of course, if that is the graphic it doesnt mean anything.
(This post was last modified: 2012-01-08 19:01 by vikjon0.)
find quote
bladesuk1 Offline
Junior Member
Posts: 32
Joined: Jul 2011
Reputation: 0
Post: #44
vikjon0 Wrote:and if you run the patched version on a standard HTPC, does the CPU run normal? I mean you may want to isolate the issue since it is not a stable version. and how does the un-patched/patched run in virtual debian WITH GUI?
EDIT: The standard beta also run 1 CPU at 100% constantly on virtual ubtuntu (vmware). Of course, if that is the graphic it doesnt mean anything.

as far as i can tell, patched/unpatched versions both take up an entire cpu permanently. i suspect that this is likely to be something buried in the code somewhere, but if i get a chance i can start taking a look through it to see what i can find. like i said earlier, all i've really done with this patch is to remove the requirement for the front-end display, so everything else is still running. if there's something that's permanently running and taking up a cpu, then it's still going to be there.
find quote
bladesuk1 Offline
Junior Member
Posts: 32
Joined: Jul 2011
Reputation: 0
Post: #45
Targettio Wrote:I am sure the devs will work on the full server mode in time, but it isn't likely to be a quick turn around (that's not a pop at the devs, just these things take time). As you say, this is a 'zero cost' temporary solution, which is why it is great.
Setting it up without any form of ui is a little more involved than normal, but a HOW-TO on wiki would solve that problem.

to be honest, i'm not sure that the devs are interested as it's going to need a full redesign of the way the back end is coded to do it 'properly'.

as to setting it up, the easiest way is to simply copy the settings files across from a known good source. that way, you can use the graphical front-end to do any tweaking that you like, and you're good to go.
find quote
Post Reply