Bug 367639 - k3b fails to continue multisession (blue ray)
Summary: k3b fails to continue multisession (blue ray)
Status: RESOLVED FIXED
Alias: None
Product: k3b
Classification: Applications
Component: Data Project (show other bugs)
Version: 2.0.3
Platform: Fedora RPMs Linux
: NOR grave
Target Milestone: ---
Assignee: k3b developers
URL:
Keywords:
: 373523 378157 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-08-21 12:24 UTC by mnl
Modified: 2017-11-08 01:26 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mnl 2016-08-21 12:24:24 UTC
When trying to continue a multisession blue ray on Fedora 24 k3b resports a severe error. Here's the log:

Burned media
-----------------------
BD-R sequenziell Pseudo-Überschreiben (SRM+POW)

Devices
-----------------------
HL-DT-ST BD-RE  BH16NS55 1.02 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R doppelschichtig, BD-CD-ROM, BD-CD-R, BD-RE, DVD+R, DVD+RW, DVD+R doppelschichtig) [DVD-ROM, DVD-R sequenziell, Zweischichtige DVD-R sequenziell, Zweischicht-DVD-R-Sprung, DVD-RAM, DVD-RW Eingeschränktes Überbrennen, DVD-RW sequenziell, DVD+RW, DVD+R, Zweischichtige DVD+R, CD-ROM, CD-R, CD-RW, BD-CD-ROM, BD-R sequenziell (SRM), BD-R Zufällig (RRM), BD-RE] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Eingeschränktes Überschreiben, Sprung zwischen DVD-Schichten, Zufällige Aufnahme, Sequenzielle Aufnahme, Sequenzielle Aufnahme + POW] [%7]

K3b::IsoImager
-----------------------
mkisofs print size result: 322106 (659673088 bytes)

System
-----------------------
K3b Version: 2.0.3
KDE Version: 4.14.22
QT Version:  4.8.7
Kernel:      4.6.4-301.fc24.x86_64

Used versions
-----------------------
mkisofs: 1.1.11
growisofs: 7.1

growisofs
-----------------------
/usr/bin/growisofs: -C argument is insane.

growisofs command:
-----------------------
/usr/bin/growisofs -C 0,0 -M /dev/sr0=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=4gms -use-the-force-luke=tracksize:322106 -speed=4 -use-the-force-luke=bufsize:32m

mkisofs
-----------------------
Rock Ridge signatures found
322106
I: -input-charset not specified, using utf-8 (detected in locale settings)

mkisofs calculate size command:
-----------------------
/usr/bin/genisoimage -cdrecord-params 0,0 -prev-session /dev/sr0 -gui -graft-points -print-size -quiet -volid Pictures-III -volset  -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher  -preparer  -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-mnl/k3bUw5052.tmp -rational-rock -hide-list /tmp/kde-mnl/k3bpN5052.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-mnl/k3bNy5052.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-mnl/k3bhK5052.tmp

mkisofs command:
-----------------------
/usr/bin/genisoimage -cdrecord-params 0,0 -prev-session /dev/sr0 -gui -graft-points -volid Pictures-III -volset  -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher  -preparer  -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-mnl/k3bnT5052.tmp -rational-rock -hide-list /tmp/kde-mnl/k3bJw5052.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-mnl/k3bPR5052.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-mnl/k3byV5052.tmp

Reproducible: Always

Steps to Reproduce:
1. Start session (works)
2. Continue session (fails)
Comment 1 Leslie Zhai 2016-08-26 04:29:48 UTC
Hi mnl,

Please try k3b v2.10.0, its' github mirror: https://github.com/KDE/k3b

and I do not have blueray... so I can NOT test it ;-(

Regards,
Leslie Zhai
Comment 2 mnl 2016-08-26 11:02:19 UTC
Hi Leslie,

I cannot compile 2.10.0 on Fedora because it requires "ecm". (It has obviously not been a dependency for 2.0.3, because I could successfully build this older version.)

I failed to find a package that provides "ecm" on Fedora (though it seems to be "standard" on Ubuntu for a long time). Can you give me a hint?

 - Michael
Comment 3 Burkhard Lück 2016-08-26 11:05:57 UTC
(In reply to mnl from comment #2)
> I failed to find a package that provides "ecm" on Fedora (though it seems to
 be "standard" on Ubuntu for a long time). Can you give me a hint?

http://pkgs.fedoraproject.org/cgit/rpms/extra-cmake-modules.git/
Comment 4 Leslie Zhai 2016-08-27 13:59:27 UTC
Hi mnl,

I am using Fedora too, and also ArchLinux ;-)

Please have a look at http://www.leetcode.cn/2016/08/k3b.html described build dependence, it is better to sudo dnf upgrade --refresh your Fedora!

Regards,
Leslie Zhai
Comment 5 Leslie Zhai 2016-08-29 04:29:41 UTC
Hi mnl,

This might help you https://help.ubuntu.com/community/CdDvd/Burning#Blu-Ray_Burning

Regards,
Leslie Zhai
Comment 6 mnl 2016-08-30 08:09:44 UTC
Version 2.10.0 still fails to compile:

------------
CMake Error at /usr/lib64/cmake/Qt5Gui/Qt5GuiConfig.cmake:15 (message):
  The imported target "Qt5::Gui" references the file

     "/usr/lib64/libEGL.so"

  but this file does not exist.  Possible reasons include:
...
------------

I checked. The file IS there!
Comment 7 Leslie Zhai 2016-08-30 08:56:56 UTC
Hi mnl,

try sudo dnf install qt5-qtbase-devel and qt5-qtwebkit-devel

and have a look at https://help.ubuntu.com/community/CdDvd/Burning#Blu-Ray_Burning

Regards,
Leslie Zhai
Comment 8 Leslie Zhai 2016-08-30 15:22:58 UTC
Git commit fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c by Leslie Zhai.
Committed on 30/08/2016 at 15:19.
Pushed by lesliezhai into branch 'master'.

Use cdrecord for burning blueray instead of wodim.

Because wodim from cdrkit (CD only, DVD deprecated, unmaintained) https://wiki.archlinux.org/index.php/Optical_disc_drive
and the website http://www.cdrkit.org/ was down, so could not package it any more.

M  +1    -4    libk3b/core/k3bdefaultexternalprograms.cpp
M  +2    -3    libk3b/jobs/k3bdvdcopyjob.cpp
M  +0    -1    libk3b/jobs/k3bmetawriter.cpp
M  +3    -9    libk3b/projects/datacd/k3bdatajob.cpp
M  +1    -1    libk3b/projects/k3bcdrecordwriter.cpp
M  +1    -1    libk3bdevice/k3bdevice.cpp
M  +1    -2    src/k3bsystemproblemdialog.cpp
M  +1    -2    src/option/k3bexternalbinpermissionmodel.cpp

http://commits.kde.org/k3b/fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c
Comment 9 mnl 2016-08-31 07:42:35 UTC
The problem with cdrecord on Fedora is that it is in none of the standard repositories nor in the free/nonfree Fusion repositories except as "limited cdrecord compatibility wrapper" in package "cdrskin".
Comment 10 Leslie Zhai 2016-08-31 09:23:40 UTC
Hi mnl,

yes! I manually build && install cdrecord in my Fedora box, but there is cdrtools package for ArchLinux https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/cdrtools

wodim was unmaintained ;-(  I will provide detailed how to build && install dependence for Fedora box http://www.leetcode.cn/2016/08/k3b.html

and another issue is transcode, the same story! also unmaintained https://bitbucket.org/achurch_/transcode/pull-requests/1/migrate-to-ffmpeg-313/diff perhaps I will use mplayer for ripping encrypted videodvd!

Regards,
Leslie Zhai
Comment 11 mnl 2016-08-31 09:34:08 UTC
This is a bit off topic, but on the long run these "self building requirements" are going to make k3b unusable for most Fedora users.

I will continue to try to build the new version as I have time. But to get my blue-ray burning done, I've had a look at command line usage of growisfs in the meantime. It works fine (I think the only problem is the "-C" parameter that k3b passes to it, as can be seen in the log) and it is really easy to use. The only obvious advantage that k3b still offers to me regarding my burning tasks is proof reading.
Comment 12 Leslie Zhai 2016-09-01 01:42:18 UTC
> This is a bit off topic, but on the long run these "self building requirements" are going to make k3b unusable for most Fedora users.

How to add cdrtools.spec to Fedora rpms repos? I can rpmbuild the cdrtools-XXX.rpm for Fedora users, I often do that ;-) http://koji.isoft-linux.org/koji/

growisfs -C , just like wget -c, continue doing the job, I will check growisfs's source code!

Regards,
Leslie Zhai
Comment 13 Leslie Zhai 2016-09-01 04:26:17 UTC
Git commit 62fda2003fcc355c8d18b9b530c725427578ad77 by Leslie Zhai.
Committed on 01/09/2016 at 04:23.
Pushed by lesliezhai into branch 'master'.

Don't have to specify -C option for multisession.

growisofs will construct one for you, and if provided wrong
alleged_next_session, it will throw -C argument is insane error!

Also please have a look at http://www.leetcode.cn/2016/08/k3b.html about
cdrtools.

M  +2    -0    libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp
M  +5    -2    libk3b/projects/k3bgrowisofswriter.cpp

http://commits.kde.org/k3b/62fda2003fcc355c8d18b9b530c725427578ad77
Comment 14 Thomas Schmitt 2016-09-01 07:00:38 UTC
Hi,

i am developer of libburn and wonder since years why K3B ignores
programs based on it.
cdrskin and xorriso burn CD, DVD, and BD just fine.
The only shortcomming towards wodim and cdrecord is with exotic CD layouts
like mixed mode or "raw" writing. (I lack of test cases and of the will
to get into trouble with copyright holders of cloned CDs.)

@Leslie Zhai:
I am willing to help. Not only with adapting to cdrskin but also with
identifying problems in growisofs.

Isn't your patch
  "Use cdrecord for burning blueray instead of wodim."
  http://commits.kde.org/k3b/fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c
mislabelled ?
Shouldn't it rather be
  "Use cdrecord for burning blueray and DVD instead of growisofs"
?

Well, cdrecord and libburn are both living projects, in contrast to
growisofs and wodim. So this choice is not unreasonable on the first
hand.
Nevertheless you should be aware that growisofs has the better
understanding of DVD as specified in MMC-5/MMC-6. Its BD code has
a few flaws, indeed. Some have been fixed in the last 8 years by
distro patches.

So i advise to keep growisofs as default at least for DVD media if
you cannot get yourself to give cdrskin a try.

On BD media, cdrecord does not format BD-R (which is good for burn
speed) but cannot employ Streaming mode on BD-RE (which is bad for
burn speed).
cdrskin can format BD-R if desired, which yields checkreading during
burn and slow burning speed. It can also disable checkreading on
formatted media. The latter makes 2x BD-RE burn with 2x effective speed
instead of 0.8x to 1.0x speed.

(Looking at libk3bdevice/k3bdevice.cpp line 3611 i wonder why K3B
 is diving into MMC entrails instead of letting the burn program
 determine the disc state. Does K3B have own MMC expertise ?)

Have a nice day :)

