tboooe Wrote:I run Sickbeard adn SAB on my ND-22. Work fine for me though I dont think I ever was watching a movie while SAB unpacked a file. Unpacking is a fairly processor intensive activity so I am not sure what the impact would be while watching a 1080p movie. Overall I have no complaints using the ND-22 in this manner.
Here is the potential issue with mixing xbmc on the same host with SABnzbd (IMO sickbeard from a host perspective is a low impact application with the exception of post processing).
You first need to basically understand video playback (assuming GPU acceleration) is a read intensive process, and while I have not looked at the code, xbmc likely reads a buffer of data starts playing that buffer, and while processing that buffer for display it goes and reads the next buffer of data, etc etc until EOF or some other event tells it to stop. So as long as XBMC can keep the data in the buffer, it can continue to play. Secondarily, as long as it can get the process cycles it needs to process the video it will continue to play the video with out issue.
This is where SABnzbd is potentially a problem. SABnzbd has 3 potential nasty parts to it when it comes to sharing system resources, PAR2, RAR and post processing. PAR2 can shred the CPU and dasd IO and RAR is hard on IO and post processing. When these process are spawned, they start consuming resources if nothing balances those resources it can come at the expense of your other processes like XBMC causing it to buffer or perhaps stop playback. To quote the developer of SABnzbd "Both unrar and par2 are quite good at exposing marginal hardware"
Under *inx, SABnzbd starts these process under nice and ionice so you have the underlying OS managing the process priority and with ionice trying to manage the process from constraining the IO channels. Under windows, you dont have a ionice functionality, and you will want to consider going into the services and lowering the priorities for SAB processes so when they get process intensive they are constrained, but that only gives you some side effect protection from being IO constrained.
Lastly, you have the SABnzbd and sickbeard post processing, these functions may be moving, depending on your configuration, large video files, which can be a potential problem in a multi volume environment.
So basically you are potentially pitting a read heavy process (xbmc) with a set of potentially IO and compute heavy online batch style set of processes, hoping that the OS can manage the constraints to minimize the impact on the user experience of XBMC. I have experienced some inconsistent issues mixing this components, such as video shuddering, buffering or stop of playback when mixed on the same host, but If you desire, you can read more about these experiences on the SABnzbd forum. So if you opt to build such a configuration, IMO linux is a preferred platform, the reason being is as SABnzbd supports ionice for IO management under linux which is not supported by windows, and linux has potentially lower overhead (based on your configuration) so you are starting off with more resources free.
My personal preference it to keep like functional things together, so I choose to keep a separate host that does file/SABnzbd/Sickbeard/etc/etc services. Then I use a content presentation oriented hosts for my display clients, like a nettop, and these hosts primarily only run xbmc. This segmentation makes sure that my display clients are not competing for resources, this way I know I have minimized potential impact, but so much of this will be tied to ones unique usage and expectations.
(new slogan for XBMC)) ... I think I may still consider getting this because there will be few instances when XBMC and Sab are competing for resources... AND I can control when SAB is processing RAR and PAR files in the config...
