Bug 381074

Created attachment 106038 [details]
Empty BD-R medium

Hello,

Download with jigdo:
http://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/

Regards,
--
Cristian

Git commit 81b4b37b9b580ac701a57c570c8eca58d1b33331 by Leslie Zhai.
Committed on 12/06/2017 at 03:38.
Pushed by lesliezhai into branch 'master'.

Reproducebility race?

M  +2    -1    src/k3bemptydiscwaiter.cpp

https://commits.kde.org/k3b/81b4b37b9b580ac701a57c570c8eca58d1b33331

Hi Cristian,

> Reproducebility race?
> 
> M  +2    -1    src/k3bemptydiscwaiter.cpp
> 
> https://commits.kde.org/k3b/81b4b37b9b580ac701a57c570c8eca58d1b33331

Could you reproduce the issue all the time?

Regards,
Leslie Zhai

(In reply to Leslie Zhai from comment #4)
> Hi Cristian,

Hello Leslie

[...]

 
> Could you reproduce the issue all the time?

Yes.


Regards,
--
Cristian

ping Leslie :-)

Hi,

See this report:
https://bugs.launchpad.net/cdemu/+bug/1697987

Regards,
--
Cristian

ping

Hi Cristian,

Sorry for my late response!

> See this report:
> https://bugs.launchpad.net/cdemu/+bug/1697987

Yes, I do not have BD medium for testing, and the simulator is not able to reproduce the issue by providing the same environment, please Thomas give me some suggestion, thanks a lot!

Regards,
Leslie Zhai

Hi,

i would need to search for the 8.8.0 ISO, because now 9.1.0 is in the
"current" directory at the Debian download site.
Let's have a look at 9.1.0. It should suffice to get the 450 KB Jigdo file.

   wget http://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/debian-9.1.0-amd64-BD-1.jigdo
   gunzip debian-9.1.0-amd64-BD-1.jigdo | less

reveils as final image size:
   # Image size 22985682944 bytes

That's 11223478 blocks and should well fit into the 11826176 blocks of
a default formatted BD-R.

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

Questions:

- Do we know where in K3B the refusal message comes from ?
  (The original message text might help to find it.)

- What is the exact size of your downloaded ISO ?
  ("22 G" is too coarse, i'd need to know the byte count.)

- What does dvd+rw-mediainfo tell about the BD-R medium ?
  (Again, the info from the K3B screenshot is too coarse.)
  Insert it and load the drive tray. Then run

     dvd+rw-mediainfo /dev/sr0 2>&1 | tee -i >/tmp/bd_mediainfo.txt

  and post the resulting file bd_mediainfo.txt.


Have a nice day :)

Thomas

Hi,

the screenshot message
  https://bugsfiles.kde.org/attachment.cgi?id=106037
does not really look to me as a complaint about lack of medium space.
It rather looks like the medium is not recognized at all.

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

The message probably stems from

  https://cgit.kde.org/k3b.git/tree/libk3b/tools/k3bmedium.cpp#n691

                        return i18n("Please insert an empty medium into drive<p><b>%1</b>", deviceString);

called by

  https://cgit.kde.org/k3b.git/tree/libk3b/tools/k3bmedium.cpp#n647

        toReturn.append(mediaRequestString( requestedMediaTypes, requestedMediaStates, requestedSize, dev));

There are specific messages for lack of capacity, but they do not show up
in the screenshot.

So the output of dvd+rw-mdiainfo with the affected BD-R medium is of
high interest.


Have a nice day :)

Thomas

Hi,

i have to correct a copy+paste error of mine.
It's not line 691
                return i18n("Please insert an empty medium into drive<p><b>%1</b>", deviceString);
