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

Thu Sep 1 09:09:44 UTC 2016

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

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

Leslie Zhai wrote:
> I am starting to read the source code of growisofs.c this morning ;-)

As a new fellow burn programmer you should get your hands on SCSI specs
SPC-3, MMC-5 or MMC-6, SBC-2.

  https://en.wikipedia.org/wiki/MultiMedia_Commands
has external links where you might find drafts for free.
My own knowledge is recorded in
  http://libburnia-project.org/browser/libburn/trunk/doc/cookbook.txt
(regrettably the T10 links meanwhile just yield PDFs with the offer
 to buy the specs for 30 USD each).

> > Isn't your patch mislabelled ?
> NO, I only dropped woidm,

In

https://quickgit.kde.org/?p=k3b.git&a=blobdiff&h=0517d6f372551c8d0ae3ec8354e8a692bf92c299&hp=0bc7b38bd1f587f3de6a0efbbd12e32359cbcffd&hb=fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c&f=libk3b%2Fjobs%2Fk3bdvdcopyjob.cpp
i see

-  // prefer growisofs to wodim, which doesn't work all that great for DVDs
-  // (and doesn't support BluRay at all)
-  if ( k3bcore->externalBinManager()->binObject("cdrecord")->hasFeature(
"wodim" ) )
+  // wodim from cdrkit (CD only, DVD deprecated, unmaintained)
+  if ( false )
       d->usedWritingApp = K3b::WritingAppGrowisofs;

which i believe prevents the automatic use of growisofs.
(I might be wrong, of course.)

> cdrkit (forked cdrtools) was unmaintained.

The demise of cdrkit is a deplorable fact indeed.
It's source can still be browsed at
  https://sources.debian.net/src/cdrkit/9:1.1.11-3/
and i guess debian-mentors could help to locate an upstream source tarball.
But well, if you have cdrecord, there is few use for wodim.

> I do NOT have dvd/blueray for test,

That will be a problem when you work on the DVD/BD code.
You need a tester who is an experienced K3B user and can tell you about
any regression caused by a changeset.

> I use CDemu to create a blank recordable disc: DVD+R S

I read on
  http://cdemu.sourceforge.net/about/daemon/
  "Implemens a set of packet commands specified by MMC-3"
MMC-3 did not yet specify DVD+R (only DVD+RW, DVD-R, DVD-RW, DVD-RAM)
so you might be better off with DVD-R emulation.

Whatever, you'd also need to test with emulated DVD+RW which would
serve as role model of DVD-RAM, BD-RE, Pseudo-Overwrite BD-R, formatted
DVD-RW.
Maybe you can even reproduce the production of bad option -C 0,0 on
DVD+RW. (See below for motivation.)

> I will try cdrskin!

Let's see how far we get. I am optimistic about DVD and BD, because they
offer no exotic sector formats. With CD, we might be restricted to plain
data and plain audio. No video, no data-audio-mix, ...

I can confirm that cdrskin and xorrecord do multi-session on BD-R.

You should try to get a verification that cdrecord can do multi-session
on BD-R. (Last big improvement i saw was multi-session on DVD-R.)

> yes, I dropped alleged_next_session, but let growisofs construct next
> session

Looks like a good idea. Test it with emulated DVD+RW.
(It would be a bad idea with cdrecord/wodim/xorrecord as burn program.)

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

As for the original bug:

One should try to find out why K3B composed
  -C 0,0
which indicates to mkisofs/genisoimage/xorrisofs that it shall read the
ISO superblock at offset 0+16 and prepare an addon session to be written
at Next Writable Address 0.
This is of course unplausible because the add-on must be written at
some Next Writable Address after the end of the existing tracks.

So K3B did not properly determine the Next Writable Address (NWA).

One would have to dive into the MMC code of K3B.
Normally this info is inquired from cdrecord/cdrskin/xorrecord by

  $program dev=/dev/sr0 -msinfo

which should reply on stdout two numbers separated by a comma:

  10718944,10795616

(numbers obtained from an appendable sequential BD-R with 181 sessions)
The second number should never be 0 if the medium already contains
a session.

My best guess is that the medium is BD-RE or a BD-R formatted to
state "Pseudo Overwrite". Both would like DVD-RAM, DVD+RW, and
formatted DVD-RW report via MMC a single track which is writable
beginning at block offset 0.
On these media one has rather to inquire the ISO 9660 superblock
to find the end of the written area and choose a pseudo-NWA after
that end.

growisofs does this inquiry by its ISO 9660 knowledge, not by its
MMC knowledge.
cdrskin can do this inquiry, if its option
  --grow_overwriteable_iso
is present. Normally, like cdrecord, it inquires by MMC commands that
the medium is writable starting at block 0 (i.e. pseudo blank in
the CD inspired media model of cdrecord/cdrskin/xorrecord).

A workaround for growisofs and BD-R media would be to use growisofs
option

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

on the first burn run, in order to prevent formatting the blank BD-R.
This would also yield full nominal burn speed on that BD-R medium.
And it would prevent a growisofs bug which throws error at the very
end of first BD-R burn run.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713016

A workaround for formatted media would be to let K3B use

   cdrskin dev=/dev/sr0 --grow_overwriteable_iso -msinfo

or to let K3B inquire the ISO 9660 Primary Volume Descriptor to find
the filesystem end.
A PDF with ISO 9660 specs (aka ECMA-119) is available for free:
  http://www.ecma-international.org/publications/standards/Ecma-119.htm
See
  8.4.8 Volume Space Size (BP 81 to 88)
(First 4 bytes little-endian, next 4 give same number as big-endian.
 BP 81 means byte offset 32768 + 81 - 1 in the ISO filesystem image.)

Have a nice day :)

Thomas

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