Do you know how to tell cdrecord not to reload the media (if the cd tray is open)? Because it would be nice for my purposes to eject the cd so that it's obvious that something is done, but then still be able to query everything to see if there is an available drive.
There might not be a flag for this (unfortunately). And I really would prefer not having to customize cdrecord for my project.
Thanks,
John
=:->
Miguel Figueiredo wrote:
Hi,
To check if there is valid media i check de output of
cdrecord -atip dev=x,x,x
But this does not tell you if the cd has data or not. Maybe trying to mount the filesystem...
This is my approach to the problem. Clumsy but works ;)
As for the rest of your problem I don't have a clue.
Hope this helps a bit.
Miguel
On Wednesday 11 December 2002 17:02, John F Meinel Jr wrote:
Hello to all-
Is there an easy way to tell if I can use a particular drive for burning
a CD? Basically, I'm trying to set up a web front end for CD Recording
here at work. We have a machine with 4 writers on it, and I want to
allow a user to submit jobs to be recorded into the queue. Then as the
drives become available, it will start recording. So I need to know if
the drive is in use, and if it has media. I also want it to be robust
in case someone comes along and starts their own burn outside of my
program. I suppose I could just do a ps | grep cdrecord to determine which
drives are currently in use. However, I still need to know if there is
valid media (perhaps the last person when they went to pick up their CD
didn't put it back in the drive)
I also know that if a burn is in progress (not in the wait time, but
actually in the burning stage)
cdrecord -checkdrive will report that there are no supported modes.
I know if I do cdrecord -dummy -v ..., it will not burn, but will
attempt and will try to detect media, etc.
However, this waits for 9 seconds to do an test burn before exiting. I
suppose I could send a ^C into the stdin, it just in general seems like
a clumsy way to do it.
I realize this is a little unorthodox of a situtation, but if I get it
working, it could be pretty useable.
The basic flow for those who are interested...
A web front end (written in python) that allows users to submit new
entries into the queue, browse the queue, remove entries from it, etc.
The front end requires the user to log in as well as supply an email
address so they can get notifications.
Then a cron job runs every minute and checks to see if there are any
entries that haven't been burned yet. It then checks the list of drives
for the first available one. If it doesn't find any, it will leave the
item in the queue and wait. If an item has been in the queue too long,
it will send an email back to the user saying it hasn't been able to
fulfill the request yet.
If there is an available drive, it will create 2 new processes. mkisofs
and cdrecord. mkisofs will be run as the user (to prevent the user from
burning to disk things that they shouldn't be able to see), but cdrecord
has to run as root (at the very least setuid root, but might as well
stay root)
I'm not sure if I'll need to finish mkisofs before starting cdrecord.
That will depend on network latencies, but I'm thinking to just give
cdrecord a fairly large fifo buffer (like 10-20MB) and see if that
works. We use a fairly underused 100Mb network, so I think it will be
able to handle it (although with 4 burns going at the same time, I'll
have to play around a little.)
That reminds me, I'm also getting some weird results when trying to burn
two CDs at the same time. Basically if the drives are on the same IDE
channel it gets REALLY flaky. In general it seems that when one of the
burns finishes it will cause a 'scsi' error on the other drive.
Any suggestions on how to fix this? I already have 1 add-in IDE
controller so I have 4 available IDE channels (the hard-drive is on 1,
so that leaves 3 free). And I'd really like to be able to use all 4
drives at the same time. Especially since eventually we'll move to DVDs
which means much more time waiting for finished disks.
Thanks for any help,
John
=:->
PS> I would consider releasing this if there is any interest. It's
really only going to be a collection of about 10 python scripts. So I
don't know if it's a big enough project to be worthwile.
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