but line 728

                return i18n( "Please insert an empty medium of size %1 or larger into drive<p><b>%2</b>",


My theory that the medium was not recognized is dwindling.
STATE_EMPTY means that the medium is blank, not that the tray is empty.
(According to libk3bdevice/k3bdevicetypes.h that would be STATE_NO_MEDIA.)

But the size is told because there is no particular medium type requested,
not because that size was too large for the given medium.

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

Now i ended up at the spot where Leslie put a comment in june.
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n146
  K3b::Device::MediaType K3b::EmptyDiscWaiter::waitForDisc

I understand from a comment above
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n189
      if( !d->waitingDone ) {
that this function is called even if a medium is already detected, and
that it should return immediately in this case.
Obviously it does not return.

It looks like the state
  d->waitingDone
changes inside
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n196
  void K3b::EmptyDiscWaiter::enterLoop()
but currently i do not understand how this loop works and were the state
is changed.

Will try to get insight later today. But this looks like C++ idiom which
an old C programmer has difficulties to grasp.


Have a nice day :)

Thomas

Hi Thomas,

Thanks for your kind suggestion!

> but currently i do not understand how this loop works and were the state is changed.

QEventLoop http://doc.qt.io/qt-5/qeventloop.html

it will emit leaveModality signal when finishWaiting https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n706 then quit the QEventLoop https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n199


Hi Cristian,

> dvd+rw-mediainfo /dev/sr0 2>&1 | tee -i >/tmp/bd_mediainfo.txt

Please try and attach the bd_mediainfo.txt, thanks!

Regards,
Leslie Zhai

Hi,

Leslie Zhai wrote:
> QEventLoop http://doc.qt.io/qt-5/qeventloop.html

This does not help much with understanding under which circumstances
the particular medium waiting loop shall end.

I searched for "waitingDone = true" which i find in
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n710
  K3b::EmptyDiscWaiter::finishWaiting()

This is called in
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n210
  K3b::EmptyDiscWaiter::slotMediumChanged()
which is also called before the loop.
So the beef must be in there.

Most of the finishWaiting() calls are in if-cases which apply to
non-BD-R media only.
Two calls remain. One is unlikely because of this comment
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n641

    // this is for CD drives that are not able to determine the state of a disk

-----------------------------------------------------------------------------
So ours must be in

  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n634

    else if( (d->wantedMediaType & medium.diskInfo().mediaType()) &&
             (d->wantedMediaState & medium.diskInfo().diskState()) &&
             (d->wantedMinMediaSize <= medium.actuallyRemainingSize() ||
              IsOverburnAllowed( d->wantedMinMediaSize, medium.diskInfo().capacity(), medium.actuallyUsedCapacity() )) ) {
        finishWaiting( medium.diskInfo().mediaType() );

One can see how the criteria are set up in waitForDisc():
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n158

    d->wantedMediaState = mediaState;
    d->wantedMediaType = mediaType;
    d->wantedMinMediaSize = minMediaSize;

Currently i fail to see the spot where this is called. So it would be
interesting to see by what values the loop gets programmed.

A print statement at that position would be of help.

In general we have three possible reasons for not accepting the BD-R
in the drive:

- A type is requested which does not match BD-R.
  The text snippet "empty medium of size" indicates that K3B does not
  look for MEDIA_WRITABLE_BD, because then it would say "Blu-ray medium".

- The BD-R is not in the desired state. (This is unlikely because we have
   the statement in the screenshot that it is an empty BD-R and that the
   waiter wants to see an empty medium.)

- The actuallyRemainingSize() is less than the required size.

So we are back at the question how much size is offered by the BD-R.


Have a nice day :)

Thomas

Hi,

@Leslie:
Maybe you can determine the expectations of slotMediumChanged without having
a BD-R medium and drive.

Try by creating a data file of 21.5 GiB size

  dd if=/dev/zero bs=2048 count=11272192 of=test.img

and submitting it to K3B while it uses a CDemu drive with some virtual
blank DVD+R or DVD-R medium.

Print before the big "if" in slotMediumChanged()
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n257
  if ( (d->wantedMediaType & K3b::Device::MEDIA_BD_RE) &&
the requirement settings and medium properties:

  d->wantedMediaType
  d->wantedMediaState
  d->wantedMinMediaSize

  medium.diskInfo().mediaType() 
  medium.diskInfo().diskState()
  medium.actuallyRemainingSize()

The "wanted" values are supposed to be realistic. At least the value
of actuallyRemainingSize() will be insufficient. So best print only
once and use a static variable to prevent a flood of more messages.

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

It would also be helpful to assert that really the if-test in line 634
is reached and performed.
For that you could (very temporarily) insert a case before
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n632
  // we have exactly what was requested (K3b never requests a specific
that prints a message and accepts any medium, state, and size.

    } else if (1) {

        // >>> print message that this line was reached

        finishWaiting( medium.diskInfo().mediaType() );

While above print proposal would be helpful on Cristian's system, too,
this mindless accepter here is not suitable for tests with real media,
although it is supposed to let Critian's intended burn run start.
(Only good if the medium is the right one, inserted, and already recognized
 by the drive.)

Without this accepter, you should look for the message from line 649:
        qDebug() << "------ nothing useful found.";
which would prove that really all tests were made and none matched.


Have a nice day :)

Thomas

> One can see how the criteria are set up in waitForDisc():
> Currently i fail to see the spot where this is called. So it would be
> interesting to see by what values the loop gets programmed.

call waitForDisc https://github.com/KDE/k3b/blob/master/src/k3bemptydiscwaiter.cpp#L747

^
|
|

call K3b::EmptyDiscWaiter::wait https://github.com/KDE/k3b/blob/master/src/k3bjobprogressdialog.cpp#L625

^
|
|

override Device::MediaType waitForMedium https://github.com/KDE/k3b/blob/master/src/k3bjobprogressdialog.h#L65

^
|
|

virtual Device::MediaType waitForMedium https://github.com/KDE/k3b/blob/master/libk3b/core/k3bjob.h#L154

Hi Cristian,

> Try by creating a data file of 21.5 GiB size

Then how to reproduce the issue? https://pbs.twimg.com/media/DHzWyToVYAAwEse.png

Regards,
Leslie Zhai

Hi,

if there is no simple code change which circumvents that size check,
then you will have to prepare the printing of the decision criteria 
for Cristian, so that he can try.

With the data type "Msf" of d->wantedMinMediaSize and
medium.actuallyRemainingSize() i propose to print the .lba() aspect.


Have a nice day :)

Thomas

Created attachment 107535 [details]
bd_mediainfo.txt

Hello Leslie Zhai,

[...]


> Hi Cristian,
> 
> > dvd+rw-mediainfo /dev/sr0 2>&1 | tee -i >/tmp/bd_mediainfo.txt
> 
> Please try and attach the bd_mediainfo.txt, thanks!

Ok

Regards,
--
Cristian

Hi,

the given BD-R medium is not blank but rather seems to have been
used already with growisofs. Only growisofs formats BD-R to state SRM+POW:

  Mounted Media:         41h, BD-R SRM+POW

