Is there a possibility, to build support in for multiple-cd-drives?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Incert at least 2 audio cd's into your drive's.
2. Start the ripper proces.
3. It stops after the first cd is done, and does not go on with the second.

What is the expected output? What do you see instead?
The output look's OK. But if you connect four cd drive on to the ide ports
or seven cd drives on a scsi controller, rubyripper does not support these.
In that case you have a multiple-cd system like a cd-rip-tower or cd-jukebox.

What version of rubyripper are you using? On what operating system? Are you
using the gtk2 or the commandline interface?
The svn version running on Ubuntu Hardy. Using the commandline interface

Please provide any additional information below.
Created this case.

*So it rip the songs on the cd-drive, goes to the second one and rip the
songs on the cd-drive, and goes drive by drive. 
*It got to check there's a audio-cd in the next drive, otherwise skip
the one and go on to the next one.
*It got to check a audio-cd in the drive is done or refreshed.
*Create a looping, if the last one is done, start all over.
*There got to be a way to register the cd-drive devices, setting like
cdrom=/dev/hdc,/dev/hdd, etc or /dev/sg0,dev/sg1 op to 7 drives.
*There are drives for 1 cd and there are ones for 4 or 5 cd's. These
drives work the same as a drive with one cd. Scsi sees these as sgN.

Original issue reported on code.google.com by fberc...@xs4all.nl on 26 Nov 2007 at 10:45

[GoogleCodeExporter]

In fact you'd like to have an autobatch mode with a loop possibility for the 
cli 
frontend? This should not be too hard to implement. Any idea how the options 
should 
be named or behave?

Something like ./rrip_cli --batchmode --loop --devices=/dev/cdrom0,/dev/cdrom1 ?

Original comment by rubyripp...@gmail.com on 28 Nov 2007 at 6:21

• Changed state: Accepted

[GoogleCodeExporter]

These by cli are well named, I am happy. Let us hack this in and we can do some
testing. I will be in direct contact. Improvement for checking, etc etc ... is 
later
possible.

Original comment by fberc...@xs4all.nl on 28 Nov 2007 at 9:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Check1: The --batchmode can not be set without using --devices=
Idea: --batchmode-devices=
Check2: The --loop will only run if there is a batch set.

Original comment by fberc...@xs4all.nl on 28 Nov 2007 at 10:06

[GoogleCodeExporter]

I think what one would really want is the ability to rip multiple cds in 
parallel! 
So  you just put two cds in and it does both at the same tmie, then pops them 
out
when done, and lets you put in new ones as soon as each one is popped out 
(doesn't
have to wait for both.)

Original comment by samsli...@gmail.com on 5 Dec 2007 at 3:56

[GoogleCodeExporter]

With the SATA interfaces these days, this would indeed offer some advantage. 
Perhaps I'll get it in the user interface too. It will take some time, but I'll 
implement it sooner or later. However, I don't think this should have top 
priority.

Original comment by rubyripp...@gmail.com on 31 Dec 2007 at 6:19

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Issue 314 has been merged into this issue.

Original comment by rubyripp...@gmail.com on 24 Jun 2009 at 6:02

[GoogleCodeExporter]

The temp dir is made unique with the freedb id number. Only drawback is that 
when you
disable freedb this solution won't work.

Can anyone test if ripping with two instances of rubyripper open (with each
configured it's own drive) acts now as expected? At least one drive should have 
a
SATA connection. Multiple cores for the cpu are also recommended (if you want
improved speed).

Original comment by rubyripp...@gmail.com on 30 Jun 2009 at 5:18

[GoogleCodeExporter]

This is fixed as reported in issue 314.

Original comment by rubyripp...@gmail.com on 11 Jul 2009 at 8:16

• Changed state: Fixed