When trying to continue a multisession blue ray on Fedora 24 k3b resports a severe error. Here's the log: Burned media ----------------------- BD-R sequenziell Pseudo-Überschreiben (SRM+POW) Devices ----------------------- HL-DT-ST BD-RE BH16NS55 1.02 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R doppelschichtig, BD-CD-ROM, BD-CD-R, BD-RE, DVD+R, DVD+RW, DVD+R doppelschichtig) [DVD-ROM, DVD-R sequenziell, Zweischichtige DVD-R sequenziell, Zweischicht-DVD-R-Sprung, DVD-RAM, DVD-RW Eingeschränktes Überbrennen, DVD-RW sequenziell, DVD+RW, DVD+R, Zweischichtige DVD+R, CD-ROM, CD-R, CD-RW, BD-CD-ROM, BD-R sequenziell (SRM), BD-R Zufällig (RRM), BD-RE] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Eingeschränktes Überschreiben, Sprung zwischen DVD-Schichten, Zufällige Aufnahme, Sequenzielle Aufnahme, Sequenzielle Aufnahme + POW] [%7] K3b::IsoImager ----------------------- mkisofs print size result: 322106 (659673088 bytes) System ----------------------- K3b Version: 2.0.3 KDE Version: 4.14.22 QT Version: 4.8.7 Kernel: 4.6.4-301.fc24.x86_64 Used versions ----------------------- mkisofs: 1.1.11 growisofs: 7.1 growisofs ----------------------- /usr/bin/growisofs: -C argument is insane. growisofs command: ----------------------- /usr/bin/growisofs -C 0,0 -M /dev/sr0=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=4gms -use-the-force-luke=tracksize:322106 -speed=4 -use-the-force-luke=bufsize:32m mkisofs ----------------------- Rock Ridge signatures found 322106 I: -input-charset not specified, using utf-8 (detected in locale settings) mkisofs calculate size command: ----------------------- /usr/bin/genisoimage -cdrecord-params 0,0 -prev-session /dev/sr0 -gui -graft-points -print-size -quiet -volid Pictures-III -volset -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher -preparer -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-mnl/k3bUw5052.tmp -rational-rock -hide-list /tmp/kde-mnl/k3bpN5052.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-mnl/k3bNy5052.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-mnl/k3bhK5052.tmp mkisofs command: ----------------------- /usr/bin/genisoimage -cdrecord-params 0,0 -prev-session /dev/sr0 -gui -graft-points -volid Pictures-III -volset -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher -preparer -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-mnl/k3bnT5052.tmp -rational-rock -hide-list /tmp/kde-mnl/k3bJw5052.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-mnl/k3bPR5052.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-mnl/k3byV5052.tmp Reproducible: Always Steps to Reproduce: 1. Start session (works) 2. Continue session (fails)
Hi mnl, Please try k3b v2.10.0, its' github mirror: https://github.com/KDE/k3b and I do not have blueray... so I can NOT test it ;-( Regards, Leslie Zhai
Hi Leslie, I cannot compile 2.10.0 on Fedora because it requires "ecm". (It has obviously not been a dependency for 2.0.3, because I could successfully build this older version.) I failed to find a package that provides "ecm" on Fedora (though it seems to be "standard" on Ubuntu for a long time). Can you give me a hint? - Michael
(In reply to mnl from comment #2) > I failed to find a package that provides "ecm" on Fedora (though it seems to be "standard" on Ubuntu for a long time). Can you give me a hint? http://pkgs.fedoraproject.org/cgit/rpms/extra-cmake-modules.git/
Hi mnl, I am using Fedora too, and also ArchLinux ;-) Please have a look at http://www.leetcode.cn/2016/08/k3b.html described build dependence, it is better to sudo dnf upgrade --refresh your Fedora! Regards, Leslie Zhai
Hi mnl, This might help you https://help.ubuntu.com/community/CdDvd/Burning#Blu-Ray_Burning Regards, Leslie Zhai
Version 2.10.0 still fails to compile: ------------ CMake Error at /usr/lib64/cmake/Qt5Gui/Qt5GuiConfig.cmake:15 (message): The imported target "Qt5::Gui" references the file "/usr/lib64/libEGL.so" but this file does not exist. Possible reasons include: ... ------------ I checked. The file IS there!
Hi mnl, try sudo dnf install qt5-qtbase-devel and qt5-qtwebkit-devel and have a look at https://help.ubuntu.com/community/CdDvd/Burning#Blu-Ray_Burning Regards, Leslie Zhai
Git commit fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c by Leslie Zhai. Committed on 30/08/2016 at 15:19. Pushed by lesliezhai into branch 'master'. Use cdrecord for burning blueray instead of wodim. Because wodim from cdrkit (CD only, DVD deprecated, unmaintained) https://wiki.archlinux.org/index.php/Optical_disc_drive and the website http://www.cdrkit.org/ was down, so could not package it any more. M +1 -4 libk3b/core/k3bdefaultexternalprograms.cpp M +2 -3 libk3b/jobs/k3bdvdcopyjob.cpp M +0 -1 libk3b/jobs/k3bmetawriter.cpp M +3 -9 libk3b/projects/datacd/k3bdatajob.cpp M +1 -1 libk3b/projects/k3bcdrecordwriter.cpp M +1 -1 libk3bdevice/k3bdevice.cpp M +1 -2 src/k3bsystemproblemdialog.cpp M +1 -2 src/option/k3bexternalbinpermissionmodel.cpp http://commits.kde.org/k3b/fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c
The problem with cdrecord on Fedora is that it is in none of the standard repositories nor in the free/nonfree Fusion repositories except as "limited cdrecord compatibility wrapper" in package "cdrskin".
Hi mnl, yes! I manually build && install cdrecord in my Fedora box, but there is cdrtools package for ArchLinux https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/cdrtools wodim was unmaintained ;-( I will provide detailed how to build && install dependence for Fedora box http://www.leetcode.cn/2016/08/k3b.html and another issue is transcode, the same story! also unmaintained https://bitbucket.org/achurch_/transcode/pull-requests/1/migrate-to-ffmpeg-313/diff perhaps I will use mplayer for ripping encrypted videodvd! Regards, Leslie Zhai
This is a bit off topic, but on the long run these "self building requirements" are going to make k3b unusable for most Fedora users. I will continue to try to build the new version as I have time. But to get my blue-ray burning done, I've had a look at command line usage of growisfs in the meantime. It works fine (I think the only problem is the "-C" parameter that k3b passes to it, as can be seen in the log) and it is really easy to use. The only obvious advantage that k3b still offers to me regarding my burning tasks is proof reading.
> This is a bit off topic, but on the long run these "self building requirements" are going to make k3b unusable for most Fedora users. How to add cdrtools.spec to Fedora rpms repos? I can rpmbuild the cdrtools-XXX.rpm for Fedora users, I often do that ;-) http://koji.isoft-linux.org/koji/ growisfs -C , just like wget -c, continue doing the job, I will check growisfs's source code! Regards, Leslie Zhai
Git commit 62fda2003fcc355c8d18b9b530c725427578ad77 by Leslie Zhai. Committed on 01/09/2016 at 04:23. Pushed by lesliezhai into branch 'master'. Don't have to specify -C option for multisession. growisofs will construct one for you, and if provided wrong alleged_next_session, it will throw -C argument is insane error! Also please have a look at http://www.leetcode.cn/2016/08/k3b.html about cdrtools. M +2 -0 libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp M +5 -2 libk3b/projects/k3bgrowisofswriter.cpp http://commits.kde.org/k3b/62fda2003fcc355c8d18b9b530c725427578ad77
Hi, i am developer of libburn and wonder since years why K3B ignores programs based on it. cdrskin and xorriso burn CD, DVD, and BD just fine. The only shortcomming towards wodim and cdrecord is with exotic CD layouts like mixed mode or "raw" writing. (I lack of test cases and of the will to get into trouble with copyright holders of cloned CDs.) @Leslie Zhai: I am willing to help. Not only with adapting to cdrskin but also with identifying problems in growisofs. Isn't your patch "Use cdrecord for burning blueray instead of wodim." http://commits.kde.org/k3b/fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c mislabelled ? Shouldn't it rather be "Use cdrecord for burning blueray and DVD instead of growisofs" ? Well, cdrecord and libburn are both living projects, in contrast to growisofs and wodim. So this choice is not unreasonable on the first hand. Nevertheless you should be aware that growisofs has the better understanding of DVD as specified in MMC-5/MMC-6. Its BD code has a few flaws, indeed. Some have been fixed in the last 8 years by distro patches. So i advise to keep growisofs as default at least for DVD media if you cannot get yourself to give cdrskin a try. On BD media, cdrecord does not format BD-R (which is good for burn speed) but cannot employ Streaming mode on BD-RE (which is bad for burn speed). cdrskin can format BD-R if desired, which yields checkreading during burn and slow burning speed. It can also disable checkreading on formatted media. The latter makes 2x BD-RE burn with 2x effective speed instead of 0.8x to 1.0x speed. (Looking at libk3bdevice/k3bdevice.cpp line 3611 i wonder why K3B is diving into MMC entrails instead of letting the burn program determine the disc state. Does K3B have own MMC expertise ?) Have a nice day :) Thomas
Hi Thomas, > wonder since years why K3B ignores programs based on it. cdrskin and xorriso burn CD, DVD, and BD just fine. I am newbie of K3B http://www.leetcode.cn/2016/08/k3b.html I just want to fix KF5 related issue at very begining ;-) > The only shortcomming towards wodim and cdrecord is with exotic CD layouts like mixed mode or "raw" writing I have some Audio CD, so I can test Ripping CD, but not test burning Audio/Mixed CD neither. > I am willing to help. Not only with adapting to cdrskin but also with identifying problems in growisofs. cool! I am starting to read the source code of growisofs.c this morning ;-) > Isn't your patch mislabelled ? NO, I only dropped woidm, cdrkit (forked cdrtools) was unmaintained. > So i advise to keep growisofs as default at least for DVD media if you cannot get yourself to give cdrskin a try I do NOT have dvd/blueray for test, so I use CDemu to create a blank recordable disc: DVD+R SL with ISO image writer: cdemu create-blank --writer-id=WRITER-ISO --medium-type=dvd+r 0 ~/output-image.iso I will try cdrskin! > i wonder why K3B is diving into MMC entrails instead of letting the burn program determine the disc state yes, I dropped alleged_next_session, but let growisofs construct next session for me https://quickgit.kde.org/?p=k3b.git&a=commit&h=62fda2003fcc355c8d18b9b530c725427578ad77 Regards, Leslie Zhai
Hi, Leslie Zhai wrote: > I am starting to read the source code of growisofs.c this morning ;-) As a new fellow burn programmer you should get your hands on SCSI specs SPC-3, MMC-5 or MMC-6, SBC-2. https://en.wikipedia.org/wiki/MultiMedia_Commands has external links where you might find drafts for free. My own knowledge is recorded in http://libburnia-project.org/browser/libburn/trunk/doc/cookbook.txt (regrettably the T10 links meanwhile just yield PDFs with the offer to buy the specs for 30 USD each). > > Isn't your patch mislabelled ? > NO, I only dropped woidm, In https://quickgit.kde.org/?p=k3b.git&a=blobdiff&h=0517d6f372551c8d0ae3ec8354e8a692bf92c299&hp=0bc7b38bd1f587f3de6a0efbbd12e32359cbcffd&hb=fcb0ff1f36c319fd1e2b4bd92c2c08fdc690212c&f=libk3b%2Fjobs%2Fk3bdvdcopyjob.cpp i see - // prefer growisofs to wodim, which doesn't work all that great for DVDs - // (and doesn't support BluRay at all) - if ( k3bcore->externalBinManager()->binObject("cdrecord")->hasFeature( "wodim" ) ) + // wodim from cdrkit (CD only, DVD deprecated, unmaintained) + if ( false ) d->usedWritingApp = K3b::WritingAppGrowisofs; which i believe prevents the automatic use of growisofs. (I might be wrong, of course.) > cdrkit (forked cdrtools) was unmaintained. The demise of cdrkit is a deplorable fact indeed. It's source can still be browsed at https://sources.debian.net/src/cdrkit/9:1.1.11-3/ and i guess debian-mentors could help to locate an upstream source tarball. But well, if you have cdrecord, there is few use for wodim. > I do NOT have dvd/blueray for test, That will be a problem when you work on the DVD/BD code. You need a tester who is an experienced K3B user and can tell you about any regression caused by a changeset. > I use CDemu to create a blank recordable disc: DVD+R S I read on http://cdemu.sourceforge.net/about/daemon/ "Implemens a set of packet commands specified by MMC-3" MMC-3 did not yet specify DVD+R (only DVD+RW, DVD-R, DVD-RW, DVD-RAM) so you might be better off with DVD-R emulation. Whatever, you'd also need to test with emulated DVD+RW which would serve as role model of DVD-RAM, BD-RE, Pseudo-Overwrite BD-R, formatted DVD-RW. Maybe you can even reproduce the production of bad option -C 0,0 on DVD+RW. (See below for motivation.) > I will try cdrskin! Let's see how far we get. I am optimistic about DVD and BD, because they offer no exotic sector formats. With CD, we might be restricted to plain data and plain audio. No video, no data-audio-mix, ... I can confirm that cdrskin and xorrecord do multi-session on BD-R. You should try to get a verification that cdrecord can do multi-session on BD-R. (Last big improvement i saw was multi-session on DVD-R.) > yes, I dropped alleged_next_session, but let growisofs construct next > session Looks like a good idea. Test it with emulated DVD+RW. (It would be a bad idea with cdrecord/wodim/xorrecord as burn program.) ------------------------------------------------------------------------- As for the original bug: One should try to find out why K3B composed -C 0,0 which indicates to mkisofs/genisoimage/xorrisofs that it shall read the ISO superblock at offset 0+16 and prepare an addon session to be written at Next Writable Address 0. This is of course unplausible because the add-on must be written at some Next Writable Address after the end of the existing tracks. So K3B did not properly determine the Next Writable Address (NWA). One would have to dive into the MMC code of K3B. Normally this info is inquired from cdrecord/cdrskin/xorrecord by $program dev=/dev/sr0 -msinfo which should reply on stdout two numbers separated by a comma: 10718944,10795616 (numbers obtained from an appendable sequential BD-R with 181 sessions) The second number should never be 0 if the medium already contains a session. My best guess is that the medium is BD-RE or a BD-R formatted to state "Pseudo Overwrite". Both would like DVD-RAM, DVD+RW, and formatted DVD-RW report via MMC a single track which is writable beginning at block offset 0. On these media one has rather to inquire the ISO 9660 superblock to find the end of the written area and choose a pseudo-NWA after that end. growisofs does this inquiry by its ISO 9660 knowledge, not by its MMC knowledge. cdrskin can do this inquiry, if its option --grow_overwriteable_iso is present. Normally, like cdrecord, it inquires by MMC commands that the medium is writable starting at block 0 (i.e. pseudo blank in the CD inspired media model of cdrecord/cdrskin/xorrecord). A workaround for growisofs and BD-R media would be to use growisofs option -use-the-force-luke=spare=none on the first burn run, in order to prevent formatting the blank BD-R. This would also yield full nominal burn speed on that BD-R medium. And it would prevent a growisofs bug which throws error at the very end of first BD-R burn run. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713016 A workaround for formatted media would be to let K3B use cdrskin dev=/dev/sr0 --grow_overwriteable_iso -msinfo or to let K3B inquire the ISO 9660 Primary Volume Descriptor to find the filesystem end. A PDF with ISO 9660 specs (aka ECMA-119) is available for free: http://www.ecma-international.org/publications/standards/Ecma-119.htm See 8.4.8 Volume Space Size (BP 81 to 88) (First 4 bytes little-endian, next 4 give same number as big-endian. BP 81 means byte offset 32768 + 81 - 1 in the ISO filesystem image.) Have a nice day :) Thomas
Hi Thomas, Thanks for your detailed DVD background information, I will deep into it ;-) > which i believe prevents the automatic use of growisofs I will double check it! > That will be a problem when you work on the DVD/BD code yes! people often use clound or usb disk right now, so I have to borrow some empty DVD/Blu-ray... > So K3B did not properly determine the Next Writable Address (NWA) yes, wrong 0,0 alleged_next_session, and I will also deep into it, very interesting and it is able to learn some thing ;-) Regards, Leslie Zhai
Git commit f3f4602e30c67bf622b5a52ea39c78817b1dd020 by Leslie Zhai. Committed on 02/09/2016 at 02:15. Pushed by lesliezhai into branch 'master'. Use growisofs for burning DVD/Blu-ray by default. M +3 -2 libk3b/jobs/k3bdvdcopyjob.cpp http://commits.kde.org/k3b/f3f4602e30c67bf622b5a52ea39c78817b1dd020
*** Bug 356434 has been marked as a duplicate of this bug. ***
*** Bug 281818 has been marked as a duplicate of this bug. ***
Hi, this is about the effort needed to implement multi-session on DVD+RW, DVD-RAM, formatted DVD-RW, BD-RE, overwritably formatted BD-R. It should be possible by duplicating capabilities of growisofs and xorriso. Probably one would be better off by delegating the job into one of these programs, but i assume the separation of ISO 9660 producer and burn program is part of K3B's architecture. cdrskin --grow_overwriteable_iso would fit best into that separation. A compatibility problem is that only growisofs operates on overwritably formatted BD-R, which it formats by default when getting them in blank state. Given the corresponding CLOSE SESSION bug in original growisofs-7.1, the slow speed of formatted BD-R, and this compatibility problem, one should really consider to add option -use-the-force-luke=spare=none by default to growisofs runs on blank unformatted BD-R. The run will succeed with original growisofs-7.1 and the medium will be usable for cdrskin and xorriso, if it does not get closed by growisofs options. If cdrecord supports multi-session on BD-R, then quite surely only on those which are not formatted to be pseudo-overwritable. (I dare to predict this because Joerg Schilling expressed his general objections against emulated multi-session on overwritables.) -------------------------------------------------------------------- Why there is a problem: -C X,0 is not suitable for ISO 9660 multi-session, because Next Writable Address 0 would overwrite the existing session instead of appending a new session after its end. I looked into libk3bdevice/k3bdevice.cpp : ...::getNextWritableAdress(). It inquires the start of the last written session by SCSI command READ TRACK INFORMATION with address type 1. The value is taken from the reply field "Logical Track Start Address". This number is supposed to be 0 with overwritably formatted media. That's well ok for the first parameter value of mkisofs option -C if an ISO 9660 filesystem is present on the medium. The ISO superblock at address 0 is supposed to point to the newest directory tree. The second parameter value for option -C is the Next Writable Address. To obtain it, K3B sends READ TOC/PMA/ATIP with reply format 1, which returns for non-CD media a fabricated Table-Of-Content. The value is taken from reply field "Start Address of First Track in Last Session". (The "last session" is supposed to be the unwritten medium area.) With an overwritably formatted medium, this value is supposed to be always 0. ---------------------------------------------------------------------- How to fix it growisofs style: growisofs introduced emulated multi session by reading the size information of the ISO 9660 filesystem, writing the add-on session after the end of the existing filesyem, and overwriting the ISO 9660 superblock at the start of the medium. So one should read block 16 (* 2048 bytes) of the medium and check its first 6 bytes for {0x01,'C','D','0','0','1'}. If this magic number of ISO 9660 is found, then bytes 80 to 83 of the block tell the number of blocks as little-endian unsigned 32 bit number. This number would be the first block address which does not overwrite blocks from the existing ISO 9660 sessions. One should round it up to the next multiple of 32 blocks, in order to match alignment constraints of some DVD and BD media. (Caution: growisofs rounds to 16, not 32.) This way one gets a suitable second parameter value for mkisofs -C. Next is the problem to talk the burn program into writing the output of mkisofs to the same start block as was told to mkisofs by this value. growisofs source code shows that there is an option -use-the-force-luke=seek=<number> which might be usable together with option -Z (but not -M) to force growisofs into starting the write run at the given block number. One would have to test with DVD+RW, BD-RE, or formatted DVD-RW. cdrskin has option write_start_address=<byte_offset> (i.e. one has to multiply the block number by 2048) which lets writing start at the given byte number. Afterwards, a copy of the new ISO 9660 superblock must be written to block 0 (up to at least block 17), so that mount(8) shows the new directory tree. In this copy it is necessary to add the start block address to the number of blocks counter in the superblock. One will recognize success by the new files of the new session showing up after mount. This last step is tricky with burn programs, because they tend to write more data than given to them. On Linux, one does not need a burn program for writing to overwritable media. Normal open(2), lseek(2), write(2) will do. ---------------------------------------------------------------------- cdrskin's special offer: With cdrskin it is possible to let it decide about the -C parameter values with the promise that it will use the second told value as start address of the future burn run and to copy the patched superblock: $ cdrskin --grow_overwriteable_iso dev=/dev/sr0 -msinfo 2>/dev/null 0,3438672 $ mkisofs ... -M /dev/sr0 -C 0,3438672 ... \ | cdrskin --grow_overwriteable_iso dev=/dev/sr0 -waiti -multi ... - (Note the misspelling: "grow_overwrit*e*able_iso". Sorry for that.) Option --grow_overwriteable_iso does not hamper the work with unformatted multi-session media: CD-R, DVD-R, DVD+R, ... So the shown commands work with the media spectrum from CD-R to BD-RE. Only DVD-R DL and fast blanked DVD-RW cannot do multi-session for drive-media-internal reasons. growisofs and xorriso actually aim to encapsulate this gesture so that the user does not have to care for the multi-session peculiarities. ---------------------------------------------------------------------- Have a nice day :) Thomas
Hi Thomas, Thanks for your detailed information, I will carefully read it ;-) Regards, Leslie Zhai
Hi, > How to fix it growisofs style yes, growisofs implemented it: * - implement -use-the-force-luke=seek:N -Z /dev/dvd=image to arrange * for 'builtin_dd if=image of=/dev/dvd obs=32k seek=N/16' (note that * N is expected to be expressed in 2KB chunks); > -use-the-force-luke=spare=none please review it https://git.reviewboard.kde.org/r/128932/ Regards, Leslie Zhai
Hi, > please review it https://git.reviewboard.kde.org/r/128932/ My browser seems not to be ready for the layout or your changeset is much too small. I only see: QStringList ms = d->multiSessionInfo.split(','); if (ms.size() == 2) { if (ms[0] == 0 || ms[1] == "0") { qDebug() << "you don't have to specify -C option, growisofs will construct one for you!"; d->process << "-use-the-force-luke=spare=none"; } else { d->process << "-C" << d->multiSessionInfo; } } where i wonder who is addressed as "you". Other parts of K3B which constructed the d->multiSessionInfo content ? growisofs tolerates a -C option if the second value matches its own perception of medium and ISO 9660 filesystem. https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs.c/#L3271 } else if (alleged_next_session!=next_session) fprintf (stderr,"%s: -C argument is %s.\n", argv[0],alleged_next_session>=0? "insane":"undefined"), exit(FATAL_START(EINVAL)); You need to pass the same -C value to mkisofs as the one which growisofs will determine (i.e. import growisofs code into K3B and hope that growisofs stays as it is), or you have to force growisofs to use the -C value which you computed more freely and gave to mkisofs. (Possibly/hopefully by growisofs option -use-the-force-luke=seek:N) Do i get it right that if (ms[0] == 0 || ms[1] == "0") { shall catch "-C 0,0" that was determined by K3B ? If so, then K3B has probably seen an overwritable medium. In this case it should have already checked whether an ISO 9660 is present and where it ends. From that end it should have composed d->multiSessionInfo = "0,N" with N being a suitably rounded 2KiB block number after the end of the ISO filesystem. So when multiSessionInfo hits k3bgrowisofswriter.cpp it should be already a usable value and should be forced onto growisofs. As said, the value has to be used with the mkisofs run. Handing it over to growisofs would be a good check to prevent misunderstandings between K3B and growisofs. Better growisofs refuses to start than that it writes an add-on session to the wrong address. Background: -C old_start,new_start tells mkisofs to read the ISO superblock at address old_start and to prepare the output superblock and tree for being written to address new_start. Wrong old_start will yield mkisofs abort due to lack of superblock. Wrong new_start will yield output and no mkisofs error. growisofs will write the output to medium. But then the new session will not be mountable or the directory tree will yield i/o errors and/or wrong data file content. That's because all inner block number fields of the ISO will be wrong. ----------------------------------------------------------------------- My proposal to use -use-the-force-luke=spare=none was only for the case of blank BD-R media. Those will not have d->multiSession set while they are blank, i assume. So in the changeset code the option will not be applied to them. Background: If growisofs is ordered to write to BD-R without option ...spare=none, then it formats them to Pseudo-Overwritable state. Indigestible for libburn and probably for cdrecord. After the first session the BD-R will cause -C 0,0 and thus will need the special processing above. With option ...spare=none, growisofs leaves the BD-R unformatted and plainly writes the first session to it. (At full nominal speed !) Then the BD-R resembles much a written DVD+R. Current K3B will be able to inquire the correct -C values and hopefully perform multi-session as it hopefully does on DVD+R. (Somebody must test, of course.) --------------------------------------------------------------------- I can navigate in quickgit.kde.org quite well. So better point me to code or changesets there. In general i doubt that i can be of much help with K3B implementation details, except checking code which reads info from ISO 9660 filesystems. What i can offer is technical background info and testing of growisofs on re-usable media. I will try to make a demo script with mkisofs and growisofs running separately. Have a nice day :) Thomas
Hi, i tested growisofs and separately running mkisofs/genisoimage/xorrisofs on DVD+RW to show how i imagine this could be done in K3B: ------------------------------------------------------------------- # Create some input files echo file1 >file1 echo file2_a_bit_larger >file2 # First session genisoimage -R file1 | \ growisofs -Z /dev/sr0=/dev/fd/0 # This run reports: 176 extents written (0 MB) # So i choose a deliberately high Next Writable Address: 1024 # mount(8) and ls(1) show one file in the ISO # -rw-r--r-- 1 thomas thomas 6 Sep 18 14:59 file1 # Second session (after unmounting /dev/sr0, of course) genisoimage -M /dev/sr0 -C 0,1024 -R file2 | \ growisofs -use-the-force-luke=seek=1024 -C 0,1024 -Z /dev/sr0=/dev/fd/0 # mount(8) and ls(1) show both files in the ISO # -rw-r--r-- 1 thomas thomas 6 Sep 18 14:59 file1 # -rw-r--r-- 1 thomas thomas 19 Sep 18 14:59 file2 ------------------------------------------------------------------- Both are needed: -use-the-force-luke=seek=1024 and -C 0,1024 Else mount(8) and ls(1) will show only file1 after the second session. (I.e. without -C, growisofs does not update the superblock at offset 0.) In the second run growisofs reports: About to execute 'builtin_dd if=/dev/fd/0 of=/dev/sr0 obs=32k seek=64' builtin_dd: 176*2KB out @ average 0.1x1352KBps genisoimage reports: 1200 extents written (2 MB) We learn that genisoimage added 1024 and 176 in its message. Suitable Next Writable Address would be any properly aligned value not smaller than 1200. So it would work with growisofs if K3B would compute its own Next Writable Address and force it on genisoimage and growisofs. For the sake of BD-RE performance and compatibility to my software i sincerely advise to round up to full multiples of 32 blocks. growisofs rounds to 16, which is not necessary aligned to a BD data unit of 32 (aka "Cluster"). DVD has 16 blocks per "ECC Block". Being selfish i show the cdrskin way: ------------------------------------------------------------------- # Pseudo-blank the medium, so that cdrskin will not append its # first session to the existing ISO filesystem. # The same command blanks CD-RW and unformatted DVD-RW. # It tolerates blank media and fails on non-blank non-blankable media. cdrskin --grow_overwriteable_iso dev=/dev/sr0 -v blank=as_needed # First session. # Option --grow_overwriteable_iso lets cdrskin tolerate -multi on DVD+RW. # (One cannot close a DVD+RW. So -multi is normally rejected.) genisoimage -R file1 | \ cdrskin --grow_overwriteable_iso -multi dev=/dev/sr0 -v -eject - # Inquire values for genisoimage -C. # Option --grow_overwriteable_iso lets cdrskin inspect the ISO. # Nevertheless this works too on sequential media: # CD-R[W], DVD-R[W], DVD+R, non-pseudo-overwritable BD-R. C_VALUES=$(cdrskin dev=/dev/sr0 --grow_overwriteable_iso -msinfo) # Second session. Option --grow_overwriteable_iso lets cdrskin direct # the burn run to the same address as predicted by the previous run # and handed to genisoimage. genisoimage -M /dev/sr0 -C "$C_VALUES" -R file2 | \ cdrskin --grow_overwriteable_iso -multi dev=/dev/sr0 -v -eject - ------------------------------------------------------------------- The advantage of this is that K3B does not have to inspect the ISO and can operate any kind of media by the same cdrskin runs. Have a nice day :) Thomas
I should mention that session 2 tests with growisofs -M instead of -Z failed.
Hi Thomas, > I should mention that session 2 tests with growisofs -M instead of -Z failed growisofs -M /dev/sr0=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=4gms -use-the-force-luke=tracksize:322106 -speed=4 -use-the-force-luke=bufsize:32m you mean the above failed to work? then what described http://fy.chalmers.se/~appro/linux/DVD+RW/ you don't have to specify -C option, growisofs will construct one for you?! wrongly implemented? Regards, Leslie Zhai
Git commit 477870ea36d07505889bfcccce33becc41ba57f3 by Leslie Zhai. Committed on 19/09/2016 at 02:37. Pushed by lesliezhai into branch 'multisession'. growisofs described you don't have to specify -C option, it will construct one for you. M +9 -1 libk3b/projects/k3bgrowisofswriter.cpp http://commits.kde.org/k3b/477870ea36d07505889bfcccce33becc41ba57f3
Hi, i wrote: > > I should mention that session 2 tests with growisofs -M instead of -Z > > failed Leslie Zhai wrote: > growisofs -M /dev/sr0=/dev/fd/0 ... > you mean the above failed to work? It failed together with -use-the-force-luke=seek=1024: $ genisoimage -M /dev/sr4 -C 0,1024 -R file2 | growisofs -use-the-force-luke=seek=1024 -M /dev/sr4=/dev/fd/0 ... growisofs: -C argument is undefined. $ genisoimage -M /dev/sr4 -C 0,1024 -R file2 | growisofs -use-the-force-luke=seek=1024 -C 0,1024 -M /dev/sr4=/dev/fd/0 ... growisofs: -C argument is insane. I assume that -M causes growisofs to do an own Next Writable Address computation and to ignore -use-the-force-luke=seek=1024. > then what described > http://fy.chalmers.se/~appro/linux/DVD+RW/ you don't have to specify -C > option, growisofs will construct one for you?! wrongly implemented? Not wrong implemented but other use case. growisofs (like my xorriso) aims to simplify the gesture of obtaining the next writable address, giving mkisofs the right -C values, and piping the output of mkisofs to optical media. man growisofs shows these well working examples: Session 1: growisofs -Z /dev/dvd -R -J /some/files Session 2 growisofs -M /dev/dvd -R -J /more/files mkisofs is in both runs started by growisofs. With these runs, you do not have to give a -C option. But K3B does not use growisofs that way. It rather starts mkisofs and growisofs separately and pipes the output of mkisofs into the input of growisofs. Option -M may well work with sequential media: DVD-R, DVD+R, unformatted DVD-RW, non-overwritable BD-R. That's because both, K3B and growisofs ask the burner drive to determine the Next Writable Address. With the other media and media states, there is the problem that K3B would have to determine the Next Writable Address from the ISO 9660 filesystem size. But there is some freedom of choice with this value and growisofs and mkisofs *must* use the same value. So my tested proposal is to determine some suitable Next Writable Address from the ISO 9660 superblock and to force it on both, mkisofs and growisofs. It worked only with growisofs -Z, not with growisofs -M. Note well: This is appropriate only with overwritable media. I assume you can recognize the situation by K3B determining -C 0,0 when it inquires the Next Writable Address from MMC commands in K3b::Device::Device::getNextWritableAdress() , libk3bdevice/k3bdevice.cpp Or you recognize media profiles as does setup_C_parm() in growisofs.c : if (!poor_man || profile==0x1A || profile==0x2A || profile==0x13 || profile==0x12 || profile==0x42 || profile==0x43) { next_session = from_733(descr->volume_space_size); /* pad to closest 32K boundary */ (That's DVD+RW, DVD+RW DL, formatted DVD-RW, DVD-RAM, pseudo-overwritable BD-R, and BD-RE.) ------------------------------------------------------------------------- I will make tests with growisofs -M and a computed Next Writable Address which matches the computation of growisofs. (If you go that way, then K3B must always compute the same value as does growisofs. That's quite a risky design.) Have a nice day :) Thomas
Hi Thomas, in short: Plan A - rewrite K3b::Device::Device::getNextWritableAdress() Plan B - avoid risky design, don't have to specify -C option, let growisofs construct one Regards, Leslie Zhai
Hi, > Plan A - rewrite K3b::Device::Device::getNextWritableAdress() Augment it by the equivalent of growisofs code, if the multisession -C parameters turn out as 0,0: next_session = from_733(descr->volume_space_size); /* pad to closest 32K boundary */ next_session += 15; next_session /= 16; next_session *= 16; sprintf (C_parm,"16,%u",next_session); (The "16" as first -C value is actually wrong but mkisofs will understand what is meant. Legacy tradition.) I would advise to align to 64 K at least for BD media. But that is not what growisofs does. Whatever, determination of -C values is needed in any case, because K3B needs to hand over the values to mkisofs. > Plan B - avoid risky design, don't have to specify -C option, let growisofs > construct one You got me wrong here. I deem it risky if you bet on K3B's capability to determine the same second number for -C as growisofs does. I.e. if you do not use: -use-the-force-luke=seek=... -C ... -Z /dev/sr0=/dev/fd/0 I did not yet get to the experiment whether -C ... -M /dev/sr0=/dev/fd/0 works fine if i submit the same value to -C as growisofs computes. It does not help to omit with the growisofs run. If the value is acceptable then growisofs will go on. If you gave mkisofs a value which growisofs will not accept, then it is ok to abort the burn run, because mkisofs prepared the add-on session with incorrect offset. (Remember: The statement "You don't have to specify the -C option" in the man page is about the use case which K3B does *not* use. In case of /dev/sr0=/dev/fd/0 the statement is not really true.) Have a nice day :) Thomas
Hi Thomas, Then key point is: > Whatever, determination of -C values is needed in any case, because K3B needs to hand over the values to mkisofs If ScsiCommand 0x52 (MMC_READ_TRACK_INFORMATION) 0x1(incomplete) wrongly return 0 (as mnl experienced), then how to fix it? Regards, Leslie Zhai
Hi, > If ScsiCommand 0x52 (MMC_READ_TRACK_INFORMATION) 0x1(incomplete) wrongly > return 0 (as mnl experienced), The answer 0 is correct. It is just given by the wrong entity, namely the drive and not the filesystem superblock. A MMC drive regards an overwritable medium as having a single session with a single track. This track is readable beginning at block 0. Thus the first -C value is determined by the drive as 0. The track is also writable beginning at block 0. Thus the second -C value is determined by the drive as 0. But we do not want to overwrite the existing ISO. We want to append in multi-session style. This is the reason why growisofs began to exist. Andy Polyakov wanted multi-session on media which are not prepared for multi-session but rather allow random access writing. man growisofs begins by: growisofs was originally designed as a frontend to genisoimage to facilitate appending of data to ISO9660 volumes residing on random- access media such as DVD+RW, DVD-RAM, plain files, hard disk parti‐ tions. In the course of development general purpose DVD recording sup‐ port was implemented, and as of now growisofs supports not only random- access media, but even mastering of multisession DVD media such as DVD+R and DVD-R/-RW. It was Andy's great invention to inquire the ISO 9660 superblock and to use a block number after the end of the ISO as pseudo Next Writable Address. Currently K3B is prepared only for "multisession DVD media" but not for the "random-access media" which growisofs originally targets. This is because it does not use growisofs to start mkisofs but rather starts both program side by side. > then how to fix it? Do it like Andy (and me in xorriso): - Inquire the ISO filesystem size. - Choose a block address after the end of the ISO. - Instruct all involved programs that this address will be used for writing the add-on session. growisofs does the ISO inquiry by the call from_733(descr->volume_space_size); "733" refers to ECMA-119 paragraph 7.3.3 which says: 7.3.3 Both-byte orders A numerical value represented by the hexadecimal representation (st uv wx yz) shall be recorded in an eight-byte field as (yz wx uv st st uv wx yz). For example, the decimal number 305419896 has (12 34 56 78) as its hexadecimal representation and is recorded as (78 56 34 12 12 34 56 78). "descr" is the content of the Primary Volume Descriptor (ECMA-119, 8.4). This is recorded at block 16. "->volume_space_size" accesses the bytes at offset 80 in the Descriptor. ECMA-119, 8.4.8: Volume Space Size (BP 81 to 88) This field shall specify as a 32-bit number the number of Logical Blocks in which the Volume Space of the volume is recorded. This field shall be recorded according to 7.3.3. Note that ECMA-119 counts byte position BP beginning with 1. I.e. BP 81 is byte offset 80. So at byte offset 80 in block 16 begins the little-endian 4-byte block count of the ISO. At offset 84 begins the same number represented as big-endian. In growisofs.c this is expressed by a C structure: struct iso_primary_descriptor { ... members with together 80 bytes ... unsigned char volume_space_size [8]; ... }; But one may simply do fseek() to 32768+80, read the 4 bytes, and interpret them as little-endian 32 bit value. Have a nice day :) Thomas
Hi, it really works when you tell growisofs -M the correct -C values which match the ones computed by growisofs. Session 1: genisoimage -R file1 | \ growisofs -Z /dev/sr4=/dev/fd/0 The ISO has a size of 176 blocks. growisofs would next round up to integer multiples of 16. That still yields 176. So i use -C 0,176 in Session 2: genisoimage -M /dev/sr4 -C 0,176 -R file2 | \ growisofs -C 0,176 -M /dev/sr4=/dev/fd/0 growisofs agreed to -C 0,176. So it was not necessary to override the ideas of growisofs via option -use-the-force-luke=seek=... Mounting the DVD+RW shows both files. So this would be a viable method, too. One just would have to try ISO 9660 size determination if the MMC track position inquiry yields 0,0. Don't forget to check for the magic number of ISO 9660 at the start of block 16. If the first 6 bytes are not {0x01,'C','D','0','0','1'}, then it is not an ISO 9660 and there is no use in reading the 32 bit number from byte offset 80. In this case, no multi-session can be offered to the user. Have a nice day :) Thomas
Git commit 9a6340ed76aaa8fa8784168ef7d286710097cee3 by Leslie Zhai. Committed on 21/09/2016 at 02:41. Pushed by lesliezhai into branch 'master'. Wrong alleged_next_session for growisofs WIP in multisession branch. M +2 -2 libk3b/projects/k3bgrowisofswriter.cpp http://commits.kde.org/k3b/9a6340ed76aaa8fa8784168ef7d286710097cee3
Git commit b22f60344db146aa6b5136373b0a0b270d5d8ee9 by Leslie Zhai. Committed on 21/09/2016 at 04:09. Pushed by lesliezhai into branch 'multisession'. Inquire the ISO filesystem size Hi Thomas, please review it ;-) CCMAIL: scdbackup@gmx.net M +16 -3 libk3b/projects/k3bgrowisofswriter.cpp http://commits.kde.org/k3b/b22f60344db146aa6b5136373b0a0b270d5d8ee9
Git commit e9faad4a24e80ee83a3881707e394ca4be66f5c7 by Leslie Zhai. Committed on 21/09/2016 at 04:36. Pushed by lesliezhai into branch 'multisession'. Add more check for inquiring the ISO filesystem size M +5 -1 libk3b/projects/k3bgrowisofswriter.cpp http://commits.kde.org/k3b/e9faad4a24e80ee83a3881707e394ca4be66f5c7
Hi, Leslie Zhai wrote: > Hi Thomas, please review it ;-) Most problematic: I do not see where you hand over the growisofs-ly computed -C values to mkisofs. It could be that it gets to see -C 0,0 despite the effort in k3bgrowisofswriter.cpp. I am uncertain whether i caught all problems. You need to test with (maybe emulated) DVD+RW medium. (Not DVD+R or DVD-R.) ------------------------------------------------------------------------- > http://commits.kde.org/k3b/9a6340ed76aaa8fa8784168ef7d286710097cee3 Looks good to me, under the assumption that d->multiSessionInfo contains the suitable values which growisofs will accept. ------------------------------------------------------------------------- > http://commits.kde.org/k3b/b22f60344db146aa6b5136373b0a0b270d5d8ee9 I riddle about this gesture + if (d->image.isEmpty()) + fptr = fopen("/dev/fd/0", "r"); It is clearly wrong to open "/dev/fd/0" out of multiple reasons: - It is unclear to what the stdin of K3B is connected. Quite surely not to the stdout of the mkisofs run. And if so, then reading would consume irrevocably the start of the ISO stream. This is a show stopper ! - "/dev/fd/0" is both, a Linux device address and a symbolic address in growisofs. If growisofs sees this address, then it does not open the Linux file but rather uses stdin (the already open file descriptor 0). See growisofs.c: if (sscanf(in_image,"/dev/fd/%u",&imgfd) == 1) imgfd = dup (imgfd); /* validate descriptor */ - stdin is not seekable. fseek(3) will probably cause errno EBADF. Under what circumstance is the condition d->image.isEmpty() true ? Can this happen at all, when d->multiSession is true ? ------ + fptr = fopen(d->image.toStdString().c_str(), "r"); Is it sure that this path leads to the random-access readable file object which hold the previous ISO 9660 session ? ------ You do not check for the ISO 9660 magic number before you read the size. This is absolutly mandatory or else the pseudo Next Writable Address will be more or less random and growisofs will most probably not accept it. Roughly (needs error handling with fseek and fread): char buf[6]; fseek(fptr, 32 * 1024, SEEK_SET); fread(fptr, 1, 6, buf); if (buf[0] != 0x01 || buf[1] != 'C' || buf[2] != 'D' || buf[3] != '0' || buf[4] != '0' || buf[5] != '1') { // TODO: handle that no ISO 9660 is present at medium start } ------ + fread(buf, 1, sizeof(buf), fptr); + d->process << "-C 0," << buf; Between these two line you have to convert the 4 bytes into a 32 bit number by interpreting them as little-endian number. Your code would fail on machines with big-endian byte order. (They are rare but still exist.) Further you did not round up to full multiples of 16. I'd do (in the hope that i understand the "d->process << " gesture): uint32_t c2; uint8_t buf[4]; ret = fread(buf, 1, sizeof(buf), fptr); if (ret != sizeof(buf)) { // TODO: handle inability to read ISO size } // Interpret the read bytes as little-endian number. // See also growisofs.c function from_733(). c2 = buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24); // Round up to full multipes of 16, as growisof does // in its function setup_C_parm(). c2 += 15; c2 /= 16; c2 *= 16; d->process << "-C 0," << c2; uint32_t and uint8_t from C header <stdint.h> guarantee the size and unsignedness. If they are not acceptable to K3B, use "unsigned long" and "unsigned char". (Note that "<<" has two completely different meanings here. A C++ promoter who ridicules BASIC's GOTO should be asked to compare it with the inheritance piles and spaghetti overloading of C++.) ------ + qWarning() << strerror(errno); Warning seems to weak as reaction to me. We noticed an unusable d->multiSessionInfo and try to replace it by a usable one. Now this failed and we actually have to refuse the burn run, because it would fail with a growisofs error message. Also, if you just show the error message, then the user will not know why you tried to fseek and read. I'd throw a severe error and report "Medium is not of multi-session type and does not contain ISO 9660. Cannot emulate multi-session on it." ------------------------------------------------------------------------- > http://commits.kde.org/k3b/e9faad4a24e80ee83a3881707e394ca4be66f5c7 I understand this is a correction to the previous patch. (Did "<<" buf show undesired bytes ?) + int next = atoi(buf); The signed data type "int" is slightly wrong here. The problem would show up only with ISOs of size 4 TiB or larger. Nevertheless, the field is defined by ECMA-119 as unsigned 32 bit stored in both endiannesses. atoi(buf) will yield wrong results on big-endian machines. You first need to left-shift the bytes into their little-endian positions before you can treat the result as 32 bit number. // Interpret the read bytes as little-endian number c2 = buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24); Further atoi(3) yields signed int. (Again, a problem only with >= 4 TiB.) -------------------------------------------------------------------------- We are getting nearer to the goal. I am undecided whether interpretation of ISO size is correctly located in k3bgrowisofswriter.cpp . -------------------------------------------------------------------- Pro: You can follow the habits of growisofs as awkward they may be. Contra: You must give mkisofs the same -C values as you tell growisofs. So if you leave the computation in k3bgrowisofswriter.cpp then you must update d->multiSessionInfo and you must make sure that the mkisofs run is composed only after d->multiSessionInfo was corrected. Multi-session emulation on overwritable media is not only provided by growisofs. So if other capable programs get used by K3B, one will have to duplicate large parts of the ISO inspection. (A habit to align to larger granularity than 16 could possibly be handled in the specialized writer by rounding again. This works only if the new alignement is a multiple of 16.) -------------------------------------------------------------------- So i'd imagine this architecture: - A generic checker for d->multiSessionInfo, which tries to determine a better value from ISO if the current value is 0,0. This function would _not_ round the c2 value. - A writer specific function which inspects the c2 value and rounds it to the granularity which the writer program uses. (16 for growisofs.) - Only after this is done you may compose the program arguments of mkisofs and writer program. -------------------------------------------------------------------- Have a nice day :) Thomas
Git commit ae0413daf1df44cb2c8c6e88a5b86180f1f52c3a by Leslie Zhai. Committed on 22/09/2016 at 03:42. Pushed by lesliezhai into branch 'multisession'. Multisession implemented as Thomas suggested Summary: - validate file descriptor - check for the ISO 9660 magic number - convert the 4 bytes into a 32 bit number by interpreting them as little-endian number - A generic checker for GrowisofsWriter (growisofs) and IsoImager (mkisofs) M +1 -0 libk3b/projects/datacd/k3bdatajob.cpp M +41 -0 libk3b/projects/datacd/k3bisoimager.cpp M +2 -30 libk3b/projects/k3bgrowisofswriter.cpp http://commits.kde.org/k3b/ae0413daf1df44cb2c8c6e88a5b86180f1f52c3a
Hi, > http://commits.kde.org/k3b/ae0413daf1df44cb2c8c6e88a5b86180f1f52c3a > libk3b/projects/datacd/k3bisoimager.cpp Then let's see ... > + char* in_image = "/dev/fd/0"; This is still wrong. We need to access the existing ISO 9660 filesystem on the medium. So this should rather be the path to the drive with the DVD+RW. (I.e. something like "/dev/sr0" on Linux.) > + // Validate file descriptor > + if (sscanf(in_image, "/dev/fd/%u", &imgfd) == 1) > + imgfd = dup(imgfd); > + else This case should then not occur. (We cannot lseek() on stdin anyway.) > + imgfd = open(in_image, O_RDONLY); This will be in effect. (For the subsequent code i can just hope that i did not propose too much nonsense. It needs to be tested when the path problem is solved.) I do not see where you throw severe error if m_multiSessionInfo stays with string value "0,0". This value means that we cannot use the growisofs emulation of multi-session and that growisofs will raise protest about -C 0,0. Without -C it would probably just overwrite the existing data instead of adding new data. Maybe it would complain about -M without -C. K3B should tell the user that it won't work instead of letting growisofs or other writers do undesired things or issue cryptic error messages. > - A generic checker for GrowisofsWriter (growisofs) and IsoImager (mkisofs) You did not put the rounding stage into a writer specific function. As it is now, the function in k3bisoimager.cpp assumes that all writers behave like growisofs. So to stay modular (and to give cdrskin a chance to override the values by its own findings) you should not round in k3bisoimager.cpp but rather introduce a new writer specific function for all writers. - The one of growisofs will round up to 16. - The (future i hope) one of cdrskin would ask cdrskin for its own values for the given medium and ISO 9660 filesystem. - The one of cdrecord would throw error, because i assume that cdrecord does not support on DVD+RW a write start address other than 0. To prepare for cdrskin, the new function should know the path of the drive's device file (e.g. "/dev/sr0"). Have a nice day :) Thomas
Git commit 076340502f14a5ecd928551500392e5f38dd2c41 by Leslie Zhai. Committed on 23/09/2016 at 02:35. Pushed by lesliezhai into branch 'multisession'. Fix multisession implementation as Thomas suggested Summary: - Use device driver's path instead of stdin - Stay module DataMultiSessionParameterJob so CdrskinIsoImager can use that - Throw error info message to user M +1 -0 libk3b/projects/datacd/k3bdatajob.cpp M +30 -0 libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp M +0 -41 libk3b/projects/datacd/k3bisoimager.cpp M +8 -2 libk3b/projects/k3bgrowisofswriter.cpp http://commits.kde.org/k3b/076340502f14a5ecd928551500392e5f38dd2c41
Hi, > libk3b / projects / datacd / k3bdatamultisessionparameterjob.cpp I hate to say it, but it looks like there is already handling for growisofs multi-session on overwritable media in this source file. Just a few lines above your code addition there is: // FIXME: Does BD-RE really behave like DVD+RW here? if( info.mediaType() & (K3b::Device::MEDIA_DVD_PLUS_RW| K3b::Device::MEDIA_DVD_PLUS_RW_DL| K3b::Device::MEDIA_DVD_RW_OVWR| K3b::Device::MEDIA_BD_RE) ) { It refers to DVD+RW, DVD+RW DL, overwritable DVD_RW, and BD-RE. But it does not refer to pseudo-overwritable BD-R, which caused this bug report. (Arrrghhh !!!) It is quite likely that the fix for this bug is simply to add the profile for pseudo-overwritable BD-R to the list. libk3bdevice/k3bdevicetypes.h has it probably as MEDIA_BD_R_SRM_POW: enum MediaType { ... /** Writable Blu-ray Disc (BD-R) */ MEDIA_BD_R_SRM_POW = 0x2000000, It could need a change from "Writable" to "Pseudo-Overwritable" in its comment to distinguish it from unformatted MEDIA_BD_R_SRM.) Except the occurence in setupMultiSessionParameters(), there is another one in determineMultiSessionModeFromMedium(), where you should add the MEDIA_BD_R_SRM_POW too. -------------------------------------------------------------------- Reasoning: MEDIA_BD_R_SRM_POW gets recognized in libk3bdevice/k3bdevice.cpp line 1872 by case 0x41: { if( featureCurrent( FEATURE_BD_PSEUDO_OVERWRITE ) == 1 ) return MEDIA_BD_R_SRM_POW; else return MEDIA_BD_R_SRM; The profile number 0x41 indicates BD-R which are not formatted to Random Recording Mode (which is not used by growisofs). libk3bdevice / k3bdevicetypes.h has const unsigned short FEATURE_BD_PSEUDO_OVERWRITE = 0x038; The MMC feature 0x38 indeed indicates Pseudo-Overwrite formatting on profile 0x41. (MMC-5 5.3.28: BD-R Pseudo-Overwrite (POW) Feature.) ------------------------------------------------------------------ Darn. Your newest change really looks as if we were nearly there. Error throwing was not sufficient yet. And when i looked for a code example how to do it, i came to that list of overwritable profiles. We should have first searched for the correct place in the program architecture and only then have tried to implement it. One never stops learning ... Have a nice day :) Thomas
Hi, Surprise: growisofs does not inspect the ISO with BD-R profile 0x41 ! So adding MEDIA_BD_R_SRM_POW will not be correct. Do Not Commit, Please. I rather see in growisofs_mmc.cpp a special handling for pseudo-overwritable BD-R which i did not remember to have seen in the SCSI MMC related code of K3B: cmd[0] = 0x52; // READ TRACK INFORMATION cmd[1] = 1; cmd[4] = next_track>>8; cmd[5] = next_track; // ask for last track cmd[8] = sizeof(buf); cmd[9] = 0; err = cmd.transport (READ,buf,sizeof(buf)); ... if (mmc_profile==0x41 && bdr_plus_pow && buf[7]&1) // NWA_V { next_session = buf[12]<<24; next_session |= buf[13]<<16; next_session |= buf[14]<<8; next_session |= buf[15]; } else { next_session = buf[8]<<24; // Track Start Address next_session |= buf[9]<<16; next_session |= buf[10]<<8; next_session |= buf[11]; } The first case is for what K3B recognizes as MEDIA_BD_R_SRM_POW. I will now revisit the code of K3B which asks the drive for the Next Writable Address. Have a nice day :) Thomas
Hi, libk3bdevice/k3bdevice.cpp , K3b::Device::Device::getNextWritableAdress() has // Read start address of the incomplete track if( readTrackInformation( trackData, 0x1, nextTrack ) ) { nextWritableAdress = from4Byte( &trackData[8] ); which matches the else-case of growisofs_mmc.cpp cmd[0] = 0x52; // READ TRACK INFORMATION ... if (mmc_profile==0x41 && bdr_plus_pow && buf[7]&1) // NWA_V { next_session = buf[12]<<24; next_session |= buf[13]<<16; next_session |= buf[14]<<8; next_session |= buf[15]; } else { next_session = buf[8]<<24; // Track Start Address next_session |= buf[9]<<16; next_session |= buf[10]<<8; next_session |= buf[11]; } There is no counterpart for the bdr_plus_pow case. In K3B the equivalent would have to look like // Read start address of the incomplete track if( readTrackInformation( trackData, 0x1, nextTrack ) ) { if (m == MEDIA_BD_R_SRM_POW && (trackData[7] & 1)) nextWritableAdress = from4Byte( &trackData[12] ); else nextWritableAdress = from4Byte( &trackData[8] ); Have a nice day :) Thomas
Hi. a summary of the winded road which brought me to the current diagnosis. After my theory of lack of multi-session support on overwritable media brought us to the code where this support is already implemented, i first thought it was only about a missing media type in the list of overwritables. But the code for detection of BD-R in POW state made it clear that i misinterpreted the list of overwritables in growisofs. The growisofs list does not contain BD-R POW (profile 0x41 + feature 0x38) but rather BD-R RRM (profile 0x42), which is still missing in K3B's list. Since growisofs does not format BD-R to RRM by default, there had to be a different deviation of K3B's determination of Next Writable Address from growisofs method of determination. I found this deviation when comparing K3b::...::getNextWritableAdress() with plusminus_r_C_parm() in growisofs_mmc.cpp. Discovered problems along that road: Obviously the K3B code to predict growisofs decisions was not completely updated after growisofs introduced support for BD media. One would possibly have to compare all media related gestures with those of growisofs. (I compared the computation of lastSessionStart for BD-R POW and found it correct. But other aspects may still offer pitfalls.) One known deviation is the difference between the list of overwritables in growisofs (DVD+RW, DVD+RW DL, formatted DVD-RW, DVD-RAM, BD-R RRM, and BD-RE) to the ones in K3B (MEDIA_DVD_PLUS_RW, MEDIA_DVD_PLUS_RW_DL, MEDIA_DVD_RW_OVWR, MEDIA_BD_RE). I.e. DVD-RAM and BD-R RRM are missing in the K3B list of overwritables. It seems essential that both programs use the same list. Have a nice day :) Thomas
Git commit cbe652000292dc5a6c9e36de0d1000ca0d84f75d by Leslie Zhai. Committed on 26/09/2016 at 02:08. Pushed by lesliezhai into branch 'multisession'. Update multisession implementation as Thomas suggested Summary: - Fix getNextWritableAdress issue with counterpart for the bdr_plus_pow case - Remove duplicated nextSessionStart M +0 -2 libk3b/projects/datacd/k3bdatajob.cpp M +0 -32 libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp M +4 -1 libk3bdevice/k3bdevice.cpp http://commits.kde.org/k3b/cbe652000292dc5a6c9e36de0d1000ca0d84f75d
Hi, > http://commits.kde.org/k3b/cbe652000292dc5a6c9e36de0d1000ca0d84f75d > libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp Actually one should still throw error if (nextSessionStart == 0) at the end of setupMultiSessionParameters(). Especially since DVD-RAM and BD-R RRM are missing in K3B's list of overwritable media. > libk3bdevice/k3bdevice.cpp This mirrors sufficiently the growisofs gesture at https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs_mmc.cpp/#L949 But there are more differences to BD-R POW in growisofs plusminus_r_C_parm() versus K3B getNextWritableAdress(). -------------------------------------------------------------------- The determination of the next_track number differs: https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs_mmc.cpp/#L926 if (mmc_profile==0x41 && bdr_plus_pow) next_track = disc_info[6]|disc_info[11]<<8; else next_track = disc_info[5]|disc_info[10]<<8; So for BD-R POW, growisofs reads field "Last Track Number in Last Session" rather than "First Track Number in Last Session". (Not sure why it does this.) K3B has only first_track: int nextTrack = inf->first_track_l|inf->first_track_m<<8; The definition of disc_info_t in libk3bdevice/k3bmmc.h has corresponding fields .last_track_l and .last_track_m. I propose: int nextTrack; if( m == MEDIA_BD_R_SRM_POW ) nextTrack = inf->last_track_l|inf->last_track_m<<8; else nextTrack = inf->first_track_l|inf->first_track_m<<8; -------------------------------------------------------------------- Contrary to my statement on saturday, there is a deviation with lastSessionStart: https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs_mmc.cpp/#L962 if (mmc_profile==0x41 && bdr_plus_pow) prev_session=0; else ... determination via READ PMA/TOC/ATIP ... K3B has: // Read start address of the first track in the last session if( readTocPmaAtip( trackData, 0x1, false, 0x0 ) ) { lastSessionStart = from4Byte( &trackData[8] ); success = true; } which should become // Read start address of the first track in the last session if( m == MEDIA_BD_R_SRM_POW ) { lastSessionStart = 0; success = true; } else { if( readTocPmaAtip( trackData, 0x1, false, 0x0 ) ) { lastSessionStart = from4Byte( &trackData[8] ); success = true; } } -------------------------------------------------------------------- Hopefully these are all deviations in getNextWritableAdress(). But growisofs has bdr_plus_pow mentioned in get_2k_capacity(). One would have to search for the corresponding code in K3B. We will need a courageous tester soon. (Expensive BD-R media will be at risk.) Have a nice day :) Thomas
Git commit b189d1c39b52d5b646a089863eb8f44d3eeaa333 by Leslie Zhai. Committed on 27/09/2016 at 02:30. Pushed by lesliezhai into branch 'multisession'. Update multisession implementation as Thomas suggested Summary: - emit error infoMessage for checking nextSessionStart in setupMultiSessionParameters - nextTrack for bdr_plus_pow - lastSessionStart for bdr_plus_pow I am on vacation from Sep, 27 to Oct, 9 in small village, so I can *NOT* quick response. M +4 -0 libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp M +13 -4 libk3bdevice/k3bdevice.cpp http://commits.kde.org/k3b/b189d1c39b52d5b646a089863eb8f44d3eeaa333
Hi, > http://commits.kde.org/k3b/b189d1c39b52d5b646a089863eb8f44d3eeaa333 > libk3bdevice/k3bdevice.cpp: > emit infoMessage(i18n("Medium is not of multi-session type and does not > contain ISO 9660. Cannot emulate multi-session on it."), MessageError); To make this statement true, the list of overwritable media needs to be completed. K3B functions determineMultiSessionModeFromMedium() and setupMultiSessionParameters() have: if( info.mediaType() & (K3b::Device::MEDIA_DVD_PLUS_RW| K3b::Device::MEDIA_DVD_PLUS_RW_DL| K3b::Device::MEDIA_DVD_RW_OVWR| K3b::Device::MEDIA_BD_RE) ) { So setupMultiSessionParameters() will not look for ISO 9660 if the medium is MEDIA_DVD_RAM or MEDIA_BD_R_RRM. In this case the error message statement "does not contain ISO 9660" might be wrong. ------------------------------------------------------------------------ > libk3bdevice/k3bdevice.cpp Well, let's hope that we translated correctly from growisofs. (Everybody is invited to check.) What to do with growisofs_mmc.cpp : get_2k_capacity() which has special processing for BD-R POW ? It computes the remaining writable space on the medium. It seems that capacities computed in libk3bdevice/k3bdevice.cpp are about the overall capacity of the medium. Any idea where the writable space on medium is determined ? A tester could possibly tell, whether a BD-R with a first session written by growisofs shows any wrong numbers when inspected by K3B. ------------------------------------------------------------------------ Have a nice day :) Thomas
Git commit 15d3b05ce24a9158e120d4eaf0caadb0407fc0e7 by Leslie Zhai. Committed on 17/10/2016 at 04:31. Pushed by lesliezhai into branch 'multisession'. Complete mediaType as Thomas suggested. After KDE 20 years party (Oct 15), I have time to fix KDEBUG now ;-) Towards writable space on medium is determined, when there is *NO* space writable available, K3B will throw ERROR to user, so does not need to compute the remaing writable space? M +6 -2 libk3b/projects/datacd/k3bdatamultisessionparameterjob.cpp http://commits.kde.org/k3b/15d3b05ce24a9158e120d4eaf0caadb0407fc0e7
http://commits.kde.org/k3b/15d3b05ce24a9158e120d4eaf0caadb0407fc0e7 looks good to me. Now we'd need a tester who confirms that DVD-RAM can be used for multi-session like DVD+RW. (BD-R RRM might be hard to achieve and possibly were never tested with growisofs. But maybe somebody still has a DVD-RAM on the shelf.)
Hi Thomas, > Now we'd need a tester, BD-R RRM might be hard to achieve I will ask other KDE users to test it, and thank you so much for your help! you teach me a lot as a mentor patiently and carefully, it is trasure to me ;-) Regards, Leslie Zhai
In these commits, I see things like ,ms[0] == 0 or ms[1] != 0, where ms is a QStringList, so you are comparing a QString against 0. This doesn't look right. Either use isEmpty() or compare with the string "0", depending on what you actually meant.
(In reply to Kevin Kofler from comment #53) > In these commits, I see things like ,ms[0] == 0 or ms[1] != 0, where ms is a > QStringList, so you are comparing a QString against 0. This doesn't look > right. Either use isEmpty() or compare with the string "0", depending on > what you actually meant. Hi please review it https://github.com/KDE/k3b/blob/master/libk3b/projects/k3bgrowisofswriter.cpp#L201
*** Bug 373523 has been marked as a duplicate of this bug. ***
*** Bug 378157 has been marked as a duplicate of this bug. ***
*** Bug 386401 has been marked as a duplicate of this bug. ***
Hy Sorry people I don't have your level I am a simple user, I see a lot of talks but at the end it seems that you didn't yet find the solution :-( , I don't want to switch to another software, Please HELP
Hi, i don't think that bugs 378157 and 386401 are duplicates of 367639. 367639 (and 373523) is about a wrong growisofs option which was used by K3B because it was not aware of the special needs of BD-R media formatted to Pseudo-Overwrite. This is supposed to be fixed meanwhile. 378157 looks like a problem with the ISO 9660 producer program (mkisofs ?). 386401 looks like some inner problem of K3B. Maybe caused by the state of the medium. @Leslie: Can you separate 386401 from 367639 ? @sebastian: Please post the output of dvd+rw-mediainfo /dev/sr0 when the DVD+R is inserted. This should tell us the medium state. Have a nice day :) Thomas
Hi Thomas, Thanks a lot for your Multi-Session help :) @sebastian Please test as Thomas suggested, the simulator is not able to reproduce Multi-Session environment. Regards, Leslie Zhai