The first track is completely written:

 READ TRACK INFORMATION[#1]:
  Track State:           partial incremental
  Track Start Address:   0*2KB
  Free Blocks:           0*2KB
  Track Size:            11560096*2KB

The remaining space is about 1 GIB:

 READ TRACK INFORMATION[#2]:
  Track State:           invisible incremental
  Track Start Address:   11560096*2KB
  Next Writable Address: 11560096*2KB
  Free Blocks:           528224*2KB
  Track Size:            528224*2KB

The peculiar formatting causes an optimistic reply about the number of
readable blocks. It includes written and unwritten capacity:

  READ CAPACITY:          12088320*2048=24756879360

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

This medium is indeed not suitable for a burn run of 21.4 GiB.

You need to insert a new one that was never burnt.

dvd+rw-mediinfo should report something like
  ...
  READ DISC INFORMATION:
   Disc status:           blank
   Number of Sessions:    1
   State of Last Session: empty
   "Next" Track:          1
   Number of Tracks:      1
  ...
  READ TRACK INFORMATION[#1]:
   Track State:           invisible incremental
   Track Start Address:   0*2KB
   Next Writable Address: 0*2KB
   Free Blocks:           12219392*2KB
   Track Size:            12219392*2KB
  READ CAPACITY:          0*2048=0

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

If this is the medium that caused this bug report, then there remains
the riddle why
  https://bugsfiles.kde.org/attachment.cgi?id=106037
shows the text
  "Empty BD-R medium"

It should say something like "Appendable BD-R medium".

(And can it be that the english text "size 21,4 GiB" in the image bears
 a german decimal comma ? Pinching eyes ...)


Have a nice day :)

Thomas

Created attachment 107536 [details]
bd_mediainfo.txt (BD R empty)

(In reply to Thomas Schmitt from comment #20)
> Hi,
> 
> the given BD-R medium is not blank but rather seems to have been
> used already with growisofs. Only growisofs formats BD-R to state SRM+POW:


Hello Thomas Schmitt,

BD R empty

Regards,
--
Cristian

Hi,

> BD R empty
> https://bugs.kde.org/attachment.cgi?id=107536

Indeed. Unformatted and unused.

Does this medium produce the messages from
  https://bugsfiles.kde.org/attachment.cgi?id=106037
when you try to burn the Debian ISO onto it ?


Have a nice day :)

Thomas

Created attachment 107544 [details]
Empty BD-R medium - ISO Debian 9.1.0 - k3b 17.8.0

Hello,

caravena@caravena-530U3C-530U4C:/media/mis-doc/ISO/debian$ ls -lisha
total 22G
 1225    0 drwxrwx--- 1 root plugdev  184 ago 27 12:39 .
10828 8,0K drwxrwx--- 1 root plugdev 8,0K ago 27 12:39 ..
 1265  22G -rwxrwx--- 1 root plugdev  22G ago 27 00:01 debian-9.1.0-amd64-BD-1.iso
caravena@caravena-530U3C-530U4C:/media/mis-doc/ISO/debian$ du
22446956	.

Regards,
--
Cristian

Hi,

i am out of ideas, except that Leslie prepares a test version of K3B
by which Cristian can build and test.
It should show the information mentioned in
  https://bugs.kde.org/show_bug.cgi?id=381074#c15

I am not aware how difficult it is to build K3B from git and provide it
with all required libraries. Being on Debian 8 and using fvwm2 as window
manager, i assume to be 1 or 2 lightyears away from that goal.

Have a nice day :)

Thomas

(In reply to Thomas Schmitt from comment #24)

Hello,


> i am out of ideas, except that Leslie prepares a test version of K3B
> by which Cristian can build and test.

I look forward to compiling the trial version and testing it. Just let me know the commit to download ...

Regards,
--
Cristian

(In reply to Cristian Aravena Romero from comment #25)
> (In reply to Thomas Schmitt from comment #24)
> 
> Hello,
> 
> 
> > i am out of ideas, except that Leslie prepares a test version of K3B
> > by which Cristian can build and test.
> 
> I look forward to compiling the trial version and testing it. Just let me
> know the commit to download ...

http://www.leetcode.cn/2016/08/k3b.html#depend

please follow the Dependence and Build.

> 
> Regards,
> --
> Cristian

Hello Leslie Zhai,

git clone git://anongit.kde.org/k3b (?)

Regards,
--
Cristian

(In reply to Leslie Zhai from comment #26)
> (In reply to Cristian Aravena Romero from comment #25)
> > (In reply to Thomas Schmitt from comment #24)

[...]

 
> > > i am out of ideas, except that Leslie prepares a test version of K3B
> > > by which Cristian can build and test.
> > 
> > I look forward to compiling the trial version and testing it. Just let me
> > know the commit to download ...
> 
> http://www.leetcode.cn/2016/08/k3b.html#depend
> 
> please follow the Dependence and Build.


Hello,

https://askubuntu.com/questions/212027/getting-build-dependencies-and-source-by-default

#apt-get build-dep k3b


Regards,
--
Cristian

Hello,

Report en Launchpad.net
https://bugs.launchpad.net/k3b/+bug/1713485

Regards,
--
Cristian

Hi,

are the proposed print commands already in place ?
If so, how would they look ?

Are they supposed to show up in
  https://bugs.launchpad.net/k3b/+bug/1713485/+attachment/4940133/+files/JournalErrors.txt
?

Have a nice day :)

Thomas

Hello Leslie Zhai,

git clone git://anongit.kde.org/k3b (?)

Regards,
--
Cristian

Yes!

> Hello Leslie Zhai,
> 
> git clone git://anongit.kde.org/k3b (?)
> 
> Regards,
> --
> Cristian

Created attachment 107640 [details]
k3b v17.11.90 (git)

Hello,

At night I try, already is the version of compiled k3b

Regards,
--
Cristian

Hi,

i just did a git pull in my clone from git://anongit.kde.org/k3b.git
and cannot see any related commit by git log.
Can you point me to the changeset which puts the print statements into
the code ?
(My proposals are in
  https://bugs.kde.org/show_bug.cgi?id=381074#c15
)

Have a nice day :)

Thomas

Please use GDB to set breakpoint and print

(In reply to Leslie Zhai from comment #35)
> Please use GDB to set breakpoint and print

Hello Leslie

?

Regards,
--
Cristian

(In reply to Thomas Schmitt from comment #34)
> Hi,
> 
> i just did a git pull in my clone from git://anongit.kde.org/k3b.git
> and cannot see any related commit by git log.
> Can you point me to the changeset which puts the print statements into
> the code ?
> (My proposals are in
>   https://bugs.kde.org/show_bug.cgi?id=381074#c15
> )


Hello Thomas,

How do I test?
git ...?

Regards,
-
Cristian

Hi,

@Cristian:
Leslie asks you to run K3B under control of the program gdb, to set a
"breakpoint" at line 257 of k3bemptydiscwaiter.cpp, and to let gdb
print the desired variable content when it stops execution at that
breakpoint.
The desired info is listed in
  https://bugs.kde.org/show_bug.cgi?id=381074#c15
after my naive proposal to Leslie that he could try to reach the
interesting location in the K3B code by help of CDEmu.

@Leslie:
We should concentrate on exploiting Cristian's willingness to build
and run K3B, not try to give him a quick course in debugging.

Can you make a git branch for Cristian and make a code change which prints
the desired info in a user-visible way ?
(Then post the git command line which fetches it. At least for me that
would be necessary.)

Have a nice day :)

Thomas

Hi,

just to summarize the riddle we are trying to solve:

K3B reports to see an empty BD-R medium but in the same window demands 
to get fed by an empty medium of at least 21.4 GiB.
An empty (in SCSI/MMC terms: "blank") BD-R should fulfill this demand.
dvd+rw-mediainfo confirmed before the try that the medium is blank,
offers 22.5 GiB in its default formatting size, or 23.3 GiB unformatted.

So why doesn't K3B accept it ?

Have a nice day :)

Thomas

I will add qDebug to print them next Monday, I am using my phone to reply :)

Git commit 837eeb482a13af6a27616a4412f5cd8d92b7feaf by Leslie Zhai.
Committed on 04/09/2017 at 02:11.
Pushed by lesliezhai into branch 'master'.

Prints the desired info in a user-visible way.

Test plan:
Cristian Aravena Romero run k3b in his enviorment to reproduce the issue,
then print the MediaType, MediaState and MinMediaSize.

M  +4    -0    src/k3bemptydiscwaiter.cpp

https://commits.kde.org/k3b/837eeb482a13af6a27616a4412f5cd8d92b7feaf

Hi,

we not only need to know the wanted properties but also the properties
which K3B sees as present at that point in the code.
To my understanding that would be:

  medium.diskInfo().mediaType()
  medium.diskInfo().diskState()
  medium.actuallyRemainingSize()

Further the "Msf" size class has multiple aspects. For comparison it uses
the aspect Msf.lba(), afaics. ("Minute,second,frame" is an old CD sector
address form. DVD and BD only get addressed by Logical Block Address.)

So i would print

  medium.actuallyRemainingSize().lba()
  d->wantedMinMediaSize.lba()


Have a nice day :)

Thomas

(In reply to Leslie Zhai from comment #41)
> Git commit 837eeb482a13af6a27616a4412f5cd8d92b7feaf by Leslie Zhai.
> Committed on 04/09/2017 at 02:11.
> Pushed by lesliezhai into branch 'master'.
> 
> Prints the desired info in a user-visible way.
> 
> Test plan:
> Cristian Aravena Romero run k3b in his enviorment to reproduce the issue,
> then print the MediaType, MediaState and MinMediaSize.
> 
> M  +4    -0    src/k3bemptydiscwaiter.cpp
> 
> https://commits.kde.org/k3b/837eeb482a13af6a27616a4412f5cd8d92b7feaf


Hello,

How do I download that version?
$ git ...

Regards,
-
Cristian

Hi,

the changeset is labeled "master". So i assume

  git clone git://anongit.kde.org/k3b

or in a cloned directory of git://anongit.kde.org/k3b

  git pull

Then build and run with a blank BD-R (check by dvd+rw-mediainfo if in doubt).
After seeing the window which demands BD-R, look in the log whether you
can see a message that begins by "DEBUG:".

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

@Leslie:
A more significant constant text like "Bug 381074:" would help to recognize
the texts from your change.

Where exactly should Cristian look for those texts ?

Have a nice day :)

Thomas

(In reply to Thomas Schmitt from comment #44)

[...]


> A more significant constant text like "Bug 381074:" would help to recognize
> the texts from your change.

+#ifdef K3B_DEBUG
+    qDebug() << "Bug 381074:" << __PRETTY_FUNCTION__ << d->wantedMediaType
+             << d->wantedMediaState << d->wantedMinMediaSize;
+#endif

Regards,
--
Cristian

Hello,

caravena@caravena-530U3C-530U4C:~/Programas/k3b/k3b$ gedit src/k3bemptydiscwaiter.cpp
caravena@caravena-530U3C-530U4C:~/Programas/k3b/k3b$ git commit -m "https://bugs.kde.org/show_bug.cgi?id=381074" -a
[master e241f5492] https://bugs.kde.org/show_bug.cgi?id=381074
 1 file changed, 1 insertion(+), 1 deletion(-)

caravena@caravena-530U3C-530U4C:~/Programas/k3b/k3b$ git push https://github.com/KDE/k3b
Username for 'https://github.com': caravena
Password for 'https://caravena@github.com': 
remote: Invalid username or password.

???
How do I upload my changes?
???

Regards,
--
Cristian

Hello,

https://github.com/KDE/k3b/compare/master...caravena:patch-1

Regards,
--
Cristian

Hi,

if you feel adventurous enough: I propose something like

    qDebug() << "Bug 381074: wanted: "
             << __PRETTY_FUNCTION__ << d->wantedMediaType
             << d->wantedMediaState << d->wantedMinMediaSize.lba();

    qDebug() << "Bug 381074: found: "
             << __PRETTY_FUNCTION__ << medium.diskInfo().mediaType()
             << medium.diskInfo().diskState()
             << medium.actuallyRemainingSize().lba();

I now understand that __PRETTY_FUNCTION__ is supposed to print the name
of the function the qDebug() statement is in.
So the message text is not as hard to find, as i first thought.
The function name should be "slotMediumChanged()".

Have a nice day :)

Thomas

Hi,

there is no need to upload. Just change the code, build K3B, and test what 
it reports. If you find the messages in the log, then show them together with
the code piece by which you printed it.

Have a nice day :)

Thomas

(In reply to Thomas Schmitt from comment #49)

> If you find the messages in the log, then show them together with
> the code piece by which you printed it.

Hello,

What log?

Regards,
--
Cristian

Created attachment 107691 [details]
Editing the source code

Hello,

Are the changes correct?

Regards,
--
Cristian

Hi,

> What log?

I can only guess where qDebug() messages show up.
The web talks of "application output". An example on
  http://www.qtcentre.org/threads/19534-redirect-qDebug%28%29-to-file
indicates that it is normal "standard output"i, i.e. the start terminal.

So try in a shell terminal window

  k3b | tee -i /tmp/k3b_log_file

and after the run look into file /tmp/k3b_log_file .


> Are the changes correct?

They are half of what we need: The "found" part.
You also need to print the "wanted" info. (Something between them does
not match. I just have no idea yet what it could be. Need to see.)

So add also

    qDebug() << "Bug 381074: wanted: "
             << __PRETTY_FUNCTION__ << d->wantedMediaType
             << d->wantedMediaState << d->wantedMinMediaSize.lba();

directly before or after the printing of "found".

Have a nice day :)

Thomas

Created attachment 107692 [details]
/home/caravena/Programas/k3b/k3b/src/k3bemptydiscwaiter.cpp:271:2:

Hello,

Information when compiling applied patches:

[ 94%] Building CXX object tests/CMakeFiles/k3bexternalbinmanagertest.dir/__/src/k3bemptydiscwaiter.cpp.o
/home/caravena/Programas/k3b/k3b/src/k3bemptydiscwaiter.cpp:271:2: warning: #warning FIXME: We need to preformat empty BD-RE just like we do with empty DVD+RW [-Wcpp]
 #warning FIXME: We need to preformat empty BD-RE just like we do with empty DVD+RW
  ^~~~~~~

Regards,
--
Cristian

Hi,

those warnings are kind of a reminder of a developer who did not
finish his work yet. If no error messages appear, then k3b is probably
ready to run.

But don't ask me where the executable program file is now. I am really
balancing at the edge of my knowledge here.
Leslie ! Help !


Have a nice day :)

Thomas

In reply to Thomas Schmitt from comment #52)

[...]

 
> > What log?
> 
> I can only guess where qDebug() messages show up.
> The web talks of "application output". An example on
>   http://www.qtcentre.org/threads/19534-redirect-qDebug%28%29-to-file
> indicates that it is normal "standard output"i, i.e. the start terminal.
> 
> So try in a shell terminal window
> 
>   k3b | tee -i /tmp/k3b_log_file
> 
> and after the run look into file /tmp/k3b_log_file .

Ok!


> > Are the changes correct?
> 
> They are half of what we need: The "found" part.
> You also need to print the "wanted" info. (Something between them does
> not match. I just have no idea yet what it could be. Need to see.)
> 
> So add also
> 
>     qDebug() << "Bug 381074: wanted: "
>              << __PRETTY_FUNCTION__ << d->wantedMediaType
>              << d->wantedMediaState << d->wantedMinMediaSize.lba();
> 
> directly before or after the printing of "found".

ok!


-------------------This right?----------------------------------
#ifdef K3B_DEBUG
    qDebug() << "Bug 381074: found: "
             << __PRETTY_FUNCTION__ << medium.diskInfo().mediaType()
             << medium.diskInfo().diskState()
             << medium.actuallyRemainingSize().lba();

    qDebug() << "Bug 381074: wanted: "
             << __PRETTY_FUNCTION__ << d->wantedMediaType
             << d->wantedMediaState << d->wantedMinMediaSize.lba();
#endif
-----------------------------------------------------------------


Regards,
--
Cristian

Hello,

caravena@caravena-530U3C-530U4C:~$ k3b | tee -i /tmp/k3b_log_file.txt
QFileInfo::absolutePath: Constructed with empty filename
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 2816, result = 0
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kdeinit5: opened connection to :0
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'
org.kde.kcoreaddons: Error loading plugin "k3bffmpegdecoder" "No se ha encontrado la biblioteca compartida." 
Plugin search paths are ("/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/local/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
QObject::connect: No such signal KLineEdit::lostFocus()
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
QLayout: Attempting to add QLayout "" to QFrame "", which already has a layout
Couldn't start kuiserver from org.kde.kuiserver.service: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kuiserver was not provided by any .service files")
QLayout: Attempting to add QLayout "" to K3b::EmptyDiscWaiter "", which already has a layout
QLayout: Attempting to add QLayout "" to K3b::EmptyDiscWaiter "", which already has a layout
org.kde.knotifications: Audio notification requested, but sound file from notifyrc file was not found, aborting audio notification
org.kde.knotifications: Audio notification requested, but sound file from notifyrc file was not found, aborting audio notification


* k3b_log_file.txt is empty

Regards,
--
Cristian

Hi,

> * k3b_log_file.txt is empty

So those messages came out of stderr, not stdout.

It may be that macro K3B_DEBUG is not defined and thus the qDebug()
statements did not get compiled. Try what happens if you remove the line
  #ifdef K3B_DEBUG
before the qDebug() statements and the line
  #endif
after them.         
Maybe we get to see new interesting compiler messages. X-|

There may be the need for enabling qDebug at run time.
But i find few in the web. Maybe
  https://bugzilla.redhat.com/show_bug.cgi?id=1227295#c32

(When is it morning where Leslie lives ? I'm overdue for bed.)


Have a nice day :)

Thomas

Git commit 4cc3da32a6dac6405a67f7791f49ef38149dadd6 by Leslie Zhai.
Committed on 05/09/2017 at 02:28.
Pushed by lesliezhai into branch 'master'.

also print the properties which sees as present.

removed K3B_DEBUG macro, this macro will be enabled only with
 -DK3B_DEBUG=ON cmake build option.

When is it morning where Leslie lives? I'm overdue for bed too :)

M  +8    -4    src/k3bemptydiscwaiter.cpp

https://commits.kde.org/k3b/4cc3da32a6dac6405a67f7791f49ef38149dadd6

Hello,

caravena@caravena-530U3C-530U4C:~/Programas/k3b$ k3b
QFileInfo::absolutePath: Constructed with empty filename
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 10510, result = 0
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kdeinit5: opened connection to :0
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'
kf5.kservice.sycoca: Parse error in  "/home/caravena/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu" , line  1 , col  1 :  "unexpected end of file"
The desktop entry file "/usr/share/applications/org.gnome.ChromeGnomeShell.desktop" has Type= "Application" but no Exec line
kf5.kservice.sycoca: Invalid Service :  "/usr/share/applications/org.gnome.ChromeGnomeShell.desktop"
org.kde.kcoreaddons: Error loading plugin "k3bffmpegdecoder" "No se ha encontrado la biblioteca compartida." 
Plugin search paths are ("/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/local/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
QObject::connect: No such signal KLineEdit::lostFocus()
kf5.kio.core: Invalid URL: QUrl("")
QLayout: Attempting to add QLayout "" to QFrame "", which already has a layout
Couldn't start kuiserver from org.kde.kuiserver.service: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kuiserver was not provided by any .service files")
QLayout: Attempting to add QLayout "" to K3b::EmptyDiscWaiter "", which already has a layout
QLayout: Attempting to add QLayout "" to K3b::EmptyDiscWaiter "", which already has a layout
org.kde.knotifications: Audio notification requested, but sound file from notifyrc file was not found, aborting audio notification
umount: /dev/sr0: not mounted.
org.kde.knotifications: Audio notification requested, but sound file from notifyrc file was not found, aborting audio notification
QObject::connect: No such signal KLineEdit::lostFocus()
QLayout: Attempting to add QLayout "" to QFrame "", which already has a layout
QLayout: Attempting to add QLayout "" to K3b::EmptyDiscWaiter "", which already has a layout
QLayout: Attempting to add QLayout "" to K3b::EmptyDiscWaiter "", which already has a layout
org.kde.knotifications: Audio notification requested, but sound file from notifyrc file was not found, aborting audio notification
org.kde.knotifications: Audio notification requested, but sound file from notifyrc file was not found, aborting audio notification
QObject::connect: No such signal KLineEdit::lostFocus()
QLayout: Attempting to add QLayout "" to QFrame "", which already has a layout
QLayout: Attempting to add QLayout "" to K3b::EmptyDiscWaiter "", which already has a layout
QLayout: Attempting to add QLayout "" to K3b::EmptyDiscWaiter "", which already has a layout
org.kde.knotifications: Audio notification requested, but sound file from notifyrc file was not found, aborting audio notification

Regards,
--
Cristian

Created attachment 107704 [details]
$QT_LOGGING_RULES="*.debug=true" k3b / k3b_log.txt

Hello Thomas and Leslie,

Bug 381074: wanted:  void K3b::EmptyDiscWaiter::slotMediumChanged(K3b::Device::Device*) "DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+RW Dual Layer, DVD+R Dual Layer" "empty medium" 11223478
Bug 381074: found:  void K3b::EmptyDiscWaiter::slotMediumChanged(K3b::Device::Device*) "BD-R Sequential (SRM)" "empty medium" 12219392

Regards,
--
Cristian

Hi,

this qDebug and its "<<" methods are a little debugger on its own.
I would have expected some hex number which we'd need to decipher to
a list of media types. But this is comfortable.

Pinching my eyes:

> Bug 381074: wanted: [...]
> "DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential,
> DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite,
> DVD-RW Sequential, DVD+RW, DVD+R, DVD+RW Dual Layer, DVD+R Dual Layer"

There is neither BD-RE nor BD-R in the list, is it ?

> Bug 381074: found:
> "BD-R Sequential (SRM)" "empty medium" 12219392

Correctly recognized and obviously blank with still full capacity.
If only the "wanted" list would contain it.

So the next question is why the EmptyDiscWaiter object was not properly
programmed to accept BD media before it called slotMediumChanged().

I will dig. Everybody else is invited to dig too and to insert prints
where this programming is done. (I dimmly remember to have visited that
code piece. Must re-read this whole thread now.)

Have a nice day :)

Thomas

Hi,

do we get through this piece of code ?

https://cgit.kde.org/k3b.git/tree/libk3b/projects/datacd/k3bdatajob.cpp#n699
  bool K3b::DataJob::waitForBurnMedium()
  {
     // start with all media types supported by the writer
      Device::MediaTypes m  = d->doc->supportedMediaTypes() & d->doc->burner()->writeCapabilities();


Please put qDebug() statements in there

  qDebug() << "Bug 381074: supportedMediaTypes: "
           << d->doc->supportedMediaTypes();

  qDebug() << "Bug 381074: writeCapabilities: "
           << d->doc->burner()->writeCapabilities();

------------------------------------------------------------------
Where i got lost so far:

The detected writeCapabilities() are probably reported in the newest
attachment of cristian:
  https://bugsfiles.kde.org/attachment.cgi?id=107704
as
  Write Cap:       "DVD-R, DVD-R Sequential, DVD-R Dual Layer,
      DVD-R Dual Layer Sequential, DVD-RW, DVD-RW Restricted Overwrite,
      DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-R, CD-RW, BD-R,
      BD-R Sequential (SRM), BD-R Sequential Pseudo Overwrite (SRM+POW),
      BD-R Random (RRM), BD-RE"

So for d->doc->supportedMediaTypes().
Is it this one ?
  https://cgit.kde.org/k3b.git/tree/libk3b/projects/datacd/k3bdatadoc.cpp#n1516
  K3b::Device::MediaTypes K3b::DataDoc::supportedMediaTypes() const
  {
      return Device::MEDIA_WRITABLE;
  }

I find MEDIA_WRITABLE in
  https://cgit.kde.org/k3b.git/tree/libk3bdevice/k3bdevicetypes.h#n266

            MEDIA_WRITABLE_BD = MEDIA_REWRITABLE_BD |
            MEDIA_BD_R |
            MEDIA_BD_R_SRM |
            MEDIA_BD_R_SRM_POW |
            MEDIA_BD_R_RRM,
            ...
            MEDIA_WRITABLE = MEDIA_WRITABLE_CD |
            MEDIA_WRITABLE_DVD |
            MEDIA_WRITABLE_BD,

So the absence of BD media types in "wanted" stays a riddle.

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

Have a nice day :)

Thomas

Hi,

i found a suspect:

  https://cgit.kde.org/k3b.git/tree/libk3b/jobs/k3biso9660imagewritingjob.cpp#n232
  void K3b::Iso9660ImageWritingJob::startWriting()
  {
      ...
      else {
          mt = K3b::Device::MEDIA_WRITABLE_DVD;
      }

And no  MEDIA_WRITABLE_BD  !

This would mean it happens only with image writing but not with
Data Composition. A good explanation why K3B can claim BD capability since
years but does not work for Cristian's use case.

The fog rises up.

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

Coarse test proposal:

Add (actually "or") unconditionally K3b::Device::MEDIA_WRITABLE_BD to mt.

    else {
        mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD;
    }

Does this change appease that nasty "give me a 21.4 GiB medium" window ?

If this works, then Leslie and i have to riddle whether this is the
final solution and thus what this piece of code does. I have some idea
but that would have to be verified.

Have a nice day :)

Thomas

Hi,

if the change in line 264 does not help, try the same in line 252 ff.:

        else if( d->isDvdImage )
            mt = K3b::Device::MEDIA_WRITABLE_DVD |
                 K3b::Device::MEDIA_WRITABLE_BD;

Have a nice day :)

Thomas

Hello,

I get lost ... Please tell me to download the commit

Regards,
--
Cristian

Hi,

> I get lost ... Please tell me to download the commit

Excuse my enthusiasm. :))
And forget about the qDebug() proposal of Comment 62 for now.