Thomas
Comment 15 Leslie Zhai 2016-09-01 07:37:46 UTC
Hi Thomas,

> wonder since years why K3B ignores programs based on it. cdrskin and xorriso burn CD, DVD, and BD just fine.

I am newbie of K3B http://www.leetcode.cn/2016/08/k3b.html I just want to fix KF5 related issue at very begining ;-)

> The only shortcomming towards wodim and cdrecord is with exotic CD layouts like mixed mode or "raw" writing

I have some Audio CD, so I can test Ripping CD, but not test burning Audio/Mixed CD neither.

> I am willing to help. Not only with adapting to cdrskin but also with identifying problems in growisofs.

cool! I am starting to read the source code of growisofs.c this morning ;-)

> Isn't your patch mislabelled ?

NO, I only dropped woidm, cdrkit (forked cdrtools) was unmaintained.

> So i advise to keep growisofs as default at least for DVD media if you cannot get yourself to give cdrskin a try

I do NOT have dvd/blueray for test, so I use CDemu to create a blank recordable disc: DVD+R SL with ISO image writer: cdemu create-blank --writer-id=WRITER-ISO --medium-type=dvd+r 0 ~/output-image.iso
I will try cdrskin!

> i wonder why K3B is diving into MMC entrails instead of letting the burn program determine the disc state

yes, I dropped alleged_next_session, but let growisofs construct next session for me https://quickgit.kde.org/?p=k3b.git&a=commit&h=62fda2003fcc355c8d18b9b530c725427578ad77

Regards,
Leslie Zhai
Comment 16 Thomas Schmitt 2016-09-01 09:09:44 UTC
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
Comment 17 Leslie Zhai 2016-09-02 02:05:50 UTC
Hi Thomas,

Thanks for your detailed DVD background information, I will deep into it ;-)

> which i believe prevents the automatic use of growisofs

I will double check it!

> That will be a problem when you work on the DVD/BD code

yes! people often use clound or usb disk right now, so I have to borrow some empty DVD/Blu-ray...

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

yes, wrong 0,0 alleged_next_session, and I will also deep into it, very interesting and it is able to learn some thing ;-)

Regards,
Leslie Zhai
Comment 18 Leslie Zhai 2016-09-02 02:17:32 UTC
Git commit f3f4602e30c67bf622b5a52ea39c78817b1dd020 by Leslie Zhai.
Committed on 02/09/2016 at 02:15.
Pushed by lesliezhai into branch 'master'.

Use growisofs for burning DVD/Blu-ray by default.

M  +3    -2    libk3b/jobs/k3bdvdcopyjob.cpp

http://commits.kde.org/k3b/f3f4602e30c67bf622b5a52ea39c78817b1dd020
Comment 19 Leslie Zhai 2016-09-06 04:34:32 UTC
*** Bug 356434 has been marked as a duplicate of this bug. ***
Comment 20 Leslie Zhai 2016-09-06 06:02:25 UTC
*** Bug 281818 has been marked as a duplicate of this bug. ***
Comment 21 Thomas Schmitt 2016-09-13 18:47:03 UTC
Hi,

this is about the effort needed to implement multi-session on
DVD+RW, DVD-RAM, formatted DVD-RW, BD-RE, overwritably formatted BD-R.

It should be possible by duplicating capabilities of growisofs and
xorriso. Probably one would be better off by delegating the job into
one of these programs, but i assume the separation of ISO 9660 producer
and burn program is part of K3B's architecture.
cdrskin --grow_overwriteable_iso would fit best into that separation.

A compatibility problem is that only growisofs operates on overwritably
formatted BD-R, which it formats by default when getting them in blank
state.
Given the corresponding CLOSE SESSION bug in original growisofs-7.1,
the slow speed of formatted BD-R, and this compatibility problem, one
should really consider to add option

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

by default to growisofs runs on blank unformatted BD-R.
The run will succeed with original growisofs-7.1 and the medium will
be usable for cdrskin and xorriso, if it does not get closed by growisofs
options.
If cdrecord supports multi-session on BD-R, then quite surely only on
those which are not formatted to be pseudo-overwritable. (I dare to
predict this because Joerg Schilling expressed his general objections
against emulated multi-session on overwritables.)

