Comment 8 for bug 1356528

Hi,

> You mean 7 millimeters? The burned area is exactly 7 mm, or ends -
> measured from the center at 29,5 mm.

Urm ... reading again ECMA-167 ...
10.6.1 Sub-divisions of the Information Zone,
Table 1 - End of the Information Zone.
It may vary 70.0 to 117.0 mm.

It talks of diameteri "d 10", though, not of radius.
My fault. 35 mm, then.

Measuring a blank DVD-R with a 1970s Geodreieck ...
29.5 mm is very narrow. Are you sure this DVD was written with
-use-the-force-luke=dao:... ?

> 19 lines in the log. I haven't taken the exact time.

growisofs.c:progress_print() sleeps by poll(2) with timeout 3333.
That's milliseconds. I.e. the last WRITE lasted roughly 60 seconds.

I believe to see in growisofs_mmc.cpp:poor_mans_pwrite64() that
the timeout for DAO should be 180 seconds. The default timeout is
60 seconds.

Well, i am not the author of growisofs, but rather a competitor.
Maybe i misinterpret its timeout settings.

> Now I tested the smaller image with a external drive, with success.
> The drive finishes immediately after the data stream has ended and
> doesn't fill any disc space which is, as far as I understood, against
> the specs. One can see it too on the burned disc: The written area is
> smaller (about 5 mm, or 27,5 from the center)

If this was really a DAO run, then the drive decided to not obey
the specs.
A burn program is supposed to announce the number of payload blocks
and not the minimum disc size. It's up to the drive to write a
compliant track to the medium.

> Maybe the internal drive simply doesn't like dvd-r discs.

At least there seems to be a mismatch of timeout and drive behavior.
One could do experiments in the growisofs source code to enlarge
the timeouts.

> Now I am a little bit lost and thinking about giving up with this topic:
> I have one drive, which fails to write, and another which writes the
> image without errors but not like the specifications want it to be.

The minimum size should be no problem with any computer DVD drive.
Only the brain damaged entertainment video DVD drives are said
to depend on this part of ECMA-267.

After all, the other write type Incremental is the default for
growisofs and my own program xorriso. It does not impose a minimum
size.

> cdrecord at the k3b advanced settings, which worked as well for me

Might be that it has set a longer timeout and that growisofs for
some reason failed to recognize the need for that.

Selfish question: How do xorriso or cdrskin perform ?

  xorriso -as cdrecord -v -dao dev=/dev/sr0 speed=8 fs=32m medien/filme/DVD-ABBILDER/show-musikprojekt.iso

resp.

  cdrskin -v -dao dev=/dev/sr0 speed=8 fs=32m medien/filme/DVD-ABBILDER/show-musikprojekt.iso

> If you want, you can close the bug report.

I hold no admin rank at Ubuntu or Launchpad.

Actually it might well be a bug in growisofs by setting the wrong
SG_IO timeout for the write type.

But growisofs upstream is not maintained any more. So there is few
use in diagnosing the problem, unless you want to run a fixed
growisofs on your machine(s). In that case, i could make proposals.

Have a nice day :)

Thomas