growisofs BD-R overflow error despite capacity check

[Thomas Schmitt]

Hi,

firstly: thanks for taking care of
  https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1113679

Secondly: I hate to say it now, but i think a Debian user
just complained about the problem's little brother:

  http://forums.debian.net/viewtopic.php?f=10&t=120566

reports that an oversized burn attempt used up the
medium and finally ended by

  :-[ WRITE@LBA=b87400h failed with SK=5h/END OF USER AREA ENCOUNTERED ON THIS TRACK]: Input/output error

I believe that the not-yet-aware bug reporter in
forums.debian.org tried to squeeze data for the capacity of
an unformatted BD-R into a then formatted BD-R with not
enough capacity.

growisofs.c has code to prevent the start of such a burn:

  off64_t capacity=0, ... ;
  ...
    if (ioctl_handle!=INVALID_HANDLE)
        capacity = get_capacity (ioctl_handle);
  ...
        if (capacity && progress.final > capacity)
        { fprintf (stderr,":-( %s: %"LLD" blocks are free, "
                            "%"LLD" to be written!\n",
                            ioctl_device,
                            (capacity-outoff)/2048,tracksize/2048);

  ...
        pwrite64_method = poor_mans_setup (ioctl_handle,
                                           outoff+tracksize);

But the BD-R gets automatically formatted not before the
call to growisofs_mmc.cpp : poor_mans_setup()

        case 0x41: // BD-R SRM
            if ((disc_info[2]&3) == 0) // blank
                bd_r_format (cmd);

This lets the capacity shrink from 25,025,314,816 to
24,220,008,448 = 0xb87400 * 2048.

I will have to think about possible remedies.
Problem is that one has to reliably predict the formatted
capacity in order not to format the BD-R and to then say
"Hey ! Now your data do not fit any more !"

But that would mean to derive a predictor function
from bd_r_format(). This will not be as small a patch
as the one in bug 1113679.
And not be developped in half an hour, i fear.
It does not only have to predict the size but also
whether auto-formatting will happen at all.

In any case i'd need a tester who's willing to burn
a few tightly filled BD-R (hopefully sucessfully).

Have a nice day :)

Thomas

[Federico Tello Gentile (federicotg)]

It is not that simple.
The same burn that failed with growisofs here

https://bugs.launchpad.net/ubuntu/utopic/+source/dvd+rw-tools/+bug/1113679/comments/13

finishes correctly with cdrecord.

Both burns where done with K3B in the same system. K3b can use any of growisofs or cdrecord. I used 2 blank BD-R from the same spindle and burned exacly the same 3 files into them.

I have burned ~ 50 BD-R using K3B with cdrecord and they all burn flawlessly at 4X (1 GB/s). K3B using growisofs (besides never burning correctly), burns at 2X (and reports it as 4X) while keeping the burner's hardware buffer below 50%.

K3B with drecord keeps is at 97+% all the time while burning.

Basically growisofs is useless for BD-R. CDrecord should be the default or at least an easy to use option. Right now (and since BD-R where invented) you need to add a PPA and use K3B to actually burn BD-R.

[Thomas Schmitt (scdbackup)]

Hi,

> It is not that simple.
> The same burn that failed with growisofs here
> https://bugs.launchpad.net/ubuntu/utopic/+source/dvd+rw-tools/+bug/1113679/comments/13
> finishes correctly with cdrecord.
> [...] they all burn
> flawlessly at 4X (1 GB/s). K3B using growisofs (besides never burning
> correctly), burns at 2X (and reports it as 4X) while keeping the
> burner's hardware buffer below 50%.
> K3B with drecord keeps is at 97+% all the time while burning.

That's all because cdrecord does not automatically format
BD-R before writing. (Neither do libburn based programs
like xfburn, cdrskin, or xorriso.)

You can achieve the same effect with growisofs by option
  -use-the-force-luke=spare:none

In previous versions of K3B there was a menu to set
options for backend programs ... "Setup External Programs",
"User Parameters".

> Basically growisofs is useless for BD-R.

Ah no. I am a competitor of growisofs, but would not say
that. Actually growisofs has more clue about the MMC
aspects of BD media than cdrecord.

It's just that Andy wanted to be smart with auto-formatting
and regrettably quit maintaining of growisofs before he
could iron out the consequential bugs.

Have a nice day :)

Thomas

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.