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

[Thomas Schmitt via KDE Bugzilla]

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

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

i wrote:
> > I should mention that session 2 tests with growisofs -M instead of -Z
> > failed

Leslie Zhai wrote:
> growisofs -M /dev/sr0=/dev/fd/0 ...
> you mean the above failed to work?

It failed together with -use-the-force-luke=seek=1024:

  $ genisoimage -M /dev/sr4 -C 0,1024 -R file2 | growisofs
-use-the-force-luke=seek=1024 -M /dev/sr4=/dev/fd/0
  ...
  growisofs: -C argument is undefined.

  $ genisoimage -M /dev/sr4 -C 0,1024 -R file2 | growisofs
-use-the-force-luke=seek=1024 -C 0,1024 -M /dev/sr4=/dev/fd/0
  ...
  growisofs: -C argument is insane.

I assume that -M causes growisofs to do an own Next Writable Address
computation and to ignore -use-the-force-luke=seek=1024.


> then what described
> http://fy.chalmers.se/~appro/linux/DVD+RW/ you don't have to specify -C
> option, growisofs will construct one for you?! wrongly implemented?

Not wrong implemented but other use case.

growisofs (like my xorriso) aims to simplify the gesture of obtaining
the next writable address, giving mkisofs the right -C values, and
piping the output of mkisofs to optical media.

man growisofs shows these well working examples:
Session 1:
  growisofs -Z /dev/dvd -R -J /some/files
Session 2
  growisofs -M /dev/dvd -R -J /more/files
mkisofs is in both runs started by growisofs.
With these runs, you do not have to give a -C option.

But K3B does not use growisofs that way. It rather starts mkisofs and
growisofs separately and pipes the output of mkisofs into the input
of growisofs.
Option -M may well work with sequential media: DVD-R, DVD+R,
unformatted DVD-RW, non-overwritable BD-R. That's because both, K3B and
growisofs ask the burner drive to determine the Next Writable Address.

With the other media and media states, there is the problem that K3B
would have to determine the Next Writable Address from the ISO 9660
filesystem size. But there is some freedom of choice with this value
and growisofs and mkisofs *must* use the same value.

So my tested proposal is to determine some suitable Next Writable
Address from the ISO 9660 superblock and to force it on both, mkisofs
and growisofs. It worked only with growisofs -Z, not with growisofs -M.

Note well: This is appropriate only with overwritable media.

I assume you can recognize the situation by K3B determining -C 0,0
when it inquires the Next Writable Address from MMC commands in
K3b::Device::Device::getNextWritableAdress() , libk3bdevice/k3bdevice.cpp

Or you recognize media profiles as does setup_C_parm() in growisofs.c :
    if (!poor_man ||    profile==0x1A || profile==0x2A ||
                        profile==0x13 || profile==0x12 ||
                        profile==0x42 || profile==0x43)
    {   next_session = from_733(descr->volume_space_size);
        /* pad to closest 32K boundary */

(That's DVD+RW, DVD+RW DL, formatted DVD-RW, DVD-RAM,
  pseudo-overwritable BD-R, and BD-RE.)

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

I will make tests with growisofs -M and a computed Next Writable Address
which matches the computation of growisofs.
(If you go that way, then K3B must always compute the same value as
 does growisofs. That's quite a risky design.)

Have a nice day :)

Thomas

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