--------------------------------------------------------------------
Why there is a problem:

-C X,0 is not suitable for ISO 9660 multi-session, because Next Writable
Address 0 would overwrite the existing session instead of appending a
new session after its end.

I looked into libk3bdevice/k3bdevice.cpp : ...::getNextWritableAdress().

It inquires the start of the last written session by SCSI command
READ TRACK INFORMATION with address type 1. The value is taken from
the reply field "Logical Track Start Address".
This number is supposed to be 0 with overwritably formatted media.

That's well ok for the first parameter value of mkisofs option -C
if an ISO 9660 filesystem is present on the medium. The ISO superblock
at address 0 is supposed to point to the newest directory tree.

The second parameter value for option -C is the Next Writable Address.
To obtain it, K3B sends READ TOC/PMA/ATIP with reply format 1, which
returns for non-CD media a fabricated Table-Of-Content. The value is
taken from reply field "Start Address of First Track in Last Session".
(The "last session" is supposed to be the unwritten medium area.)
With an overwritably formatted medium, this value is supposed to be
always 0.

----------------------------------------------------------------------
How to fix it growisofs style:

growisofs introduced emulated multi session by reading the size
information of the ISO 9660 filesystem, writing the add-on session after
the end of the existing filesyem, and overwriting the ISO 9660 superblock
at the start of the medium.

So one should read block 16 (* 2048 bytes) of the medium and check its
first 6 bytes for {0x01,'C','D','0','0','1'}. If this magic number of
ISO 9660 is found, then bytes 80 to 83 of the block tell the number of
blocks as little-endian unsigned 32 bit number.
This number would be the first block address which does not overwrite
blocks from the existing ISO 9660 sessions. One should round it up to
the next multiple of 32 blocks, in order to match alignment constraints
of some DVD and BD media. (Caution: growisofs rounds to 16, not 32.)

This way one gets a suitable second parameter value for mkisofs -C.
Next is the problem to talk the burn program into writing the output
of mkisofs to the same start block as was told to mkisofs by this value.

growisofs source code shows that there is an option
  -use-the-force-luke=seek=<number>
which might be usable together with option -Z (but not -M) to force
growisofs into starting the write run at the given block number.
One would have to test with DVD+RW, BD-RE, or formatted DVD-RW.

cdrskin has option write_start_address=<byte_offset> (i.e. one has
to multiply the block number by 2048) which lets writing start at the
given byte number.

Afterwards, a copy of the new ISO 9660 superblock must be written to
block 0 (up to at least block 17), so that mount(8) shows the new
directory tree. In this copy it is necessary to add the start block
address to the number of blocks counter in the superblock.
One will recognize success by the new files of the new session showing
up after mount.

This last step is tricky with burn programs, because they tend to write
more data than given to them.
On Linux, one does not need a burn program for writing to overwritable
media. Normal open(2), lseek(2), write(2) will do.

----------------------------------------------------------------------
cdrskin's special offer:

With cdrskin it is possible to let it decide about the -C parameter
values with the promise that it will use the second told value as start
address of the future burn run and to copy the patched superblock:

  $ cdrskin --grow_overwriteable_iso dev=/dev/sr0 -msinfo 2>/dev/null
  0,3438672

  $ mkisofs ... -M /dev/sr0 -C 0,3438672 ... \
    | cdrskin --grow_overwriteable_iso dev=/dev/sr0 -waiti -multi ... -

(Note the misspelling: "grow_overwrit*e*able_iso". Sorry for that.)

Option --grow_overwriteable_iso does not hamper the work with
unformatted multi-session media: CD-R, DVD-R, DVD+R, ...
So the shown commands work with the media spectrum from CD-R to BD-RE.
Only DVD-R DL and fast blanked DVD-RW cannot do multi-session for
drive-media-internal reasons.

growisofs and xorriso actually aim to encapsulate this gesture so that
the user does not have to care for the multi-session peculiarities.

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

Have a nice day :)

Thomas
Comment 22 Leslie Zhai 2016-09-18 01:54:47 UTC
Hi Thomas,

Thanks for your detailed information, I will carefully read it ;-)

Regards,
Leslie Zhai
Comment 23 Leslie Zhai 2016-09-18 02:41:18 UTC
Hi,

> How to fix it growisofs style

yes, growisofs implemented it:

 * - implement -use-the-force-luke=seek:N -Z /dev/dvd=image to arrange              
 *   for 'builtin_dd if=image of=/dev/dvd obs=32k seek=N/16' (note that             
 *   N is expected to be expressed in 2KB chunks);

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

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

Regards,
Leslie Zhai
Comment 24 Thomas Schmitt 2016-09-18 10:49:24 UTC
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
Comment 25 Thomas Schmitt 2016-09-18 13:48:39 UTC
Hi,

i tested growisofs and separately running mkisofs/genisoimage/xorrisofs
on DVD+RW to show how i imagine this could be done in K3B:

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

# Create some input files
  echo file1 >file1
  echo file2_a_bit_larger >file2

# First session 

  genisoimage -R file1 | \
  growisofs -Z /dev/sr0=/dev/fd/0 

# This run reports:  176 extents written (0 MB)
# So i choose a deliberately high Next Writable Address:  1024

# mount(8) and ls(1) show one file in the ISO
#   -rw-r--r-- 1 thomas thomas 6 Sep 18 14:59 file1

# Second session (after unmounting /dev/sr0, of course)

  genisoimage -M /dev/sr0 -C 0,1024 -R file2 | \
  growisofs -use-the-force-luke=seek=1024 -C 0,1024 -Z /dev/sr0=/dev/fd/0 

# mount(8) and ls(1) show both files in the ISO
#   -rw-r--r-- 1 thomas thomas  6 Sep 18 14:59 file1
#   -rw-r--r-- 1 thomas thomas 19 Sep 18 14:59 file2

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

Both are needed: -use-the-force-luke=seek=1024 and -C 0,1024
Else mount(8) and ls(1) will show only file1 after the second session.
(I.e. without -C, growisofs does not update the superblock at offset 0.)

In the second run growisofs reports:
  About to execute 'builtin_dd if=/dev/fd/0 of=/dev/sr0 obs=32k seek=64'
  builtin_dd: 176*2KB out @ average 0.1x1352KBps
genisoimage reports:
  1200 extents written (2 MB)
We learn that genisoimage added 1024 and 176 in its message.
Suitable Next Writable Address would be any properly aligned value
not smaller than 1200.

So it would work with growisofs if K3B would compute its own Next Writable
Address and force it on genisoimage and growisofs.
For the sake of BD-RE performance and compatibility to my software i
sincerely advise to round up to full multiples of 32 blocks.
growisofs rounds to 16, which is not necessary aligned to a BD data
unit of 32 (aka "Cluster"). DVD has 16 blocks per "ECC Block".


Being selfish i show the cdrskin way:
-------------------------------------------------------------------

# Pseudo-blank the medium, so that cdrskin will not append its
# first session to the existing ISO filesystem.
# The same command blanks CD-RW and unformatted DVD-RW.
# It tolerates blank media and fails on non-blank non-blankable media.

  cdrskin --grow_overwriteable_iso dev=/dev/sr0 -v blank=as_needed

# First session. 
# Option --grow_overwriteable_iso lets cdrskin tolerate -multi on DVD+RW.
# (One cannot close a DVD+RW. So -multi is normally rejected.)

  genisoimage -R file1 | \
  cdrskin --grow_overwriteable_iso -multi dev=/dev/sr0 -v -eject -

