[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 #51 from Thomas Schmitt  ---
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.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #24 from Thomas Schmitt  ---
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 watching all bug changes.

[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 #25 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #26 from Thomas Schmitt  ---
I should mention that session 2 tests with growisofs -M instead of -Z failed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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  ---
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 watching all bug changes.

[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 #31 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #33 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #34 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #38 from Thomas Schmitt  ---
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  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 corr

[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 #40 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #42 from Thomas Schmitt  ---
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 = 0x200,

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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #43 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #44 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #45 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #47 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #49 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

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

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

--- Comment #14 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #16 from Thomas Schmitt  ---
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 bu

[k3b] [Bug 281818] K3B - Crash - "Fatal error during recording: input/output error" - at end of 21.2gb burn

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 356434] Cannot Burn Multisession DVD's on Linux Mint System

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #9 from Thomas Schmitt  ---
The main problem is that google does not find any free tool to master
a UDF filesystem for Blu-ray. Burning the filesystem to media would
then be easy.
Aren't any Blu-ray players out there which play video files from other 
filesystems like ISO 9660 ? (If there are: Boycott the others.)

UDF specs are available for free as PDFs of ECMA-167 plus UDF-2.60.
But they are written in an unappealing way. So it would need some sincere
bribery to get this done. (One or two picky Blu-ray players, a few
standards-conformant commercial Blu-ray videos, a variety of addictive
drugs to keep the programmer from running away.)
It might also cost money to get official specs for Blu-ray video which
might name more constraints beyond UDF.
(I would not reject a contribution to libisofs. But integrating and testing
it will not be a picnic.)



I doubt that https://bugs.kde.org/show_bug.cgi?id=344392 is a duplicate
of this bug report here.
Here we bemoan the lack of a Blu-ray video mastering tool.
344392 is about the suspicion that K3B insists in particular image formats
like ISO 9660 and rejects UDF.

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

--- Comment #8 from Thomas Schmitt  ---
I doubt that the problem described here is a duplicate of
https://bugs.kde.org/show_bug.cgi?id=257602

257602 bemoans the lack of a free Blu-ray video mastering tool which puts
out UDF 2.5 or later.
The bug ireport here is about the suspicion that K3B insists in particular
image formats like ISO 9660 and rejects UDF.

I did not find an online repository of K3B upstream. So i looked into
Debians source tree and think that the suspicion gets confirmed in
function (C++tapeworm)::slotUpdateImage
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=517#L517
First d->foundImageType = IMAGE_UNKNOWN; then it looks for ISO 9660,
for "cdrecord clone image" (binary file accompanied by .toc file),
for a CDRWIN .cue file, and has a TODO comment for "cdrdao tocfile".
If none matches, then the image gets the complaint
  "Seems not to be a usable image"

The motivation for the curiosity seems to be the desire to interpret
structured image descriptions like .toc and .cue, which shall not be
written onto medium but rather tell what data to put where on the medium.



A brutal hack and proof of concept would be to default IMAGE_UNKNOWN
to IMAGE_ISO:

d->foundImageType = IMAGE_ISO;
d->imageFile = path;

instead of

K3b::ListViewItem* item = new K3b::ListViewItem( m_infoView,
m_infoView->lastItem(),
 i18n("Seems not to be a usable image") );

and to delete the else-clause before the case of known image type:

-else {
+{
  // remember as recent image

If this works in the further course of K3B processing, then one could
make the hack permanent. I.e. write unknown images as ISOs.

It might be, nevertheless, that other K3B parts interpret IMAGE_ISO
not only as the order to copy plainly and unaltered but also as
promise that indeed an ISO 9660 superblock and directory tree are
present in the image.
Relying on such a promise would of course yield failure.

If such a promise/expectation exists or if one just wants to implement
it neatly, then one should split all occurences of IMAGE_ISO into those
which just indicate plain image copying and those which really indicate
an ISO 9660 filesystem.
The list of occurences is finite:
  https://codesearch.debian.net/search?q=package%3Ak3b+IMAGE_ISO

A new enum value in
 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.h/?hl=79#L79
could then be IMAGE_RAW, indicating that it's not an ISO but nevertheless
shall be copied as if it was one.

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #10 from Thomas Schmitt  ---
I had a look at the spots where Debian's source search finds IMAGE_ISO.

Whether IMAGE_RAW is really needed seems to depend only on the tolerance 
towards the size test in
 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=463#L463
If isoFs() or isoFs.open() throw an exception then it might be necessary
to skip this test.

In this case it would be necessary to introduce IMAGE_RAW or let
IMAGE_UNKNOWN take over the role of IMAGE_RAW.
It seem, though, that IMAGE_UNKNOWN also serves as "Image Unsuitable".
So one better introduces a new value.

--

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=887#L887
would be ok for IMAGE_RAW, too. I.e.
if( currentImageType() == IMAGE_ISO || currentImageType() == IMAGE_RAW) {

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=244#L244
 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=249#L249
would need mapping and reverse mapping for IMAGE_RAW.
Actually the existing text "Plain data image" would rather match IMAGE_RAW
than IMAGE_ISO.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=1087#L1087
would need a display text for IMAGE_RAW. Like "opaque".
 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=1048#L1048
would then need a case "opaque" and make use of the reverse mapping
defined by L249.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=845#L845
would have to allow growisofs for IMAGE_RAW as for IMAGE_ISO.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=858#L858
one would have to add IMAGE_RAW to the "||" list.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=867#L867
Same as L858.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=874#L874
Same as L858.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=548#L548
must stay as is, because it determines whether the file is really an
ISO 9660 filesystem image. It will thus determine the difference between
IMAGE_ISO and IMAGE_RAW.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.h/?hl=81#L81
would define the new enum value IMAGE_RAW.

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #14 from Thomas Schmitt  ---
Hi,

Leslie Zhai:
> I am reading carefully about your implementation about IMAGE_RAW. and please
> rebase your patch for image-raw branch

Well, i did not implement anything but only inspected the situation
and made a rough plan what would need a change.
I am running neither KDE nor Gnome on my workstation. Building K3B
from source would start a big endeavor on its own.

But i will from now on study that branch (maybe still using Debian
code search, because searching "IMAGE_ISO" in https://quickgit.kde.org/
yields no match).

Let's see whether i find something to nitpick:
-
Line 473 of k3bimagewritingdialog.cpp:

d->comboImageType->addItem(i18n("Optical disc media"));

I would rather call it "ISO 9660 filesystem image".

I is not an optical medium but rather shall get onto optical medium.
Albeit ISO 9660 (and its predecessor High Sierra) was announced as
the filesystem for CD-ROM media, ISO 9660 has long escaped that cage.
It is as read-only filesystem very well suited for backup and archiving.
In its role as bootable filesystem it has conquered USB sticks and
memory cards.

-
Line 707:

case IMAGE_RAW:
case IMAGE_ISO:
{
K3b::Iso9660 isoFs( d->imageFile );
if( isoFs.open() ) {

}

I proposed to introduce IMAGE_RAW in order to be able to skip this test
for size. So there should be an if around it:

case IMAGE_RAW:
case IMAGE_ISO:
{
if ( d->currentImageType() == IMAGE_ISO ) {
K3b::Iso9660 isoFs( d->imageFile );
if( isoFs.open() ) {

}
}

Has it been tested already that

K3b::Iso9660ImageWritingJob* job_ = new K3b::Iso9660ImageWritingJob( &dlg
);

works with non ISO 9660 images ?

-
Line 871:

if (KMessageBox::questionYesNo(this,
   i18n("Seems not to be a usable image, do
you want to treat it as RAW?"),
   i18n("Unkown image type")) ==
KMessageBox::Yes) {

The text is somewhat misleading, especially since "raw" has an old
meaning in the context of CD burning.

I would rather state
  "Type of image file is not recognizable. Do you want to burn it anyway ?"

-
Line 938:

You removed the case  d->currentImageType() == IMAGE_UNKNOWN .

I am not sure whether IMAGE_UNKNOWN can reach this code. Nevertheless
we would need a source code review to assert that it cannot.

So i'd cowardly keep IMAGE_UNKNOWN in the "||" list.

-

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #17 from Thomas Schmitt  ---
Hi,

Leslie Zhai wrote:
> Please review it https://git.reviewboard.kde.org/r/128860/

I see a box "Testing Done" but no place to state that i did a code
review but did not test.

Shall i write: "Code reviewed but not tested" ?


> I do *NOT* have BD50 (Blu-ray double layer) ISO image,

The problem is neither about the size nor about the medium.
So you could create any non-ISO image file:

  dd if=/dev/zero bs=1M count=100 of=my_100mb_test.img

and use the CD emulator as target device.


Nitpicks:
---

The comment

  // set a wanted media type (DVD/BD -> only ISO)

riddled me already when i looked at the code for the first time.

I believe it wants to say that if the image is not IMAGE_ISO, IMAGE_RAW,
or IMAGE_UNKNOWN, then it is a structured CD image description which
cannot be interpreted for DVD or BD media.
So the wanted medium type is  MEDIA_WRITABLE_CD  in this case, and
any medium type for ISO, RAW, and UNKNOWN.

Maybe one should change it to

  // set a wanted media type
  // some image types can be put on any medium, some only on CD

---

I still have scruples about the type name "raw" in lines 1152

else if (imageType == "raw")

and 1200:
 imageType = "raw";

In man cdrecord (or man wodim) there are lots of references to "raw"
in the sense that CD sector metadata are provided by the input data
of the burn program. A CD sector has 98 * (24 + 8 + 1) = 3234 bytes.
CD-Audio uses 98 * 24 = 2352 for payload. The rest is C1,C2 checksums
and 98 subchannel bytes. CD-ROM uses 2048 for payload. The rest is
filled with more meta-info about the CD sector. Normally we send only
the 2048 bytes to the drive which then computes the meta data.
In "raw" write mode cdrecord sends some or all of the meta-data too.

But this is not what we mean with "raw" image.
So the user should get to see a different word when IMAGE_RAW is being
processed.

(One could argue that IMAGE_RAW should be IMAGE_PLAIN and the text
 should be "plain".
 If i had thought of the raw-raw nomenclature collision i had
 proposed a different macro name. But "IMAGE_RAW" will only be seen
 by programmers, whom i suppose to easily find out that IMAGE_RAW
 is not an image for cdrecord -raw.
)

---

Elsewise the changeset looks good to me.
Testing will tell whether it suffices to solve the problem.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #22 from Thomas Schmitt  ---
Hi,

Leslie Zhai wrote:
> Please click 'Review' to review the patch:
> You can click 'Expand All' to be familiar with KDE's review process

Probably i do not see any text fields to fill because i am not logged in
and my bugs.kde.org account does not work.
Registering now as non-robot ...

After login i see a tab "Review" which brings me to a page with 
checkbox "Ship it" and editable text box "Edit header".

I begin to read the online documentation.
If you have instructions for me how to operate it, i would be glad
to follow them.


> CDEmu might has strict image test! when I try to cdemu load 0
> ~/my_100mb_test.img, it thrown such error:

my_100mb_test.img shall not emulate the medium. It shall be copied
onto the emulated medium.

I assume CDEmu has means to create a simulated CD or DVD.
(Did not find a user manual yet.)
This emulated drive and medium would then be the CD drive for the
K3B test. In K3B you select my_100mb_test.img as image file to be
burned.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #23 from Thomas Schmitt  ---
Hi,

i reviewed the whole patch as "Looks good to me".
Since i see no problematic details i think i can skip for now learning
how to comment on single lines. (Tell me if i shall add more info to
the review.)


You need to get a DVD drive. Last year i bought an LG GH24NSC0 for
12.95 EUR. Blu-ray burners still cost around 80 EUR. My newest is
ASUS BW-16D1HT and works well.

Next you'd need a few DVD-RW media, because they are re-usable and can
assume both main roles of optical media: sequential and overwritable.
Switch by dvd+rw-format: no extra option for making overwritable,
option -blank for making sequential, option -blank=full to make it
ready for sequential multi-session.
(-blank[=full] has to be repeated before each sequential re-use.
 Overwritable media can be re-used without formatting them again.
 Formatting and -blank=full last as long as a full capaity write run.)

DVD+RW are more reliable than DVD-RW, but they cannot be written in
sequential state. DVD-RW can be used like DVD-R and quite like DVD+R
or unformatted BD-R.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #25 from Thomas Schmitt  ---
Hi,

i wanted to paste to following text into the "Edit header" field
of https://git.reviewboard.kde.org/r/128860/.

But neither the paste function of the window manager nor the paste
menu item of Firefox puts the X selection into the browser field.
Further i always have to disable Javascript when using Debian
code search and enable it before git.reviewboard.kde.org is willing
to communicate with me.

I am getting too old for this modern stuff, i fear.


Review text:


The green "Success" text in the screenshot is a reason to cheer.

While digging in the code i found in
   libk3b / jobs / k3biso9660imagewritingjob.cpp
line 340:

   if( m_simulate )
return i18n("Simulating ISO 9660 Image");
else
return ( i18n("Burning ISO 9660 Image");

Did you see pacifier texts or a headline stating "ISO 9660" ?

Not really understanding how variable "d" enters the context of
the functions and to what type it points, i have no clue whether
one can inquire d->foundImageType or whether currentImageType()
is in reach to avoid the text "ISO 9660" in case of not IMAGE_ISO.


End of review text.


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #27 from Thomas Schmitt  ---
Hi,

Phil wrote:
> Are there any easy to install and use Linux ".deb" files

Well, as soon as it becomes a released feature of K3B, one may ask
pkg-kde-ext...@lists.alioth.debian.org for packaging, or file a
Debian bug against package "k3b" requesting it.
Debian's package info is at https://tracker.debian.org/pkg/k3b .

Maybe https://launchpad.net/~kubuntu-members as mentioned on 
https://launchpad.net/ubuntu/+source/k3b would be willing to make 
a shortcut.

> hould I create another "KDE bug - feature" [...]
> verifying ".iso"  images to include a more current  "sha256" checksum

I guess the rules here require that we discuss this in a different
bug report thread.
For transport and storage security, MD5 suffices. The probability of
a false match is far less than the earth being hit by a 10 km asteroid
within the next microsecond. If you don't fear that, then there is no 
need to fear accidential MD5 match.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #29 from Thomas Schmitt  ---
Hi,

Leslie Zhai wrote:
> D-Pointer https://wiki.qt.io/D-Pointer

Looks like somebody had to work around some consequences of the
decision to use C++. (Oh if only Bjarne Stroustrup had a real life
back in the 1980s !)


> headline stating "ISO 9660"
> https://forum.isoft-linux.org/viewtopic.php?f=3&t=47

Yep. The "Writing Data Project (virt)" window says "ISO 9660 Filesystem".
But that is not the text i see in k3biso9660imagewritingjob.cpp
"Simulating ISO 9660 Image" and ""Burning ISO 9660 Image".

Question is where this comes from and how to provide the information
about ImageWritingDialog.foundImageType at that place.


Phil wrote:
> should I create another "KDE bug - feature" request

If i shall join that discussion. i'd need a pointer to the thread
by email: scdbac...@gmx.net
(Google finds me places where people say "xorriso", "libburn", or
 "growisofs". But "K3B" yields just too many hits per day.)


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 360184] k3b should offer option to select either md5 sum or sha256 when loading dvd iso

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

--- Comment #3 from Thomas Schmitt  ---
Hi,

K3B already uses class QCryptographicHash. (In the Debian version it is
deprecated class KMD5.)
See libk3b/tools/k3bmd5job.cpp, line 44.

The newly used class offers a long list of hash algorithms:
  http://doc.qt.io/qt-5/qcryptographichash.html

If i get it right, then currently MD5 is hardcoded in line 35 of
k3bmd5job.cpp:

 : md5(QCryptographicHash::Md5),

This hardcoded default needs to be replaced by a user choice among the 
offered algorithms. E.g.  QCryptographicHash::Sha512 .

Now that's where i reach the end of my expertise as C programmer and
command line burner. The remaining work is about C++ tech and testing
whether it works with other algorithms and does not display confusing
messages about MD5 when SHA512 is selected.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #21 from Thomas Schmitt  ---
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=
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= (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:

  $ cd

[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 #51 from Thomas Schmitt  ---
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.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #24 from Thomas Schmitt  ---
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 watching all bug changes.

[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 #25 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #26 from Thomas Schmitt  ---
I should mention that session 2 tests with growisofs -M instead of -Z failed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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  ---
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 watching all bug changes.

[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 #31 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #33 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #34 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #38 from Thomas Schmitt  ---
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  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 corr

[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 #40 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #42 from Thomas Schmitt  ---
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 = 0x200,

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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #43 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #44 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #45 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #47 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #49 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

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

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

--- Comment #14 from Thomas Schmitt  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #16 from Thomas Schmitt  ---
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 bu

[k3b] [Bug 281818] K3B - Crash - "Fatal error during recording: input/output error" - at end of 21.2gb burn

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 356434] Cannot Burn Multisession DVD's on Linux Mint System

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #9 from Thomas Schmitt  ---
The main problem is that google does not find any free tool to master
a UDF filesystem for Blu-ray. Burning the filesystem to media would
then be easy.
Aren't any Blu-ray players out there which play video files from other 
filesystems like ISO 9660 ? (If there are: Boycott the others.)

UDF specs are available for free as PDFs of ECMA-167 plus UDF-2.60.
But they are written in an unappealing way. So it would need some sincere
bribery to get this done. (One or two picky Blu-ray players, a few
standards-conformant commercial Blu-ray videos, a variety of addictive
drugs to keep the programmer from running away.)
It might also cost money to get official specs for Blu-ray video which
might name more constraints beyond UDF.
(I would not reject a contribution to libisofs. But integrating and testing
it will not be a picnic.)



I doubt that https://bugs.kde.org/show_bug.cgi?id=344392 is a duplicate
of this bug report here.
Here we bemoan the lack of a Blu-ray video mastering tool.
344392 is about the suspicion that K3B insists in particular image formats
like ISO 9660 and rejects UDF.

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

--- Comment #8 from Thomas Schmitt  ---
I doubt that the problem described here is a duplicate of
https://bugs.kde.org/show_bug.cgi?id=257602

257602 bemoans the lack of a free Blu-ray video mastering tool which puts
out UDF 2.5 or later.
The bug ireport here is about the suspicion that K3B insists in particular
image formats like ISO 9660 and rejects UDF.

I did not find an online repository of K3B upstream. So i looked into
Debians source tree and think that the suspicion gets confirmed in
function (C++tapeworm)::slotUpdateImage
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=517#L517
First d->foundImageType = IMAGE_UNKNOWN; then it looks for ISO 9660,
for "cdrecord clone image" (binary file accompanied by .toc file),
for a CDRWIN .cue file, and has a TODO comment for "cdrdao tocfile".
If none matches, then the image gets the complaint
  "Seems not to be a usable image"

The motivation for the curiosity seems to be the desire to interpret
structured image descriptions like .toc and .cue, which shall not be
written onto medium but rather tell what data to put where on the medium.



A brutal hack and proof of concept would be to default IMAGE_UNKNOWN
to IMAGE_ISO:

d->foundImageType = IMAGE_ISO;
d->imageFile = path;

instead of

K3b::ListViewItem* item = new K3b::ListViewItem( m_infoView,
m_infoView->lastItem(),
 i18n("Seems not to be a usable image") );

and to delete the else-clause before the case of known image type:

-else {
+{
  // remember as recent image

If this works in the further course of K3B processing, then one could
make the hack permanent. I.e. write unknown images as ISOs.

It might be, nevertheless, that other K3B parts interpret IMAGE_ISO
not only as the order to copy plainly and unaltered but also as
promise that indeed an ISO 9660 superblock and directory tree are
present in the image.
Relying on such a promise would of course yield failure.

If such a promise/expectation exists or if one just wants to implement
it neatly, then one should split all occurences of IMAGE_ISO into those
which just indicate plain image copying and those which really indicate
an ISO 9660 filesystem.
The list of occurences is finite:
  https://codesearch.debian.net/search?q=package%3Ak3b+IMAGE_ISO

A new enum value in
 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.h/?hl=79#L79
could then be IMAGE_RAW, indicating that it's not an ISO but nevertheless
shall be copied as if it was one.

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #10 from Thomas Schmitt  ---
I had a look at the spots where Debian's source search finds IMAGE_ISO.

Whether IMAGE_RAW is really needed seems to depend only on the tolerance 
towards the size test in
 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=463#L463
If isoFs() or isoFs.open() throw an exception then it might be necessary
to skip this test.

In this case it would be necessary to introduce IMAGE_RAW or let
IMAGE_UNKNOWN take over the role of IMAGE_RAW.
It seem, though, that IMAGE_UNKNOWN also serves as "Image Unsuitable".
So one better introduces a new value.

--

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=887#L887
would be ok for IMAGE_RAW, too. I.e.
if( currentImageType() == IMAGE_ISO || currentImageType() == IMAGE_RAW) {

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=244#L244
 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=249#L249
would need mapping and reverse mapping for IMAGE_RAW.
Actually the existing text "Plain data image" would rather match IMAGE_RAW
than IMAGE_ISO.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=1087#L1087
would need a display text for IMAGE_RAW. Like "opaque".
 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=1048#L1048
would then need a case "opaque" and make use of the reverse mapping
defined by L249.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=845#L845
would have to allow growisofs for IMAGE_RAW as for IMAGE_ISO.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=858#L858
one would have to add IMAGE_RAW to the "||" list.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=867#L867
Same as L858.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=874#L874
Same as L858.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=548#L548
must stay as is, because it determines whether the file is really an
ISO 9660 filesystem image. It will thus determine the difference between
IMAGE_ISO and IMAGE_RAW.

 
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.h/?hl=81#L81
would define the new enum value IMAGE_RAW.

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #14 from Thomas Schmitt  ---
Hi,

Leslie Zhai:
> I am reading carefully about your implementation about IMAGE_RAW. and please
> rebase your patch for image-raw branch

Well, i did not implement anything but only inspected the situation
and made a rough plan what would need a change.
I am running neither KDE nor Gnome on my workstation. Building K3B
from source would start a big endeavor on its own.

But i will from now on study that branch (maybe still using Debian
code search, because searching "IMAGE_ISO" in https://quickgit.kde.org/
yields no match).

Let's see whether i find something to nitpick:
-
Line 473 of k3bimagewritingdialog.cpp:

d->comboImageType->addItem(i18n("Optical disc media"));

I would rather call it "ISO 9660 filesystem image".

I is not an optical medium but rather shall get onto optical medium.
Albeit ISO 9660 (and its predecessor High Sierra) was announced as
the filesystem for CD-ROM media, ISO 9660 has long escaped that cage.
It is as read-only filesystem very well suited for backup and archiving.
In its role as bootable filesystem it has conquered USB sticks and
memory cards.

-
Line 707:

case IMAGE_RAW:
case IMAGE_ISO:
{
K3b::Iso9660 isoFs( d->imageFile );
if( isoFs.open() ) {

}

I proposed to introduce IMAGE_RAW in order to be able to skip this test
for size. So there should be an if around it:

case IMAGE_RAW:
case IMAGE_ISO:
{
if ( d->currentImageType() == IMAGE_ISO ) {
K3b::Iso9660 isoFs( d->imageFile );
if( isoFs.open() ) {

}
}

Has it been tested already that

K3b::Iso9660ImageWritingJob* job_ = new K3b::Iso9660ImageWritingJob( &dlg
);

works with non ISO 9660 images ?

-
Line 871:

if (KMessageBox::questionYesNo(this,
   i18n("Seems not to be a usable image, do
you want to treat it as RAW?"),
   i18n("Unkown image type")) ==
KMessageBox::Yes) {

The text is somewhat misleading, especially since "raw" has an old
meaning in the context of CD burning.

I would rather state
  "Type of image file is not recognizable. Do you want to burn it anyway ?"

-
Line 938:

You removed the case  d->currentImageType() == IMAGE_UNKNOWN .

I am not sure whether IMAGE_UNKNOWN can reach this code. Nevertheless
we would need a source code review to assert that it cannot.

So i'd cowardly keep IMAGE_UNKNOWN in the "||" list.

-

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #17 from Thomas Schmitt  ---
Hi,

Leslie Zhai wrote:
> Please review it https://git.reviewboard.kde.org/r/128860/

I see a box "Testing Done" but no place to state that i did a code
review but did not test.

Shall i write: "Code reviewed but not tested" ?


> I do *NOT* have BD50 (Blu-ray double layer) ISO image,

The problem is neither about the size nor about the medium.
So you could create any non-ISO image file:

  dd if=/dev/zero bs=1M count=100 of=my_100mb_test.img

and use the CD emulator as target device.


Nitpicks:
---

The comment

  // set a wanted media type (DVD/BD -> only ISO)

riddled me already when i looked at the code for the first time.

I believe it wants to say that if the image is not IMAGE_ISO, IMAGE_RAW,
or IMAGE_UNKNOWN, then it is a structured CD image description which
cannot be interpreted for DVD or BD media.
So the wanted medium type is  MEDIA_WRITABLE_CD  in this case, and
any medium type for ISO, RAW, and UNKNOWN.

Maybe one should change it to

  // set a wanted media type
  // some image types can be put on any medium, some only on CD

---

I still have scruples about the type name "raw" in lines 1152

else if (imageType == "raw")

and 1200:
 imageType = "raw";

In man cdrecord (or man wodim) there are lots of references to "raw"
in the sense that CD sector metadata are provided by the input data
of the burn program. A CD sector has 98 * (24 + 8 + 1) = 3234 bytes.
CD-Audio uses 98 * 24 = 2352 for payload. The rest is C1,C2 checksums
and 98 subchannel bytes. CD-ROM uses 2048 for payload. The rest is
filled with more meta-info about the CD sector. Normally we send only
the 2048 bytes to the drive which then computes the meta data.
In "raw" write mode cdrecord sends some or all of the meta-data too.

But this is not what we mean with "raw" image.
So the user should get to see a different word when IMAGE_RAW is being
processed.

(One could argue that IMAGE_RAW should be IMAGE_PLAIN and the text
 should be "plain".
 If i had thought of the raw-raw nomenclature collision i had
 proposed a different macro name. But "IMAGE_RAW" will only be seen
 by programmers, whom i suppose to easily find out that IMAGE_RAW
 is not an image for cdrecord -raw.
)

---

Elsewise the changeset looks good to me.
Testing will tell whether it suffices to solve the problem.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #22 from Thomas Schmitt  ---
Hi,

Leslie Zhai wrote:
> Please click 'Review' to review the patch:
> You can click 'Expand All' to be familiar with KDE's review process

Probably i do not see any text fields to fill because i am not logged in
and my bugs.kde.org account does not work.
Registering now as non-robot ...

After login i see a tab "Review" which brings me to a page with 
checkbox "Ship it" and editable text box "Edit header".

I begin to read the online documentation.
If you have instructions for me how to operate it, i would be glad
to follow them.


> CDEmu might has strict image test! when I try to cdemu load 0
> ~/my_100mb_test.img, it thrown such error:

my_100mb_test.img shall not emulate the medium. It shall be copied
onto the emulated medium.

I assume CDEmu has means to create a simulated CD or DVD.
(Did not find a user manual yet.)
This emulated drive and medium would then be the CD drive for the
K3B test. In K3B you select my_100mb_test.img as image file to be
burned.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #23 from Thomas Schmitt  ---
Hi,

i reviewed the whole patch as "Looks good to me".
Since i see no problematic details i think i can skip for now learning
how to comment on single lines. (Tell me if i shall add more info to
the review.)


You need to get a DVD drive. Last year i bought an LG GH24NSC0 for
12.95 EUR. Blu-ray burners still cost around 80 EUR. My newest is
ASUS BW-16D1HT and works well.

Next you'd need a few DVD-RW media, because they are re-usable and can
assume both main roles of optical media: sequential and overwritable.
Switch by dvd+rw-format: no extra option for making overwritable,
option -blank for making sequential, option -blank=full to make it
ready for sequential multi-session.
(-blank[=full] has to be repeated before each sequential re-use.
 Overwritable media can be re-used without formatting them again.
 Formatting and -blank=full last as long as a full capaity write run.)

DVD+RW are more reliable than DVD-RW, but they cannot be written in
sequential state. DVD-RW can be used like DVD-R and quite like DVD+R
or unformatted BD-R.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #25 from Thomas Schmitt  ---
Hi,

i wanted to paste to following text into the "Edit header" field
of https://git.reviewboard.kde.org/r/128860/.

But neither the paste function of the window manager nor the paste
menu item of Firefox puts the X selection into the browser field.
Further i always have to disable Javascript when using Debian
code search and enable it before git.reviewboard.kde.org is willing
to communicate with me.

I am getting too old for this modern stuff, i fear.


Review text:


The green "Success" text in the screenshot is a reason to cheer.

While digging in the code i found in
   libk3b / jobs / k3biso9660imagewritingjob.cpp
line 340:

   if( m_simulate )
return i18n("Simulating ISO 9660 Image");
else
return ( i18n("Burning ISO 9660 Image");

Did you see pacifier texts or a headline stating "ISO 9660" ?

Not really understanding how variable "d" enters the context of
the functions and to what type it points, i have no clue whether
one can inquire d->foundImageType or whether currentImageType()
is in reach to avoid the text "ISO 9660" in case of not IMAGE_ISO.


End of review text.


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #27 from Thomas Schmitt  ---
Hi,

Phil wrote:
> Are there any easy to install and use Linux ".deb" files

Well, as soon as it becomes a released feature of K3B, one may ask
pkg-kde-ext...@lists.alioth.debian.org for packaging, or file a
Debian bug against package "k3b" requesting it.
Debian's package info is at https://tracker.debian.org/pkg/k3b .

Maybe https://launchpad.net/~kubuntu-members as mentioned on 
https://launchpad.net/ubuntu/+source/k3b would be willing to make 
a shortcut.

> hould I create another "KDE bug - feature" [...]
> verifying ".iso"  images to include a more current  "sha256" checksum

I guess the rules here require that we discuss this in a different
bug report thread.
For transport and storage security, MD5 suffices. The probability of
a false match is far less than the earth being hit by a 10 km asteroid
within the next microsecond. If you don't fear that, then there is no 
need to fear accidential MD5 match.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 344392] Can't burn BD50 ISO image - Seems not to be a usable image

[Thomas Schmitt via KDE Bugzilla]

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

--- Comment #29 from Thomas Schmitt  ---
Hi,

Leslie Zhai wrote:
> D-Pointer https://wiki.qt.io/D-Pointer

Looks like somebody had to work around some consequences of the
decision to use C++. (Oh if only Bjarne Stroustrup had a real life
back in the 1980s !)


> headline stating "ISO 9660"
> https://forum.isoft-linux.org/viewtopic.php?f=3&t=47

Yep. The "Writing Data Project (virt)" window says "ISO 9660 Filesystem".
But that is not the text i see in k3biso9660imagewritingjob.cpp
"Simulating ISO 9660 Image" and ""Burning ISO 9660 Image".

Question is where this comes from and how to provide the information
about ImageWritingDialog.foundImageType at that place.


Phil wrote:
> should I create another "KDE bug - feature" request

If i shall join that discussion. i'd need a pointer to the thread
by email: scdbac...@gmx.net
(Google finds me places where people say "xorriso", "libburn", or
 "growisofs". But "K3B" yields just too many hits per day.)


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[k3b] [Bug 360184] k3b should offer option to select either md5 sum or sha256 when loading dvd iso

[Thomas Schmitt via KDE Bugzilla]

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

Thomas Schmitt  changed:

   What|Removed |Added

 CC||scdbac...@gmx.net

--- Comment #3 from Thomas Schmitt  ---
Hi,

K3B already uses class QCryptographicHash. (In the Debian version it is
deprecated class KMD5.)
See libk3b/tools/k3bmd5job.cpp, line 44.

The newly used class offers a long list of hash algorithms:
  http://doc.qt.io/qt-5/qcryptographichash.html

If i get it right, then currently MD5 is hardcoded in line 35 of
k3bmd5job.cpp:

 : md5(QCryptographicHash::Md5),

This hardcoded default needs to be replaced by a user choice among the 
offered algorithms. E.g.  QCryptographicHash::Sha512 .

Now that's where i reach the end of my expertise as C programmer and
command line burner. The remaining work is about C++ tech and testing
whether it works with other algorithms and does not display confusing
messages about MD5 when SHA512 is selected.

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[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 #21 from Thomas Schmitt  ---
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=
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= (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:

  $ cd