Re: dvd+rw-tools update [6.0, DVD-R DL]
- internal ring buffer to harmonize the rates at which data is produced
and written(**);
top reports growisofs gained 32 MB of weight. (The difference
between RBU 92.2% and RBU 37.0% is 18513920. That matches.)
Isn't 32 MB a bit greedy as default buffer size ?
Well, it's definitely wasteful for 4x recordings, but it's at the edge
for 16x [I reckon]. So it's kind of a trade-off decision targeting
average Joe who commonly have loads of RAM anyway and can afford 32MB
temporarily "taken away." In other words yes, you can say that 32MB is a
bit greedy:-)
Would it be possible to get a ring buffer size option ?
-use-the-force-luke=bufsize:8m or whatever larger than 1m you consider
appropriate.
About -use-the-force-luke=noopc :
I lost a dozen DVD-RW meanwhile with
:-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h]: Input/output error
Will they get a new life by this option ?
I don't know (and it's actually stands at the very end of -RW companion
page:-)
Can you tell me something about your motivation to introduce it ?
Trouble is that no specification tells what is "the right thing(tm)" to
do and checking for profile in READ DISC INFORMATION structure and
asking for OPC if none is found appeared as appropriate thing to do. By
the time nobody objected, nobody commented, and I myself had *never* had
problems with OPC. But user reports suggest that sometimes [presumably
with some specific firmwares] it helps to skip it, even though 3/73/03
smells "unsupported media." Users actually suggest to perform OPC, but
ignore all OPC errors no matter what they are. I consider the option to
skip OPC altogether is more appropriate.
What about -use-the-force-luke=noload ?
Does it work now ?
No, it doesn't. :(
I'll have to look into it...
Is there still the old reason not to leave the tray in
after writing under any circumstances ?
I suppose we're talking about Linux [keep in mind that the requirement
is system-specific and most of other system don't require reload]. Is
there other way to *reliably* detect that block buffer is guaranteed to
be purged? "Other" refers to one implemented now, ioctl
(fd,CDROM_MEDIA_CHANGED,CDSL_CURRENT)... I can check latest Linux kernel
sources...
If not: since what version of growisofs is it possible
to risk the tray staying in and somebody reading from the
DVD. (I remember some ugly freezes 3 years ago. You then
introduced the in-out ballet of the tray.)
Tray reload is meant to purge the block buffer, which [if not purged]
can appear as corrupted data to user. I don't recall any freezes... I
can imagine some firmwares can freeze [or cause kernel to freeze], but
that is beyond our control [broken firmwares that is].
As for DVD-R DL. I've got quite discouraging results when testing
Some reports about experiences and recommendable growisofs
options for DL media would be welcome.
Is this the question to me? Because I think it's answered on my page: no
matter what you do [-dvd-compat or not] it comes out unappendable. My
limited tests show that incremental recordings [no extra options
whatsoever] are more compatible than DAO [-use-the-force-luke=dao]. I
know it contradicts the DVD Forum's promises, but it might be just
concidental. Which is why I think that the question should target the
community, not me personally.
I received some questions
about DL from my users recently and could only point to the changelist
in growisofs.c 5.21.
Now you lost me. 5.2x supports only DVD+R DL, while I thought we were
discussing DVD-R DL. As far as DVD+R DL goes, everything that applies to
DVD+R applies to DVD+R DL [except that with -dvd-compat you have an
option to specify layer break position, but that is of interest only
when duplicating DVD-Video, hardly for archiving application such as
scdbackup]. A.
Reply to: