Hi there,

I'd like to set up a small (4 devices) copying machine for simultaneous copying CD-R and DVD-R mainly from image. Images will be self-created CDs and DVDs, so no matter about copy protection or something. I'd think about k3b because my users like KDE much... but I don't have the time to try around much (there's an order waiting...) and I couldn't find anything like "cdrdao can do this" or "use mkisofs". Just nothing... so if you please would be so kind to tell me if it is possible to have an array of 4 simultaneously burning burners burning DVDs or CDs with using Linux/KDE? How much effort would be the setup or is there even a standard way? If you say there's no smooth way and much trying around, I'll have to do it with Win2k for this order and maybe the machine will stay this way forever... you don't want to happen that, do you?

Best wishes & Thanx for reply,
//mc

It'd be pretty simple to do and if it was just a burning machine I wouldn't even install X on it. Just write some shell scripts to make use of mkisofs and cdrecord and then call them remotely from your desktop. The multiple burners part is possible because it's just different devices, easy just specify which one you want to write to and go for gold.

Thank you for your quick answer,
but I forgot to mention: A shell script would be *my* choice, but not the user's choice...
they are accustomed to clickety-click... you surely understand what I mean
So my question directly pointed to something with GUI like k3b... :-)

//mc

So make a shortcut.

To extend on that, you could write the scripts and maybe chuck together a simple UI for them to use as a front end.

Thank you again all for your suggestions, I think this will be the solution. Some scripts, wrapped together by a little web frontend. That's fitting the needs here perfectly.
The machine is now up and running, but I have some troubles with performance.
hdparm -t for the SATA drive reports around 55MB/s, but it's not possibe to burn 3 or 4 simultaneus copies of a 3GB DVD at Doublespeed, After a while the buffer of 2 burners drops slowly until less than 10% and cdrecord drops burning speed to Singlespeed.
These 2 burners are on the "longer" end of the IDE cables, which lets me suspect either there's a problem with cable lengths (somewhere deep in my mind I can remember reading something about it), or with the longer cable always and generally making trouble. If you could please share your observations on this with me/the community or point me to a site where the problem causing this effect is being discussed. The main question is - will (or is there at least a chance) a pair of new (shorter) 80pin IDE cables resolve the problem? The burners are set to UDMA66 which is the highest I could find (or is there an even better setting?) CPU is almost idle at burning, it's just the harddisk which is making lots of noise (and causing a system load of 4 ;-) ). Is there a report tool which displays harddisk usage per second or something? Just to ensure there is no harddisk bandwith shortage, but after studying the effects (2 burners on one IDE controller -> problem; 2 burners on different controllers -> no problem) I think this can almost be consideren proven...

Best wishes,
//mc

they are the slave drives, get a pci ide drive and use one drive per cable

-Joey

No, I have a SATA Harddisk and 4 IDE burners, so the burners are master and slave drives. For testing I connected a master and a slave on the "long" side, but it didn't have any effect.
The configuration I have is:

SATA1 - Harddisk (hde)
SATA2 - empty
IDE Prim. Master - Burner on long cable connection (hda)
IDE Prim. Slave - Burner on short cable connection (hdb)
IDE Sec. Master - Burner on short cable connection (hdc)
IDE Sec. Slave - Burner on long cable connection (hdd)

It shows up that hda and hdd are the slow ones I mentioned before.

//mc

Just to make a quick notice (maybe it helps someone in future):

I solved it, using the experimental -immed parameter for cdrecord. The machine now burns 4 simultaneus copies of a DVD ISO image. So it turned out that the real problem was that the IDE bus was too busy.

Thanks to anyone,
//mc