Ability to throttle background processes? - Printable Version +- Forum (http://forum.xbian.org) +-- Forum: Software (/forum-6.html) +--- Forum: Testing & Experimental (/forum-21.html) +--- Thread: Ability to throttle background processes? (/thread-521.html) Pages: 1 2 |
RE: Ability to throttle background processes? - CurlyMo - 1st Mar, 2013 01:58 AM It should be pretty simple to implement a direct stop or isScanning function to the API, but as you can see, it isn't really necessary. RE: Ability to throttle background processes? - 2twisty - 1st Mar, 2013 02:06 AM I think one of my big issues with scan time may be database performance. I set up XBMC on my Mac and mounted the media from the pi to the same structure on the mac. I then used the Mac to scan the media (via SMB from the Pi) and it went pretty fast. At least 10-20 times faster than scanning on the pi directly. I then copied MyVideos75.db to the Database folder on the Pi and now all my library is there. So, it gets me wondering... If the slowness in the scan is not the result of NTFS or SMB, I can only assume that it's the performance of the database on the Pi. This is either because the database engine can't do the work at the same time as accessing the file system, or the write speed of the SD card is too slow (I am using a Class 10 card) I may try either a USB install, or simply putting the .xbmc directory on a faster device (hard drive or USB flash) But, just to check my understanding, calling the "scan" function a second time will stop an existing scan? Can you think of any way (system flag or something) that we can tell if a scan is already in progress? Re: Ability to throttle background processes? - rikardo1979 - 1st Mar, 2013 02:12 AM im pretty sure when scan is in progress and you call it again you just get message that scan is in progress. cant say for sure as dont have access to xbmc at the moment RE: Ability to throttle background processes? - CurlyMo - 1st Mar, 2013 02:13 AM No, we need to expose the IsMusicScanning or IsVideoScanning function to the JSON functionality. The best solution is just using the external mysql database functionality. RE: Ability to throttle background processes? - 2twisty - 1st Mar, 2013 02:25 AM Would running MySQL on the Pi be acceptable? I'm trying to eliminate extra machines and use less power and resources. If I have ti run MySQL on a separate machine, I might as well run XBMC on that machine, instead. RE: Ability to throttle background processes? - CurlyMo - 1st Mar, 2013 02:27 AM I just have a data NAS which also runs a mysql database. You can just try running mysql on the RPi. Never tried. Re: Ability to throttle background processes? - rikardo1979 - 1st Mar, 2013 02:40 AM or just get one more RPi and run it as a server only RE: Ability to throttle background processes? - 2twisty - 7th Mar, 2013 12:17 AM OK. I'm gonna try running mysql on the pi to see if db performance is any better. My next option is to get another Pi, I guess. I have plenty of powerful hardware (I have a dual-processor Opteron server with total 16 cores and 24GB of ram at my disposal, so computing power is not an issue), but since I'm trying to find a way to use the least amount of power possible, using that big server is not ideal. A little more background: My wife and I are planning to go totally off-grid within the next 5 years. So, I am learning about power conservation -- without sacrificing technology. I can tell you -- it's a fun exercise sometimes! RE: Ability to throttle background processes? - BartOtten - 7th Mar, 2013 10:22 AM That's cool. Please kepp us informed about everything you have found to minimize power usage Is there some blog I can follow as I really like the idea (although will never do such a thing) RE: Ability to throttle background processes? - 2twisty - 7th Mar, 2013 10:36 AM Well, using MySQL on the Pi seems to be working well. I've installed XBMC on my MacBook and am using it to scan and update the database. Performance testing will have to wait a bit since I am still updating the library remotely. However, I can say that when I am running a background scan (and subsequent scrape) with SQLite, I can't reliably play videos at all. Just WAY too choppy. When using MYSql and having the MacBook to the scan (the files are served by SMB from the Pi) and letting it do the scraping and update over the network, I am able to play video with only the very rarest of interruptions. I'm going to start a new thread in Experimental about lean computing. Ive got some ideas, and I think that Pi users might also be of similar mindset. RE: Ability to throttle background processes? - CurlyMo - 7th Mar, 2013 07:08 PM And what about having MySQL and XBMC on the same RPi? RE: Ability to throttle background processes? - 2twisty - 8th Mar, 2013 12:18 AM Sorry if my last post wasn't clear. I only have one Pi. So, MySQL is running on the same Pi as XBMC. It seems to be doing just fine. The media is connected to the Pi via USB and is exported to the network via Samba on the Pi. MySQL is on the Pi, as is XBMC. I have XBMC on my MacBook scanning the data in the shares over SMB, then it does any scraping needed, and then updates the database over MySQL. It is taking a very long time to scan the data. About the same amount of time that it would take if I had the Pi doing it all locally. However, the huge difference is this: When I scan it all locally, I can't reliably play video while it's doing it. It's just chunky and fails the "wife test" miserably. Right now, she's using the system while the MacBook scans and updates the database. She literally does not know that I am doing that. it's completely transparent to her. There has been the occasional hiccup in playback. However, that could be due to the fact that I was running the entire system in 1080p (see this thread) so I will see how it shakes out now that I'm back in 720p. Right now, I only have the video and music databases handled by MySQL. I may try moving ALL the DBs out of SQLite (can I?) to see if that is a viable thing. If so, you may want to consider modding the XBian distro so that it uses MySQL by default. |