# Inquire values for genisoimage -C.
# Option --grow_overwriteable_iso lets cdrskin inspect the ISO.
# Nevertheless this works too on sequential media:
#   CD-R[W], DVD-R[W], DVD+R, non-pseudo-overwritable BD-R.

  C_VALUES=$(cdrskin dev=/dev/sr0 --grow_overwriteable_iso -msinfo)

# Second session. Option --grow_overwriteable_iso lets cdrskin direct
# the burn run to the same address as predicted by the previous run
# and handed to genisoimage.

  genisoimage -M /dev/sr0 -C "$C_VALUES" -R file2 | \
  cdrskin --grow_overwriteable_iso -multi dev=/dev/sr0 -v -eject -

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

The advantage of this is that K3B does not have to inspect the ISO
and can operate any kind of media by the same cdrskin runs.


Have a nice day :)

Thomas
Comment 26 Thomas Schmitt 2016-09-18 14:25:57 UTC
I should mention that session 2 tests with growisofs -M instead of -Z failed.
Comment 27 Leslie Zhai 2016-09-19 02:31:58 UTC
Hi Thomas,

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

growisofs -M /dev/sr0=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=4gms -use-the-force-luke=tracksize:322106 -speed=4 -use-the-force-luke=bufsize:32m

you mean the above failed to work? 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?

Regards,
Leslie Zhai
Comment 28 Leslie Zhai 2016-09-19 02:40:06 UTC
Git commit 477870ea36d07505889bfcccce33becc41ba57f3 by Leslie Zhai.
Committed on 19/09/2016 at 02:37.
Pushed by lesliezhai into branch 'multisession'.

growisofs described you don't have to specify -C option, it will
construct one for you.

M  +9    -1    libk3b/projects/k3bgrowisofswriter.cpp

http://commits.kde.org/k3b/477870ea36d07505889bfcccce33becc41ba57f3
Comment 29 Thomas Schmitt 2016-09-19 07:10:56 UTC
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
Comment 30 Leslie Zhai 2016-09-20 01:28:38 UTC
Hi Thomas,

in short:

Plan A - rewrite K3b::Device::Device::getNextWritableAdress()
Plan B - avoid risky design, don't have to specify -C option, let growisofs construct one

Regards,
Leslie Zhai
Comment 31 Thomas Schmitt 2016-09-20 06:37:24 UTC
Hi,

> Plan A - rewrite K3b::Device::Device::getNextWritableAdress()

Augment it by the equivalent of growisofs code, if the multisession
-C parameters turn out as 0,0:

        next_session = from_733(descr->volume_space_size);
        /* pad to closest 32K boundary */
        next_session += 15;
        next_session /= 16;
        next_session *= 16;
        sprintf (C_parm,"16,%u",next_session);

(The "16" as first -C value is actually wrong but mkisofs will understand
 what is meant. Legacy tradition.)

I would advise to align to 64 K at least for BD media.
But that is not what growisofs does.

Whatever, determination of -C values is needed in any case, because K3B
needs to hand over the values to mkisofs.


> Plan B - avoid risky design, don't have to specify -C option, let growisofs
> construct one

You got me wrong here.
I deem it risky if you bet on K3B's capability to determine the same
second number for -C as growisofs does.
I.e. if you do not use:
   -use-the-force-luke=seek=... -C ... -Z /dev/sr0=/dev/fd/0

I did not yet get to the experiment whether
   -C ... -M /dev/sr0=/dev/fd/0
works fine if i submit the same value to -C as growisofs computes.

It does not help to omit with the growisofs run. If the value is
acceptable then growisofs will go on. If you gave mkisofs a value
which growisofs will not accept, then it is ok to abort the burn run,
because mkisofs prepared the add-on session with incorrect offset.

(Remember: The statement "You don't have to specify the -C option"
 in the man page is about the use case which K3B does *not* use.
 In case of /dev/sr0=/dev/fd/0 the statement is not really true.)


Have a nice day :)

Thomas
Comment 32 Leslie Zhai 2016-09-20 07:17:22 UTC
Hi Thomas,

Then key point is:

> Whatever, determination of -C values is needed in any case, because K3B needs to hand over the values to mkisofs

If ScsiCommand 0x52 (MMC_READ_TRACK_INFORMATION) 0x1(incomplete) wrongly return 0 (as mnl experienced), then how to fix it?

Regards,
Leslie Zhai
Comment 33 Thomas Schmitt 2016-09-20 10:44:50 UTC
Hi,

> If ScsiCommand 0x52 (MMC_READ_TRACK_INFORMATION) 0x1(incomplete) wrongly
> return 0 (as mnl experienced),

The answer 0 is correct. It is just given by the wrong entity,
namely the drive and not the filesystem superblock.

A MMC drive regards an overwritable medium as having a single session
with a single track.
This track is readable beginning at block 0. Thus the first -C value is
determined by the drive as 0.
The track is also writable beginning at block 0. Thus the second -C
value is determined by the drive as 0.

But we do not want to overwrite the existing ISO. We want to append
in multi-session style.

This is the reason why growisofs began to exist. Andy Polyakov wanted
multi-session on media which are not prepared for multi-session but
rather allow random access writing.
man growisofs begins by:

   growisofs was originally designed  as  a  frontend  to  genisoimage  to
   facilitate  appending  of  data  to ISO9660 volumes residing on random-
   access media such as DVD+RW, DVD-RAM, plain  files,  hard  disk  parti‐
   tions. In the course of development general purpose DVD recording sup‐
   port was implemented, and as of now growisofs supports not only random-
   access  media,  but  even  mastering  of multisession DVD media such as
   DVD+R and DVD-R/-RW.

It was Andy's great invention to inquire the ISO 9660 superblock and to
use a block number after the end of the ISO as pseudo Next Writable Address.

Currently K3B is prepared only for "multisession DVD media" but not for
the "random-access media" which growisofs originally targets.
This is because it does not use growisofs to start mkisofs but rather starts
both program side by side.


> then how to fix it?

Do it like Andy (and me in xorriso):
- Inquire the ISO filesystem size.
- Choose a block address after the end of the ISO.
- Instruct all involved programs that this address will be used for
  writing the add-on session.

growisofs does the ISO inquiry by the call
  from_733(descr->volume_space_size);

"733" refers to ECMA-119 paragraph 7.3.3 which says:
  7.3.3 Both-byte orders
  A numerical value represented by the hexadecimal representation
  (st uv wx yz) shall be recorded in an eight-byte field as
  (yz wx uv st st uv wx yz).
  For example, the decimal number 305419896 has (12 34 56 78) as its
  hexadecimal representation and is recorded as (78 56 34 12 12 34 56 78).

"descr" is the content of the Primary Volume Descriptor (ECMA-119, 8.4).
This is recorded at block 16.
"->volume_space_size" accesses the bytes at offset 80 in the Descriptor.
ECMA-119, 8.4.8:
  Volume Space Size (BP 81 to 88)
  This field shall specify as a 32-bit number the number of Logical Blocks
  in which the Volume Space of the volume is recorded.
  This field shall be recorded according to 7.3.3.
Note that ECMA-119 counts byte position BP beginning with 1. I.e. BP 81
is byte offset 80.

So at byte offset 80 in block 16 begins the little-endian 4-byte block
count of the ISO. At offset 84 begins the same number represented as
big-endian.

In growisofs.c this is expressed by a C structure:
  struct iso_primary_descriptor {
      ... members with together 80 bytes ...
      unsigned char volume_space_size [8];
      ...
  };
But one may simply do fseek() to 32768+80, read the 4 bytes, and interpret
them as little-endian 32 bit value.


Have a nice day :)

