> Guy Macon wrote:
> > David Brown wrote:
> >
> >>larwe@larwe.com wrote:
> >>
> >>>>Currently the host runs Sonic DLA (was Adaptec/Roxio) which is a UDF
> >>>>packet writing driver and a script is used to finally transfer from HDD
> >>>>to DVD (write once media - mandatory!).
> >>>
> >>>
> >>>mkisofs and cdrecord would be my choice. I'm not sure if you can build
> >>>working copies for WinXP, though.
> >>
> >>They certainly work fine for CDR burning under W2K. Prebuilt binaries
> >>are available if you look around (try searching for CDR Front End).
> >
> >
> > http://demosten.com/cdrfe/#description
> > ftp://ftp.berlios.de/pub/cdrecord/alpha/win32/README.win32
> > ftp://ftp.berlios.de/pub/cdrecord/alpha/win32/
> > http://www.geoshock.com/cdrtools/
>
> Thanks to all. I did stumble across cdrecord and mkisofs in my searches
> but it wasn't immediately obvious to me as to whether it can do
> file-at-a-time writing similar to the UDF driver.
>
> I've never had to delve into the intricacies of CD/DVD buring before so
> my concerns about an implementation like this are:
>
> My need is for the retrieved files to be written to the DVD media as
> soon as possible after they are received. This is a customer requirement
> not a technical one. Is this possible with cdrecord?
>
> Are there any special steps that must be taken before the media is
> removed (i.e finalising etc)?
>
> The media is typically re-used until it's full i.e inserted/removed many
> times. Is this possible with cdrecord (I'm assuming some sort of
> multisession operation)?
>
> Thanks for any further suggestions.
>
> Chris.
We did a stand-alone embedded processor based "one touch" CD copier that was
used with a robotic disk change station for unattended CD copying. The unit
supported two IDE channels. One for the CD-ROM source disk and one for the
writable drives.
By adding a Hard drive in place of the CD-ROM source disk, this unit could be
adapted to spool data onto the Hard Drive and then copy data out to the
writable drive.
We did some work with the Buffer Under Run Protection (Burn Proof) on the
writable drives. Our early work inidcated that these drives should be able to
handle streamed data. Data could be streamed into the drive. When the buffers
reached some level, the buffer was released to the writer for transcribing onto
disk. While this approach might be possible, using a hard drive to buffer
records would be more reliable.
It was a great project. Did it first for SCSI and then when the market
shifted, ported it to ATAPI.
Blakely
Reply by Anton Erasmus●June 22, 20052005-06-22
On Wed, 22 Jun 2005 01:10:58 GMT, chris <c@b.a> wrote:
>Guy Macon wrote:
>> David Brown wrote:
>>
>>>larwe@larwe.com wrote:
>>>
>>>>>Currently the host runs Sonic DLA (was Adaptec/Roxio) which is a UDF
>>>>>packet writing driver and a script is used to finally transfer from HDD
>>>>>to DVD (write once media - mandatory!).
>>>>
>>>>
>>>>mkisofs and cdrecord would be my choice. I'm not sure if you can build
>>>>working copies for WinXP, though.
>>>
>>>They certainly work fine for CDR burning under W2K. Prebuilt binaries
>>>are available if you look around (try searching for CDR Front End).
>>
>>
>> http://demosten.com/cdrfe/#description
>> ftp://ftp.berlios.de/pub/cdrecord/alpha/win32/README.win32
>> ftp://ftp.berlios.de/pub/cdrecord/alpha/win32/
>> http://www.geoshock.com/cdrtools/
>
>Thanks to all. I did stumble across cdrecord and mkisofs in my searches
>but it wasn't immediately obvious to me as to whether it can do
>file-at-a-time writing similar to the UDF driver.
I think if file-at-a-time is a requirement you are stuck with UDF. The
only other standard way I know of to write only a little data at a
time is to go multi-session. One wastes a fair amount of space for
each session, and I am not sure how many sessions one may fit
onto a disc.
[Rest Snipped]
Regards
Anton Erasmus
Reply by Guy Macon●June 22, 20052005-06-22
chris wrote:
>Thanks. Do you know how well it handles one file at a time (potentially
>thousands of them) and ejecting & re-using the same media (while there's
>free space on it)?
You can make that work, but it will be a pain, and the result will
not be as reliable as you might wish.
A better solution would be to put a low-cost PC with two hard drives
on the other end of an ethernet cable and use XXCOPY (that's not a
typo; XXCOPY, not XCOPY) to send the data to both.
Reply by chris●June 22, 20052005-06-22
Peter wrote:
> Nero V6 comes with "nerocmd.exe" which can burn CD's & DVD's from the
> command line. I use it as a part of our backup scripts to burn files to
> a DVD-R. The only documentation I can find is the output of it's "help"
> option but it wasn't hard to get working.
>
> Regards
> Peter
Thanks. Do you know how well it handles one file at a time (potentially
thousands of them) and ejecting & re-using the same media (while there's
free space on it)?
Chris.
Thanks to all. I did stumble across cdrecord and mkisofs in my searches
but it wasn't immediately obvious to me as to whether it can do
file-at-a-time writing similar to the UDF driver.
I've never had to delve into the intricacies of CD/DVD buring before so
my concerns about an implementation like this are:
My need is for the retrieved files to be written to the DVD media as
soon as possible after they are received. This is a customer requirement
not a technical one. Is this possible with cdrecord?
Are there any special steps that must be taken before the media is
removed (i.e finalising etc)?
The media is typically re-used until it's full i.e inserted/removed many
times. Is this possible with cdrecord (I'm assuming some sort of
multisession operation)?
Thanks for any further suggestions.
Chris.
Reply by Peter●June 21, 20052005-06-21
Nero V6 comes with "nerocmd.exe" which can burn CD's & DVD's from the
command line. I use it as a part of our backup scripts to burn files to
a DVD-R. The only documentation I can find is the output of it's "help"
option but it wasn't hard to get working.
Regards
Peter
Reply by Guy Macon●June 21, 20052005-06-21
David Brown wrote:
>
>larwe@larwe.com wrote:
>>
>>>Currently the host runs Sonic DLA (was Adaptec/Roxio) which is a UDF
>>>packet writing driver and a script is used to finally transfer from HDD
>>>to DVD (write once media - mandatory!).
>>
>>
>> mkisofs and cdrecord would be my choice. I'm not sure if you can build
>> working copies for WinXP, though.
>
>They certainly work fine for CDR burning under W2K. Prebuilt binaries
>are available if you look around (try searching for CDR Front End).
>
>>Currently the host runs Sonic DLA (was Adaptec/Roxio) which is a UDF
>>packet writing driver and a script is used to finally transfer from HDD
>>to DVD (write once media - mandatory!).
>
>
> mkisofs and cdrecord would be my choice. I'm not sure if you can build
> working copies for WinXP, though.
>
They certainly work fine for CDR burning under W2K. Prebuilt binaries
are available if you look around (try searching for CDR Front End).
Reply by ●June 21, 20052005-06-21
> Currently the host runs Sonic DLA (was Adaptec/Roxio) which is a UDF
> packet writing driver and a script is used to finally transfer from HDD
> to DVD (write once media - mandatory!).
mkisofs and cdrecord would be my choice. I'm not sure if you can build
working copies for WinXP, though.
Reply by chris●June 21, 20052005-06-21
Hi All,
Porbably a bit OT for an 'embedded' group, but it's related to
unattended operation so here goes....
Host system consisting of a PC (Win XP Pro) with DVD Burner that's
connected via TCP/IP to another (slave) node running QNX. Slave node
periodically creates files (eg 2 - 3 per minute, but may extend to 2 - 3
per 24 hours) that buffer on a local HDD. Host checks every 30sec via
ftp for those files and uploads (moves) them to local HDD storage.
Currently the host runs Sonic DLA (was Adaptec/Roxio) which is a UDF
packet writing driver and a script is used to finally transfer from HDD
to DVD (write once media - mandatory!).
The DLA driver is undesirable from several aspects,
- reliability is suspect (unaccounted-for stoppages & write failures)
- requires media to be specially UDF formatted
- requires UDF driver installed on back office PCs to read the data
Is this operation feasible using some other utility/driver combination
that the forum may be aware of? So far my (admittedly limited)
investigation hasn't turned up suitable commandline-oriented apps.
TIA
Chris.