Version 17.04.0 When choosing importing previous session and choosing that session, K3b does nothing, that means, files from previous session aren't present in the project view, the project view is still empty.
Appendix: This is the newest version of K3b (17.04.0), compiled by me.
Hi Lukasz, Thanks for your report! I think it is easy to reproduce and fix! Regards, Leslie Zhai
Hi Łukasz, I can not reproduce the bug, my operation process: File -> New Project -> New Data Project -> then drag some folders to the K3b data project -> Save -> close K3B File -> Open Recent -> choose your saved project -> successfully loaded the saved project. My question is how to import previous session? can you explain your operation? and I do not have REAL DVD to test multisession https://bugs.kde.org/show_bug.cgi?id=367639 but only use simulator CDEmu instead http://www.leetcode.cn/2016/08/k3b.html#test Regards, Leslie Zhai
(In reply to Leslie Zhai from comment #3) > Hi Łukasz, > > I can not reproduce the bug, my operation process: > File -> New Project -> New Data Project -> then drag some folders to the K3b > data project -> Save -> close K3B > > File -> Open Recent -> choose your saved project -> successfully loaded the > saved project. > > My question is how to import previous session? can you explain your > operation? and I do not have REAL DVD to test multisession > https://bugs.kde.org/show_bug.cgi?id=367639 but only use simulator CDEmu > instead http://www.leetcode.cn/2016/08/k3b.html#test > > Regards, > Leslie Zhai Hi Leslie. You are talking about opening saved project in K3b. But problem isn't here. The problem is with multisession DVDs. So what do I do? There are two variants. First variant. 1) Insert partially written multisession DVD to the drive. 2) More actions... -> Continue Multisession Project It does nothing. Really. No changes in the user interface. That means: the project view in the bottom of the window doesn't appear. Nothing happens. Second variant. 1) Insert partially written multisession DVD to the drive. 2) Click "New Data Project". 3) Click "Import Session". 4) Choose the most recent session of the available in the mini window. It does nothing. Files from imported session aren't present in the left side of the project view in the bottom of the window. Nothing happens. Of course you can add some files, but files from previous session aren't present here. The problem is grave. If user assumes, that K3b does import session, but only interface is broken, the user will append new files to the partially written DVD and destroy her/his data from previous session. She/He then will not be able to read them. Only new data will appear in the file manager. Regards. Łukasz Konieczny
(In reply to Leslie Zhai from comment #3) Leslie, I have forgotten to add third point to the first variant. Here it is: 3) Choose the most recent session of the available in the mini window. Some thoughts about K3b from me. I have read about K3b not being able to properly append data to multisession DVDs and CDs, and Blu-Rays, and I have experienced this bug myself. I have read, that this bug has been fixed in the 17.04.0, but now I see, that a new bug, which I report, appeared in the program. K3b is one of the most important free software project. If someone want to do serious job with burning DVDs, neither Brasero nor Xfburn nor other software can meet their needs. Please, make K3b able to properly handle appending data to DVDs with many sessions and able to import sessions written to disc. K3b is mission critical for the GNU/Linux users.
Hi Łukasz, Thanks for your detailed report! I have to work harder to fix multisession related bugs! I do not have REAL DVD to test multisession and the simulator CDEmu does not support multisession, so please attach the screenshots reproduced the bug, the UIs are better in English, then I can grep them -r in the src. Sorry for my poor test environment but we will fix it! Regards, Leslie Zhai
Created attachment 105263 [details] Info about the disc (1)
Created attachment 105264 [details] Info about the disc (2)
Created attachment 105265 [details] Continuing multisession
Created attachment 105266 [details] Importing session
Created attachment 105267 [details] First variant ends - nothing happened
Created attachment 105268 [details] New data project
Created attachment 105269 [details] Import session button
Created attachment 105270 [details] Importing session (2)
Created attachment 105271 [details] Second variant ends - nothing happened
Created attachment 105272 [details] Files on the DVD disc, which should appear in the project view after importing session
Created attachment 105273 [details] Output from terminal during K3b run
Very clear! I will check Import Session Dialog related src!
Hi, The payload looks like videos. Would K3B recognize this fact and write the initial session as ISO 9660 / UDF hybrid filesystem ? Afaik, mkisofs is not able to do multi-session on UDF. One could tell by this shell command file /dev/sr0 which would report among others "UDF" and not only "ISO 9660". > I have read about K3b not being able to properly append data to > multisession DVDs Afaik this was only on pseudo-overwritable Blu-rays because K3B did not predict correctly the address computations of growisofs. https://bugs.kde.org/show_bug.cgi?id=367639#c44 Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #19) > Hi, > > The payload looks like videos. Would K3B recognize this fact and write > the initial session as ISO 9660 / UDF hybrid filesystem ? > Afaik, mkisofs is not able to do multi-session on UDF. I always choose pure UDF from the list of options. So this disc is formatted in UDF. > > One could tell by this shell command > > file /dev/sr0 > > which would report among others "UDF" and not only "ISO 9660". > $ file -s /dev/sr0 /dev/sr0: UDF filesystem data (version 1.5) 'Filmy 5' > > > I have read about K3b not being able to properly append data to > > multisession DVDs > > Afaik this was only on pseudo-overwritable Blu-rays because K3B did > not predict correctly the address computations of growisofs. > https://bugs.kde.org/show_bug.cgi?id=367639#c44 I had this problem on DVDs too. The problem was that imported directories from previous session had size of 0 B. After burning new files, all files from previous session had size of 0 B. One could see that in Dolphin. > > Have a nice day :) > > Thomas
Hi, > I always choose pure UDF from the list of options. Now that's a starting point for Leslie's investigations. Does K3B, when importing a session, take into respect that it is UDF and does this have consequences for its further preparations of the mkisofs run ? My local genisoimage program happily appends an UDF session to an UDF filesystem on an appendable sequential DVD-RW. But afterwards the added files are not visible when the medium gets mounted. Obviously my Linux 3.16 mounts session 1. If i force it to load the newly added session: mount -o sbsector=119344 /dev/sr3 /mnt/iso i get mount: wrong fs type, bad option, bad superblock on /dev/sr3, Nevertheless if xorriso loads the second session via the ISO 9660 tree, then it sees all files from both sessions. The same positive result can be seen if i force Linux to use ISO 9660: mount -t iso9660 -o sbsector=119344 /dev/sr3 /mnt/iso So we can conclude that at least older mkisofs spoils UDF on multi-session. Possibly K3B is aware of this and refrains without a clear error message. > > https://bugs.kde.org/show_bug.cgi?id=367639#c44 > I had this problem on DVDs too. I guess this was a different one. The symptom of 367639 was this error message: /usr/bin/growisofs: -C argument is insane. which we after some forth and back identified as caused by a deviation between K3B and growisofs when it came to the prediction of the Next Writable Address of the medium. > After burning new files, all files from > previous session had size of 0 B. One could see that in Dolphin. Looks like a another bug. Number three in our local counting. The file size in the result is hardly influencable by K3B. This is in the responsibility of the ISO 9660 or UDF producer program. Normally mkisofs or genisoimage. Have a nice day :) Thomas
Hi, this search in the K3B code https://github.com/KDE/k3b/search?utf8=%E2%9C%93&q=udf&type= does not yield any suspect for special treatment of UDF add-on sessions in K3B. So it becomes more probable that K3B lets mkisofs or genisoimage load the old session and add the files, but that subsequent readers get pointed to the first UDF session rather than the last session (as is sual with ISO 9660 on most operating systems). Tests for this theory: - Does dvd+rw-mediainfo report more than one session on your DVD+R ? (I.e. did K3B write a new session at all.) - Do you see the files of both sessions if you force Linux mount to use the ISO 9660 aspect of the medium ? mkdir /mnt/iso (To be later unmounted by umount /dev/sr0 ) Have a nice day :) Thomas
Hi, by copy+paste i crippled my last post. "as is sual" should have been "as is usual". The second test for my theory should of course contain a mount command: - Do you see the files of both sessions if you force Linux mount to use the ISO 9660 aspect of the medium ? mkdir /mnt/iso mount -t iso9660 /dev/sr0 /mnt/iso find /mnt/iso | less (To be later unmounted by umount /dev/sr0 ) Have a nice day :) Thomas
Created attachment 105284 [details] dvd+rw-mediainfo output of the disc with one session This shows output of disc on which I have written only one session (disc is appendable).
Created attachment 105285 [details] dvd+rw-mediainfo output of the disc with two sessions This shows output from dvd+rw-mediainfo about disc, on which I have written two sessions. When I mount this UDF disc, files from first session have size of 0 (zero) bytes, only files from second session are readable.
(In reply to Thomas Schmitt from comment #22) > - Do you see the files of both sessions if you force Linux mount to use > the ISO 9660 aspect of the medium ? > > mkdir /mnt/iso > > (To be later unmounted by > umount /dev/sr0 > ) > Yes, when I mount UDF disc on which K3b has written two session, now files of all sessions have appropriate size and are readable.
Hi, K3B indeed wrote the second session: READ TRACK INFORMATION[#2]: Track State: complete incremental Track Start Address: 1991984*2KB Free Blocks: 0*2KB Track Size: 175104*2KB Last Recorded Address: 2167087*2KB The allocated block range was completely written: 1991984 + 175104 = 2167088. So all looks well from the view of the medium. > > - Do you see the files of both sessions if you force Linux mount to use > > the ISO 9660 aspect of the medium ? > Yes, when I mount UDF disc on which K3b has written two session, > now files of all sessions have appropriate size and are readable. Just to be sure because this is crucial for the following diagnosis: You see all files with mount -t iso9660. You see the files of session 1 crippled if mounted without -t or with -t udf. Right ? In this case it is not the fault of K3B but rather of genisoimage. (At least genisoimage is in charge if you did not install cdrtools by Joerg Schilling which is not provided by Debian since 2006.) UDF offers its own appendability features. Obviously genisoimage does not make proper use of them. They would not easily be compatible with ISO 9660 and its multi-session method, which is the main topic of genisoimage. But obviously your kernel and my kernel react in a different way. Mine mounts session 1 and thus misses the newer files. Yours seems to mount session 2 but fails to make the connection from directory tree to the older file content. (So bug two and three in our preliminary counting are only one bug: genisoimage does not properly combine multi-session and UDF.) I myself studied ECMA-167 and UDF-2.60, concluded that it is darn complicated and offers no features which ISO 9660 + Rock Ridge couldn't easily provide, and thus decided to snub it in libisofs development. It's only good for video players which cannot play anything but UDF 1.02. This imposes a problem with DVD video and appendability anyways: https://en.wikipedia.org/wiki/Universal_Disk_Format states that video players expect UDF 1.02 whereas the VAT tables for appendabilty were added only in version 1.5. So even if you find a program that does UDF VAT it might be that your video player does not understand it. (And if you do not have a player which needs UDF, why have mkisofs style UDF at all ?) Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #27) > > > > - Do you see the files of both sessions if you force Linux mount to use > > > the ISO 9660 aspect of the medium ? > > > Yes, when I mount UDF disc on which K3b has written two session, > > now files of all sessions have appropriate size and are readable. > > Just to be sure because this is crucial for the following diagnosis: > You see all files with mount -t iso9660. You see the files of session 1 > crippled if mounted without -t or with -t udf. Right ? I don't see files from first session at all when mount with -t udf. I see them crippled when KDE automounts this disc. I see them properly with -t iso9660, despite the filesystem is UDF. Regards. Łukasz
So we have two problems now: 1) Problem with interface, about which I have been talking with Leslie. 2) Problem with UDF multisession discs.
Hi, Łukasz wrote: > I don't see files from first session at all when mount with -t udf. Aha. That's like with my kernel if i mount with -t udf, or no -t at all. > I see them crippled when KDE automounts this disc. I wonder what mount options it uses at this occasion. (Is the filesystem then reachable by other programs or does only K3B show it ? Maybe it is not mounted but K3B rather has an own UDF reader.) > I see them properly with -t iso9660, despite the filesystem is UDF. That's because UDF specifies that an ISO 9660 superblock and directory tree shall be present for backwards compatibility. The tree is allowed to be empty, which would constitue a "pure" UDF filesystem. But genisoimage is an ISO 9660 producer with just enough UDF to please the DVD video players. So it produces ISO 9660 with UDF add-on just like Joliet as add-on for Windows of HFS as add-on for old Macs. ISO 9660 and its Rock Ridge enhancements are the main palyers. Leslie wrote: > 1) Problem with interface, about which I have been talking with Leslie. I understand from comments 3 and 4 that you did not discuss the same user interface part. You tested a saved but not yet burned project whereas Łukasz has problems with adding a new session to an already burned DVD+R. I can reproduce at leat the behavior which Łukasz experiences with mount -t udf. In my case by using genisoimage and xorrecord on unformatted DVD-RW. In the case of Łukasz and K3B' by genisoimage and growisofs on DVD+R. The decisive point is the output of genisoimage and its perception by Linux and/or K3B (if it reads UDF by own means). > 2) Problem with UDF multisession discs. If one cannot demonstrate a set of mkisofs options to make UDF and multi-session fully compatible, K3B should refuse to add any session to an UDF filesystem or an UDF session to any filesystem. If such options are found (against my expectation) then one should teach K3B to use them. Looking at our old construction site bug 367639 where we explored the multi-session stuff quite in vain, i'd say that d->multiSessionParameterJob->nextSessionStart() in libk3b/projects/datacd/k3bdatajob.cpp would be a good indicator for an add-on session. UDF would be ok only if nextSessionStart is 0. The plan to create the add-on session with UDF is recognizable by the return value "true" of createUdf() as of libk3b/projects/datacd/k3bisooptions.h I have no idea how to ask K3B whether the loaded session was UDF. K3B should not add an ISO 9660 session because Linux will prefer UDF over ISO 9660 when mounting without -t. Have a nice day :) Thomas
Hi, i just misattributed Łukasz's recent problem list to Leslie. Sorry for that. Well, user interface of K3B isn't my turf anyway. Nobody shall take me serious on that topic. Nevertheless my proposal to Leslie for precautionary refusal on UDF multi-session stands ... for now. Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #30) > > I see them crippled when KDE automounts this disc. > > I wonder what mount options it uses at this occasion. Perhaps -t udf -o nostrict. When I mounted with this option, it behaved exactly like when KDE mounts the disc.
(In reply to Thomas Schmitt from comment #31) I have created a new DVD by writing the first session, but I have chosen "Linux/Unix + Windows" instead of UDF. Then I have written the second session and it works. All files are visible and readable. Attention: I have done that on K3b 2.0.3, not on the newest 17.04.0 version. The newest version has problems with interface, about which this bug is.
Hi Thomas, You are my mentor forever :) yes, I will check k3b frontend at first, I am not good at backends, just like not deep into the internals of llvm's backend neither https://reviews.llvm.org/p/xiangzhai/ I am a newbie in many fields, so please point out my fault if I made any mistakes! and I prefer to use libburnia backend if others fail to work. I use my phone to reply, I will debug frontend in May 2th, Happy international Labor Day :) Regards, Leslie Zhai
Hi Łukasz, Very clear! It must be the frontend issue, I will fix it! Regrads, Leslie Zhai
Hi, > > I wonder what mount options it uses at this occasion. > Perhaps -t udf -o nostrict. Indeed. This option must cause the second session to be mounted. When i make the first session without Rock Ridge (no option -R), the older files are not only shown with 0 bytes but also with their truncated ISO 9660 upper case names and not the UDF names with full length and case distinction. This looks as if the loaded file information propagates from the ISO 9660 tree to the UDF tree. I.e. the first UDF session is not loaded. Why the size gets set to 0 is a matter of genisoimage entrails. I guess this is where it gets copied from internal tree model to UDF model: https://sources.debian.net/src/cdrkit/9:1.1.11-3/genisoimage/udf.c/#L919 Question is why directory_entry.realsize is not set to the size of the file in the loaded ISO tree. It seems to get set for data files only in https://sources.debian.net/src/cdrkit/9:1.1.11-3/genisoimage/tree.c/#L1931 which exploits info obtained by function stat_filter() in https://sources.debian.net/src/cdrkit/9:1.1.11-3/genisoimage/tree.c/#L232 which uses local disk filesystem function stat(2). So this cannot be the case of loaded ISO tree but rather of newly added files from the local fileystem. So obviously the directory_entry.realsize seen by the UDF writer is not set to the size of the file as loaded with the ISO session info. Other writers seem not use .realsize at all. In order to see what happens i preliminarily insert (*pnt)->realsize = (*pnt)->size; after (*pnt)->size = isonum_733((unsigned char *) idr->size); in https://sources.debian.net/src/cdrkit/9:1.1.11-3/genisoimage/multi.c/#L664 Compilation is hampered by lack of gmake and other bitrot. Since /usr/bin/make is GNU make, it is safe to do ln -s make /usr/bin/gmake Despite wodim still fails to build i get a working genisoimage. Yep. Old files get sizes that way. A few diff comparisons between original and copy look ok. I mounted the medium explicitely -t udf. But even if this now really works, it would not be sufficient as permanent solution because one needs to sum up the extent sizes of a file. More than one extent usually happens only if a file is of size 4 GiB or larger. The first step of a solid solution is to find a maintainer for genisoimage. Urm. As faithful Debian users we should be normally loyal to the maintainers' decision of 2006 to permanently ban mkisofs. Nevertheless you could try an original mkisofs that's 10 years more advanced and maybe has the problem fixed meanwhile. If not fixed yet, it could become a very interesting time to have Joerg Schilling here and to discuss my findings. (I thought i had newer cdrtools but a find run on the whole disk reveiled only 2.01.01a77, which is nearly as outdated as genisoimage.) I guess this is the current release: https://sourceforge.net/projects/cdrtools/files/cdrtools-3.01.tar.gz/download Well, if it works then i have to modify my opinion that K3B should refuse on multi-session on UDF. It should probably rather warn and best should try to find out whether it works with a fixed mkisofs. Have a nice day :) Thomas
Hi Thomas, Excellent analysis! Clang analyzer, sanitizer could not help to fix such logical issue :) I must read your investigation carefully! Regards, Leslie Zhai
Hi, Leslie (this time really) wrote: > You are my mentor forever :) I'm always interested in new adventures around optical media. > I must read your investigation carefully! Well, this time the road was less winded. It's a lapse in genisoimage file multi.c combined with an optimistic expectation in udf.c. My remedy is a proof-of-concept suitable for files up to 4 GiB minus 1 byte. I would help a maintainer of genisoimage to fix it, but will not take over the maintainer job myself. (Same with growisofs.) > Clang analyzer, sanitizer Although it is worthwhile to check complaints from such tools, one has to be aware that about 1 of 100 warnings is actually misunderstanding a not-so-obvious necessity in the code. A few years ago i shot my own foot when fixing a bunch of Coverity warnings. Have a nice day :) Thomas
Hi, i finally found my copy of cdrtools-3.02a05.tar.gz and had a look into mkisofs/multi.c and mkisofs/udf.c. There is no member "realsize" in struct directory_entry. In udf.c the member "size" is used instead of "realsize". This does not look much smarter than my test hack. Whether this is the right thing to do with files of 4 GiB or larger will have to be tested. (It could well be that the state of genisoimage is a clumsy attempt to fix a bug with such large files.) At least it seems worth a try. Have a nice day :) Thomas
Hi, i tested my hack with a large file in the first session. genisoimage refuses to create a suitable test situation. mkisofs works even in old version 2.01.01. genisoimage cannot do multi-session with files of 4 GiB or larger, because it does not understand option -iso-level 3 as permission to write such files as multiple directory records of the same name. It works only with option -allow-limited-size which already in the first session spoils the size of the file in the ISO 9660 tree. Since the UDF tree of the second session is based on the loaded ISO 9660 tree of the first session, the spoiled size gets into the UDF tree. My test: # Make dummy file larger than 4 GB dd if=/dev/zero bs=1M count=1 seek=4096 of=file_of_4gb+1m # Use my hacked genisoimage or old mkisofs # mkisofs=/.../cdrkit-1.1.10/build/genisoimage/genisoimage # limit_size="-iso-level 3 -allow-limited-size" mkisofs=/.../cdrtools-2.01.01a64/mkisofs/OBJ/x86_64-linux-cc/mkisofs limit_size="-iso-level 3" # Blank the DVD-RW fully for multi-session (lasts 20 minutes at 4x) xorriso -outdev /dev/sr0 -blank all -eject all # Write first session $mkisofs -R -udf $limit_size -v -graft-points /1=./file_of_4gb+1m | \ xorriso -as cdrecord dev=/dev/sr0 -v -multi -waiti -eject - # Determine numbers for option -C c_values=$(xorriso -as cdrecord dev=/dev/sr0 -msinfo) # Write second session with small file /bin/ls as payload $mkisofs -R -udf $limit_size -v -graft-points -C "$c_values" -M /dev/sr0 \ /2=/bin/ls | \ xorriso -as cdrecord dev=/dev/sr0 -v -multi -waiti -eject - After mounting -t udf, i see after using my hacked genisoimage: $ ls -l /mnt/iso total 8825 -rw-r--r-- 1 thomas thomas 1048576 May 1 09:54 1 -rwxr-xr-x 1 thomas thomas 118280 Mar 14 2015 2 but after using ye olde mkisofs-2.01.01a64: total 4195444 -r--r--r-- 2 root root 4296015872 May 1 09:54 1 -r-xr-xr-x 1 root root 118280 Mar 14 2015 2 I disabled the check for large files in mkisofs/tree.c and ran above test again. Result: Only a single directory record gets written for the large file with size number rolled over from 4 GiB + 1 MiB to 1 MiB. So it is hopeless to use genisoimage with large files unless in a single session with -udf -allow-limited-size and the hope that all readers will prefer UDF over the crippled ISO 9660 tree. Have a nice day :) Thomas
Git commit a8f1221b407b7861771c8d8b1c422bb43d1585ce by Leslie Zhai. Committed on 02/05/2017 at 04:27. Pushed by lesliezhai into branch 'master'. Fix DataMultisessionImportDialog No okClicked or cancelClicked signal issue. K3b was developed by Sebastian Trueg started in 1998! and K3b::DataMultisessionImportDialog was migrated by Michał Małek to KF5 in 2014! There are okClicked and cancelClicked signals for KDialog. Unfornately KDialog has been deprecated and moved to kde4support. KF5 Prefer QDialog, but there is no such signal, and clang analyzer was not taught to find such migration issue :) Please (code review) pay more attention to K3b::DataMultisessionImportDialog::slotOk and K3b::DataDoc::importSession, I prefer to use the backends provided by libburnia developing and maintaining by Thomas if others failed to importSession! M +3 -3 src/projects/k3bdatamultisessionimportdialog.cpp https://commits.kde.org/k3b/a8f1221b407b7861771c8d8b1c422bb43d1585ce
Hi Łukasz, Please try to compile the git master of k3b for debug and test https://github.com/KDE/k3b/blob/master/INSTALL.txt#L37 Sorry that I do not have CD/DVD driver nor empty CD/DVD/Blu-ray disc to test, but only the simulator CDEmu, unfortunately VHBA module https://sourceforge.net/p/cdemu/code/ci/master/tree/vhba-module/ does not support multisession? so I can not verify the related issues! Thanks, Leslie Zhai
> Sorry that I do not have CD/DVD driver nor empty CD/DVD/Blu-ray disc to > test, but only the simulator CDEmu, unfortunately VHBA module > https://sourceforge.net/p/cdemu/code/ci/master/tree/vhba-module/ does not > support multisession? so I can not verify the related issues! Not having a CD drive or CD-Rs to test is quite a problem for the k3b maintainer! They are easy enough to buy at any hardware shop. I got the Kubuntu fund to refund me the cost, you can try asking them if that helps although it would need a way to send money from Scotland to China.
Hi Jonathan, Thanks for your reply! I think CDEmu is good enough for covering almost the general testcases, for example burning a ISO for Kubuntu, Fedora and ArchLinux. and it is very faster than real CD/DVD driver and CD/DVD disc to save debugging time https://bugs.kde.org/show_bug.cgi?id=367639#c16 :) But multisession is a special testcase: * a big enough DVD/BlueRay disc, in this bug, Łukasz burn over 4+ GB video! * is general CD/DVD driver able to work for the BlueRay disc? So Thomas is helping me to review code just like https://bugs.kde.org/show_bug.cgi?id=367639 and teaching me about the backends, and Łukasz and other K3b users can verify it! I hope more users to test K3b, report bug to me, then I could make it better, thanks a lot! Regards, Leslie Zhai
(In reply to Leslie Zhai from comment #42) > Hi Łukasz, > > Please try to compile the git master of k3b for debug and test > https://github.com/KDE/k3b/blob/master/INSTALL.txt#L37 > > Sorry that I do not have CD/DVD driver nor empty CD/DVD/Blu-ray disc to > test, but only the simulator CDEmu, unfortunately VHBA module > https://sourceforge.net/p/cdemu/code/ci/master/tree/vhba-module/ does not > support multisession? so I can not verify the related issues! > > Thanks, > Leslie Zhai I have error during compilation: [ 43%] Building CXX object src/CMakeFiles/k3b.dir/main.cpp.o /home/panlukasz/Informatyka/Kod_źródłowy/k3b-master/src/main.cpp:138:9: error: use of undeclared identifier '__sanitizer_print_memory_profile' __sanitizer_print_memory_profile(atoi(argv[1]), atoi(argv[2])); ^ 1 error generated.
Hi, Jonathan Riddell wrote: > > Not having a CD drive or CD-Rs to test is quite a problem for the k3b > > maintainer! Leslie Zhai wrote: > I think CDEmu is good enough for covering almost the general testcases, We had those unclear failures with cdrskin and the emulator in https://bugs.kde.org/show_bug.cgi?id=137436. So i have to agree with Jonathan that you need a real burner drive for development and testing. Unlike me, you will probably not need more than one or two. As backend programmer i always have to check with other drives when one drive fails with unclear symptoms. (I have to use them via /dev/sg instead of /dev/sr because of http://marc.info/?l=linux-scsi&m=135705061804384&w=2 ) > But multisession is a special testcase: > * a big enough DVD/BlueRay disc, in this bug, Łukasz burn over 4+ GB video! Łukasz experiences the problem here with DVD+R. I reproduced it rather by unformatted DVD-RW, because this is the only medium type of DVD size which does real multi-session and is re-usable. One has to be patient when it comes to blanking. Experiments with DVD+R or DVD-R would have sufficed, too, but would then have produced lots of plastic waste. DVD+RW, DVD-RAM, or formatted DVD-RW would not be suitable for exploring true multi-session and the behavior of filesystem readers when they get to see a real multi-session disc. > * is general CD/DVD driver able to work for the BlueRay disc? No. DVD drives only do DVD and CD. You'd need a drive which explicitely promises to write BD media, e.g. by advertising write speeds for BD-R and BD-RE media. Beware of "combo" drives, which can read BD but write only DVD. A SATA DVD burner costs about 15 EUR here, a SATA BD burner about 80 EUR. The LG BH16NS55 BD burner is currently sold for about 60 EUR. ("Combo" drives cost as much as burner drives. So do not only look at the price tag.) If rebooting your workstation would be a problem, it might be worth to put the drive into a SATA-USB box with external power supply, even if you have a full height drive slot free in your machine. If the drive gets stuck during experiments then it can be easily reset by switching power off and on. (This should not happen often with KDE development, but is rather a risk with backend experiments. ) Empty USB boxes cost about 50 EUR. BD drives in USB box cost about 130 EUR. You'd also need some CD-RW, DVD+RW, BD-RE media for experiments with re-usable media, and probably a few BD-R for the occasions were real multi-session on BD-R is desired. Have a nice day :) Thomas
Hi Łukasz, Just comment or remove all #if __clang__ ... #endif blocks in the src/main.cpp it is almost nightly build LLVM in my box, because I am also a LLVM developer https://reviews.llvm.org/p/xiangzhai/ so very new API unavailable for release version. or you could use GNU compiler just ignored __clang__ marco. Regards, Leslie Zhai
(In reply to Leslie Zhai from comment #47) > Hi Łukasz, > > Just comment or remove all #if __clang__ ... #endif blocks in the > src/main.cpp it is almost nightly build LLVM in my box, because I am also a > LLVM developer https://reviews.llvm.org/p/xiangzhai/ so very new API > unavailable for release version. or you could use GNU compiler just ignored > __clang__ marco. > > Regards, > Leslie Zhai I have compiled master branch using GNU C++. Program have compiler succesfully. But when I ran it, an error occured: $ /usr/local/bin/k3b ASAN:DEADLYSIGNAL ================================================================= ==25017==ERROR: AddressSanitizer: SEGV on unknown address 0x619000006e88 (pc 0x7ff51b779a20 bp 0x619000006e80 sp 0x7ffdec701580 T0) ASAN:DEADLYSIGNAL AddressSanitizer: nested bug in the same thread, aborting.
Hi Łukasz, Just disable sanitizer for GNU compiler: cmake .. -DCMAKE_INSTALL_PREFIX=/usr \ -DKDE_INSTALL_LIBDIR=lib \ -DKDE_INSTALL_LIBEXECDIR=lib \ -DKDE_INSTALL_USE_QT_SYS_PATHS=ON \ -DK3B_BUILD_API_DOCS=ON \ -DK3B_ENABLE_PERMISSION_HELPER=ON \ -DK3B_DEBUG=ON PS: There is an extra-cmake-modules GNU sanitizer bug https://git.reviewboard.kde.org/r/129708/ I know GNU compiler supported sanitizer and there is KASan for Linux kernel https://www.kernel.org/doc/html/latest/dev-tools/kasan.html but I have not experienced it in my box, I only use LLVM's! Regards, Leslie Zhai
(In reply to Leslie Zhai from comment #49) > Hi Łukasz, > > Just disable sanitizer for GNU compiler: > > cmake .. -DCMAKE_INSTALL_PREFIX=/usr \ > -DKDE_INSTALL_LIBDIR=lib \ > -DKDE_INSTALL_LIBEXECDIR=lib \ > -DKDE_INSTALL_USE_QT_SYS_PATHS=ON \ > -DK3B_BUILD_API_DOCS=ON \ > -DK3B_ENABLE_PERMISSION_HELPER=ON \ > -DK3B_DEBUG=ON > > PS: There is an extra-cmake-modules GNU sanitizer bug > https://git.reviewboard.kde.org/r/129708/ > > I know GNU compiler supported sanitizer and there is KASan for Linux kernel > https://www.kernel.org/doc/html/latest/dev-tools/kasan.html but I have not > experienced it in my box, I only use LLVM's! > > Regards, > Leslie Zhai The bug is fixed now. The user interface works properly and project view with files from previous session appears after choosing the session to import. Thank you very much Leslie. Regards. Łukasz Konieczny
Hi Łukasz, You are welcome! Thanks for your testing :) Regards, Leslie Zhai
*** Bug 386401 has been marked as a duplicate of this bug. ***