See Bug 137436 On start up k3b gives this message: Unable to find cdrskin executable K3b uses cdrskin in place of cdrecord. Solution: Install the libburn package which contains cdrskin Forcing unsuspecting users to use a development alternative to cdrecord which works fine for years.
> Forcing unsuspecting users to use a development alternative to cdrecord which works fine for years. Really? I argue that https://lists.debian.org/debian-devel-announce/2006/09/msg00002.html so please remove wodim (forked cdrecord) from cdrkit (CD only, DVD deprecated, unmaintained), website was down, release tarball is NOT available, svn repos is so quiet! But install cdrtools A.K.A cdrecord instead. http://www.leetcode.cn/2016/08/k3b.html#bug
(In reply to Leslie Zhai from comment #1) > > Forcing unsuspecting users to use a development alternative to cdrecord which works fine for years. > > Really? I argue that > https://lists.debian.org/debian-devel-announce/2006/09/msg00002.html so > please remove wodim (forked cdrecord) from cdrkit (CD only, DVD deprecated, > unmaintained), website was down, release tarball is NOT available, svn repos > is so quiet! But install cdrtools A.K.A cdrecord instead. > http://www.leetcode.cn/2016/08/k3b.html#bug We've had cdrtools a.k.a. cdrecord in openSUSE for a few years and had no problems, I can understand the problem with distributions that don't want to use schilly's program but it's well maintained and it works. openSUSE:Leap:42.3 is supposed to be a stable lts release and it appears that cdrskin is still in development. There should be a switch to disable this message for those who wish to use cdrecord. My question is will k3b still function as expected without cdrskin or do we have to require cdrskin? I don't see anything relating to cdrskin in CMakeLists,txt. See also https://bugzilla.suse.com/show_bug.cgi?id=1050715
Git commit 52a2493f77c1ed6cc77bdeb2dceb2afb51cda815 by Leslie Zhai. Committed on 27/07/2017 at 06:08. Pushed by lesliezhai into branch 'master'. Update problem's message about missing cdrskin at start up. Thomas Schmitt, the core developer of libburn, taught me to implement K3b::CdrskinWriter to fix BUG 137436, and Cristian Aravena Romero helped us to test cdrskin see BUG 380067 CCMAIL: scdbackup@gmx.net M +1 -1 src/k3bsystemproblemdialog.cpp https://commits.kde.org/k3b/52a2493f77c1ed6cc77bdeb2dceb2afb51cda815
> My question is will k3b still function as expected without cdrskin or do we have to require cdrskin?
Next question, which version of libburn/cdrskin is stable. Ironically I tried to submit the latest libburn to Leap:42.3 just before freeze last month and it wasn't considered necessary. I maintain multimedia and not kde so I didn't have a clue about this then.
Hi Dave, > My question is will k3b still function as expected without cdrskin or do we have to require cdrskin? I don't see anything relating to cdrskin in CMakeLists,txt. See also https://bugzilla.suse.com/show_bug.cgi?id=1050715 Sorry that I don't have the account to login SUSE's bugzilla, and not prefer to provide too much my personal information when registering, please help me to quote my comments for K3B's users, thanks! 1. I don't know the quality of cdrtools (AKA cdrecord), but we know cdrkit, dvd+rw-tools, libburnia, libisoburn and even Linux Kernel :) http://www.leetcode.cn/2016/11/analyzing-code-for-kde-qt-open-source-components.html 2. only Thomas Schmitt, the core developer of libburnia, taught me about ISO 9660 and MMC knowledage, helped me to fix BUG 367639 and more than that https://mail.kde.org/pipermail/k3b So I prefer to use cdrskin personally and K3B is still able to work without it, but just show the problem messages if the user choose other utilities and libraries which not maintained any more and deprecated. Regards, Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/
(In reply to davejplater@gmail.com from comment #5) > Next question, which version of libburn/cdrskin is stable. Ironically I > tried to submit the latest libburn to Leap:42.3 just before freeze last > month and it wasn't considered necessary. I maintain multimedia and not kde > so I didn't have a clue about this then. ping Thomas and Cc to him :)
Hi, the current upstream release of libburn and cdrskin is 1.4.6. Since then there were not many significant changes in the development version 1.4.7, which one can derive from git clone git@dev.lovelyhq.com:libburnia/libburn.git * Bug fix: Option -dummy did not affect writing by direct_write_amount= * Refusing to write to BD-R if formatted to Pseudo Overwrite The former does hardly affect K3B. The latter might be interesting for K3B, because libburn 1.4.6 tries to append sessions to growisofs burnt appendable BD-R media, but spoils them because growisofs formatted them to Pseudo-Overwrite state. libburn-1.4.8 will refuse to start writing on such media. K3B could detect that medium state MEDIA_BD_R_SRM_POW is present and refuse to let cdrskin write to such a medium. See https://www.mail-archive.com/kde-bugs-dist@kde.org/msg77288.html for code snippets which mention that state. Have a nice day :) Thomas
(In reply to Leslie Zhai from comment #6) > but just show the problem messages if the user choose other utilities > and libraries which not maintained any more and deprecated. But cdrecord is maintained and not deprecated. Maybe the message should be reworded to state that cdrskin is *optional*, and k3b will use it in place of cdrecord *if it is installed*. I.e. make it clear that burning will still be possible without cdrskin installed. One thing though: I tried to install cdrskin here. This removed the message on startup, but k3b (17.04.3) still seems to use cdrecord according to its output. Uninstalling cdrecord gave an error message on startup that it is missing and broke burning completely even with cdrskin installed (and it is detected in the settings dialog). So apparently cdrskin is not even used currently for some reason?
(In reply to Wolfgang Bauer from comment #9) > (In reply to Leslie Zhai from comment #6) > > but just show the problem messages if the user choose other utilities > > and libraries which not maintained any more and deprecated. > > But cdrecord is maintained and not deprecated. > > Maybe the message should be reworded to state that cdrskin is *optional*, > and k3b will use it in place of cdrecord *if it is installed*. I.e. make it > clear that burning will still be possible without cdrskin installed. > > One thing though: I tried to install cdrskin here. This removed the message > on startup, but k3b (17.04.3) still seems to use cdrecord according to its > output. > Uninstalling cdrecord gave an error message on startup that it is missing > and broke burning completely even with cdrskin installed (and it is detected > in the settings dialog). > > So apparently cdrskin is not even used currently for some reason? BUG 137436 but Cristian Aravena Romero helped us to test cdrskin see BUG 380067 and of course I can enable cdrskin as default writter to take place of cdrecord, or even totally disable it.
(In reply to Leslie Zhai from comment #10) > (In reply to Wolfgang Bauer from comment #9) > > (In reply to Leslie Zhai from comment #6) > > > but just show the problem messages if the user choose other utilities > > > and libraries which not maintained any more and deprecated. > > > > But cdrecord is maintained and not deprecated. > > > > Maybe the message should be reworded to state that cdrskin is *optional*, > > and k3b will use it in place of cdrecord *if it is installed*. I.e. make it > > clear that burning will still be possible without cdrskin installed. > > > > One thing though: I tried to install cdrskin here. This removed the message > > on startup, but k3b (17.04.3) still seems to use cdrecord according to its > > output. > > Uninstalling cdrecord gave an error message on startup that it is missing > > and broke burning completely even with cdrskin installed (and it is detected > > in the settings dialog). > > > > So apparently cdrskin is not even used currently for some reason? > > BUG 137436 > > but Cristian Aravena Romero helped us to test cdrskin see BUG 380067 > > and of course I can enable cdrskin as default writter to take place of > cdrecord, or even totally disable it. disable cdrecord, but if the user prefer to use it, please though command line, not k3b, thanks!
(In reply to Leslie Zhai from comment #11) > > and of course I can enable cdrskin as default writter to take place of > > cdrecord, or even totally disable it. > > disable cdrecord, Of course you can, but that's not the case at the moment. Does that mean you plan to do that in the near future? But as I wrote, cdrskin doesn't seem to be used at all currently here. So currently the message seems bogus anyway to me. Or am I misunderstanding something? (e.g. is it only used for DVDs/BDs? I only tested CDs) > but if the user prefer to use it, please though command > line, not k3b, thanks! And why? It works (since years), it is maintained upstream. And actually it seems to be used by k3b here even with cdrskin installed.
(In reply to Wolfgang Bauer from comment #12) > (In reply to Leslie Zhai from comment #11) > > > and of course I can enable cdrskin as default writter to take place of > > > cdrecord, or even totally disable it. > > > > disable cdrecord, > > Of course you can, but that's not the case at the moment. > Does that mean you plan to do that in the near future? when cdrskin and related utilities are able to cover all user cases https://bugs.kde.org/show_bug.cgi?id=137436#c20 > > But as I wrote, cdrskin doesn't seem to be used at all currently here. > So currently the message seems bogus anyway to me. > > Or am I misunderstanding something? (e.g. is it only used for DVDs/BDs? I > only tested CDs) > > > but if the user prefer to use it, please though command > > line, not k3b, thanks! > > And why? the good compiler is depends on tons of source code tuning, and cdrskin also need more users to use and test :) > It works (since years), it is maintained upstream. And actually it seems to > be used by k3b here even with cdrskin installed. it is easy to use clang analyzer, sanitizer, libfuzzer, or commercial utilities to analysis cdrecord source code http://www.leetcode.cn/2016/11/analyzing-code-for-kde-qt-open-source-components.html and welcome benchmark.
Just to shed a bit of light. openSUSE worked with Jörg Schilling to have cdrecord/cdrtools in the distribution in 2013 due to numerous bugs with wodim/cdrkit-cdrtools-compat particularly with k3b. It has been a part of the distribution since 13.2 2013-12-04 and has performed very well since then but it has been installed from alternate repositories many years prior due to wodim problems. @Leslie Zhai you can understand our concerns about changing something that is proven for something that is new.
Hi, just as technical background info: libburn underneath cdrskin is well tested since 10 years. It supports CD data and CD audio, but not the more exotic CD sector formats, simply because i lack of any test user or test case for those CD sectors. With DVD and BD media, it can compete with growisofs, which is preferred by K3B over cdrecord for a reason. A main advantage for users is that libburn can disable Defect Management on BD-RE media. This makes burning as fast as the nominal speed of the medium (i.e. 2x rather than 0.9x) and it keeps media usable which Defect Management would swamp with replacement blocks although the original blocks are still good enough. Like cdrecord it does not format BD-R by default, thus yielding full speed on BD-R media. I provide support for libburn (and growisofs if necessary). Its bug list at least on Debian is clean. If SuSE has open bugs, please forward them to pkg-libburnia-devel@lists.alioth.debian.org. Elsewise, everybody should be free to choose the burn backend which one likes most. No need to quarrel. Have a nice day :) Thomas
(In reply to davejplater@gmail.com from comment #14) > Just to shed a bit of light. openSUSE worked with Jörg Schilling to have > cdrecord/cdrtools in the distribution in 2013 due to numerous bugs with > wodim/cdrkit-cdrtools-compat particularly with k3b. It has been a part of > the distribution since 13.2 2013-12-04 and has performed very well since > then but it has been installed from alternate repositories many years prior > due to wodim problems. > @Leslie Zhai you can understand our concerns about changing something that > is proven for something that is new. Disabled check system config by default https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp#L723
Just to be clear here: It is not my intention to "quarrel" over whether k3b should use cdrskin or cdrecord. Actually I don't mind personally (openSUSE does have both), as long as it works (and to avoid a possible misunderstanding: I have no reason to believe nor do I want to suggest that cdrskin does not work). Although I don't see a good reason to drop support for cdrecord either. Keep both and prefer cdrskin if you want, I'd say... ;-) I just wanted to note that I find the message a bit misleading, as long as cdrecord is supported. Also I'd like to repeat that according to my tests, cdrecord is actually *mandatory* and cdrskin is not even used if it's installed, contrary to the message. (for CDs at least, I don't have a DVD or BD burner to try) (In reply to Leslie Zhai from comment #16) > Disabled check system config by default > https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp#L723 Not really. As I understand the code, the line before explicitly sets it to true on first start (or whenever k3b is updated to a new version). Also, that would affect the whole system problems dialog, not just the cdrskin message. I'm not sure it's a good idea to disable that by default (especially now that the "do not show again" option works again... ;-) ).
Hi, In https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp it should not be recorded as CRITICAL if only one of cdrecord or cdrskin is not usable. A quick solution would be to report the messages preliminarily as NON_CRITICAL and to check at the end of the burn program tests whether both are missing. If so, one would issue a CRITICAL message saying that no CD burn program for cdrecord compatible options was found. --------------------------------------------------------------------- In general the relation of the burn programs is wrongly represented in this piece of code. The programs overlap with their capabilites. If you just want to burn a DVD-R with write type DAO, then growisofs, cdrecord, and cdrskin are all three valid candidates for that. If you want to burn CD XA or fast BD-RE multi-session, then two of the three are not suitable. So the severity evaluation should be delayed until it is clear how many of the burn programs are available, and which tasks they can cover. Consider something like this (properly adapted to K3B idiom, of course): struct burn_candidate { char *name; char *path; char *purpose; char *remarks[8]; /* Problems, restrictions, or reasons for being unusable */ int permission_problem; int does_not_exist; int is_outdated; int too_much_root; int not_enough_root; int would_need_atapi; ... maybe more ... /* Program capabilities */ int does_cd_data; int does_cd_audio; int does_cd_other; int does_cd_multi_session; int does_cd_by_options; int does_cd_by_cue; int does_dvd; int does_dvd_multi_session; int does_bd; int does_bd_multi_session; int does_overwritable_multi_session; int does_fast_bdre; ... maybe more ... }; There would be an array of them with an element for each program that may be used. The tests would assess the problems and capabilities but not yet call problems.append(). They would rather record the parameters needed for the messages. When all assessment is done, one would next look which programs are actually usable and which capabilities are covered by them. If an important capapability is not covered by a usable program, then this is should be reported as CRITICAL. Further one could at this point choose the default programs for the various tasks which demand the covered capabilities. (Another burn backend K3B could encounter is "xorrecord", which is the cdrecord options emulation of xorriso. CD, DVD, BD. Data only. No audio. Based on libburn like cdrskin.) --------------------------------------------------------------------- Before declaring a capability to be covered, the programmer will have to verify that K3B can actually use that program for that task. I.e. is K3B prepared to produce the necessary options ? Can the program really do what the options demand ? So, this proposal would cause substantial work and review of the existing K3B code that controls the backend runs. Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #18) > Hi, > > In > https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp > it should not be recorded as CRITICAL if only one of cdrecord or cdrskin > is not usable. > > A quick solution would be to report the messages preliminarily as > NON_CRITICAL and to check at the end of the burn program tests whether > both are missing. > If so, one would issue a CRITICAL message saying that no CD burn program > for cdrecord compatible options was found. > > --------------------------------------------------------------------- > > In general the relation of the burn programs is wrongly represented in > this piece of code. > > The programs overlap with their capabilites. If you just want to burn > a DVD-R with write type DAO, then growisofs, cdrecord, and cdrskin are > all three valid candidates for that. > If you want to burn CD XA or fast BD-RE multi-session, then two of > the three are not suitable. > > So the severity evaluation should be delayed until it is clear how many of > the burn programs are available, and which tasks they can cover. > > Consider something like this (properly adapted to K3B idiom, of course): > > struct burn_candidate { > char *name; > char *path; > char *purpose; > char *remarks[8]; > > /* Problems, restrictions, or reasons for being unusable */ > int permission_problem; > int does_not_exist; > int is_outdated; > int too_much_root; > int not_enough_root; > int would_need_atapi; > ... maybe more ... > > /* Program capabilities */ > int does_cd_data; > int does_cd_audio; > int does_cd_other; > int does_cd_multi_session; > int does_cd_by_options; > int does_cd_by_cue; > int does_dvd; > int does_dvd_multi_session; > int does_bd; > int does_bd_multi_session; > int does_overwritable_multi_session; > int does_fast_bdre; > ... maybe more ... > }; very good suggestion! k3b use too simple `QStringList` https://github.com/KDE/k3b/blob/master/libk3b/core/k3bexternalbinmanager.cpp#L64 1. addFeature, for example: https://github.com/KDE/k3b/blob/master/libk3b/core/k3bdefaultexternalprograms.cpp#L551 2. hasFeature, for example: https://github.com/KDE/k3b/blob/master/libk3b/projects/k3bcdrskinwriter.cpp#L216 it needs more detailed feature checker for cdrecord, growisofs, cdrdao and other K3bConcreteWriter. > > There would be an array of them with an element for each program that > may be used. > The tests would assess the problems and capabilities but not yet call > problems.append(). > They would rather record the parameters needed for the messages. > > When all assessment is done, one would next look which programs are > actually usable and which capabilities are covered by them. > > If an important capapability is not covered by a usable program, > then this is should be reported as CRITICAL. > Further one could at this point choose the default programs for the > various tasks which demand the covered capabilities. > > (Another burn backend K3B could encounter is "xorrecord", which is the > cdrecord options emulation of xorriso. CD, DVD, BD. Data only. No audio. > Based on libburn like cdrskin.) > > --------------------------------------------------------------------- > > Before declaring a capability to be covered, the programmer will have > to verify that K3B can actually use that program for that task. > I.e. is K3B prepared to produce the necessary options ? > Can the program really do what the options demand ? > > So, this proposal would cause substantial work and review of the > existing K3B code that controls the backend runs. yes, k3b will emit infoMessage about MessageError when be lack of some feature during the prepareProcess before the actual burning job, for example: https://github.com/KDE/k3b/blob/master/libk3b/projects/k3bcdrskinwriter.cpp#L245 and it is better to provide detailed checkSystem at startup, so users might install missing packages if desire some features, thoughts? > > > Have a nice day :) > > Thomas
Hi, Leslie Zhai wrote: > it needs more detailed feature checker for cdrecord, growisofs, cdrdao > and other K3bConcreteWriter. > [...] > it is better to provide detailed checkSystem at startup, so users might > install missing packages if desire some features, thoughts? If i may think big, then i imagine two checks: One at program start to verify that a roughly sufficient set of burn backends is available. The second check would be made late when all needs of the K3B task are determined. It could choose a burn program which matches those needs. Refining my rough struct sketch, i would create a class that represents the program capabilities and the task needs. Probably with an array and named indice instead of single "does_some_thing" integers. #define DOES_NEEDS_BYTES 2 #define DOES_NEEDS_CD_DATA 0 ... #define DOES_NEEDS_FAST_BDRE 11 unint_8 capabilities_or_needs[DOES_NEEDS_BYTES]; A capability (e.g. DOES_NEEDS_FAST_BDRE) would be marked by value 1 in (capabilities_or_needs[DOES_NEEDS_FAST_BDRE / 8] >> (DOES_NEEDS_FAST_BDRE % 8)) & 1 Both the drive examinations and the task preparation would fill out such class instances. The arrays of capabilities_or_needs[] would be compared by logical AND operations. If the result is the same as the needs array, then the program is fully suitable for the task. If the result has less bits than the needs array, then some capabilities are missing. In this case another burn program would have to be chosen, or the task would have to be refused (with hints how to get it doable). Above bit array would work well if all capabilities are yes/no decisions. If we expect to get more possible values for a single capability, then one should rather use a byte or integer array: #define DOES_NEEDS_BYTES 12 #define DOES_NEEDS_CD_DATA 0 ... #define DOES_NEEDS_FAST_BDRE 11 unint_8 capabilities_or_needs[DOES_NEEDS_BYTES]; Here the macros are not but indice but rather byte indice: capabilities_or_needs[DOES_NEEDS_FAST_BDRE] Comparison would not be done by AND but rather by "==" comparison of the single array bytes. The DOES_NEEDS class would then become a member of a BURN_PROG_ASSESS class which contains the rest of information from my sketched struct burn_candidate: name, permission_problem, ... The early burn program assessment would fill out BURN_PROG_ASSESS class instances and record them for use with the later check for task needs. It would already warn if some generally important capabilities are not covered by the detected burn programs. The K3B task preparation would fill out a DOES_NEEDS instance and submit it for comparison with those registered BURN_PROG_ASSESS instances, which have no fatal problems. This comparison would yield a list of suitable BURN_PROG_ASSESS instances among which K3B or its user may chose for that particular task. ------------------------------------------------------------------------ But before working on that big structural change, i would first roughly fix the check for cdrecord and cdrskin, so that they are considered as alternatives for the main use cases of audio and data burn runs. Further i would examine the report that cdrskin is not used when it should. As Wolfgang Bauer wrote: > cdrecord is actually *mandatory* and cdrskin is not even used if it's > installed, contrary to the message. And this bug report should be made open again. Currently it says "Status: RESOLVED FIXED" which seems not to be true yet. Have a nice day :) Thomas
Git commit 4a6aa76ea4d80dfdf530921d54060fac3647c9ac by Leslie Zhai. Committed on 03/08/2017 at 08:38. Pushed by lesliezhai into branch 'master'. Prepare for big structural change. M +2 -2 src/k3bsystemproblemdialog.cpp https://commits.kde.org/k3b/4a6aa76ea4d80dfdf530921d54060fac3647c9ac
Hi, > https://cgit.kde.org/k3b.git/commit/?id=4a6aa76ea4d80dfdf530921d54060fac3647c9ac The commit message is quite misleading. I already thought you'd go full speed ahead without investigating the existing tasks of K3B whether they can be represented in the way of my idea. (I'd expect hours of code digging before this is clear.) --------------------------------------------------------------------- For the non-quarrel aspect, which we always have to consider: It seems unwise to say to the user that cdrskin is "better" than cdrecord. Joerg Schilling could raise protest and it would be not easy to defeat any possible point he could make. I was once his user. Since a few years he has to accept me as peer - reluctantly. (German language readers may look at https://forum.ubuntuusers.de/topic/k3b-brennt-keine-audio-cd-2/2/ where we quite nearly cooperated to find the reason why Xfburn worked and K3B did not. It was an interesting ride.) So how about (after due check whether it is really true in the context of K3B): "Cdrskin can substitute for cdrecord with data and audio CD, and for growisofs with DVD and BD." "Consider to install the libburn and cdrskin packages." --------------------------------------------------------------------- Further, the test for cdrecord and the test for cdrskin should both set a local flag which indicates that a program with cdrecord's mainstream options interface is available. The tests for cdrecord should then preliminarily report their problems as NON_CRITICAL. If the new local flag is not set after the burn program tests, then K3B should issue a CRITICAL message which tells that neither cdrecord nor cdrskin are available for use by K3B. --------------------------------------------------------------------- A similar situation lurks between growisofs and cdrskin. The lack of growisofs should only be CRITICAl if not cdrskin can substitute by its cdrecord-ish options interface. cdrskin can substitute if it is available and if K3B is ready to use it on DVD and BD by cdrecord-ish options. cdrskin by modes of its option "blank=" can perform the tasks of "dvd+rw-format": Formatting of DVD-RW, DVD+RW, DVD-RAM, BD-R, BD-RE. Deformatting of DVD-RW. But that would first have to be implemented in K3B, before availability of cdrskin could make the lack of dvd+rw-format NON_CRITICAL. (See man cdrskin or ask me for translating dvd+rw-format options to cdrskin blank modes.) Have a nice day :) Thomas
Git commit a3b8df01582085729d36f4a068e8f592179f95db by Leslie Zhai. Committed on 04/08/2017 at 01:18. Pushed by lesliezhai into branch 'master'. Fix complains about missing cdrskin at start up before big structural change. M +3 -2 src/k3bsystemproblemdialog.cpp https://commits.kde.org/k3b/a3b8df01582085729d36f4a068e8f592179f95db
*** Bug 385305 has been marked as a duplicate of this bug. ***
*** Bug 389423 has been marked as a duplicate of this bug. ***
This bug has disappeared with time