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

[Leslie Zhai]

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

--- Comment #60 from Leslie Zhai  ---
Hi Thomas,

Thanks a lot for your Multi-Session help :)

@sebastian

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

Regards,
Leslie Zhai

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

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

[Thomas Schmitt]

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

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

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

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

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

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

@Leslie:
Can you separate 386401 from 367639 ?

@sebastian:
Please post the output of

  dvd+rw-mediainfo /dev/sr0

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

Have a nice day :)

Thomas

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

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

[sebastian]

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

--- Comment #58 from sebastian  ---
Hy
Sorry people I don't have your level I am a simple user, I see a lot of talks
but at the end it seems that you didn't yet find the solution :-( , I don't
want to switch to another software, Please HELP

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

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

[Leslie Zhai]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||rikudou__sen...@outlook.com

--- Comment #57 from Leslie Zhai  ---
*** Bug 386401 has been marked as a duplicate of this bug. ***

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

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

[Simon Andric]

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

Simon Andric  changed:

   What|Removed |Added

 CC||simonandr...@gmail.com

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

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

[Leslie Zhai]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||ftefrjbhfvas...@o2.pl

--- Comment #56 from Leslie Zhai  ---
*** Bug 378157 has been marked as a duplicate of this bug. ***

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

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

[Leslie Zhai]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||roger_nor...@inorbit.com

--- Comment #55 from Leslie Zhai  ---
*** Bug 373523 has been marked as a duplicate of this bug. ***

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

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

[Leslie Zhai]

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

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

Hi please review it
https://github.com/KDE/k3b/blob/master/libk3b/projects/k3bgrowisofswriter.cpp#L201

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

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

[Kevin Kofler]

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

--- Comment #53 from Kevin Kofler  ---
In these commits, I see things like ,ms[0] == 0 or ms[1] != 0, where ms is a
QStringList, so you are comparing a QString against 0. This doesn't look right.
Either use isEmpty() or compare with the string "0", depending on what you
actually meant.

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #52 from Leslie Zhai  ---
Hi Thomas,

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

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

Regards,
Leslie Zhai

-- 
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 #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)

[Leslie Zhai via KDE Bugzilla]

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

Leslie Zhai  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Latest Commit|http://commits.kde.org/k3b/ |http://commits.kde.org/k3b/
   |62fda2003fcc355c8d18b9b530c |15d3b05ce24a9158e120d4eaf0c
   |725427578ad77   |aadb0407fc0e7
 Status|REOPENED|RESOLVED

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

Complete mediaType as Thomas suggested.

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

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

http://commits.kde.org/k3b/15d3b05ce24a9158e120d4eaf0caadb0407fc0e7

-- 
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)

[Leslie Zhai via KDE Bugzilla]

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

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

Update multisession implementation as Thomas suggested

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

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

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

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