Edit file

  libk3b/jobs/k3biso9660imagewritingjob.cpp

There are two lines (253 and 264) which each say

  mt = K3b::Device::MEDIA_WRITABLE_DVD;

Those match what your qDebug() reported as "wanted": Any kind of DVD.
We want to accept any kind of BD, too.

So change both lines to

  mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD;

build K3B and try whether it now accepts your BD-R.
(And also lists "BD-R Sequential (SRM)" among the "wanted" media types.)

Have a nice day :)

Thomas

Git commit 329c969be1dbc3455d65925bcad32f4df3a5b428 by Leslie Zhai.
Committed on 06/09/2017 at 01:54.
Pushed by lesliezhai into branch 'master'.

Add BD-RE MediaType as Thomas's idea.

M  +4    -2    libk3b/jobs/k3biso9660imagewritingjob.cpp
M  +6    -0    libk3b/projects/datacd/k3bdatajob.cpp

https://commits.kde.org/k3b/329c969be1dbc3455d65925bcad32f4df3a5b428

Created attachment 107723 [details]
k3b.txt

Dear Friends,

I am happy :-) We have solved this "Error". Now you can record the .iso image thanks to the help of Lezlie and Thomas. I repeat, I'm very happy :-)

Regards and thank you very much,
-
Cristian



