Created attachment 105668 [details] k3b_git85105cd.log Hello, I'm testing k3b_git85105cd And not recording Fine. Regards, -- Cristian
Hi Cristian, Sorry for my late response, I am doing my work assignment about L4 http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/ so I do not have time to fix K3B bugs recently. Burned media ----------------------- BD-R Sequential (SRM) sorry I do not have BD-R to reproduce your issue, but I could ask other K3B users who have to test :) Regards, Leslie Zhai
Hi Cristian, Please use cdrskin as Writing app https://pbs.twimg.com/media/CyVrhH2UQAAE2DD.png developed by Thomas :) Regards, Leslie Zhai
Hi, the end of the log looks like drive and medium had problems with Defect Management. Up to 70.7 % the run had a normal speed for 2x BD media under Defect Management. Then effective speed drops to values which indicate re-location of blocks. The medium seems to have degrading quality towards its end. The final error happens after 209 MB of hobbling. It is not a medium error but rather a problem of the drive firmware. The drive issued a status code which indicates that it had experienced a medium change or a similar problem, but now is ready for work again. Such an event is not normal. I'd blame it on the firmware's efforts with Defect Management, if i had to guess. It might be that the problem is about the indivual medium and that the next try will succeed. If it is systematic among all media of a particular brand, then you could try BD-R from other brands. If it is just about the internal pitfalls of Defect Management (one can see it fail quite often), then one could try whether the media work if Defect Management is disabled. Using cdrskin as backend would avoid automatic formatting of the BD-R and thus not enable Defect Management. With growisofs one would have to use option -use-the-force-luke=spare=none to avoid formatting. If you burn without Defect Management on possibly poor media, then it is important to checkread the media after burning. (If it is about BD-RE media, then formatting is inavoidable. With cdrskin it is possible to nevertheless disable Defect Management by option stream_recording=off ) At this point i have to hand over to Leslie or others who know how to let K3B use extra options of cdrskin and/or growisofs. Have a nice day :) Thomas
Hi Thomas, Thanks for your reply! > At this point i have to hand over to Leslie or others who know how to let K3B use extra options of cdrskin and/or growisofs. 1. for debug quickly, I can directly add extra options, then Cristian is able to test 2. for fix this bug, I need to change the UI to let user to enable such extra options, correct? Regards, Leslie Zhai
Hi, > 2. for fix this bug, I need to change the UI to let user to enable such > extra options, correct? I was recently asked whether "User Parameters dialog" could do this: https://forums.linuxmint.com/viewtopic.php?f=47&t=246015&p=1319185#p1319598 "-If I want to use the option you mentioned with growisofs, can I set it in K3b's "User Parameters" dialog? It looks like this lets you set command line options for the programs used by K3b." My answer was: "Just try it when you burn your next BD-R". Up to now, there is no report about the outcome of such a try. Have a nice day :) Thomas
Hi Thomas, Thanks for your hint! it does not need to change the UI, there is "User Parameters" dialog already :) > I was recently asked whether "User Parameters dialog" could do this: > https://forums.linuxmint.com/viewtopic.php?f=47&t=246015&p=1319185#p1319598 > "-If I want to use the option you mentioned with growisofs, can I set it > in K3b's "User Parameters" dialog? It looks like this lets you set > command line options for the programs used by K3b." > > My answer was: "Just try it when you burn your next BD-R". > Up to now, there is no report about the outcome of such a try. Cristian, please have a try :) https://pbs.twimg.com/media/DBoAyizU0AIaWvf.png > > > Have a nice day :) > > Thomas Regards, Leslie Zhai
Hi, i have to correct myself: The cdrskin option for disabling Defect Management on formatted BD media is stream_recording=on not "off". Sorry for the confusion. Have a nice day :) Thomas
Ping Cristian
Created attachment 105999 [details] Settings-k3b-17.07.70.png
Hi Cristian, > Settings-k3b-17.07.70.png fixed or failed? and what about the output of log? Regards, Leslie Zhai
Created attachment 106014 [details] I am not seeing this option
Created attachment 106020 [details] K3b with cdrskin
Created attachment 106023 [details] k3b log
growisofs command: ----------------------- /usr/bin/growisofs ... -use-the-force-luke=spare=none Then failed?
Hi, the k3b.log in https://bugs.kde.org/attachment.cgi?id=106023 looks like a successful burn with growisofs at 2x speed. (growisofs was told to use 4x speed and the drive says it was set to that value, but the effective speed is 2x, which matches the 0.9x when Defect Management is enabled.) The next step would be to read the BD-R and to check whether its files match their originals on the disk. If this is true, then we can claim full success. Have a nice day :) Thomas
(In reply to Leslie Zhai from comment #14) > growisofs command: > ----------------------- > /usr/bin/growisofs ... -use-the-force-luke=spare=none > > Then failed? Apparently I record well, now I'm going to do the test that Thomas asks: Burn an ISO image and then make a md5sum of the BD-R to see if it is correctly recorded. Regards, -- Cristian
Good news :) > > Apparently I record well, now I'm going to do the test that Thomas asks: > Burn an ISO image and then make a md5sum of the BD-R to see if it is > correctly recorded. > > Regards, > -- > Cristian
Created attachment 106040 [details] k3b log - Fail caravena@caravena-530U3C-530U4C:/media/mis-doc/ISO/tmp$ dd if=/dev/zero of=archivoX.txt bs=1024 count=4048576 4048576+0 registros leídos 4048576+0 registros escritos 4145741824 bytes (4,1 GB, 3,9 GiB) copied, 247,034 s, 16,8 MB/s caravena@caravena-530U3C-530U4C:/media/mis-doc/ISO/tmp$ ls -lihsa total 20G 74249 4,0K drwxrwx--- 1 root plugdev 4,0K jun 10 16:04 . 10828 8,0K drwxrwx--- 1 root plugdev 8,0K jun 10 16:09 .. 78259 3,9G -rwxrwx--- 1 root plugdev 3,9G jun 10 15:47 archivo1.txt 78858 3,9G -rwxrwx--- 1 root plugdev 3,9G jun 10 15:51 archivo2.txt 78859 3,9G -rwxrwx--- 1 root plugdev 3,9G jun 10 15:56 archivo3.txt 79568 3,9G -rwxrwx--- 1 root plugdev 3,9G jun 10 16:01 archivo4.txt 81161 3,9G -rwxrwx--- 1 root plugdev 3,9G jun 10 16:08 archivo5.txt caravena@caravena-530U3C-530U4C:/media/mis-doc/ISO$ genisoimage -r -J -o blu-ray.iso tmp I: -input-charset not specified, using utf-8 (detected in locale settings) 0.05% done, estimate finish Sat Jun 10 16:09:02 2017 0.10% done, estimate finish Sat Jun 10 16:09:02 2017 0.15% done, estimate finish Sat Jun 10 16:20:16 2017 0.20% done, estimate finish Sat Jun 10 16:17:27 2017 [...] 99.79% done, estimate finish Sat Jun 10 16:26:09 2017 99.84% done, estimate finish Sat Jun 10 16:26:09 2017 99.89% done, estimate finish Sat Jun 10 16:26:10 2017 99.93% done, estimate finish Sat Jun 10 16:26:09 2017 99.98% done, estimate finish Sat Jun 10 16:26:10 2017 Total translation table size: 0 Total rockridge attributes bytes: 589 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 0 10121621 extents written (19768 MB) caravena@caravena-530U3C-530U4C:/media/mis-doc/ISO$ md5sum blu-ray.iso 7d671d16ec304caf1d9a07eccd1133a3 blu-ray.iso
Hi, > :-[ WRITE@LBA=596780h failed with SK=4h/ASC=03h/ACQ=01h]: Input/output error This is not good news. SK=4h means "Hardware error". SPC-3 table 27: "Indicates that the device server detected a non-recoverable hardware failure (e.g., controller failure, device failure, or parity error) while performing the command or during a self test. ASC=03h/ACQ=01h is listed in SPC-3 as "NO WRITE CURRENT". No idea what this shall mean. According to http://www.t10.org/lists/asc-num.htm#ASC_03 it is supposed to be emitted by SSC tapes, not by MMC optical drives. I'd say it indicates a period of drive unconsciousness. This would be a situation after which one could get the wake-up message from the first failure in this bug report: > > :-[ FLUSH CACHE failed with SK=6h/NOT READY TO READY CHANGE, MEDIUM MAY HAVE CHANGED]: Input/output error This is surely not K3B's fault and very probably not the fault of growisofs. It rather looks like the drive hates the medium and gets into strange states while gnawing on it. It does not happen always. I assume that the shorter burn runs without Defect Management improve the chance to get done before madness strikes. But the situation is clearly unstable. The only proposal i have is to try other media or a different drive. Have a nice day :) Thomas
Hi, Upgrade firmware? What Firmware??? Regards, -- Cristian
Thomas Hi, > Upgrade firmware? If there is a newer version than "1.02" it would be worth a try. But usually you need a MS-Windows system to run the firmware installer program. (I conclude "1.02" from the log text Devices ------------------- MATSHITA BD-MLT UJ240AS 1.02 (/dev/sr0 ... ) "UJ240AS firmware" is probably the term to search for in google or on firmware providing sites. (I expect a substantial risk of malware on such sites if not run by the drive manufacturer.) Have a nice day :) Thomas
Created attachment 106042 [details] K3b log Good Hello, I have good news!!! I followed this [0] guide for updating the firmware. Https://apingxh.blogspot.cl/2015/02/how-to-upgrade-firmware-for-uj240as-blu.html And then I've burned the ISO image again. Apparently the firmware update gave solution to the previous recording error. Thank you, - Cristian
Created attachment 106043 [details] Finished K3b
Hi, "Written data verified" is indeed good news. Let's hope that this success is repeatable with the next burn runs. Did the pacifier messages of growisofs report speeds around "@2.0x" or did it burn with the speed 4x which growisofs demands and which the drive in the beginning reports to have set ? Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #24) [...] > Did the pacifier messages of growisofs report speeds around "@2.0x" > or did it burn with the speed 4x which growisofs demands and which the > drive in the beginning reports to have set ? I do not understand Regards, -- Cristian
Hi, i wrote: > > Did the pacifier messages of growisofs report speeds around "@2.0x" > > or did it burn with the speed 4x [...] ? Cristian Aravena Romero wrote: > I do not understand In the logs before the firmware upgrade, we have the growisofs announcement of 4.1x: /dev/sr0: "Current Write Speed" is 4.1x4390KBps. but during the write run it reports mostly 2.0x or slightly lower 2406088704/20729948160 (11.6%) @2.0x, remaining 36:02 RBU 100.0% UBU 96.9% 2431909888/20729948160 (11.7%) @1.7x, remaining 36:06 RBU 100.0% UBU 96.9% 2462121984/20729948160 (11.9%) @2.0x, remaining 35:59 RBU 100.0% UBU 96.9% See e.g. https://bugsfiles.kde.org/attachment.cgi?id=106040 My question is whether it now reports something like 462121984/20729948160 (11.9%) @4.0x, remaining 18:00 RBU 100.0% UBU 96.9% and is done in half the time than before upgrade. Have a nice day :) Thomas
Hi, when doing copy+paste i left out a digit "2". My made-up pacifier line should have looked like 2462121984/20729948160 (11.9%) @4.0x, remaining 18:00 RBU 100.0% UBU 96.9% not 462121984/20729948160 (11.9%) @4.0x, remaining 18:00 RBU 100.0% UBU 96.9% Have a nice day :) Thomas
what do I do now? -- Cristian
Hi, most important is to find out whether the drive now burns BD-R reliably. If you experience failure, please post the growisofs log. If half a dozen successes in a row happen, then you can expect to have solved the problem. Please give us a short note in this case. Have a nice day :) Thomas
Created attachment 106049 [details] k3 giteb55cd2 1/6 -> Correct recording :-)
Created attachment 106050 [details] k3b_giteb55cd2.png
Hi Thomas, My mentor, please teaching me about UDF filesystem for bigger than 2GB files, is it available for Linux in the open source world? I need to deepin to it :) PS: One or two picky Blu-ray players, a few standards-conformant commercial Blu-ray videos, a variety of addictive drugs to keep the programmer from running away. https://bugs.kde.org/show_bug.cgi?id=257602#c9 Regards, Leslie Zhai
Hi, mkisofs writes: > This size can only be represented in the UDF filesystem. > Make sure that your clients support and use it. although having got among its arguments: > ... -iso-level 3 ... File of size >= 4 GiB are not properly read from ISO 9660 by Solaris and the BSD Unixes. Linux and MS-Windows can handle large ISO 9660 files just fine. ISO 9660 organizes the data content of files in "extents", which are ranges of data blocks on the medium. An extent can at most have 4 GiB - 1 byte of size. But ISO 9660 can express larger data files by chaining extents, up to the maximum size of a ISO 9660 filesystem with block size 2048. That's 2 exp (32 + 11) = 8 TiB. By a poor design decision in libisofs API, xorriso is limited to 4 TiB of filesystem size. This chaining is called "Level 3". See ECMA-119, 10, "Levels of Interchange": - Level 1 allows files up 4 GiB - 1 byte with 8 characters in the file name and 3 characters in the extension. Directories may not have a name extension (i.e. only 8 characters). The character set is very limited. - Level 2 allows file names as long as fits into the directory record (255 - 34 characters - some bytes needed for attaching Rock Ridge). The character set is not specified. UTF-8 should be ok. - Level 3 allows long names, exotic characters, and multiple extents. > please teaching me about UDF filesystem for bigger than 2GB files, > is it available for Linux in the open source world? mkisofs and genisoimage have option -udf. It produces UDF 1.02 metadata in addition to ISO 9660, RockRidge, and Joliet metadata. This is the UDF version prescribed for DVD video players. Blu-ray UDF is specified to use UDF 2.50, which to my knowledge no Linux tool can produce. The Linux kernel has a driver for reading UDF and writing the random read-write variant (version unknown to me). This is neither the format expected by DVD or Blu-ray video players. (You may create a large file, attach it to a loop device, put an empty UDF filesystem on it by mkfs, mount it, and populate it with files by normal Linux means like "cp". Unmount and burn to medium. But as said, that's neither what DVD nor what Blu-ray video wants.) As we are it: 2 GiB is not a limit of ISO 9660 but rather of very old Linux systems which used signed 32-bit integers to store file sizes. Since we have no negative block numbers, 2 exp 31 - 1 = 2 GiB -1 is the largest size that can be expressed that way. This restriction is long gone by Large File Support on Linux. Have a nice day :) Thomas
Hi, the firmware change obviously had an effect on write speeds. https://bugsfiles.kde.org/attachment.cgi?id=106049 shows that the drive this time announced the ability for 6x speed, got set to 6x, and in typical Constant Angular Velocity manner accelerated from about 2.5x at the inner rim of the medium up to 5.8x at the outer regions. That's what one can expect from nominal 6x on BD-R without Defect Management. So yes, the firmware upgrade made the drive's behavior somewhat more normal. Have a nice day :) Thomas
Hi Thomas, > ... > This restriction is long gone by Large File Support on Linux Thanks for your detailed information! very professional! so is it ok to ignore the warning about "Found files bigger than 2 GB..." or we can change the description? > So yes, the firmware upgrade made the drive's behavior somewhat more normal. I have not experienced firmware development, it must be cool :) Regards, Leslie Zhai
Hi, > so is it ok to ignore > the warning about "Found files bigger than 2 GB..." or we can change the > description? Yes. The warning is old, at least in part it was always wrong, and the genisoimage run took all precautions which can be taken to make the large files readable after mounting the ISO. Have a nice day :) Thomas
Git commit 41e6f110c7f2753b20537c23bad56b8ac4896ba2 by Leslie Zhai. Committed on 12/06/2017 at 08:09. Pushed by lesliezhai into branch 'master'. It doesn't need to warn if filesGreaterThan2Gb M +4 -5 libk3b/projects/datacd/k3bisoimager.cpp https://commits.kde.org/k3b/41e6f110c7f2753b20537c23bad56b8ac4896ba2
Hi, i think the new message in https://cgit.kde.org/k3b.git/commit/?id=41e6f110c7f2753b20537c23bad56b8ac4896ba2 is a bit courageous and makes the user wonder why the message is emitted at all: > "Found files bigger than 2 GB. These files will be fully accessible." I propose to either - omit the message (and only check for mkisofs option -allow-limited-size) - or to state that the files may be problematic on very old Linux and on systems which do not mount the UDF aspect of an ISO by default. Reasoning: The Large File Support of Linux stems from the early years of this century. E.g. these are introductions with modification dates 2004 and 2005: https://people.redhat.com/berrange/notes/largefile.html http://users.suse.com/~aj/linux_lfs.html The latter is talking of kernels 2.2 and 2.4. mkisofs with option -udf produces both sets of metadata: ISO 9660 and UDF. Linux and MS-Windows mount UDF by default if they see such a ISO 9660/UDF hybrid filesystem. The other operating systems have to be suspected to not handle large data files in ISO 9660 correctly. The ones among them, which do not mount the UDF aspect by default, will show problems. On POSIX compliant systems, which cannot properly read large files from ISO 9660 filesystems, it should be possible to use GNU xorriso for extracting large files to the local disk. Large File Support by the local operating system is then mandatory, of course. (xorriso can cut a large file into pieces before putting it onto hard disk. But such pieces are of course cumbersome to use.) Have a nice day :) Thomas
Hi Thomas, Thanks for your advice! and it needs consider about FreeBSD now :) https://phabricator.kde.org/T6316 Regards, Leslie Zhai
Hi, > https://phabricator.kde.org/T6316 says "You Shall Not Pass: Restricted Maniphest Task You do not have permission to view this object. Users with the "Can View" capability: This object has a custom policy controlling who can take this action. The owner of a task can always view and edit it." I take ophense and rephuse to use such newfangled contraptions. What's the problem with FreeBSD ? It is supposed to mount UDF. Have a nice day :) Thomas
Created attachment 106065 [details] k3b_17.04.2_test_2-6.log 2/6 -> Correct recording :-)
Created attachment 106066 [details] k3b_17.04.2_test_2-6.png
Created attachment 106067 [details] k3b_17.04.2_test_3-6.log 3/6 -> Correct recording :-)
Created attachment 106068 [details] k3b_17.04.2_test_3-6.png
Hi, although runs 2 and 3 look good, they show different speed settings and effective speeds. Run 2 gets set to 4x, runs a long time at 2x and then suddenly goes to 4x. Run 3 gets set to 4x but runs at 2x all the time. Are these media from different brands or with different speed printed on their labels ? Have a nice day :) Thomas
Hi Thomas, > Hi, > > > https://phabricator.kde.org/T6316 > > says > "You Shall Not Pass: Restricted Maniphest Task > You do not have permission to view this object. > Users with the "Can View" capability: > This object has a custom policy controlling who can take this action. > The owner of a task can always view and edit it." Oops! directly quote it for you: Dear Ben, > The new system among other things has the option to provide both FreeBSD and Windows builds. > If you are interested in this for your application, please file a Sysadmin request. I want to provide FreeBSD build for K3B too. and it is able to use clang (FreeBSD switch to clang) analyzer to find out potential issues hope K3B could be bug free :) Regards, Leslie Zhai > > I take ophense and rephuse to use such newfangled contraptions. > > What's the problem with FreeBSD ? It is supposed to mount UDF. Sorry for my poor English! just build for FreeBSD https://build-sandbox.kde.org/view/Applications/job/Applications%20k3b%20kf5-qt5%20FreeBSDQt5.7/ Regards, Leslie Zhai
Git commit 184085430e33ad25357c5f2b8d572809818389d5 by Leslie Zhai. Committed on 13/06/2017 at 06:56. Pushed by lesliezhai into branch 'master'. Consider about old Linux system Bug from K3b Application 17.04, it depends on KF5, thanks for Michał Małek migration job! and right now it supports to build for FreeBSD using Clang compiler, I would enable C++11 or even C++17 at that time I will not consider about old system any more. M +3 -5 libk3b/projects/datacd/k3bisoimager.cpp https://commits.kde.org/k3b/184085430e33ad25357c5f2b8d572809818389d5
Ping Cristian! > Hi, > > although runs 2 and 3 look good, they show different speed settings > and effective speeds. > Run 2 gets set to 4x, runs a long time at 2x and then suddenly goes to 4x. > Run 3 gets set to 4x but runs at 2x all the time. > > Are these media from different brands or with different speed printed on > their labels ?
(In reply to Leslie Zhai from comment #48) > Ping Cristian! Hi Leslie, [...] > > Are these media from different brands or with different speed printed on > > their labels ? I have recorded on discs of different speeds. Of 4X and 6X. Regards, -- Cristian
*** Bug 384443 has been marked as a duplicate of this bug. ***
Hello, What do I do now? Regards, -- Cristian
Hi, > What do I do now? About the failure to burn successfully (Bug 380067): If it happens again, gather experience about which media fail and which succeed. We found no evidence that K3B or growisofs are to blame for the failures. It must be in the relation of drive and computer or of drive and media. ------------------------------------------------------------------------ @Leslie: This is hardly a duplicate of Bug 384443 which says "It does not record its maximum speed". The short answer is: Because Defect Management is enabled by default and thus the drive writes and checkreads alternatingly. Can you please split these two bugs again ? I dimly remember we had this topic already ... Have a nice day :) Thomas
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!