[k3b] [Bug 367639] k3b fails to continue multisession (blue ray)

Thomas Schmitt via KDE Bugzilla bugzilla_noreply at kde.org
Sun Sep 18 10:49:24 UTC 2016


https://bugs.kde.org/show_bug.cgi?id=367639

--- Comment #24 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

> please review it https://git.reviewboard.kde.org/r/128932/

My browser seems not to be ready for the layout or your changeset is
much too small.
I only see:

        QStringList ms = d->multiSessionInfo.split(',');
        if (ms.size() == 2) {
            if (ms[0] == 0 || ms[1] == "0") {
                qDebug() << "you don't have to specify -C option, growisofs
will construct one for you!";
                d->process << "-use-the-force-luke=spare=none";
            } else {
                d->process << "-C" << d->multiSessionInfo;
            }
        }

where i wonder who is addressed as "you". Other parts of K3B which
constructed the d->multiSessionInfo content ?

growisofs tolerates a -C option if the second value matches its own
perception of medium and ISO 9660 filesystem.
https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs.c/#L3271

                    } else if (alleged_next_session!=next_session)
                        fprintf (stderr,"%s: -C argument is %s.\n",
                                        argv[0],alleged_next_session>=0?
                                        "insane":"undefined"),
                        exit(FATAL_START(EINVAL));

You need to pass the same -C value to mkisofs as the one which growisofs
will determine (i.e. import growisofs code into K3B and hope that growisofs
stays as it is), or you have to force growisofs to use the -C value which
you computed more freely and gave to mkisofs.
(Possibly/hopefully by growisofs option -use-the-force-luke=seek:N)

Do i get it right that
            if (ms[0] == 0 || ms[1] == "0") {
shall catch "-C 0,0" that was determined by K3B ?

If so, then K3B has probably seen an overwritable medium. In this case it
should have already checked whether an ISO 9660 is present and where it
ends. From that end it should have composed
   d->multiSessionInfo = "0,N"
with N being a suitably rounded 2KiB block number after the end of the
ISO filesystem. 

So when multiSessionInfo hits k3bgrowisofswriter.cpp it should be already
a usable value and should be forced onto growisofs.
As said, the value has to be used with the mkisofs run.

Handing it over to growisofs would be a good check to prevent
misunderstandings between K3B and growisofs. Better growisofs refuses
to start than that it writes an add-on session to the wrong address.

Background:
-C old_start,new_start tells mkisofs to read the ISO superblock at address
old_start and to prepare the output superblock and tree for being written
to address new_start.
Wrong old_start will yield mkisofs abort due to lack of superblock.
Wrong new_start will yield output and no mkisofs error. growisofs will
write the output to medium. But then the new session will not be mountable
or the directory tree will yield i/o errors and/or wrong data file content.
That's because all inner block number fields of the ISO will be wrong.

-----------------------------------------------------------------------

My proposal to use

  -use-the-force-luke=spare=none

was only for the case of blank BD-R media. Those will not have
d->multiSession set while they are blank, i assume. So in the changeset
code the option will not be applied to them.

Background:

If growisofs is ordered to write to BD-R without option ...spare=none,
then it formats them to Pseudo-Overwritable state. Indigestible for
libburn and probably for cdrecord. After the first session the BD-R
will cause -C 0,0 and thus will need the special processing above.

With option ...spare=none, growisofs leaves the BD-R unformatted
and plainly writes the first session to it. (At full nominal speed !)
Then the BD-R resembles much a written DVD+R. Current K3B will be able
to inquire the correct -C values and hopefully perform multi-session
as it hopefully does on DVD+R. (Somebody must test, of course.)

---------------------------------------------------------------------

I can navigate in quickgit.kde.org quite well. So better point me to
code or changesets there.

In general i doubt that i can be of much help with K3B implementation
details, except checking code which reads info from ISO 9660 filesystems.

What i can offer is technical background info and testing of growisofs
on re-usable media.
I will try to make a demo script with mkisofs and growisofs running
separately.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the k3b mailing list