* Thanks to Chiefs Ernesto Miranda and Dagoberto Pacheco :-)

Created attachment 107724 [details]
Image of k3b recording the .iso of Debian 9.1.0 in the Blu Ray

Hi,

Ja ! I knew it when i saw it ... now in hindsight ... :))

I had gnawed on the code for the wrong task "Data" rather than "Image".
This little shell beauty in my K3B git clone finally gave me the nudge.
It looks for MEDIA_WRITABLE_DVD at the end of a C/C++ statment:

  $ fgrep -r MEDIA_WRITABLE_DVD';' .
  ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:    return K3b::Device::MEDIA_WRITABLE_DVD;
  ./libk3b/jobs/k3biso9660imagewritingjob.cpp:            mt = K3b::Device::MEDIA_WRITABLE_DVD;
  ./libk3b/jobs/k3biso9660imagewritingjob.cpp:        mt = K3b::Device::MEDIA_WRITABLE_DVD;


> I am happy :-) We have solved this "Error".

This error really does not need to be put in quotes. Be proud of it.

You are the first who tried burning a BD sized image file since K3B learned
to handle BD. That's a fat bug catch.
Congrats for being the user who had the endurance to complete this thread.

------------------------------------------------------------------
@Leslie:

Now the qDebug() statements about "Bug 381704" need to be removed.