Thomas
Comment 34 Thomas Schmitt 2016-09-20 16:18:21 UTC
Hi,

it really works when you tell growisofs -M the correct -C values
which match the ones computed by growisofs.

Session 1:

  genisoimage -R file1 | \
  growisofs -Z /dev/sr4=/dev/fd/0

The ISO has a size of 176 blocks. growisofs would next round up to
integer multiples of 16. That still yields 176.
So i use -C 0,176 in Session 2:

  genisoimage -M /dev/sr4 -C 0,176 -R file2 | \
  growisofs -C 0,176 -M /dev/sr4=/dev/fd/0

growisofs agreed to -C 0,176. 
So it was not necessary to override the ideas of growisofs via
option -use-the-force-luke=seek=...

Mounting the DVD+RW shows both files.

So this would be a viable method, too.
One just would have to try ISO 9660 size determination if the MMC
track position inquiry yields 0,0.

Don't forget to check for the magic number of ISO 9660 at the start
of block 16. If the first 6 bytes are not {0x01,'C','D','0','0','1'},
then it is not an ISO 9660 and there is no use in reading the 32 bit
number from byte offset 80.
In this case, no multi-session can be offered to the user.

Have a nice day :)

Thomas
Comment 35 Leslie Zhai 2016-09-21 02:50:25 UTC
Git commit 9a6340ed76aaa8fa8784168ef7d286710097cee3 by Leslie Zhai.
Committed on 21/09/2016 at 02:41.
Pushed by lesliezhai into branch 'master'.

Wrong alleged_next_session for growisofs

WIP in multisession branch.

M  +2    -2    libk3b/projects/k3bgrowisofswriter.cpp

http://commits.kde.org/k3b/9a6340ed76aaa8fa8784168ef7d286710097cee3
Comment 36 Leslie Zhai 2016-09-21 04:11:32 UTC
Git commit b22f60344db146aa6b5136373b0a0b270d5d8ee9 by Leslie Zhai.
Committed on 21/09/2016 at 04:09.
Pushed by lesliezhai into branch 'multisession'.

Inquire the ISO filesystem size

Hi Thomas, please review it ;-)
CCMAIL: scdbackup@gmx.net

M  +16   -3    libk3b/projects/k3bgrowisofswriter.cpp

http://commits.kde.org/k3b/b22f60344db146aa6b5136373b0a0b270d5d8ee9
Comment 37 Leslie Zhai 2016-09-21 04:37:06 UTC
Git commit e9faad4a24e80ee83a3881707e394ca4be66f5c7 by Leslie Zhai.
Committed on 21/09/2016 at 04:36.
Pushed by lesliezhai into branch 'multisession'.

Add more check for inquiring the ISO filesystem size

M  +5    -1    libk3b/projects/k3bgrowisofswriter.cpp

http://commits.kde.org/k3b/e9faad4a24e80ee83a3881707e394ca4be66f5c7
Comment 38 Thomas Schmitt 2016-09-21 09:16:13 UTC
Hi,

Leslie Zhai wrote:
> Hi Thomas, please review it ;-)

Most problematic:

I do not see where you hand over the growisofs-ly computed -C values
to mkisofs. It could be that it gets to see -C 0,0 despite the effort
in k3bgrowisofswriter.cpp.

I am uncertain whether i caught all problems. You need to test with
(maybe emulated) DVD+RW medium. (Not DVD+R or DVD-R.)

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

> http://commits.kde.org/k3b/9a6340ed76aaa8fa8784168ef7d286710097cee3

Looks good to me, under the assumption that d->multiSessionInfo
contains the suitable values which growisofs will accept.

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

> http://commits.kde.org/k3b/b22f60344db146aa6b5136373b0a0b270d5d8ee9

I riddle about this gesture

+                if (d->image.isEmpty())
+                    fptr = fopen("/dev/fd/0", "r");

It is clearly wrong to open "/dev/fd/0" out of multiple reasons:

- It is unclear to what the stdin of K3B is connected.
  Quite surely not to the stdout of the mkisofs run.
  And if so, then reading would consume irrevocably the start of the
  ISO stream. This is a show stopper !

- "/dev/fd/0" is both, a Linux device address and a symbolic address
  in growisofs. If growisofs sees this address, then it does not open
  the Linux file but rather uses stdin (the already open file descriptor 0).
  See growisofs.c:
                        if (sscanf(in_image,"/dev/fd/%u",&imgfd) == 1)
                            imgfd = dup (imgfd); /* validate descriptor */

- stdin is not seekable.
  fseek(3) will probably cause errno EBADF.

Under what circumstance is the condition d->image.isEmpty() true ?
Can this happen at all, when d->multiSession is true ?

------

+ fptr = fopen(d->image.toStdString().c_str(), "r");

Is it sure that this path leads to the random-access readable file object
which hold the previous ISO 9660 session ?

------

You do not check for the ISO 9660 magic number before you read the size.
This is absolutly mandatory or else the pseudo Next Writable Address will
be more or less random and growisofs will most probably not accept it.

Roughly (needs error handling with fseek and fread):

     char buf[6];
     fseek(fptr, 32 * 1024, SEEK_SET);
     fread(fptr, 1, 6, buf);
     if (buf[0] != 0x01 || buf[1] != 'C' || buf[2] != 'D' ||
         buf[3] != '0'  || buf[4] != '0' || buf[5] != '1') {

         // TODO: handle that no ISO 9660 is present at medium start

     }

------

+                        fread(buf, 1, sizeof(buf), fptr);
+                        d->process << "-C 0," << buf;

Between these two line you have to convert the 4 bytes into a 32 bit
number by interpreting them as little-endian number.
Your code would fail on machines with big-endian byte order.
(They are rare but still exist.)

Further you did not round up to full multiples of 16.

I'd do (in the hope that i understand the "d->process << " gesture):

                         uint32_t c2;
                         uint8_t buf[4];
                 
                         ret = fread(buf, 1, sizeof(buf), fptr);
                         if (ret != sizeof(buf)) {
                            // TODO: handle inability to read ISO size
                         }

                         // Interpret the read bytes as little-endian number.
                         // See also growisofs.c function from_733().
                         c2 = buf[0] | (buf[1] << 8) | (buf[2] << 16) |
                              (buf[3] << 24);

                         // Round up to full multipes of 16, as growisof does
                         // in its function setup_C_parm().
                         c2 += 15;
                         c2 /= 16;
                         c2 *= 16;

                         d->process << "-C 0," << c2;

uint32_t and uint8_t from C header <stdint.h> guarantee the size and
unsignedness.
If they are not acceptable to K3B, use "unsigned long" and "unsigned char".
                         
(Note that "<<" has two completely different meanings here.
 A C++ promoter who ridicules BASIC's GOTO should be asked to compare
 it with the inheritance piles and spaghetti overloading of C++.)

------

+                        qWarning() << strerror(errno);

Warning seems to weak as reaction to me.
We noticed an unusable d->multiSessionInfo and try to replace it by
a usable one. Now this failed and we actually have to refuse the burn
run, because it would fail with a growisofs error message.

Also, if you just show the error message, then the user will not know
why you tried to fseek and read.
I'd throw a severe error and report
  "Medium is not of multi-session type and does not contain ISO 9660.
   Cannot emulate multi-session on it."

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

> http://commits.kde.org/k3b/e9faad4a24e80ee83a3881707e394ca4be66f5c7

I understand this is a correction to the previous patch.
(Did "<<" buf show undesired bytes ?)

+                        int next = atoi(buf);

The signed data type "int" is slightly wrong here. The problem would
show up only with ISOs of size 4 TiB or larger. Nevertheless, the field
is defined by ECMA-119 as unsigned 32 bit stored in both endiannesses.