-- 
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( [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( [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)

[Leslie Zhai via KDE Bugzilla]

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

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

Update multisession implementation as Thomas suggested

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

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

http://commits.kde.org/k3b/cbe652000292dc5a6c9e36de0d1000ca0d84f75d

-- 
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 #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( [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( [12] );
else
nextWritableAdress = from4Byte( [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 #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 #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)

[Leslie Zhai via KDE Bugzilla]

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

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

Fix multisession implementation as Thomas suggested

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

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

http://commits.kde.org/k3b/076340502f14a5ecd928551500392e5f38dd2c41

-- 
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 #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", ) == 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)

[Leslie Zhai via KDE Bugzilla]

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

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

Multisession implemented as Thomas suggested

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

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

http://commits.kde.org/k3b/ae0413daf1df44cb2c8c6e88a5b86180f1f52c3a

-- 
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",) == 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 

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #37 from Leslie Zhai  ---
Git commit e9faad4a24e80ee83a3881707e394ca4be66f5c7 by Leslie Zhai.
Committed on 21/09/2016 at 04:36.
Pushed by lesliezhai into branch 'multisession'.

Add more check for inquiring the ISO filesystem size

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

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

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #36 from Leslie Zhai  ---
Git commit b22f60344db146aa6b5136373b0a0b270d5d8ee9 by Leslie Zhai.
Committed on 21/09/2016 at 04:09.
Pushed by lesliezhai into branch 'multisession'.

Inquire the ISO filesystem size

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

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

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

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

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

[Leslie Zhai via KDE Bugzilla]

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

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

Wrong alleged_next_session for growisofs

WIP in multisession branch.

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

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

-- 
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 #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)

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #32 from Leslie Zhai  ---
Hi Thomas,

Then key point is:

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

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

Regards,
Leslie Zhai

-- 
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)

[Leslie Zhai via KDE Bugzilla]

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

Leslie Zhai  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #30 from Leslie Zhai  ---
Hi Thomas,

in short:

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

Regards,
Leslie Zhai

-- 
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)

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #28 from Leslie Zhai  ---
Git commit 477870ea36d07505889bfe33becc41ba57f3 by Leslie Zhai.
Committed on 19/09/2016 at 02:37.
Pushed by lesliezhai into branch 'multisession'.

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

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

http://commits.kde.org/k3b/477870ea36d07505889bfe33becc41ba57f3

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #27 from Leslie Zhai  ---
Hi Thomas,

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

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

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

Regards,
Leslie Zhai

-- 
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 #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 #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)

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #23 from Leslie Zhai  ---
Hi,

> How to fix it growisofs style

yes, growisofs implemented it:

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

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

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

Regards,
Leslie Zhai

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #22 from Leslie Zhai  ---
Hi Thomas,

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

Regards,
Leslie Zhai

-- 
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 

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

[Leslie Zhai via KDE Bugzilla]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||2aq9j93...@cogeco.ca

--- Comment #20 from Leslie Zhai  ---
*** Bug 281818 has been marked as a duplicate of this bug. ***

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

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

[Leslie Zhai via KDE Bugzilla]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||babelfish0...@hotmail.com

--- Comment #19 from Leslie Zhai  ---
*** Bug 356434 has been marked as a duplicate of this bug. ***

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #18 from Leslie Zhai  ---
Git commit f3f4602e30c67bf622b5a52ea39c78817b1dd020 by Leslie Zhai.
Committed on 02/09/2016 at 02:15.
Pushed by lesliezhai into branch 'master'.

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

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

http://commits.kde.org/k3b/f3f4602e30c67bf622b5a52ea39c78817b1dd020

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #17 from Leslie Zhai  ---
Hi Thomas,

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

> which i believe prevents the automatic use of growisofs

I will double check it!

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

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

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

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

Regards,
Leslie Zhai

-- 
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=blobdiff=0517d6f372551c8d0ae3ec8354e8a692bf92c299=0bc7b38bd1f587f3de6a0efbbd12e32359cbcffd=fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c=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 

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #15 from Leslie Zhai  ---
Hi Thomas,

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

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

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

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

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

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

> Isn't your patch mislabelled ?

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

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

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

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

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

Regards,
Leslie Zhai

-- 
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)

[Leslie Zhai via KDE Bugzilla]

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

Leslie Zhai  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Latest Commit||http://commits.kde.org/k3b/
   ||62fda2003fcc355c8d18b9b530c
   ||725427578ad77

--- Comment #13 from Leslie Zhai  ---
Git commit 62fda2003fcc355c8d18b9b530c725427578ad77 by Leslie Zhai.
Committed on 01/09/2016 at 04:23.
Pushed by lesliezhai into branch 'master'.

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

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

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

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

http://commits.kde.org/k3b/62fda2003fcc355c8d18b9b530c725427578ad77

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #12 from Leslie Zhai  ---
> This is a bit off topic, but on the long run these "self building 
> requirements" are going to make k3b unusable for most Fedora users.

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

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

Regards,
Leslie Zhai

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

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

[via KDE Bugzilla]

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

--- Comment #11 from m...@mnl.de ---
This is a bit off topic, but on the long run these "self building requirements"
are going to make k3b unusable for most Fedora users.

I will continue to try to build the new version as I have time. But to get my
blue-ray burning done, I've had a look at command line usage of growisfs in the
meantime. It works fine (I think the only problem is the "-C" parameter that
k3b passes to it, as can be seen in the log) and it is really easy to use. The
only obvious advantage that k3b still offers to me regarding my burning tasks
is proof reading.

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #10 from Leslie Zhai  ---
Hi mnl,

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

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

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

Regards,
Leslie Zhai

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

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

[via KDE Bugzilla]

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

--- Comment #9 from m...@mnl.de ---
The problem with cdrecord on Fedora is that it is in none of the standard
repositories nor in the free/nonfree Fusion repositories except as "limited
cdrecord compatibility wrapper" in package "cdrskin".

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #8 from Leslie Zhai  ---
Git commit fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c by Leslie Zhai.
Committed on 30/08/2016 at 15:19.
Pushed by lesliezhai into branch 'master'.

Use cdrecord for burning blueray instead of wodim.

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

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

http://commits.kde.org/k3b/fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #7 from Leslie Zhai  ---
Hi mnl,

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

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

Regards,
Leslie Zhai

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

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

[via KDE Bugzilla]

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

--- Comment #6 from m...@mnl.de ---
Version 2.10.0 still fails to compile:


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

 "/usr/lib64/libEGL.so"

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


I checked. The file IS there!

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #5 from Leslie Zhai  ---
Hi mnl,

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

Regards,
Leslie Zhai

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

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

[Leslie Zhai via KDE Bugzilla]

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

--- Comment #4 from Leslie Zhai  ---
Hi mnl,

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

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

Regards,
Leslie Zhai

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

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

[Burkhard Lueck via KDE Bugzilla]

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

Burkhard Lueck  changed:

   What|Removed |Added

 CC||lu...@hube-lueck.de

--- Comment #3 from Burkhard Lueck  ---
(In reply to mnl from comment #2)
> I failed to find a package that provides "ecm" on Fedora (though it seems to
 be "standard" on Ubuntu for a long time). Can you give me a hint?

http://pkgs.fedoraproject.org/cgit/rpms/extra-cmake-modules.git/

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

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

[via KDE Bugzilla]

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

--- Comment #2 from m...@mnl.de ---
Hi Leslie,

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

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

 - Michael

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

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

[Leslie Zhai via KDE Bugzilla]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||xiangzha...@gmail.com

--- Comment #1 from Leslie Zhai  ---
Hi mnl,

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

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

Regards,
Leslie Zhai

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

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

[via KDE Bugzilla]

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

m...@mnl.de changed:

   What|Removed |Added

 CC||m...@mnl.de

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