I pondered in advance about the general appropriateness of the two lines

  mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD;

They are good. DVD and BD are not really different when it comes to MMC specs
and to backend programs which handle both media families. The true divide
is between pre-DVD (i.e. CD ) and post-DVD (i.e. DVD and BD).

So these two changed lines are the final fix for this bug.
Fix commit title could be something like
  "The task of burning an image file to media was not yet prepared
   to accept BD media."
Maybe there is a more official K3B term for "task of burning an image file
to media".

Congrats to you, too. I hope your health is getting better.

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

Nevertheless ... the now 10 comment items in startWriting() of
libk3b/jobs/k3biso9660imagewritingjob.cpp are completely out of sync with
the current code underneath them.
This needs mending.
Shall i open a new bug for this ?

Further about this fgrep match:
    ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:    return K3b::Device::MEDIA_WRITABLE_DVD;
Does K3B burn Blu-ray video ? Is there need for inspection ?

Have a nice day :)

Thomas

> Now the qDebug() statements about "Bug 381704" need to be removed.

Oops. Number flip. qDebug() statements about "Bug 381074", of course.

Hello,


(In reply to Thomas Schmitt from comment #70)


[...]

>   $ fgrep -r MEDIA_WRITABLE_DVD';' .
>   ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:    return
> K3b::Device::MEDIA_WRITABLE_DVD;
>   ./libk3b/jobs/k3biso9660imagewritingjob.cpp:            mt =
> K3b::Device::MEDIA_WRITABLE_DVD;
>   ./libk3b/jobs/k3biso9660imagewritingjob.cpp:        mt =
> K3b::Device::MEDIA_WRITABLE_DVD;

caravena@caravena-530U3C-530U4C:~/Projects/k3b/k3b$ fgrep -r MEDIA_WRITABLE_DVD';' .
./libk3b/projects/videodvd/k3bvideodvddoc.cpp:    return K3b::Device::MEDIA_WRITABLE_DVD;
caravena@caravena-530U3C-530U4C:~/Projects/k3b/k3b$   ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:    return K3b::Device::MEDIA_WRITABLE_DVD;
bash: ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:: No existe el archivo o el directorio
caravena@caravena-530U3C-530U4C:~/Projects/k3b/k3b$   ./libk3b/jobs/k3biso9660imagewritingjob.cpp:            mt = K3b::Device::MEDIA_WRITABLE_DVD;
bash: ./libk3b/jobs/k3biso9660imagewritingjob.cpp:: No existe el archivo o el directorio
caravena@caravena-530U3C-530U4C:~/Projects/k3b/k3b$   ./libk3b/jobs/k3biso9660imagewritingjob.cpp:        mt = K3b::Device::MEDIA_WRITABLE_DVD;
bash: ./libk3b/jobs/k3biso9660imagewritingjob.cpp:: No existe el archivo o el directorio

Regards,
--
Cristian

Git commit a359173975e574c4cae62214f7de28648d14167c by Leslie Zhai.
Committed on 07/09/2017 at 01:56.
Pushed by lesliezhai into branch 'master'.

Teach K3B learned to handle BD.

A patch by Thomas Schmitt!

Tested by Cristian Aravena Romero!

also took CT consultation for my brain, but the result is not too bad :)