atoi(buf) will yield wrong results on big-endian machines. You first need
to left-shift the bytes into their little-endian positions before you can
treat the result as 32 bit number.

                         // Interpret the read bytes as little-endian number
                         c2 = buf[0] | (buf[1] << 8) | (buf[2] << 16) |
                              (buf[3] << 24);

Further atoi(3) yields signed int. (Again, a problem only with >= 4 TiB.)

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

We are getting nearer to the goal.

I am undecided whether interpretation of ISO size is correctly located
in k3bgrowisofswriter.cpp .

--------------------------------------------------------------------
Pro:

You can follow the habits of growisofs as awkward they may be.

Contra:

You must give mkisofs the same -C values as you tell growisofs.
So if you leave the computation in k3bgrowisofswriter.cpp then you
must update d->multiSessionInfo and you must make sure that the
mkisofs run is composed only after d->multiSessionInfo was corrected.

Multi-session emulation on overwritable media is not only provided by
growisofs. So if other capable programs get used by K3B, one will have
to duplicate large parts of the ISO inspection.
(A habit to align to larger granularity than 16 could possibly be handled
 in the specialized writer by rounding again. This works only if the
 new alignement is a multiple of 16.)

--------------------------------------------------------------------
 
So i'd imagine this architecture:

- A generic checker for d->multiSessionInfo, which tries to determine
  a better value from ISO if the current value is 0,0.
  This function would _not_ round the c2 value.

- A writer specific function which inspects the c2 value and rounds it
  to the granularity which the writer program uses. (16 for growisofs.)

- Only after this is done you may compose the program arguments of
  mkisofs and writer program.

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

Have a nice day :)

Thomas
Comment 39 Leslie Zhai 2016-09-22 03:48:43 UTC
Git commit ae0413daf1df44cb2c8c6e88a5b86180f1f52c3a by Leslie Zhai.
Committed on 22/09/2016 at 03:42.
Pushed by lesliezhai into branch 'multisession'.

Multisession implemented as Thomas suggested

Summary:
- validate file descriptor
- check for the ISO 9660 magic number
- convert the 4 bytes into a 32 bit number by interpreting them as
little-endian number
- A generic checker for GrowisofsWriter (growisofs) and IsoImager (mkisofs)

M  +1    -0    libk3b/projects/datacd/k3bdatajob.cpp
M  +41   -0    libk3b/projects/datacd/k3bisoimager.cpp
M  +2    -30   libk3b/projects/k3bgrowisofswriter.cpp

http://commits.kde.org/k3b/ae0413daf1df44cb2c8c6e88a5b86180f1f52c3a
Comment 40 Thomas Schmitt 2016-09-22 18:23:57 UTC
Hi,

> http://commits.kde.org/k3b/ae0413daf1df44cb2c8c6e88a5b86180f1f52c3a
> libk3b/projects/datacd/k3bisoimager.cpp

Then let's see ...

> +    char* in_image = "/dev/fd/0";

This is still wrong.
We need to access the existing ISO 9660 filesystem on the medium.
So this should rather be the path to the drive with the DVD+RW.
(I.e. something like "/dev/sr0" on Linux.)


> +    // Validate file descriptor
> +    if (sscanf(in_image, "/dev/fd/%u", &imgfd) == 1)
> +        imgfd = dup(imgfd);
> +    else

This case should then not occur. (We cannot lseek() on stdin anyway.)


> +        imgfd = open(in_image, O_RDONLY);

This will be in effect.

(For the subsequent code i can just hope that i did not propose too
 much nonsense. It needs to be tested when the path problem is solved.)

I do not see where you throw severe error if m_multiSessionInfo stays
with string value "0,0". This value means that we cannot use the growisofs
emulation of multi-session and that growisofs will raise protest about
-C 0,0. Without -C it would probably just overwrite the existing data
instead of adding new data. Maybe it would complain about -M without -C.

K3B should tell the user that it won't work instead of letting growisofs
or other writers do undesired things or issue cryptic error messages.


> - A generic checker for GrowisofsWriter (growisofs) and IsoImager (mkisofs)

You did not put the rounding stage into a writer specific function.
As it is now, the function in k3bisoimager.cpp  assumes that all writers
behave like growisofs.

So to stay modular (and to give cdrskin a chance to override the values
by its own findings) you should not round in k3bisoimager.cpp but
rather introduce a new writer specific function for all writers.
- The one of growisofs will round up to 16.
- The (future i hope) one of cdrskin would ask cdrskin for its own values
  for the given medium and ISO 9660 filesystem.
- The one of cdrecord would throw error, because i assume that cdrecord
  does not support on DVD+RW a write start address other than 0.

To prepare for cdrskin, the new function should know the path of the
drive's device file (e.g. "/dev/sr0").

Have a nice day :)

Thomas
Comment 41 Leslie Zhai 2016-09-23 02:40:29 UTC
Git commit 076340502f14a5ecd928551500392e5f38dd2c41 by Leslie Zhai.
Committed on 23/09/2016 at 02:35.
Pushed by lesliezhai into branch 'multisession'.

Fix multisession implementation as Thomas suggested

Summary:
- Use device driver's path instead of stdin
- Stay module DataMultiSessionParameterJob so CdrskinIsoImager can use
that
- Throw error info message to user

M  +1    -0    libk3b/projects/datacd/k3bdatajob.cpp
M  +30   -0    libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp
M  +0    -41   libk3b/projects/datacd/k3bisoimager.cpp
M  +8    -2    libk3b/projects/k3bgrowisofswriter.cpp

http://commits.kde.org/k3b/076340502f14a5ecd928551500392e5f38dd2c41
Comment 42 Thomas Schmitt 2016-09-24 09:21:12 UTC
Hi,

> libk3b / projects / datacd / k3bdatamultisessionparameterjob.cpp

I hate to say it, but it looks like there is already handling
for growisofs multi-session on overwritable media in this source file.

