[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: