Created attachment 106037 [details] Waiting for Disk -- K3b Hi, 25GB DB-R insert and throw me that it does not have enough space to record. == Information == $ls -lihsa debian-8.8.0-amd64-BD-1.iso 72751 22G -rwxrwx--- 1 root plugdev 22G jun 10 13:35 debian-8.8.0-amd64-BD-1.iso http://cdimage.debian.org/debian-cd/current Regards, -- Cristian
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
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