Realistic Maximum Number of Drives in Batch Ripper

[MTWolf]

dbPowerAmp 14.2/Batch Ripper 1.5/WinXPsp3/AMD 8 Core 3.1g/4gigs Ram/C: SSD

I'm tweaking up a system where I have 9 composer Pro's running on one System. I'm running into some odd behavior in Batch Ripper when I do a run with all 18 Drives. It maxes out the page file at about 5gigs (the machine has 4g of ram) and then Batch Ripper hangs. The processes it started continue to run and complete but once they are all finished batch Ripper just sits and won't update the screen. If I take out 4 drives (2 robots) then it works a lot better.

During a run with 14 drives it maxes out the CPU but the OS (Win XP) is still usable and it runs with page file usage at about 3.5gigs (task monitor). But it slowly creeps up and then starts to thrash. The problem seems to come from too many CoreConverters getting spawned and they cause the system to thrash (in the current run there are 43 CoreConverters in memory).

Is there a way to limit the number of CoreConverters to 1 per drive?

So what is the Real limit on the number of drives Batch Ripper can handle?

[Spoon]

Re: Realistic Maximum Number of Drives in Batch Ripper

I would never go above 8 drives per single system, computers are cheap these days.

[MTWolf]

Re: Realistic Maximum Number of Drives in Batch Ripper

Since I had the time, Hardware, and insanity, I did some testing.

On WINDOWS 8 x64 with 8gbs of ram, an 8 core amd at 3.2g, 3 - 1394 cards, and 9 usb serial ports, dbpoweramp 14.3, I was able to get 9 Primera Composer pros (dual drive 100 disk) to run. The system didn't thrash, and the overall speed of the ripping was not impacted. So it seems that this setup will work.

There are some caveats; seems that the old BPRec drives that were used don't play nice when they hit a bad disk, and lock up the 1394 buss. I'm using my composer controller (load/unload/reject/pre/post). There are issues caused by the "Change Spindle" message, In windows 8 the message is treated as modal and blocks access to the batch ripper screen. I don't remember it being that way in XP. The boot drive is ssd so the load of coreconvert and the Controller are very fast. There is alot of tuning needed to make this work.

One note that might save some one else some time. If you see a drive that sometimes "disappears" during a run, it's the cd drive and not the 1394 interface. It seems a drive will go bad in such a way that the drives interface will lock up. It looks like CMOS overshoot lockup, the drive is still functional, it responds to the open/close button, but the computer won't see it any more and the 1394 interface shows up in the device list as code 10. I've done the testing and the problem follows the drive not the interface.

For those who haven't tried windows 8, it's different but really fast and it's the XP of the win98 family, if you can remember what that was like.