Just a few lines above your code addition there is:

    // FIXME: Does BD-RE really behave like DVD+RW here?
    if( info.mediaType() & (K3b::Device::MEDIA_DVD_PLUS_RW|
                            K3b::Device::MEDIA_DVD_PLUS_RW_DL|
                            K3b::Device::MEDIA_DVD_RW_OVWR|
                            K3b::Device::MEDIA_BD_RE) ) {

It refers to DVD+RW, DVD+RW DL, overwritable DVD_RW, and BD-RE.

But it does not refer to pseudo-overwritable BD-R, which caused this
bug report. (Arrrghhh !!!)

It is quite likely that the fix for this bug is simply to add the
profile for pseudo-overwritable BD-R to the list.

libk3bdevice/k3bdevicetypes.h has it probably as MEDIA_BD_R_SRM_POW:

        enum MediaType {
            ...
            /** Writable Blu-ray Disc (BD-R) */
            MEDIA_BD_R_SRM_POW = 0x2000000,

It could need a change from "Writable" to "Pseudo-Overwritable"
in its comment to distinguish it from unformatted MEDIA_BD_R_SRM.)

Except the occurence in setupMultiSessionParameters(), there is
another one in determineMultiSessionModeFromMedium(), where you
should add the MEDIA_BD_R_SRM_POW too.


--------------------------------------------------------------------
Reasoning:

MEDIA_BD_R_SRM_POW gets recognized in libk3bdevice/k3bdevice.cpp line 1872
by

       case 0x41: {
            if( featureCurrent( FEATURE_BD_PSEUDO_OVERWRITE ) == 1 )
                return MEDIA_BD_R_SRM_POW;
            else
                return MEDIA_BD_R_SRM;

The profile number 0x41 indicates BD-R which are not formatted to
Random Recording Mode (which is not used by growisofs).

libk3bdevice / k3bdevicetypes.h has
       const unsigned short FEATURE_BD_PSEUDO_OVERWRITE = 0x038;

The MMC feature 0x38 indeed indicates Pseudo-Overwrite formatting on
profile 0x41. (MMC-5 5.3.28: BD-R Pseudo-Overwrite (POW) Feature.)

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

Darn. Your newest change really looks as if we were nearly there.
Error throwing was not sufficient yet. And when i looked for a code
example how to do it, i came to that list of overwritable profiles.

We should have first searched for the correct place in the program
architecture and only then have tried to implement it.
One never stops learning ...


Have a nice day :)

Thomas
Comment 43 Thomas Schmitt 2016-09-24 13:36:50 UTC
Hi,

Surprise: growisofs does not inspect the ISO with BD-R profile 0x41 !

So adding MEDIA_BD_R_SRM_POW will not be correct.

Do Not Commit, Please.

I rather see in growisofs_mmc.cpp a special handling for pseudo-overwritable
BD-R which i did not remember to have seen in the SCSI MMC related code
of K3B:

    cmd[0] = 0x52;              // READ TRACK INFORMATION
    cmd[1] = 1;
    cmd[4] = next_track>>8;
    cmd[5] = next_track;        // ask for last track
    cmd[8] = sizeof(buf);
    cmd[9] = 0;
    err = cmd.transport (READ,buf,sizeof(buf));
    ...
    if (mmc_profile==0x41 && bdr_plus_pow && buf[7]&1)          // NWA_V
    {   next_session  = buf[12]<<24;
        next_session |= buf[13]<<16;
        next_session |= buf[14]<<8;
        next_session |= buf[15];
    }
    else
    {   next_session  = buf[8]<<24;     // Track Start Address
        next_session |= buf[9]<<16;
        next_session |= buf[10]<<8;
        next_session |= buf[11];
    }

The first case is for what K3B recognizes as MEDIA_BD_R_SRM_POW.

I will now revisit the code of K3B which asks the drive for the
Next Writable Address.


Have a nice day :)

Thomas
Comment 44 Thomas Schmitt 2016-09-24 14:11:39 UTC
Hi,

libk3bdevice/k3bdevice.cpp , K3b::Device::Device::getNextWritableAdress()

has 

                // Read start address of the incomplete track
                if( readTrackInformation( trackData, 0x1, nextTrack ) ) {
                    nextWritableAdress = from4Byte( &trackData[8] );

which matches the else-case of growisofs_mmc.cpp

    cmd[0] = 0x52;              // READ TRACK INFORMATION
    ...
    if (mmc_profile==0x41 && bdr_plus_pow && buf[7]&1)          // NWA_V
    {   next_session  = buf[12]<<24;
        next_session |= buf[13]<<16;
        next_session |= buf[14]<<8;
        next_session |= buf[15];
    }
    else
    {   next_session  = buf[8]<<24;     // Track Start Address
        next_session |= buf[9]<<16;
        next_session |= buf[10]<<8;
        next_session |= buf[11];
    }

There is no counterpart for the bdr_plus_pow case.

In K3B the equivalent would have to look like

                // Read start address of the incomplete track
                if( readTrackInformation( trackData, 0x1, nextTrack ) ) {
                    if (m == MEDIA_BD_R_SRM_POW && (trackData[7] & 1))
                        nextWritableAdress = from4Byte( &trackData[12] );
                    else
                        nextWritableAdress = from4Byte( &trackData[8] );


Have a nice day :)

Thomas
Comment 45 Thomas Schmitt 2016-09-25 07:47:59 UTC
Hi.

a summary of the winded road which brought me to the current diagnosis.

After my theory of lack of multi-session support on overwritable media
brought us to the code where this support is already implemented, i first
thought it was only about a missing media type in the list of overwritables.

But the code for detection of BD-R in POW state made it clear that i
misinterpreted the list of overwritables in growisofs. The growisofs list
does not contain BD-R POW (profile 0x41 + feature 0x38) but rather
BD-R RRM (profile 0x42), which is still missing in K3B's list.

Since growisofs does not format BD-R to RRM by default, there had to be
a different deviation of K3B's determination of Next Writable Address
from growisofs method of determination.
I found this deviation when comparing K3b::...::getNextWritableAdress()
with plusminus_r_C_parm() in growisofs_mmc.cpp.


Discovered problems along that road:

Obviously the K3B code to predict growisofs decisions was not completely
updated after growisofs introduced support for BD media. One would possibly
have to compare all media related gestures with those of growisofs.
(I compared the computation of lastSessionStart for BD-R POW and found
it correct. But other aspects may still offer pitfalls.)

One known deviation is the difference between the list of overwritables
in growisofs (DVD+RW, DVD+RW DL, formatted DVD-RW, DVD-RAM, BD-R RRM,
and BD-RE) to the ones in K3B (MEDIA_DVD_PLUS_RW, MEDIA_DVD_PLUS_RW_DL,
MEDIA_DVD_RW_OVWR, MEDIA_BD_RE).

I.e. DVD-RAM and BD-R RRM are missing in the K3B list of overwritables.

It seems essential that both programs use the same list.


Have a nice day :)

Thomas
Comment 46 Leslie Zhai 2016-09-26 02:11:45 UTC
Git commit cbe652000292dc5a6c9e36de0d1000ca0d84f75d by Leslie Zhai.
Committed on 26/09/2016 at 02:08.
Pushed by lesliezhai into branch 'multisession'.

Update multisession implementation as Thomas suggested

Summary:
- Fix getNextWritableAdress issue with counterpart for the bdr_plus_pow
case
- Remove duplicated nextSessionStart

M  +0    -2    libk3b/projects/datacd/k3bdatajob.cpp
M  +0    -32   libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp
M  +4    -1    libk3bdevice/k3bdevice.cpp

http://commits.kde.org/k3b/cbe652000292dc5a6c9e36de0d1000ca0d84f75d
Comment 47 Thomas Schmitt 2016-09-26 19:17:34 UTC
Hi,

> http://commits.kde.org/k3b/cbe652000292dc5a6c9e36de0d1000ca0d84f75d
> libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp

Actually one should still throw error if (nextSessionStart == 0)
at the end of setupMultiSessionParameters(). Especially since DVD-RAM
and BD-R RRM are missing in K3B's list of overwritable media.


> libk3bdevice/k3bdevice.cpp

This mirrors sufficiently the growisofs gesture at
  https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs_mmc.cpp/#L949


But there are more differences to BD-R POW in growisofs plusminus_r_C_parm()
versus K3B getNextWritableAdress().

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

The determination of the next_track number differs:

  https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs_mmc.cpp/#L926

    if (mmc_profile==0x41 && bdr_plus_pow)
        next_track = disc_info[6]|disc_info[11]<<8;
    else
        next_track = disc_info[5]|disc_info[10]<<8;

So for BD-R POW, growisofs reads field "Last Track Number in Last Session"
rather than "First Track Number in Last Session". (Not sure why it does this.)

  K3B has only first_track:

               int nextTrack = inf->first_track_l|inf->first_track_m<<8;

The definition of disc_info_t in libk3bdevice/k3bmmc.h has corresponding
fields .last_track_l and .last_track_m. I propose:

               int nextTrack;
               if( m == MEDIA_BD_R_SRM_POW )
                   nextTrack = inf->last_track_l|inf->last_track_m<<8;
               else
                   nextTrack = inf->first_track_l|inf->first_track_m<<8;

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