M  +0    -2    libk3b/jobs/k3biso9660imagewritingjob.cpp
M  +0    -6    libk3b/projects/datacd/k3bdatajob.cpp
M  +1    -1    libk3b/projects/videodvd/k3bvideodvddoc.cpp
M  +0    -9    src/k3bemptydiscwaiter.cpp

https://commits.kde.org/k3b/a359173975e574c4cae62214f7de28648d14167c

(In reply to Cristian Aravena Romero from comment #72)

[...]



> (In reply to Thomas Schmitt from comment #70)
> 
> 
> [...]
> 
> >   $ fgrep -r MEDIA_WRITABLE_DVD';' .
> >   ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:    return
> > K3b::Device::MEDIA_WRITABLE_DVD;
> >   ./libk3b/jobs/k3biso9660imagewritingjob.cpp:            mt =
> > K3b::Device::MEDIA_WRITABLE_DVD;
> >   ./libk3b/jobs/k3biso9660imagewritingjob.cpp:        mt =
> > K3b::Device::MEDIA_WRITABLE_DVD;
> 
> caravena@caravena-530U3C-530U4C:~/Projects/k3b/k3b$ fgrep -r
> MEDIA_WRITABLE_DVD';' .
> ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:    return
> K3b::Device::MEDIA_WRITABLE_DVD;
> caravena@caravena-530U3C-530U4C:~/Projects/k3b/k3b$  
> ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:    return
> K3b::Device::MEDIA_WRITABLE_DVD;
> bash: ./libk3b/projects/videodvd/k3bvideodvddoc.cpp:: No existe el archivo o
> el directorio
> caravena@caravena-530U3C-530U4C:~/Projects/k3b/k3b$  
> ./libk3b/jobs/k3biso9660imagewritingjob.cpp:            mt =
> K3b::Device::MEDIA_WRITABLE_DVD;
> bash: ./libk3b/jobs/k3biso9660imagewritingjob.cpp:: No existe el archivo o
> el directorio
> caravena@caravena-530U3C-530U4C:~/Projects/k3b/k3b$  
> ./libk3b/jobs/k3biso9660imagewritingjob.cpp:        mt =
> K3b::Device::MEDIA_WRITABLE_DVD;
> bash: ./libk3b/jobs/k3biso9660imagewritingjob.cpp:: No existe el archivo o
> el directorio

Hello,

Help...

Regards,
--
Cristian

Hi,

> Help...

I am riddling what we see with your fgrep run.

Did you copy+paste my fgrep line together with my three output lines ?

Somehow the shell "bash" tried to execute the lines which were found
by my local fgrep. Your local fgrep found only one, probably because
Leslie's change is already in your local K3B git copy.

bash complains about non-existence of the files instead of complaining
about lack of x-permission. This is because my fgrep output lines have
the filenames with trailing ':'. They only exist without that ':'.

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

Whatever, this is not related to K3B's functionality.
Actually i did not expect that you execute that fgrep yourself. I was
just showing the query by which i found the decisive spot in the code.

Important to K3B would be the questions:

- Did the burn run with the Debian ISO succeed ?
  (Your image
    https://bugsfiles.kde.org/attachment.cgi?id=107724
  shows it at 68 percent.)

- Did you already verify the result as proposed by Debian CD FAQ ?
    https://www.debian.org/CD/faq/#verify
  I translate it to these shell commands:

    /sbin/isosize -x debian-9.1.0-amd64-BD-1.iso

  which is supposed to say:  sector count: 11223478, sector size: 2048
  and

    dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum

  which is supposed to say: 81761e602af6d0e0ffde2d102c706c220e9ff0d31a612ea9ae1db1688c24cdf2a0bf45f02f738dc96651a5a64ae22d60527fe15549a195ab692b66bd669ea1d5 -
  according to
    https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/SHA512SUMS

  If the SHA-512 sum is not 8176...a1d5, then compute the SHA-512 of the ISO
  by

    sha512sum debian-9.1.0-amd64-BD-1.iso

  to verify that the .iso image indeed yields the announced 8176...a1d5

If both answers are "yes", then the next quesition would be whether it
boots on your machine. If "no" then it would not be K3B's fault, but i
myself would be the one to inspect the boot process until the first Debian
logo appears.

Have a nice day :)

Thomas

Hi,

i forgot to mention that

  dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum

will last about 1200 seconds at average 4x read speed and probably make
some noise when it reaches 6x or 8x speed near the end.

Have a nice day :)