Contrary to my statement on saturday, there is a deviation with
lastSessionStart:

  https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs_mmc.cpp/#L962

      if (mmc_profile==0x41 && bdr_plus_pow)
        prev_session=0;
      else
        ... determination via READ PMA/TOC/ATIP ...

K3B has:

                    // Read start address of the first track in the last session
                    if( readTocPmaAtip( trackData, 0x1, false, 0x0  ) ) {
                        lastSessionStart = from4Byte( &trackData[8] );
                        success = true;
                    }

which should become

                    // Read start address of the first track in the last session
                    if( m == MEDIA_BD_R_SRM_POW ) {
                        lastSessionStart = 0;
                        success = true;
                    } else {
                        if( readTocPmaAtip( trackData, 0x1, false, 0x0  ) ) {
                            lastSessionStart = from4Byte( &trackData[8] );
                            success = true;
                        }
                    }

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

Hopefully these are all deviations in getNextWritableAdress().

But growisofs has bdr_plus_pow mentioned in get_2k_capacity().
One would have to search for the corresponding code in K3B.


We will need a courageous tester soon. (Expensive BD-R media will
be at risk.)


Have a nice day :)

Thomas
Comment 48 Leslie Zhai 2016-09-27 02:38:30 UTC
Git commit b189d1c39b52d5b646a089863eb8f44d3eeaa333 by Leslie Zhai.
Committed on 27/09/2016 at 02:30.
Pushed by lesliezhai into branch 'multisession'.

Update multisession implementation as Thomas suggested

Summary:
- emit error infoMessage for checking nextSessionStart in setupMultiSessionParameters
- nextTrack for bdr_plus_pow
- lastSessionStart for bdr_plus_pow

I am on vacation from Sep, 27 to Oct, 9 in small village, so I can *NOT*
quick response.

M  +4    -0    libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp
M  +13   -4    libk3bdevice/k3bdevice.cpp

http://commits.kde.org/k3b/b189d1c39b52d5b646a089863eb8f44d3eeaa333
Comment 49 Thomas Schmitt 2016-09-27 10:06:39 UTC
Hi,

> http://commits.kde.org/k3b/b189d1c39b52d5b646a089863eb8f44d3eeaa333

> libk3bdevice/k3bdevice.cpp:

> emit infoMessage(i18n("Medium is not of multi-session type and does not
> contain ISO 9660. Cannot emulate multi-session on it."), MessageError);

To make this statement true, the list of overwritable media needs to
be completed.

K3B functions determineMultiSessionModeFromMedium() and
setupMultiSessionParameters() have:

  if( info.mediaType() & (K3b::Device::MEDIA_DVD_PLUS_RW|
                            K3b::Device::MEDIA_DVD_PLUS_RW_DL|
                            K3b::Device::MEDIA_DVD_RW_OVWR|
                            K3b::Device::MEDIA_BD_RE) ) {

So setupMultiSessionParameters() will not look for ISO 9660 if the
medium is MEDIA_DVD_RAM or MEDIA_BD_R_RRM.
In this case the error message statement "does not contain ISO 9660"
might be wrong.

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

> libk3bdevice/k3bdevice.cpp

Well, let's hope that we translated correctly from growisofs.
(Everybody is invited to check.)


What to do with growisofs_mmc.cpp : get_2k_capacity() which has
special processing for BD-R POW ?

It computes the remaining writable space on the medium.
It seems that capacities computed in libk3bdevice/k3bdevice.cpp
are about the overall capacity of the medium.

Any idea where the writable space on medium is determined ?

A tester could possibly tell, whether a BD-R with a first session
written by growisofs shows any wrong numbers when inspected by K3B.

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

Have a nice day :)

Thomas
Comment 50 Leslie Zhai 2016-10-17 04:36:52 UTC
Git commit 15d3b05ce24a9158e120d4eaf0caadb0407fc0e7 by Leslie Zhai.
Committed on 17/10/2016 at 04:31.
Pushed by lesliezhai into branch 'multisession'.

Complete mediaType as Thomas suggested.

After KDE 20 years party (Oct 15), I have time to fix KDEBUG now ;-)
Towards writable space on medium is determined, when there is *NO* space
writable available, K3B will throw ERROR to user, so does not need to
compute the remaing writable space?

M  +6    -2    libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp

http://commits.kde.org/k3b/15d3b05ce24a9158e120d4eaf0caadb0407fc0e7
Comment 51 Thomas Schmitt 2016-10-17 07:59:01 UTC
http://commits.kde.org/k3b/15d3b05ce24a9158e120d4eaf0caadb0407fc0e7
looks good to me.

Now we'd need a tester who confirms that DVD-RAM can be used for multi-session like DVD+RW.
(BD-R RRM might be hard to achieve and possibly were never tested with growisofs. But maybe
somebody still has a DVD-RAM on the shelf.)
Comment 52 Leslie Zhai 2016-10-18 01:33:29 UTC
Hi Thomas,

> Now we'd need a tester, BD-R RRM might be hard to achieve

I will ask other KDE users to test it, and thank you so much for your help! you teach me a lot as a mentor patiently and carefully, it is trasure to me ;-)

Regards,
Leslie Zhai
Comment 53 Kevin Kofler 2016-11-05 01:33:44 UTC
In these commits, I see things like ,ms[0] == 0 or ms[1] != 0, where ms is a QStringList, so you are comparing a QString against 0. This doesn't look right. Either use isEmpty() or compare with the string "0", depending on what you actually meant.
Comment 54 Leslie Zhai 2016-11-08 02:42:57 UTC
(In reply to Kevin Kofler from comment #53)
> In these commits, I see things like ,ms[0] == 0 or ms[1] != 0, where ms is a
> QStringList, so you are comparing a QString against 0. This doesn't look
> right. Either use isEmpty() or compare with the string "0", depending on
> what you actually meant.

Hi please review it https://github.com/KDE/k3b/blob/master/libk3b/projects/k3bgrowisofswriter.cpp#L201
Comment 55 Leslie Zhai 2017-03-14 08:17:19 UTC
*** Bug 373523 has been marked as a duplicate of this bug. ***
Comment 56 Leslie Zhai 2017-03-28 01:46:54 UTC
*** Bug 378157 has been marked as a duplicate of this bug. ***
Comment 57 Leslie Zhai 2017-11-07 01:46:09 UTC
*** Bug 386401 has been marked as a duplicate of this bug. ***
Comment 58 sebastian 2017-11-07 15:57:11 UTC
Hy
Sorry people I don't have your level I am a simple user, I see a lot of talks but at the end it seems that you didn't yet find the solution :-( , I don't want to switch to another software, Please HELP
Comment 59 Thomas Schmitt 2017-11-07 17:19:38 UTC
Hi,

i don't think that bugs 378157 and 386401 are duplicates of 367639.

367639 (and 373523) is about a wrong growisofs option which was used by K3B
because it was not aware of the special needs of BD-R media formatted to
Pseudo-Overwrite. This is supposed to be fixed meanwhile.

378157 looks like a problem with the ISO 9660 producer program (mkisofs ?).

386401 looks like some inner problem of K3B. Maybe caused by the state
of the medium.

@Leslie:
Can you separate 386401 from 367639 ?

@sebastian:
Please post the output of

  dvd+rw-mediainfo /dev/sr0

when the DVD+R is inserted. This should tell us the medium state.

Have a nice day :)

Thomas
Comment 60 Leslie Zhai 2017-11-08 01:26:57 UTC
Hi Thomas,

Thanks a lot for your Multi-Session help :)

@sebastian

Please test as Thomas suggested, the simulator is not able to reproduce Multi-Session environment.

Regards,
Leslie Zhai