Thomas

Hi,

forget my first question whether the burn run ended successfully.

I just found
  https://bugsfiles.kde.org/attachment.cgi?id=107723
which looks very good. Effective speed around 2x with Defect Management
enabled indicates a good relation between drive and medium

So there only remains the question whether the BD-R yields the
same blocks as written (plus some trailing garbage which we keep
dd from reading by the "count=" option).
This will be answered by the run of
  dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum

Have a nice day :)

Thomas

Hello,


(In reply to Thomas Schmitt from comment #75)

[...]
 

> Important to K3B would be the questions:
> 
> - Did the burn run with the Debian ISO succeed ?
>   (Your image
>     https://bugsfiles.kde.org/attachment.cgi?id=107724
>   shows it at 68 percent.)

Yes!: https://bugs.kde.org/attachment.cgi?id=107723

 
> - Did you already verify the result as proposed by Debian CD FAQ ?
>     https://www.debian.org/CD/faq/#verify
>   I translate it to these shell commands:
> 
>     /sbin/isosize -x debian-9.1.0-amd64-BD-1.iso

caravena@caravena-530U3C-530U4C:/media/mis-doc/ISO/debian$ LANGUAGE=C isosize -x debian-9.1.0-amd64-BD-1.iso 
sector count: 11223478, sector size: 2048


>   which is supposed to say:  sector count: 11223478, sector size: 2048
>   and
> 
>     dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum

caravena@caravena-530U3C-530U4C:/media/mis-doc/ISO/debian$ LANGUAGE=C dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum
11223478+0 records in
11223478+0 records out
22985682944 bytes (23 GB, 21 GiB) copied, 1217,61 s, 18,9 MB/s
81761e602af6d0e0ffde2d102c706c220e9ff0d31a612ea9ae1db1688c24cdf2a0bf45f02f738dc96651a5a64ae22d60527fe15549a195ab692b66bd669ea1d5  -


>   which is supposed to say:
> 81761e602af6d0e0ffde2d102c706c220e9ff0d31a612ea9ae1db1688c24cdf2a0bf45f02f738
> dc96651a5a64ae22d60527fe15549a195ab692b66bd669ea1d5 -
>   according to
>     https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/SHA512SUMS
> 
>   If the SHA-512 sum is not 8176...a1d5, then compute the SHA-512 of the ISO
>   by
> 
>     sha512sum debian-9.1.0-amd64-BD-1.iso
> 
>   to verify that the .iso image indeed yields the announced 8176...a1d5
> 
> If both answers are "yes", then the next quesition would be whether it
> boots on your machine. If "no" then it would not be K3B's fault, but i
> myself would be the one to inspect the boot process until the first Debian
> logo appears.

Hi,

the outcome of the sha512sum run indicates full success as far as K3B
is concerned.

This bug is indeed completely done.

Have a nice day :)

Thomas

Created attachment 107733 [details]
Running Debian 9.1.0

(In reply to Thomas Schmitt from comment #75)

[...]

 
> If both answers are "yes", then the next quesition would be whether it
> boots on your machine. If "no" then it would not be K3B's fault, but i
> myself would be the one to inspect the boot process until the first Debian
> logo appears.

I am attaching image .jpg running Debian 9.1.0

Regards,
--
Cristian

Hello,

Thomas asked me to add this "K3b::Device::MEDIA_WRITABLE_BD;" in two places of the same file. And now in the official patch only a line is edited

https://cgit.kde.org/k3b.git/commit/?id=a359173975e574c4cae62214f7de28648d14167c

Regards,
-
Cristian

Hi,

> now in the official patch only a line is edited
> https://cgit.kde.org/k3b.git/commit/?id=a359173975e574c4cae62214f7de28648d14167c

This is not the fix for Bug 381074 but rather the cleanup after the fix
plus a courageous move to allow BD media for "VideoDvdDoc" which talks
of the typical filesystem structures of Video DVD. E.g. directory "VIDEO_TS".

The decisive bug fix changeset is
  https://cgit.kde.org/k3b.git/commit/?id=329c969be1dbc3455d65925bcad32f4df3a5b428
where Leslie and i would still need to discuss the outdated comments.

We'd both need to practice with git in order to keep the experiments
away from the final fix.

----------------------------------------------------------------------
As for the courage in above changeset:

The format requirements for Blu-ray Video differ from DVD video.
With much caution read and compare
  https://en.wikipedia.org/wiki/Blu-ray#Data_format_standards
  https://en.wikipedia.org/wiki/DVD-Video
and keep in mind that these requirements only apply to consumer electronics
(aka "living room") video players.
With general data storage or with video files which your computer can play
from hard disk, there is no need to use UDF as filesystem or to have a
"BDMV" directory.

I know of no free tool on GNU/Linux which would produce the prescribed
format for Blu-ray video. If K3B and its helper programs can do, i'd like
to learn a URL to which i can send people who ask for Blu-ray video.

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

@Leslie:

Maybe an amateurish idea, but how about you revoke all three new
"| K3b::Device::MEDIA_WRITABLE_BD". I.e. the two fixes and the courageous one.
Also remove comment "10" above the two bug fix lines. It is outdated now.

Then commit the two MEDIA_WRITABLE_BD lines in 
  https://cgit.kde.org/k3b.git/commit/?id=329c969be1dbc3455d65925bcad32f4df3a5b428
as official fix of Bug 381074. Leave out comment "10" and the qDebug(),
of course.

If you feel still ok with the MEDIA_WRITABLE_BD in k3bvideodvddoc.cpp, then
better commit it separately.

Have a nice day :)

Thomas

*** Bug 387384 has been marked as a duplicate of this bug. ***

*** Bug 387533 has been marked as a duplicate of this bug. ***

Git commit 7114ed5d9661af6a833e55d76d63ab06de148032 by Leslie Zhai.
Committed on 28/08/2018 at 07:53.
Pushed by lesliezhai into branch 'master'.

Change my email address.

Hi Thomas, my brain is better now except kidney stones, I want to
maintainsee K3B until my brain is old, nothing could stop me, but
right now I can find out the bug ID :)

M  +1    -1    README.txt
M  +1    -1    libk3b/projects/datacd/k3bisooptions.cpp
M  +1    -1    src/k3bwelcomewidget.cpp
M  +2    -2    src/main.cpp

https://commits.kde.org/k3b/7114ed5d9661af6a833e55d76d63ab06de148032