[k3b] [Bug 429584] growisofs crashes @ 99%
https://bugs.kde.org/show_bug.cgi?id=429584 --- Comment #9 from Thomas Schmitt --- Hi, Leslie Zhai wrote: > Lng time no see :) Hehe. I'm still around, trying to uphold ISO 9660 and burning on free operating systems. (Just no talent for working on GUIs.) Stay well and ... Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 429584] growisofs crashes @ 99%
https://bugs.kde.org/show_bug.cgi?id=429584 Thomas Schmitt changed: What|Removed |Added CC||scdbac...@gmx.net --- Comment #7 from Thomas Schmitt --- Hi, medium type DVD-R, write type DAO, not aligned to full 16 blocks, and failure within the last 16 blocks of the run. This matches https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794868 "dvd+rw-tools: Burn failure of growisofs on DVD-R[W] with write type DAO" Consider to check whether a patch like this is applied: --- --- growisofs_mmc-7.1-11.cpp2015-08-07 13:07:52.0 +0200 +++ growisofs_mmc.cpp 2015-08-07 14:06:31.375597960 +0200 @@ -540,7 +540,7 @@ ssize_t poor_mans_pwrite64 (int fd,const // own higher HZ value and disrespects the user-land one. // Sending them down as milliseconds is just safer... // - if (!(errcode=cmd.transport (WRITE,(void *)buff,size))) + if (!(errcode=cmd.transport (WRITE,(void *)buff,nbl*2048))) break; //--- WRITE failed ---// --- (The write error with DVD+R indicates a bad relationship between drive and medium.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 397732] K3B: data project: when burning wrong size of written data is displayed
https://bugs.kde.org/show_bug.cgi?id=397732
--- Comment #6 from Thomas Schmitt ---
Hi,
Armin Mohring wrote:
> I am using Manjaro with k3b version 18.12.3.
> Now the written data size is reported correctly.
> Solved!
If some code change in K3B caused this improvement, then i fail to see it
in https://github.com/KDE/k3b/commits since summer 2018.
It might have been about a KDE change outside of K3B.
Back in august, i wanted to learn how k3bgrowisofswriter.cpp starts
growisofs and connects to its output channels. But i could not find
the implementation of this call:
if( !d->process.start( KProcess::MergedChannels ) ) {
I expect that in the end the system call pipe(2) is employed.
Its man page gives a glimpse of an idea what might have happened:
O_DIRECT (since Linux 3.4)
Create a pipe that performs I/O in "packet" mode.
[...]
* If a read(2) specifies a buffer size that is smaller than the
next packet, then the requested number of bytes are read, and
the excess bytes in the packet are discarded.
But as said, i got lost in the C++ jungle and could not confirm that
pipe(2) was used with flag O_DIRECT. Class GrowisofsWriter in
k3bgrowisofswriter.h has no member named "process". So "d->process" and
its member ".start()" are probably inherited from other classes.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 398190] Can't copy CD after upgrading from Ubuntu 16.04 LTS to 18.04 LTS. Error log in comment.
https://bugs.kde.org/show_bug.cgi?id=398190 --- Comment #4 from Thomas Schmitt --- Hi, Leslie Zhai wrote: > Is it better to *remove* the unusual -raw96r option by default, what I mean, > just set writingMode's default value to TAO or SAO? Welcome suggestion. Well, we shall not take away any option (even if it helps to shoot the user's foot). About defaults we can ponder when we know how that option was chosen by powder4ski...@gmail.com (maybe by default, maybe by hand ?). > It failed to mkdir for such weird path: > $mkdir -p /tmp/SO U/SO U/SO U/SO U/k3bCdCopy0/ You have to put the blanks into quotation marks. Like mkdir -p '/tmp/SO U/SO U/SO U/SO U/k3bCdCopy0/' But i suspect that rather K3B decided to create that directory. > Related to BUG385367 and BUG384117 385367 is about ripping (i.e. from CD to hard disk). 384117 seems to be a duplicate of thet. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 398190] Can't copy CD after upgrading from Ubuntu 16.04 LTS to 18.04 LTS. Error log in comment.
https://bugs.kde.org/show_bug.cgi?id=398190 --- Comment #2 from Thomas Schmitt --- Hi, the wodim option -raw96r is unusual and (years ago) was a source of trouble for me. Any idea how K3B came to think that it is good to use it ? It is chosen in libk3b/projects/k3bcdrecordwriter.cpp if d->writingMode == K3b::WritingModeRaw This seems to be configurable. Try to choose "TAO" or "SAO" instead. (I see code which sets WritingModeRaw in src/k3bwritingmodewidget.cpp) - I further wonder about the strange file addresses, like /tmp/SO U/SO U/SO U/SO U/k3bCdCopy0/Track02.wav I assume that this is one path, not five. But why the blanks and why four directories "SO U" ? Can this be due to a misconfiguration of K3B ? Does a directory "/tmp/SO U/SO U/SO U/SO U" exist while K3B is attempting to do its job ? - A cdrskin run from command line (without CD-TEXT for now) would look like (while being in the directory with the Trackxx.wav files): cdrskin -v dev=/dev/sr0 speed=48 -audio Track01.wav Track02.wav \ Track03.wav Track04.wav Track05.wav Track06.wav Track07.wav \ Track08.wav Track09.wav Production of CD-TEXT would need a file for option "textfile=" which K3B prepared and which you would need to prepare, too. CD-TEXT has few influence of the burn success. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 397732] K3B: data project: when burning wrong size of written data is displayed
https://bugs.kde.org/show_bug.cgi?id=397732 --- Comment #2 from Thomas Schmitt --- Hi, @Leslie: I am the backend guy. Operating K3B is not really my turf and my K3B is old. (But i just pulled the freshest code from git.) @Armin Mohring: As far as i can see, the numbers for the progress messages stem from the writer modules k3bgrowisofswriter.cpp or k3bcdrecordwriter.cpp. (Like "emit processedSize(...);". They seem to take their numbers from message output of the respective programs growisofs or cdrecord (or wodim). When a burn run with my K3B has ended, then the window with the progress bar offers a button "Show Debugging Output" (at the lower right). There i can see the pacifier messages from growisofs. In my try (with DVD+RW) the progress bar waited at 93 % until the medium was ejected. Then it hopped to 100 %. But the text still says "755.0 MiB of 805.0 MiB" This is halfways plausible from the view of K3B by the last pacifier message of growisofs: 807534592/859508736 (94.0%) @4.0x, remaining 0:09 RBU 100.0% UBU 99.7% growisofs reports to have written 807534592 of 859508736 bytes and to consider this as 94.0 percent of the job. The "94 %" is very near to the "93 %" which i remember to have seen. 807534592/859508736 = .939530406355288. So it is plausible to see 93. But 807534592 bytes = 770.125 MiB. 859508736 bytes = 819.69140625 MiB. So why 755.0 and 805 ? (xorriso too says its 859508736 bytes.) No further message is recorded from growisofs. That's strange. A direct run of growisofs (with an ISO image of similar size) ends by 805109760/858783744 (93.8%) @4.0x, remaining 0:09 RBU 100.0% UBU 99.7% 823623680/858783744 (95.9%) @4.0x, remaining 0:06 RBU 100.0% UBU 99.7% 842104832/858783744 (98.1%) @4.0x, remaining 0:03 RBU 49.7% UBU 99.7% builtin_dd: 419328*2KB out @ average 3.9x1352KBps /dev/sr4: flushing cache /dev/sr4: stopping de-icing /dev/sr4: writing lead-out In comparison, this looks as if K3B is not logging all messages from growisofs, possibly because it does not receive them all. The reasons for this would be out of my expertise. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 360184] k3b should offer option to select either md5 sum or sha256 when loading dvd iso
https://bugs.kde.org/show_bug.cgi?id=360184 --- Comment #7 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, guyvf wrote: > https://en.wikipedia.org/wiki/Hash_function_security_summary This is about intentional manipulations of checksums, not about their suitability for detecting incidential transport or storage errors. So the main purposes of hashes with ISO images or their content is not in danger. MD5 still is much more safe than loitering a day at an arbitrary spot on earth without being prepared for the direct hit of a 10 km asteroid during that day. (That's around 2 exp -64 of probability.) If really crypto-grade checksumming is desired, i'd propose to use some trustworthy program (if you find any) to harden the ISO image after production. You cannot expect the necessary crypto experience with the programmers of ISO 9660 programs. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #32 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i got feedback from Daniel Pielmeier, the Gentoo maintainer of libburn. He fulfilled my wish to remove the problematic configuration option by: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=55b96c727287728374a11de48028112417dbded5 Many thanks to him for working around my bug. On my question > > What would King_DuckZ have to do to get it on his machine ? he answered > He just needs to wait a few hours until the change propagates to the > mirrors. After syncing with "emaint --sync" he should get the changes > by calling "emerge libburn". Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #31 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > [ebuild R] dev-libs/libburn-1.4.8-r1::gentoo USE="track-src-odirect > -debug -static-libs" 0 KiB Here we have the trigger which activates my mistake of 2009. I wonder why nobody noticed the problem on Gentoo. Regrettably packages.gentoo.org yields error 500 today. But i will later try to talk the package maintainer out of option "track-src-odirect" and to find out since when cdrskin is broken on Gentoo. > # head -c 3145728 /dev/sr0 | hexdump Yes it's clear meanwhile that only zeros were written. Usage model "SAO": Once started, do not stop before the planned end of the burn is reached. I still ponder how to close this pitfall. There are pros and cons to weigh about the model of SAO, which cannot be aborted early, and TAO which can be aborted until the first WRITE command was sent to the drive. As said, for me the following works even if the program was built with configuration option --enable-track-src-odirect : cdrskin -v dev=/dev/sr0 fs=32m -eject -waiti -
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #29 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i can reproduce the cdrskin problem by configuring libburn with option --enable-track-src-odirect The bug is a regression from end of 2009 by release 0.7.4, when cdrskin forgot that it must prepare special buffer memory by mmap(2) when libburn is configured to do O_DIRECT. Many thanks to King_DuckZ for reporting it. But i still need to know from where the cdrskin binary stems and, if it's not the standalone version, from where libburn.so (aka libburn4.so) stems. The proposed workaround really avoids the problem here: cdrskin -v dev=/dev/sr0 fs=32m -eject -waiti -
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #28 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, if the O_DIRECT theory is correct, then this should work without errno 22 cdrskin --allow_emulated_drives -v dev=stdio:/dev/null fs=32m -eject \ -waiti - <$path and report as many read bytes as written bytes Track 01: Total bytes read/written: 49199448064/49199448064 (24023168 sectors). If this works as expected, then you could risk another BD-R medium and do cdrskin -v dev=/dev/sr0 fs=32m -eject -waiti - <$path In this case i need to know from where you got libburn.so. It might be necessary that the upstream programmer talks to the distro packager. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #27 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, grrr. The waste of your BD-R is to blame on libburn's automatic decision to handle this burn under the SAO/DAO model: Known track size, as much write preparations in advance as possible. After the preparations are done, it makes no sense to abort the burn. With CD media the burner would get stuck. With BD-R the track would already be reserved but not written. The medium whould have been saved by the explicit cdrskin option -tao. In this case no writing would have happened if the error already occurs at the first read attempt on the input file. Even better would have been option -waiti with data comming from stdin: cdrskin -v dev=/dev/sr0 fs=32m -eject -waiti -
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #26 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > The error ImgBurn gives me is something like "invalid address for write". > Other users receiving that error were told it's because of the medium > quality, It's probably a miscoordination between burn program and drive. There is SCSI error code 5 21 02 INVALID ADDRESS FOR WRITE Each SCSI WRITE command contains the block address where the write operation shall start and the number of blocks which shall be written with the payload bytes of the SCSI command. If the drive replies "invalid address", then either one of the affected blocks was out of the range of writable blocks on a BD-RE or a BD-R which was formatted to "Pseudo Overwrite" (POW), or the start block address was not the Next Writable address of a BD-R which was not formatted to POW. > 50GB Panasonics So probably double-layer BD-R. Unlike with DVD+R DL, we burn programmers have no influence on the hopping between the layers. That's rather good, as with DVD+R DL we had some problem reports with any of the possible modes of operation. My best guess would be that the passing-through of SCSI commands to the burner is prone to disturbances or hick-ups. > http://paste.debian.net/1008790/ No protests from the drive to see. It took nearly 50 GiB. The only suspicious message is > cdrfifo 0: on read: errno=22 , "Invalid argument" This was when reading the input file into the ring buffer. And it happened before writing began. But it did not prevent writing ... which i cannot reproduce yet. All my tries with simulated errors abort early. My apologies for the medium waste, anyway. errno 22 is not a usual read error. man 2 read mentions O_DIRECT. Maybe the distro configured libburn with non-default --enable-track-src-odirect and your disk has physical blocks larger than 2048. But Debian and therefore probably Mint has in the buildd log of libburn: disabled use of O_DIRECT with track input If it's O_DIRECT, then a run with growisofs might encounter the same problem. If i understand its source right, then it uses O_DIRECT by default if Linux is younger than 2.5. -- What was the exact cdrskin command you used and what do you get from ls -ld $path with $path leading to the image file ? -- What happens if you do (without risking a BD-R medium) cdrskin --allow_emulated_drives -sao -v dev=stdio:/dev/null fs=32m -eject $path Does it report again cdrfifo 0: on read: errno=22 , "Invalid argument" If so, then we need to build cdrskin from source with surely O_DIRECT disabled. -- What does a hex editor say about your burned BD-R ? Does it show any non-zero bytes after maybe some first MBs of zeros ? -- Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #23 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, there is still the riddle why ImgBurn on Wine produces mostly failing results but sometimes succeeds. An the first glimpse this does not look much like a filesystem format problem but more likely it is a problem between burner and medium, or between ImgBurn, Wine, and Linux if you burn directly from ImgBurn. So independently of the endeavor to produce BD video UDF on Linux, King_DuckZ should try to let ImgBurn write to a file image instead of the burner directly (if that is what is done currently). Then use Linux command line burn programs to burn the medium growisofs -dvd-compat -Z /dev/sr0=image.udf or cdrskin -v dev=/dev/sr0 fs=32m -eject image.udf and use Linux command "mount" to check whether the video files are readable afterwards. E.g. copy them to hard disk and watch for error messages. If there are problems at burn time or if there are problems to mount the BD and read the file, then i will try to diagnose them. Send mail to: bug-xorr...@gnu.org (growisofs is orphaned, cdrskin is made by me, as is xorriso.) Please report any program messages of failed burn, failed "mount", or failed read. With "mount" and "read", the output of command "dmesg" will be of interest. (Check for private info in there and remove it before posting publicly.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #22 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > I already have a directory containing a BDMV subtree (and CERTIFICATE). I can only google for these terms to learn what they mean. But in general this looks like a good start for exercising the last steps of Blu-ray video production. (When this part is achieved, there will arise the question how to make that subtree from own video files which are given in some common video codec's format.) I have read rumors about DVD video that mkisofs -udf has to take care not only to produce a valid UDF filesystem but also has to obey some further layout prescriptions. See in man genisoimage (or man mkisofs) the description of option -dvd-video. It has two paragraphs. The first talks briefly of that layout, the second mentions DVD-specific input files like VIDEO_TS. The equivalent of this second part is hopefully covered by your BDMV tree. But the first part will simply have to be tested. If it does not work with a picky test player, then one will have to compare the byte-level layout of a commercial Blu-ray video medium with the own UDF-2.50 result. Burning to BD media is not a hard job then. Recent K3B should do. We know from Bug 387765 that Archlinux already has it. (It warns of unknown image format. After confirming, it burned a Nero made UDF-only image.) If there are difficulties to get such a recent K3B, use the command line: growisofs -dvd-compat -Z /dev/sr0=image.udf or cdrskin -v dev=/dev/sr0 fs=32m -eject image.udf I'd use growisofs option -dvd-compat to get BD-R media closed. At lest with DVD there are hints that appendable media won't work on all players. (With BD-RE there is no closing on hardware level.) For full nominal writing speed use cdrskin -v dev=/dev/sr0 fs=32m -eject stream_recording=on image.udf This disables the immediate checkreding by Defect Management which slows down writing by a factor 2 or 3. On flaky media or drives, you paradoxically get better chances of success if you do _not_ let the drive to this check-and-replace game. > So as I see it as a user, K3B should just do the same thing as ImgBurn: you > select the directories you want to burn, ImgBurn guesses from the tree > structure that it's a video disk and asks if you want to use UDF 2.5 and > make a video disk indeed. Then you press ok and wait for it to finish. Well, that would rather be Leslie's desk. :)) He will probably need: - The description of the command line program runs needed to produce the Blu-ray video disc image. - Example input data (e.g. some commercial Blu-ray video discs) - A computer Blu-ray burner. - Testers who then verify that K3B indeed produces BDs which are playable on all Blu-ray video players. Leslie wrote: > But I argue that I don't need real equipment, CDEmu[1] is enough I dare to contradict. A K3B developer should have a BD burner and test media. I as burn backend developer have 3 BD burners and 3 DVD burners. Just to be able to distinguish individual burner flaws from general problems. (It also helps to have slightly ill burners which challenge the program's error handling.) A frontend programmer would only need 1 well working burner, although a second one will help to check program behavior when multiple burners are available in the system. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 388120] cannot burn audio cd using wma files: "error while decoding track"
https://bugs.kde.org/show_bug.cgi?id=388120 --- Comment #12 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, your friendly inconspicious mirroring service: http://scdbackup.webframe.org/kde_bug_388120_file.tar.xz MD5 0d7eb8debc4b27d9b242cc18b4f7c4e7 The name "file.tar.xz" was a bit to general. So i prepended "kde_bug_388120_" to it. Please give me a note when it is downloaded. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #19 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, King_DuckZ wrote: > Because I'm literally writing an UDF > 2.5 bluray disk as we speak, through ImgBurn/wine. Windows app or not, it's > still a userland program running on kernel 4.4 dev.d...@gmail.com pointed to the filesystem driver of Linux for UDF. ImgBurn on Wine most probably has its own UDF filesystem formatter, if it is not using some MS-Windows system driver provided by Wine for that purpose. > udftools, they claim to have added udf 2.5 support to it. > (https://github.com/pali/udftools) There seems indeed to be life in there. Sorry for not looking close enough on the first glimpse. You should try to bribe pali so he helps you working towards a Linux processing chain for Blu-ray video. If you can show a description what input files to expect, what extra info to inquire from the user, and how to process this up to a burnable image, then you could ask K3B to give this procedure a nice user interface. But with that processing chain alone, you would already be Linux heroes. > Btw, idk if I should blame wine, ImgBurn or my mediums but so far my success > rate has been 1 out of 6 - I just counted the coasters in my bin. By what program on which operating system do you actually burn the BD medium ? What are the symptoms of failure ? Burn abort ? Not mountable afterwards ? Not playing in video player ? Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #17 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, please excuse my clear language in this case: dev.d...@gmail.com wrote: > The real problem is, that Linux still is unable to create UDF 2.50 or > UDF 2.60 images: When it comes to data storage on optical media, UDF has no practical advantage over ISO 9660 with Rock Ridge, zisofs, and AAIP, except maybe that you can circumvent the 25 year old ISO 9660 drivers of the BSD Unixes. It is really only about DVD video and BD video. No other reason to use UDF, unless you need to read large files by BSD Unix and don't want to extract them by userland programs. > This is also bad for plain Bluray data disks. AFAIK especially for BD-RE > these higher UDF versions are essential for a long lifetime. Any use of BD-RE which is not mainly sequential will soon kill media and/or drive. The whole promise of Defect Management to replace overworked blocks simply does not yield good results in practice. Keep read-write filesystem drivers away from BD-RE. Use a filesystem image formatter and a burn program, like K3B does. If you do so, then it does not matter to the medium what kind of filesystem the image contains. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #16 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > That sounds fair, if you guys have an account on librepay or bountyhunter > let me know and I'll do what I can. I myself am not hyngry enough for UDF. As said, the specification is public: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-167.pdf http://www.osta.org/specs/pdf/udf250.pdf What may be missing is exact info about https://en.wikipedia.org/wiki/Blu-ray#Data_format_standards beyond the demand for UDF 2.50. > ask the dude behind ImgBurn for help? Best would be if you could talk him into releasing a Linux version. > Last information I can give, the LG WH16NS40 is working very well for me. > It's an external USB3 drive so it can be plugged and unplugged easily. The K3B project could well need such a thing stationed at Leslie's home. My own burner zoo is large enough and partly ill enough for the purpose of burn backend development. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 257602] K3B cannot burn Blurays (or AVCHDs)
https://bugs.kde.org/show_bug.cgi?id=257602 --- Comment #13 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, Dkottmair, 2010: > K3B also can't handle ISOs generated with UDF 2.5 in Nero, > so you cannot even distribute ready-made Bluray/AVCHD-ISOs for burning! This should now be possible after Leslie Zhai's changes in the course of our assessment of Bug 344392. But some ornaments are still missing for IMAGE_RAW. See https://bugs.kde.org/show_bug.cgi?id=387765#c37 https://bugs.kde.org/show_bug.cgi?id=387765#c38 King_DuckZ 2018: > Is there anything that can be done to help adding this feature? Motivationally: Ketracel-white or WWII Panzerschokolade. Technically a standalone Blu-ray recorder/player and some Blu-ray movies would help with getting valid examples and testing own results. UDF specs are for free (ECMA-167 + UDF-2.50) but hope for success is only with comprehensive examples. Leslie generally could need a (USB connected ?) computer BD burner and CD-RW, DVD-RW, DVD+RW, DVD-R, BD-R, BD-RE media for working on K3B bug reports of all kind. But that won't help much with the Blu-ray video authoring issue. > https://github.com/pali/udftools That's the UDF userland software about which the bug reporter complained in 2010. Meanwhile quite obsoleted by the UDF read-write driver in the kernel. (I think CD-RW formatting is still a valid job.) > http://devs.dhgirault.fr/article26.html 5 years ago this would have been the man to bribe, drug, and equip with examples and players. He roughly describes the plan to beef up mkisofs clone genisoimage to produce UDF 2.50 like it does with UDF 1.02. He seems to underestimate the other part of the job, namely to do for Blu-ray what dvdauthor does for DVD. Compare https://en.wikipedia.org/wiki/Blu-ray#Data_format_standards with https://en.wikipedia.org/wiki/DVD-Video#File_system to get an impression of the differences. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 388120] cannot burn audio cd using wma files: "error while decoding track"
https://bugs.kde.org/show_bug.cgi?id=388120 --- Comment #10 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, Dr. Chapatin wrote: > https://1drv.ms/u/s!AkEb8acM9pYjghsa_vagLwgBLvZS After enabling Javascript (i.e. Meltdown and Spectre) it asked me for my "Microsoft password". But on reload it offered me file.tar.xz which i downloaded. 4536744 bytes, md5sum 0d7eb8debc4b27d9b242cc18b4f7c4e7 So if necessary i can act as intermediate storage. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 388120] cannot burn audio cd using wma files: "error while decoding track"
https://bugs.kde.org/show_bug.cgi?id=388120 --- Comment #7 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, Leslie Zhai wrote: > I have no idea why cdrecord failed to work... Did cdrecord start at all ? The log only shows "started" and then complaints begin. It is not clear to me whether K3b::AudioTrackReader tries to read the input file which shall be burned, or whether it tries to read the track from CD, where it should have been written. The report beginning at "DiskInfo:" shows that the medium is not written. Somebody would have to test whether the log of a successful K3B run of audio burning with cdrecord would show any cdrecord messages. The cdrecord job has option -useinfo and *.inf files as input. man cdrecord states: "The audio data is read from stdin in this case." So it would not be cdrecord which opens the input audio data files but rather K3B which pipes the audio data into cdrecord's standard input. If this reading of input fails early, it may be that cdrecord was not started by K3B at all. The headline of this bug report "Error while decoding track" can be found in k3b/libk3b/projects/audiocd/k3baudioimager.cpp , K3b::AudioImager::run() which looks much like it is for processing of track input, not for checkreading of already written tracks. The input file was opened. Else message "Unable to read track" would be emitted. Output file was opened (else "Could not open ... for writing"). But a read attempt by trackReader.read() obviously yielded a result < 0. Maybe some data could be read. But finally an unexpected failure happended. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765 --- Comment #38 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > I noticed that when the ISO file is not recognizable, "Burn image" window > shows no info about the file despite burning process is successful > (screenshot). Ahum. My olde Debian K3B shows with real ISO 9660 a "Filesize", some info from the ISO 9660 Primary Volume Descriptor, and an MD5 sum. Maybe "Filesize" stems from the PVD, too. The messages probably come from function createIso9660InfoItems() https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp?id=0a7848344c470e70a845fa87463317f9c889f5fc#n168 There are more such functions: createCdrecordCloneItems(), createCueBinItems(), createAudioCueItems(). They are all called in slotUpdateImage(), where the confirmation dialog for unknown images is called, too. The message "Md5 sum:" stemms from function calculateMd5Sum(). It is called from slotUpdateImage() for ISO 9660 and some other recognized types. So K3B would need a new function createRawImageItems() which reports similar as e.g. createCdrecordCloneItems(): Detected: Image of unrecognized type Filesize: ... Image file: ... This new function and calculateMd5Sum() would then be called after the line d->foundImageType = IMAGE_RAW; which gets performed when the confirmation dialog has not aborted. Leslie, what do you think about such an augmentation ? Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765 --- Comment #36 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > Why "invalid"? Because it is not an ISO 9660 filesystem, regardless of its suffix ".iso". Insofar the message of K3B is correct. If i was annoyed by the dialog window about unreconized image type, then i'd file a bug with severity "wishlist" saying something like "Please remove the confirmation dialog about unrecognizable image file type" and give the dialog text as pointer to the code: "Type of image file is not recognizable. Do you want to burn it anyway?" I would also point to the changeset https://cgit.kde.org/k3b.git/commit/?id=585067b15d1d3b0d875e092c775f1925e2ba270f which introduced that dialog in order to give a hint about its reason to be. As motivation for my wish i would state that only a small set of types is recognized. Not recognizable are UDF, block-level encrypted ISO 9660, archive files, ... and possibly more legitimate types for burning to optical media. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765 --- Comment #34 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > I just burned the ISO from my link in a CD-RW. So now our changes reached your desktop. Next try whether it works with blu-ray sized images too. > But the warning is not correct and it should be eliminated. The image is not a recognizable ISO 9660 filesystem. The Linux kernel recognizes it, but it recognizes and mounts a lot of filesystems. One could question the reason behind having a confirmation dialog. Back in september 2016 there was a flat refusal on anything that's not ISO 9660, .toc, or .cue/.bin. Maybe K3B should just accept what the user submits. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765 --- Comment #30 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, just in case somebody wonders: I deleted the uploaded copy of udf+image+created+with+nero.iso . So the link is now supposed to be dead. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765 --- Comment #29 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the MD5 checksum matches the one i get here. Somehow the K3B version of Dr. Chapatin is not the same as the one of Leslie. The only idea i have is that Leslie instructs Dr. Chapatin how to download current K3B source and how to build it on his quite modern Archlinux. If it is urgent to get the UDF images onto media, i would advise to try command line tools: growisofs -dvd-compat -Z /dev/sr0=image.iso or xorriso -as cdrecord -v -eject dev=/dev/sr0 image.iso (Arch has xorriso as part of package "libisoburn".) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765 --- Comment #27 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i have put a copy of the image at http://scdbackup.webframe.org/udf+image+created+with+nero.iso Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #25 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the given URL seems not to work without Javascript. But i found in
its lengthy HTML this URL
http://download864.mediafire.com/7l3plzb6fzqg/26outwdcybhtzyp/udf+image+created+with+nero.iso
When fetched with wget it delivers a file of 9,764,864 bytes.
In 2048-bytes block 16, where an ISO 9660 filesystem image would have its
Primary Volume Descriptor with magic number {0x01, 'C', 'D', '0', '0', '1'}
it has {0x00, 'B', 'E', 'A', '0', '1'}.
This is an ECMA-167 Volume Structure Descriptor. "BEA01" means UDF.
According to ECMA-167 it is ok to have it there.
Linux mounts the image and then reports it as
... type udf ...
It will be interesting to learn how K3B manages to circumvent our changeset
about unrecognized image formats. (See my first comment in this thread:
https://bugs.kde.org/show_bug.cgi?id=387765#c5
)
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765 --- Comment #19 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, but mkisofs has no stake in image burning. It _makes_ images. Are you sure you have chosen the right job in K3B ? (Normally i'd ask to run the mkisofs command in a shell and to watch for an abort message, or to try xorrisofs as replacement of mkisofs.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #17 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> Arch Linux, K3b 17.11.90
Google brings me to the page of "k3b 1:17.11.90-1"
https://www.archlinux.org/packages/kde-unstable/x86_64/k3b/
and after some URL manipulation i get to
https://git.archlinux.org/svntogit/packages.git/tree/k3b/kde-unstable/PKGBUILDIt
has
pkgname=k3b
pkgver=17.11.90
source=("https://download.kde.org/unstable/applications/$pkgver/src/$pkgname-$pkgver.tar.xz"{,.sig})
So the source is in
https://download.kde.org/unstable/applications/17.11.90/src/k3b-17.11.90.tar.xz
Assuming that the tag v17.11.90 marks the state of that release in git,
i'd say the fix is already applied at
https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp?h=v17.11.90#n873
For now i am clueless why it does not burn the BD-R.
The warning is justified but it should not block burning.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #14 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
@Dr. Chapatin:
Did you verify that your K3B source does have these lines in
in
src/misc/k3bimagewritingdialog.cpp
?
if (d->foundImageType == IMAGE_UNKNOWN) {
if (KMessageBox::questionYesNo(this,
i18n("Type of image file is not
recognizable. Do you want to burn it anyway?"),
i18n("Unknown image type")) ==
KMessageBox::Yes) {
d->foundImageType = IMAGE_RAW;
d->imageFile = path;
}
}
The current git state is in
https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n873
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765 --- Comment #13 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the main riddle now is why the image is not copied to medium after the warning has been accepted and overridden by the user. @Leslie: I propose you create some dummy image file and make test with CDemu whether K3B accepts it for burning. The dummy could be e.g. a compressed tar archive. Maybe you can read and verify it from CDemu after the burn run looks successful. - > "sudo mount -t udf -o loop file.iso /mnt/imagemiso" [...] worked after > I restart my computer. If the ones say that it is not an ISO 9660 but mount can mount it as UDF, then there remains only one explanation: It is an UDF without ISO 9660 superblock. Quite exotic and not deserving the name file.iso but rather file.udf. (I only have UDFs from mkisofs and Microsoft Inc. DVDs. They all have ISO 9660 superblocks.) What do you get from mount -o loop -t iso9660 file.iso /mnt/imagemiso ? If this refuses then we really have such an UDF. Userland programmers are surprised: I am trying to decipher the magic number definition of "file" for ISO and UDF at e.g. https://sources.debian.org/src/file/1:5.32-1/magic/Magdir/filesystems/?hl=1952#L1937 It looks like the UDF/ISO 9660 distinction by "NSR0" is done only after a "CDROM Filesystem" was detected by the signature of an ISO 9660 superblock. (The latter starts the former by >0use cdrom See man 5 magic, pseudo-types "use" and "name".) K3B, too, seems to regard UDF as an extension to ISO 9660. > dd: invalid number: “” Something did not work with my proposal to determine the byte number 12 bytes before file end. Maybe you could compute it by hand and insert it into the command line dd bs=1 skip=$start count=12 if=file.iso | od -c Well, since mount -t udf works, my NRG theory loses its probability. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #10 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
regardless of the question why K3B does not recognize the image file as
ISO 9660 there stays the question whether and why it then really refuses
to write.
So please answer the question what happened after you got the warning
"Type of image file is not recognizable. Do you want to burn it anyway?"
Did you answer "Yes" ?
If you only have BD-R media, then better wait with a new attempt until we
solved the file format riddle.
If you have a BD-RE, then please repeat your burn attempt and record as
many info as possible until it really refuses (or starts to burn).
--
Now for the ISO riddle:
> My image is an ISO file.
> My ISO file system is UDF.
To all accounts it is not.
Program "file" should say "... ISO 9660 CD-ROM filesystem ..." or
"... UDF filesystem ..." if an ISO 9660 superblock was present.
(As said, UDFs have a ISO superblock which might only lead to one file
saying: "This is UDF and not ISO 9660. Mount as UDF to see more files.")
> K3b::Iso9660::openArchive no volume descriptors
That's ReadISO9660() confirming what program "file" says.
Another test would be to try to mount the image file on GNU/Linux.
I bet the reply is much like:
"mount: wrong fs type, bad option, bad superblock ..."
>From initial message
> I can mount and read the same ISO file using cdemu client.
This does not exclude .NRG:
https://wiki.archlinux.org/index.php/CDemu
states
"It enables you to use other disk image formats that contain more than
just the standard ISO-9660 filesystem, for instance .bin/.cue, .nrg,
or .ccd images. "
According to wikipedia, a .NRG file is recognizable by its final 12 bytes.
Try this:
end=$(ls -l file.iso | awk '{print $5}')
start=$(expr $end - 12)
echo $start
This should tell a large number in the range of 25 billion. Then read
12 bytes from that position of the file:
dd bs=1 skip=$start count=12 if=file.iso | od -c
If you then read "... N E R O ..." or "N E R 5 ...", then
it is an .NRG file (which probably contains your ISO/UDF).
> (K3b::CloneTocReader) could not open file
> "/mnt/WIN7/Users/Strangiato/Desktop/file.iso.toc"
> (K3b::CueFileParser) could not open file
> "/mnt/WIN7/Users/Strangiato/Desktop/file.iso.cue"
Might be that K3B looks for other input formats which it understands.
.CUE and .TOC are description files for CD layouts. They are usually
accompanied by one or more data files with payload.
Well, we already know that this is not the case here.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #6 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
another interesting point is why your image is not recognized as IMAGE_ISO
by K3B.
What do you get from command "file" ?
file /path/to/image/file
The following code reasoning and your mentioning of Nero brings me to the
suspicion that you have a .NRG image.
https://en.wikipedia.org/wiki/NRG_%28file_format%29
If not K3B can unpack it automagically, then you first need to retrieve
the image payload from the .NRG. This payload would then be an ISO 9660
or UDF filesystem image.
There is a tool named "nrg2iso". On a Debian derivate it should be available
as binary package. Like:
https://packages.debian.org/stretch/nrg2iso
--
No for my doubt that we have any kind of ISO 9660 filesystem image here:
The recognition of ISO 9660 filesystems is done in
https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n786
by
K3b::Iso9660 isoF( path );
if( isoF.open() ) {
...
d->foundImageType = IMAGE_ISO;
The .open() function is implemented in
https://cgit.kde.org/k3b.git/tree/libk3b/tools/k3biso9660.cpp#n589
Reasons for returning "false" would be
if( !m_filename.isEmpty() )
...
else if( d->fd > 0 )
...
else if( d->cdDevice ) {
...
else
return false;
or
d->isOpen = d->backend->open();
if( !d->isOpen )
return false;
or
desc = ReadISO9660( ::Iso9660::read_callback, d->startSector, this );
if (!desc) {
qDebug() << "K3b::Iso9660::openArchive no volume descriptors";
close();
return false;
The first occasion would be that not suitable pointer to the image file
is given: Neither name, nor file descriptor number, nor a CD device.
The second occasion is that opening as ISO 9660 fails.
bool K3b::Iso9660FileBackend::open()
in
https://cgit.kde.org/k3b.git/tree/libk3b/tools/k3biso9660backend.cpp#n129
looks like a C++ bloat of POSIX function open(2).
So it would fail only if there is no file or no permission to read it.
The third occasion is during inspection of the ISO 9660 filesystem
Volume Descriptors. The 2048-byte blocks are read beginning at d->startSector
until the end marking Volume Descriptor (ISO_VD_END) is read. Those sectors
which were identified as ISO 9660 superblock (ISO_VD_PRIMARY), El Torito Boot
Record (ISO_VD_BOOT), or Joliet superblock (ISO_VD_SUPPLEMENTARY) have been
put into a list.
If no such sectors were found, then the return value is NULL and triggers
the message "K3b::Iso9660::openArchive no volume descriptors".
UDF filesystems are supposed to have a ISO 9660 superblock for backward
compatibility. So an UDF image would yield a non-empty list and thus
be perveived by the caller of ReadISO9660 as IMAGE_ISO.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 387765] K3b says that blu-ray ISO is not recognizable
https://bugs.kde.org/show_bug.cgi?id=387765
Thomas Schmitt <scdbac...@gmx.net> changed:
What|Removed |Added
CC||scdbac...@gmx.net
--- Comment #5 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
this is not really the field where i am expert. C++ dyslexia and such ...
K3B issues the warning message if it encounters an image which it
classifies as IMAGE_UNKNOWN.
In the course of bug 344392, the changesets
https://cgit.kde.org/k3b.git/commit/?id=54173816164c825f077e8288b628e550b51ddccb
https://cgit.kde.org/k3b.git/commit/?id=585067b15d1d3b0d875e092c775f1925e2ba270f
https://cgit.kde.org/k3b.git/commit/?id=3d21bdca2a9ec4ef2d6226991118ba0e3f09a45a
introduced a new classification IMAGE_RAW which is set when the
warning appears and the user confirms that burning shall go on.
In my git clone of K3B and on
https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n873
i see:
if (d->foundImageType == IMAGE_UNKNOWN) {
if (KMessageBox::questionYesNo(this,
i18n("Type of image file is not
recognizable. Do you want to burn it anyway?"),
i18n("Unknown image type")) ==
KMessageBox::Yes) {
d->foundImageType = IMAGE_RAW;
d->imageFile = path;
}
}
The decisive line is the one that mentions IMAGE_RAW.
Do you have it in your local K3B source ?
The consequence of this setting should be in
https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n707
as
case IMAGE_RAW:
case IMAGE_ISO:
{
...
K3b::Iso9660ImageWritingJob* job_ = new K3b::Iso9660ImageWritingJob(
);
Do you see this double "case" statement in your local source ?
-
If the local code is up to date, then we need more information.
- How does the program react after you confirm that the image shall be
burned indeed ? Any further messages ?
- Does
d->foundImageType = IMAGE_RAW;
get executed after the warning dialog ?
(A debug message would bring clarity.)
- Does program execution get to
https://cgit.kde.org/k3b.git/tree/src/misc/k3bimagewritingdialog.cpp#n658
If so, what is the value of
d->currentImageType()
?
(A debug message before
switch( d->currentImageType() ) {
could bring clarity.)
-
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 384750] Progress bars don't work when I save a project to an ISO file
https://bugs.kde.org/show_bug.cgi?id=384750 --- Comment #17 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > I changed "Formats" to en-US in KDE regional settings (I wonder how it looks if you choose Inuit or Samaritan Aramaic.) > progress bars are working now. So the cheapest, but possibly incomplete, fix would be to replace commas by decimal points in int K3b::MkisofsHandler::parseMkisofsProgress( const QString& line ) of libk3b/projects/datacd/k3bmkisofshandler.cpp before interpreting the number by double p = perStr.toDouble( ); If one wants to prepare for xorrisofs, then one should submit to the converter function .toDouble() the text beginning at its first digit or decimal point. A complete solution for mkisofs would be either to decode numbers with i18n in mind, or to prevent i18n of mkisofs. The latter seems to be the better solution in respect to preventing other i18n surprises and in order to keep the debugging output of mkisofs readable for international developers. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 384750] Progress bars don't work when I save a project to an ISO file
https://bugs.kde.org/show_bug.cgi?id=384750 --- Comment #15 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > 0,08% done, estimate finish Thu Dec 7 07:05:20 2017 I guess the comma instead of the decimal point is to blame. It probably stems from internationalization (i18n) which could be a new feature in mkisofs-3.x. One could test the theory by testing whether QString perStr = "0,08"; bool ok; double p = perStr.toDouble( ); yields (ok == false) or 0.0 as resulting number. (Sorry, i don't have enough KDE/Qt for testing this.) The reverse test could be to set the environment for english language before starting K3B: export LANGUAGE=en_US:en /usr/bin/k3b mkisofs should then emit decimal points rather than commas. I assume that mkisofs uses GNU gettext which would use that variable. See https://www.gnu.org/software/gettext/manual/html_node/Locale-Environment-Variables.html If the theory is right, then K3B needs internationalization for its own number decoding, or it needs to set mkisofs to english language and number formats. (xorriso is intentionally not using i18n. It is painful to analyse the output of the own program when all words are replaced by a language which i do not know.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 384750] Progress bars don't work when I save a project to an ISO file
https://bugs.kde.org/show_bug.cgi?id=384750 Thomas Schmitt <scdbac...@gmx.net> changed: What|Removed |Added CC||scdbac...@gmx.net --- Comment #13 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the function to read the progress percentage, parseMkisofsProgress in libk3b/projects/datacd/k3bmkisofshandler.cpp, obviously expects that no other text is written before the percent number. Like in 1.29% done, estimate finish Mon Sep 25 11:04:34 2017 This would not work with xorrisofs messages xorriso : UPDATE : 0.54% done, estimate finish Wed Dec 06 14:27:33 2017 @Dr. Chapatin: Can you show a progress line from mkisofs 3.2a07 (or any other that causes the lack of progrss bar) ? It should be in the K3B log or may get produced by a shell terminal run like mkisofs -v -o /dev/null /...some.big.directory.tree... > $ rpm -qf /usr/bin/mkisofs > genisoimage-1.1.11-31.fc24.x86_64 > xorriso-1.4.8-1.fc25.x86_64 I actually discourage distros to install xorriso as "mkisofs". That would rather be a decision of the end user after considering all desired use cases. But if Fedora does this, then K3B should better prepare for decoding xorrisofs pacifier lines. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 385667] K3B doesn't close Blu-ray discs correctly
https://bugs.kde.org/show_bug.cgi?id=385667 --- Comment #5 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i cannot find the message text "APPENDABLE DATA ERROR" in the current K3B source. Please post the original message. Also please post the output of program run dvd+rw-mediainfo /dev/sr0 when one of the problematic BD-R media is inserted. (I assume that your drive has address /dev/sr0. If you have more than one, then it could be /dev/sr1, /dev/sr2, ...) If you burn some BD-R medium again, then please ishow the growisofs command line, which K3B used, and the other debug messages. growisofs keeps most media types appendable by default. But afaik, K3B adds options like -dvd-compat which would cause closing of the medium. There is a bug in original growisofs about the end of a BD-R burn run. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713016 But that is supposed not to spoil the medium but to only let growisofs report failure to its caller. (Thus i deem it a candidate for bug 387599.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387599] K3B won't close after copying
https://bugs.kde.org/show_bug.cgi?id=387599 Thomas Schmitt <scdbac...@gmx.net> changed: What|Removed |Added CC||scdbac...@gmx.net --- Comment #2 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i doubt that this is a duplicate of bug 385667. It could be a consequence of the known growisofs bug at the end of a burn run to a previously blank BD-R medium: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713016 https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1113679 This bug is supposed not to damage the burn result, because the failed SCSI transaction was not necessary. But it will cause growisofs to return with non-zero exit value and thus make K3B believe that the burn run failed. The fix in the Debian bug report is tiny. If you have growisofs source code then consider to apply it. Else urge your distro maintainers to apply it to their growisofs package. As workaround you could format the BD-R medium by program dvd+rw-format before you give it to growisofs for burning. This will cause growisofs to omit the offending SCSI transaction. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387384] Rewritable media is not cleared on burn
https://bugs.kde.org/show_bug.cgi?id=387384 --- Comment #18 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, Dr. Chapatin wrote: > K3b should prevent this situation and/or show a better warning when it > occurs. At least the little window should not hide parts of the text which tells which kind of medium is expected. (I see that i forgot to mention that "Finish multisession" would expect an "Incomplete" medium and finally convert it into a "Complete" medium.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387384] Rewritable media is not cleared on burn
https://bugs.kde.org/show_bug.cgi?id=387384 --- Comment #16 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, Dr. Chapatin wrote: > On Arch Linux sometimes K3b asks for a "suitable medium" even when an empty > cd-rw is already inserted. > Is this situation related to the problem described here? The bug fixed here is only about BD media. So: no. Your screenshot shows a text "Searching for old ses" which i assume is the start of "Searching for old session". The small window says to have found an "Empty CD-RW medium". Such a CD-RW cannot bear an old session to be found and loaded for appending a new session based on the old one. Is it possible that you checked "Continue multisession" in the "Settings" tab of the "Data Project" dialog. The web has screenshots like https://www.granneman.com/files/2713/1493/5335/k3b-Data-Project-Burn-Settings.gif I expect "No multisession" to demand an empty medium and to close it after writing, whereas "Start multisession" expects an empty medium too but will not close it and thus enable "Continue multisession" for this medium for further sessions. The medium for "Continue multisession" must be classified by K3B as "Incomplete" (or "Complete" if it's formatted). Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387384] Rewritable media is not cleared on burn
https://bugs.kde.org/show_bug.cgi?id=387384 --- Comment #13 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, Aloysius wrote: > Is that all that is required in case one wanted to backport the fix to 17.08 > and 17.04 ? Good question. That bug report has a long discussion ... We have the two occurences in https://cgit.kde.org/k3b.git/commit/?id=329c969be1dbc3455d65925bcad32f4df3a5b428 which i already proposed and you already implemented. Then there is the one in https://cgit.kde.org/k3b.git/commit/?id=a359173975e574c4cae62214f7de28648d14167c for function K3b::Device::MediaTypes K3b::VideoDvdDoc::supportedMediaTypes(). (We did not test this one. Blu-ray movie is an adventure on its own.) All other code changes in these two commits are about debugging only and supposed to have been removed meanwhile. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387384] Rewritable media is not cleared on burn
https://bugs.kde.org/show_bug.cgi?id=387384 --- Comment #12 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i wrote: > > - mt = K3b::Device::MEDIA_WRITABLE_DVD; > > + mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD; > > > > - mt = K3b::Device::MEDIA_WRITABLE_DVD; > > + mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD; Aloysius wrote: > Adding this definitely fixed the problem, thank you very much. So this is really a duplicate of bug 381074. Quite a surprise to me. But it matches my confusion about the way how the data project job would cope with formatted media. It requests STATE_EMPTY and not STATE_COMPLETE. So the proposed intelligence seems to be already present and i am not smart enough to recognize it. Well, next time ... Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387384] Rewritable media is not cleared on burn
https://bugs.kde.org/show_bug.cgi?id=387384 --- Comment #9 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i wrote: > > dvd+rw-mediainfo /dev/sr0 when the DVD-RW is inserted Aloysius wrote: > See attached log. But https://bugsfiles.kde.org/attachment.cgi?id=109147 is from a BD-RE medium. My question was about the formatting state of the DVD-RW. > > dvd+rw-format /dev/sr0 > See attachment. Unless you actually want me to go through with the > full format. Not with BD-RE. The proposal was for DVD-RW in case that it is not formatted. (The formatting run can last as long as a full write run with maximum speed.) The BD-RE is in formatted state and thus dvd+rw-format correctly did not change it. No need to re-run with option -force. > https://bugsfiles.kde.org/attachment.cgi?id=109148 This reminds me of the bug with image burning where K3B did not recognize empty BD-R media for writing of media image files (data projects worked well). https://bugs.kde.org/show_bug.cgi?id=381074 Decisive fix was in https://cgit.kde.org/k3b.git/commit/?id=329c969be1dbc3455d65925bcad32f4df3a5b428 by the two changes in K3b::Iso9660ImageWritingJob::startWriting(): - mt = K3b::Device::MEDIA_WRITABLE_DVD; + mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD; - mt = K3b::Device::MEDIA_WRITABLE_DVD; + mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD; So, Leslie and Aloysius, please find out whether Aloysius' K3B already has this fix. If not, then we need to explain why a first burn run on BD-RE succeeded. Was it by chance a data project (composed from several files) rather than an image burn run (only one file involved, typically with suffix ".iso") ? If the fix is already applied, then my next best candidate would be in line 268 of file jobs/k3biso9660imagewritingjob.cpp : Device::MediaType media = waitForMedium( m_device, K3b::Device::STATE_EMPTY, mt, K3b::imageFilesize( QUrl::fromLocalFile(m_imagePath) )/2048 ); I understand this wants medium state STATE_EMPTY whereas the BD-RE is reported as STATE_INCOMPLETE (i assume from the word "COMPLETE" in the screenshot). This state is indeed reported by the drive (and complies to the SCSI specs): Mounted Media: 43h, BD-RE ... Disc status: complete But with formatted media it does not mean that one could not write an image to the medium beginning at block 0. So for a test, but not as final solution, one could change the line to Device::MediaType media = waitForMedium( m_device, K3b::Device::STATE_EMPTY | K3b::Device::STATE_COMPLETE, K3b::imageFilesize( QUrl::fromLocalFile(m_imagePath) )/2048 ); and check whether it works with BD-RE and other formatted media. In this case the first burn would have worked because the BD-RE was not yet formatted and thus STATE_EMPTY. As final solution, one would have to make K3B smarter, so that it takes into respect the purpose of the job and the formatting state of the medium. E.g. that it takes STATE_COMPLETE as alias of STATE_EMPTY if the medium is DVD-RAM, DVD+RW, or BD-RE and shall be written from scratch. Possibly we can learn from the data project code. - The DVD-RW problem cannot stem from bug 381074. But if the cause for the BD-RE problem is the missing acceptance for STATE_COMPLETE, then this would also apply to formatted DVD-RW: Mounted Media: 13h, DVD-RW Restricted Overwrite ... Disc status: complete Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 387384] Rewritable media is not cleared on burn
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
it would also be interesting to see whether the DVD-RW medium is formatted.
BD-RE media are always formatted, but DVD-RW can be used unformatted and
then need a blanking run to get re-usable.
Formatted media can be overwritten without precautions. One just has to
convince the burn program that one does not want to keep the old content.
-
Questions to Aloysius:
So what do you get from the shell command
dvd+rw-mediainfo /dev/sr0
when the DVD-RW is inserted and the tray already loaded ?
Do you get any user prompt to decide about overwriting of BD-RE:
"Found BD-RE medium in [...burner name...] Should it be overwritten?"
Does K3B work better with your DVD-RW if you format it by this shell command ?
dvd+rw-format /dev/sr0
(If it is already formatted it will refuse. That would be ok then.)
-
Code inspection:
Strangely, libk3b/jobs/k3bblankingjob.cpp only talks of CD-RW, not of
DVD-RW media. CD-RW and unformatted DVD-RW are the only media types
which need real SCSI blanking.
The handling of used media is probably in src/k3bemptydiscwaiter.cpp
function K3b::EmptyDiscWaiter::slotMediumChanged().
For BD-RE it does:
// check if the media contains a filesystem
If it finds an ISO 9660 filesystem (with or without UDF parasite filesystem)
then it is supposed to ask by
KMessageBox::warningContinueCancel( parentWidgetToUse(),
i18n("Found %1 medium in %2 - %3. Should it be overwritten?",
This happens only if the medium is perceived in state Device::STATE_EMPTY.
If the BD-RE is not perceived as STATE_EMPTY then it seems that an add-on
ISO 9660 session will get appended to the medium.
I still have to find out how K3B perceives BD-RE writability state. On
hardware level there are only two states: unformatted and formatted.
The CD states "empty/blank", "appendable", and "closed" do not apply to
formatted media.
Now for DVD-RW.
slotMediumChanged() has:
// DVD-RW in sequential mode can be empty. DVD-RW in restricted overwrite
mode is always complete.
(The obscure names "seq. incr." and "restr. ovw." mean unformatted and
formatted, repectively.)
Formatted DVD-RW with an ISO 9660 filesystem should cause a user prompt
like with BD-RE:
i18n("Found %1 medium in %2 - %3. "
"Should it be overwritten?",
I see no code path which would cause blanking of an unformatted DVD-RW.
-
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 386401] "Continue Multisession Project" don't work
https://bugs.kde.org/show_bug.cgi?id=386401 Thomas Schmitt <scdbac...@gmx.net> changed: What|Removed |Added CC||scdbac...@gmx.net --- Comment #2 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, Leslie Zhai wrote in Bug report 367639: > Thanks a lot for your Multi-Session help :) If i only would better understand the C++ oriented architecture of K3B. When looking for the code which controls the multi-session "import", i get quite lost. Only guideline is my backend knowledge. (The fog gets thinner when i see media type names or SCSI specific terms.) Up to now i only found an otherwise suspicious spot in line 155 of src/projects/k3bdatamultisessionimportdialog.cpp where K3B looks for MEDIA_DVD_PLUS_RW and MEDIA_DVD_RW_OVWR but not for the similarly behaving types BD-RE and DVD-RAM. (Now i wonder why multi-session on BD-RE is reported to be possible. Maybe i am looking at the wrong spot in the code ...) Whatever, we talk here about DVD+R which is a multi-session medium on hardware level that should be perceived as STATE_INCOMPLETE if it is already written and still appendable. But the code piece, where the dialog causes the start of a mkisofs run, is still on my to-search list. I.e. what code is executed after sebastian's step 4 ? > 4) I choose the last session then I press "OK" > =>Result: nothing happens Leslie wrote: > @sebastian > Please test as Thomas suggested, the simulator is not able to reproduce > Multi-Session environment. Somebody should donate to Leslie a DVD burner in a USB box and a few media. My suggestion was to run in a shell terminal while the DVD+R is already inserted in the drive: dvd+rw-mediainfo /dev/sr0 and to show the output text of that program run. (If you have more than one optical drive, then it could also be /dev/sr1 or even a higher number.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 367639] k3b fails to continue multisession (blue ray)
https://bugs.kde.org/show_bug.cgi?id=367639 --- Comment #59 from Thomas Schmitt <scdbac...@gmx.net> --- 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 -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 384471] Media type selection for Image burning is partly wrong, comments are very wrong
https://bugs.kde.org/show_bug.cgi?id=384471 --- Comment #5 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the new commit looks good to me. If we do not jump into the adventure of verifying the implicit assumptions about media types and write modes, then this bug report can be closed. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 384471] Media type selection for Image burning is partly wrong, comments are very wrong
https://bugs.kde.org/show_bug.cgi?id=384471 --- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, looks ok for me, besides another mistake by me: K3b::WritingAppCdrdao is not a complete criterion for the need for CD. The criterion in the code is distributed over two if-statements. As one statement it is: (m_writingMode == K3b::WritingModeAuto || m_writingMode == K3b::WritingModeSao) && writingApp() == K3b::WritingAppCdrdao So comment 1 should become: 1. If special CD features are requested: CD types only Special are: K3b::WritingAppCdrdao with K3b::WritingModeAuto or K3b::WritingModeSao, any WritingApp with K3b::WritingModeTao, any WritingApp with K3b::WritingModeRaw Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 384471] Media type selection for Image burning is partly wrong, comments are very wrong
https://bugs.kde.org/show_bug.cgi?id=384471 --- Comment #1 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, already the first bug in my bug report. Implemented decision 5 is indeed: 5. If not decided yet: DVD and BD media types. This seems to assume that all CD use cases are completely covered by the previous decisions. If i was in charge i would allow all media types and let the media waiter decide by the requested size and the size of the inserted media type. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 384471] New: Media type selection for Image burning is partly wrong, comments are very wrong
https://bugs.kde.org/show_bug.cgi?id=384471
Bug ID: 384471
Summary: Media type selection for Image burning is partly
wrong, comments are very wrong
Product: k3b
Version: unspecified
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: k...@kde.org
Reporter: scdbac...@gmx.net
CC: mich...@jabster.pl, tr...@kde.org
Target Milestone: ---
Hi,
K3b::Iso9660ImageWritingJob::startWriting() inapropriately accepts DVD+R for
m_writingMode == K3b::WritingModeRestrictedOverwrite :
https://cgit.kde.org/k3b.git/tree/libk3b/jobs/k3biso9660imagewritingjob.cpp#n261
else if( m_writingMode == K3b::WritingModeRestrictedOverwrite ) {
mt =
K3b::Device::MEDIA_DVD_PLUS_R|K3b::Device::MEDIA_DVD_PLUS_R_DL|K3b::Device::MEDIA_DVD_PLUS_RW|K3b::Device::MEDIA_DVD_RW_OVWR;
Restricted Overwrite a speciality of formatted DVD-RW.
"Overwrite" like with DVD-RAM, DVD+RW, BD-RE. "Resctricted" because only
full chunks of 32 KiB may be written.
The allowed gestures are also allowed with DVD+RW, DVD-RAM, BD-RE.
But it is not compatible with DVD+R or DVD+R DL.
So, after due checking whether WritingModeRestrictedOverwrite really
means what its name suggests, all types except formatted DVD-RW should be
removed from the "mt" list.
If one wants to allow DVD+RW, then also DVD-RAM and BD-RE should be allowed.
(In general i wonder why K3B already knows the future write type but not the
medium type yet. Must be a GUI precognition thing.)
--
The comment in line 236 ff. is obviously outdated. The choice of wanted DVD
(and now BD) does not depend on the use of growisofs. The comment lists 10
decisions or remarks:
1. Ok. (but obviously writing app is not auto)
2. Wrong. The code looks for cdrdao as writing app, not for "not growisofs".
3. Wrong. If not cdrdao and not d->isDvdImage, then all media (including BD)
4. Ok.
5. No such code is to see.
6. No such code is to see.
7. No such code is to see.
8. No such code is to see.
9. Wrong. DVD+R and DVD+R DL are accepted inappropiately.
DVD+RW is ok, but misplaced here, nevertheless.
10. obsolete, now that Bug 381074 is fixed.
In the code i see currently these five decisions:
1. If special CD features are requested: CD types only
Special are: K3b::WritingAppCdrdao , K3b::WritingModeTao , WritingModeRaw
2. If formatted DVD-RW is requested: formatted DVD-RW, DVD+R, DVD+R DL, DVD+RW
Request is: K3b::WritingModeRestrictedOverwrite
3. If image is larger than 900 MiB (d->isDvdImage == true): DVD or BD types
See K3b::Iso9660ImageWritingJob::start()
4. If image not larger than 900 MiB: All media types
5. If not decided yet: All media types
After fixing my objection above, number 2 should become
2. If formatted DVD-RW is requested: formatted DVD-RW only
Request is: K3b::WritingModeRestrictedOverwrite
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #82 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > now in the official patch only a line is edited > https://cgit.kde.org/k3b.git/commit/?id=a359173975e574c4cae62214f7de28648d14167c This is not the fix for Bug 381074 but rather the cleanup after the fix plus a courageous move to allow BD media for "VideoDvdDoc" which talks of the typical filesystem structures of Video DVD. E.g. directory "VIDEO_TS". The decisive bug fix changeset is https://cgit.kde.org/k3b.git/commit/?id=329c969be1dbc3455d65925bcad32f4df3a5b428 where Leslie and i would still need to discuss the outdated comments. We'd both need to practice with git in order to keep the experiments away from the final fix. -- As for the courage in above changeset: The format requirements for Blu-ray Video differ from DVD video. With much caution read and compare https://en.wikipedia.org/wiki/Blu-ray#Data_format_standards https://en.wikipedia.org/wiki/DVD-Video and keep in mind that these requirements only apply to consumer electronics (aka "living room") video players. With general data storage or with video files which your computer can play from hard disk, there is no need to use UDF as filesystem or to have a "BDMV" directory. I know of no free tool on GNU/Linux which would produce the prescribed format for Blu-ray video. If K3B and its helper programs can do, i'd like to learn a URL to which i can send people who ask for Blu-ray video. - @Leslie: Maybe an amateurish idea, but how about you revoke all three new "| K3b::Device::MEDIA_WRITABLE_BD". I.e. the two fixes and the courageous one. Also remove comment "10" above the two bug fix lines. It is outdated now. Then commit the two MEDIA_WRITABLE_BD lines in https://cgit.kde.org/k3b.git/commit/?id=329c969be1dbc3455d65925bcad32f4df3a5b428 as official fix of Bug 381074. Leave out comment "10" and the qDebug(), of course. If you feel still ok with the MEDIA_WRITABLE_BD in k3bvideodvddoc.cpp, then better commit it separately. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #79 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the outcome of the sha512sum run indicates full success as far as K3B is concerned. This bug is indeed completely done. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 384443] [MATSHITA BD-MLT UJ240AS] It does not record its maximum speed
https://bugs.kde.org/show_bug.cgi?id=384443 --- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> --- I meant "the only sure way to bring BD-RE to full speed". Some few drives burn at full speed if there is no Spare Area with replacement blocks. -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 384443] [MATSHITA BD-MLT UJ240AS] It does not record its maximum speed
https://bugs.kde.org/show_bug.cgi?id=384443 Thomas Schmitt <scdbac...@gmx.net> changed: What|Removed |Added CC||scdbac...@gmx.net --- Comment #2 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the low effective speed is not a bug but a feature of formatted BD-R media. During writeing the freshly written blocks are read and compared with the data which are still in the drive buffer. This frequent change between writing and reading slows down overall speed. Especially if reading is not very successful. I.e. very low effectiive speed indicates a bad relation between drive and medium and announces failure to come soon. https://bugs.kde.org/attachment.cgi?id=107725 looks like good relation for 4x speed and mediocre for 6x speed. You may ask the drive with an unused medium for the speed list by dvd+rw-mediainfo /dev/sr0 which will reply something like Write Speed #0:8.0x4495=35968KB/s Write Speed #1:6.0x4495=26976KB/s Write Speed #2:4.0x4495=17984KB/s - Defect management can be avoided on BD-R media by adding -use-the-force-luke=spare=none to the list of extra options for growisofs. It will then skip formatting the BD-R medium before writing begins. In my olde Debian 8 K3B this would be: Pulldown menu: Settings Item: Configure K3B Side bar icon: Programs Tab: User Parameters Line: growisofs Click at column: Parameters Write the text: -use-the-force-luke=spare=none The BD-R will have full nominal capacity and will be burnt at increasing speed up to reaching full nominal speed near the end. Noise might be substantial. On BD-RE it cannot be avoided to format the medium. Above option might or might not lead to full speed. The medium will have nominal capacity. The only way to bring BD-RE to full speed is the option stream_recording=on of backend program cdrskin (or command -stream_recording of xorriso, or burn option Stream Recording in Xfburn). Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 380067] [MATSHITA BD-MLT UJ240AS] :-( unable to WRITE@LBA=6d9a00h: Input/output error
https://bugs.kde.org/show_bug.cgi?id=380067 --- Comment #52 from Thomas Schmitt <scdbac...@gmx.net> --- 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 -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #77 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, forget my first question whether the burn run ended successfully. I just found https://bugsfiles.kde.org/attachment.cgi?id=107723 which looks very good. Effective speed around 2x with Defect Management enabled indicates a good relation between drive and medium So there only remains the question whether the BD-R yields the same blocks as written (plus some trailing garbage which we keep dd from reading by the "count=" option). This will be answered by the run of dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #76 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i forgot to mention that dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum will last about 1200 seconds at average 4x read speed and probably make some noise when it reaches 6x or 8x speed near the end. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #75 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > Help... I am riddling what we see with your fgrep run. Did you copy+paste my fgrep line together with my three output lines ? Somehow the shell "bash" tried to execute the lines which were found by my local fgrep. Your local fgrep found only one, probably because Leslie's change is already in your local K3B git copy. bash complains about non-existence of the files instead of complaining about lack of x-permission. This is because my fgrep output lines have the filenames with trailing ':'. They only exist without that ':'. Whatever, this is not related to K3B's functionality. Actually i did not expect that you execute that fgrep yourself. I was just showing the query by which i found the decisive spot in the code. Important to K3B would be the questions: - Did the burn run with the Debian ISO succeed ? (Your image https://bugsfiles.kde.org/attachment.cgi?id=107724 shows it at 68 percent.) - Did you already verify the result as proposed by Debian CD FAQ ? https://www.debian.org/CD/faq/#verify I translate it to these shell commands: /sbin/isosize -x debian-9.1.0-amd64-BD-1.iso which is supposed to say: sector count: 11223478, sector size: 2048 and dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum which is supposed to say: 81761e602af6d0e0ffde2d102c706c220e9ff0d31a612ea9ae1db1688c24cdf2a0bf45f02f738dc96651a5a64ae22d60527fe15549a195ab692b66bd669ea1d5 - according to https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/SHA512SUMS If the SHA-512 sum is not 8176...a1d5, then compute the SHA-512 of the ISO by sha512sum debian-9.1.0-amd64-BD-1.iso to verify that the .iso image indeed yields the announced 8176...a1d5 If both answers are "yes", then the next quesition would be whether it boots on your machine. If "no" then it would not be K3B's fault, but i myself would be the one to inspect the boot process until the first Debian logo appears. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #71 from Thomas Schmitt <scdbac...@gmx.net> --- > Now the qDebug() statements about "Bug 381704" need to be removed. Oops. Number flip. qDebug() statements about "Bug 381074", of course. -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #66 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > I get lost ... Please tell me to download the commit Excuse my enthusiasm. :)) And forget about the qDebug() proposal of Comment 62 for now. Edit file libk3b/jobs/k3biso9660imagewritingjob.cpp There are two lines (253 and 264) which each say mt = K3b::Device::MEDIA_WRITABLE_DVD; Those match what your qDebug() reported as "wanted": Any kind of DVD. We want to accept any kind of BD, too. So change both lines to mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD; build K3B and try whether it now accepts your BD-R. (And also lists "BD-R Sequential (SRM)" among the "wanted" media types.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #64 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, if the change in line 264 does not help, try the same in line 252 ff.: else if( d->isDvdImage ) mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD; Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #63 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i found a suspect:
https://cgit.kde.org/k3b.git/tree/libk3b/jobs/k3biso9660imagewritingjob.cpp#n232
void K3b::Iso9660ImageWritingJob::startWriting()
{
...
else {
mt = K3b::Device::MEDIA_WRITABLE_DVD;
}
And no MEDIA_WRITABLE_BD !
This would mean it happens only with image writing but not with
Data Composition. A good explanation why K3B can claim BD capability since
years but does not work for Cristian's use case.
The fog rises up.
---
Coarse test proposal:
Add (actually "or") unconditionally K3b::Device::MEDIA_WRITABLE_BD to mt.
else {
mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD;
}
Does this change appease that nasty "give me a 21.4 GiB medium" window ?
If this works, then Leslie and i have to riddle whether this is the
final solution and thus what this piece of code does. I have some idea
but that would have to be verified.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #62 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
do we get through this piece of code ?
https://cgit.kde.org/k3b.git/tree/libk3b/projects/datacd/k3bdatajob.cpp#n699
bool K3b::DataJob::waitForBurnMedium()
{
// start with all media types supported by the writer
Device::MediaTypes m = d->doc->supportedMediaTypes() &
d->doc->burner()->writeCapabilities();
Please put qDebug() statements in there
qDebug() << "Bug 381074: supportedMediaTypes: "
<< d->doc->supportedMediaTypes();
qDebug() << "Bug 381074: writeCapabilities: "
<< d->doc->burner()->writeCapabilities();
--
Where i got lost so far:
The detected writeCapabilities() are probably reported in the newest
attachment of cristian:
https://bugsfiles.kde.org/attachment.cgi?id=107704
as
Write Cap: "DVD-R, DVD-R Sequential, DVD-R Dual Layer,
DVD-R Dual Layer Sequential, DVD-RW, DVD-RW Restricted Overwrite,
DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-R, CD-RW, BD-R,
BD-R Sequential (SRM), BD-R Sequential Pseudo Overwrite (SRM+POW),
BD-R Random (RRM), BD-RE"
So for d->doc->supportedMediaTypes().
Is it this one ?
https://cgit.kde.org/k3b.git/tree/libk3b/projects/datacd/k3bdatadoc.cpp#n1516
K3b::Device::MediaTypes K3b::DataDoc::supportedMediaTypes() const
{
return Device::MEDIA_WRITABLE;
}
I find MEDIA_WRITABLE in
https://cgit.kde.org/k3b.git/tree/libk3bdevice/k3bdevicetypes.h#n266
MEDIA_WRITABLE_BD = MEDIA_REWRITABLE_BD |
MEDIA_BD_R |
MEDIA_BD_R_SRM |
MEDIA_BD_R_SRM_POW |
MEDIA_BD_R_RRM,
...
MEDIA_WRITABLE = MEDIA_WRITABLE_CD |
MEDIA_WRITABLE_DVD |
MEDIA_WRITABLE_BD,
So the absence of BD media types in "wanted" stays a riddle.
--
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #61 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, this qDebug and its "<<" methods are a little debugger on its own. I would have expected some hex number which we'd need to decipher to a list of media types. But this is comfortable. Pinching my eyes: > Bug 381074: wanted: [...] > "DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential, > DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite, > DVD-RW Sequential, DVD+RW, DVD+R, DVD+RW Dual Layer, DVD+R Dual Layer" There is neither BD-RE nor BD-R in the list, is it ? > Bug 381074: found: > "BD-R Sequential (SRM)" "empty medium" 12219392 Correctly recognized and obviously blank with still full capacity. If only the "wanted" list would contain it. So the next question is why the EmptyDiscWaiter object was not properly programmed to accept BD media before it called slotMediumChanged(). I will dig. Everybody else is invited to dig too and to insert prints where this programming is done. (I dimmly remember to have visited that code piece. Must re-read this whole thread now.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #57 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > * k3b_log_file.txt is empty So those messages came out of stderr, not stdout. It may be that macro K3B_DEBUG is not defined and thus the qDebug() statements did not get compiled. Try what happens if you remove the line #ifdef K3B_DEBUG before the qDebug() statements and the line #endif after them. Maybe we get to see new interesting compiler messages. X-| There may be the need for enabling qDebug at run time. But i find few in the web. Maybe https://bugzilla.redhat.com/show_bug.cgi?id=1227295#c32 (When is it morning where Leslie lives ? I'm overdue for bed.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #54 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, those warnings are kind of a reminder of a developer who did not finish his work yet. If no error messages appear, then k3b is probably ready to run. But don't ask me where the executable program file is now. I am really balancing at the edge of my knowledge here. Leslie ! Help ! Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #52 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > What log? I can only guess where qDebug() messages show up. The web talks of "application output". An example on http://www.qtcentre.org/threads/19534-redirect-qDebug%28%29-to-file indicates that it is normal "standard output"i, i.e. the start terminal. So try in a shell terminal window k3b | tee -i /tmp/k3b_log_file and after the run look into file /tmp/k3b_log_file . > Are the changes correct? They are half of what we need: The "found" part. You also need to print the "wanted" info. (Something between them does not match. I just have no idea yet what it could be. Need to see.) So add also qDebug() << "Bug 381074: wanted: " << __PRETTY_FUNCTION__ << d->wantedMediaType << d->wantedMediaState << d->wantedMinMediaSize.lba(); directly before or after the printing of "found". Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #49 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, there is no need to upload. Just change the code, build K3B, and test what it reports. If you find the messages in the log, then show them together with the code piece by which you printed it. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #48 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, if you feel adventurous enough: I propose something like qDebug() << "Bug 381074: wanted: " << __PRETTY_FUNCTION__ << d->wantedMediaType << d->wantedMediaState << d->wantedMinMediaSize.lba(); qDebug() << "Bug 381074: found: " << __PRETTY_FUNCTION__ << medium.diskInfo().mediaType() << medium.diskInfo().diskState() << medium.actuallyRemainingSize().lba(); I now understand that __PRETTY_FUNCTION__ is supposed to print the name of the function the qDebug() statement is in. So the message text is not as hard to find, as i first thought. The function name should be "slotMediumChanged()". Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #44 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the changeset is labeled "master". So i assume git clone git://anongit.kde.org/k3b or in a cloned directory of git://anongit.kde.org/k3b git pull Then build and run with a blank BD-R (check by dvd+rw-mediainfo if in doubt). After seeing the window which demands BD-R, look in the log whether you can see a message that begins by "DEBUG:". - @Leslie: A more significant constant text like "Bug 381074:" would help to recognize the texts from your change. Where exactly should Cristian look for those texts ? Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #42 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
we not only need to know the wanted properties but also the properties
which K3B sees as present at that point in the code.
To my understanding that would be:
medium.diskInfo().mediaType()
medium.diskInfo().diskState()
medium.actuallyRemainingSize()
Further the "Msf" size class has multiple aspects. For comparison it uses
the aspect Msf.lba(), afaics. ("Minute,second,frame" is an old CD sector
address form. DVD and BD only get addressed by Logical Block Address.)
So i would print
medium.actuallyRemainingSize().lba()
d->wantedMinMediaSize.lba()
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #39 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, just to summarize the riddle we are trying to solve: K3B reports to see an empty BD-R medium but in the same window demands to get fed by an empty medium of at least 21.4 GiB. An empty (in SCSI/MMC terms: "blank") BD-R should fulfill this demand. dvd+rw-mediainfo confirmed before the try that the medium is blank, offers 22.5 GiB in its default formatting size, or 23.3 GiB unformatted. So why doesn't K3B accept it ? Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #38 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, @Cristian: Leslie asks you to run K3B under control of the program gdb, to set a "breakpoint" at line 257 of k3bemptydiscwaiter.cpp, and to let gdb print the desired variable content when it stops execution at that breakpoint. The desired info is listed in https://bugs.kde.org/show_bug.cgi?id=381074#c15 after my naive proposal to Leslie that he could try to reach the interesting location in the K3B code by help of CDEmu. @Leslie: We should concentrate on exploiting Cristian's willingness to build and run K3B, not try to give him a quick course in debugging. Can you make a git branch for Cristian and make a code change which prints the desired info in a user-visible way ? (Then post the git command line which fetches it. At least for me that would be necessary.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #34 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i just did a git pull in my clone from git://anongit.kde.org/k3b.git and cannot see any related commit by git log. Can you point me to the changeset which puts the print statements into the code ? (My proposals are in https://bugs.kde.org/show_bug.cgi?id=381074#c15 ) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #30 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, are the proposed print commands already in place ? If so, how would they look ? Are they supposed to show up in https://bugs.launchpad.net/k3b/+bug/1713485/+attachment/4940133/+files/JournalErrors.txt ? Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #24 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i am out of ideas, except that Leslie prepares a test version of K3B by which Cristian can build and test. It should show the information mentioned in https://bugs.kde.org/show_bug.cgi?id=381074#c15 I am not aware how difficult it is to build K3B from git and provide it with all required libraries. Being on Debian 8 and using fvwm2 as window manager, i assume to be 1 or 2 lightyears away from that goal. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #22 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > BD R empty > https://bugs.kde.org/attachment.cgi?id=107536 Indeed. Unformatted and unused. Does this medium produce the messages from https://bugsfiles.kde.org/attachment.cgi?id=106037 when you try to burn the Debian ISO onto it ? Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #20 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the given BD-R medium is not blank but rather seems to have been used already with growisofs. Only growisofs formats BD-R to state SRM+POW: Mounted Media: 41h, BD-R SRM+POW The first track is completely written: READ TRACK INFORMATION[#1]: Track State: partial incremental Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:11560096*2KB The remaining space is about 1 GIB: READ TRACK INFORMATION[#2]: Track State: invisible incremental Track Start Address: 11560096*2KB Next Writable Address: 11560096*2KB Free Blocks: 528224*2KB Track Size:528224*2KB The peculiar formatting causes an optimistic reply about the number of readable blocks. It includes written and unwritten capacity: READ CAPACITY: 12088320*2048=24756879360 - This medium is indeed not suitable for a burn run of 21.4 GiB. You need to insert a new one that was never burnt. dvd+rw-mediinfo should report something like ... READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty "Next" Track: 1 Number of Tracks: 1 ... READ TRACK INFORMATION[#1]: Track State: invisible incremental Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 12219392*2KB Track Size:12219392*2KB READ CAPACITY: 0*2048=0 - If this is the medium that caused this bug report, then there remains the riddle why https://bugsfiles.kde.org/attachment.cgi?id=106037 shows the text "Empty BD-R medium" It should say something like "Appendable BD-R medium". (And can it be that the english text "size 21,4 GiB" in the image bears a german decimal comma ? Pinching eyes ...) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074 --- Comment #18 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, if there is no simple code change which circumvents that size check, then you will have to prepare the printing of the decision criteria for Cristian, so that he can try. With the data type "Msf" of d->wantedMinMediaSize and medium.actuallyRemainingSize() i propose to print the .lba() aspect. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #15 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
@Leslie:
Maybe you can determine the expectations of slotMediumChanged without having
a BD-R medium and drive.
Try by creating a data file of 21.5 GiB size
dd if=/dev/zero bs=2048 count=11272192 of=test.img
and submitting it to K3B while it uses a CDemu drive with some virtual
blank DVD+R or DVD-R medium.
Print before the big "if" in slotMediumChanged()
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n257
if ( (d->wantedMediaType & K3b::Device::MEDIA_BD_RE) &&
the requirement settings and medium properties:
d->wantedMediaType
d->wantedMediaState
d->wantedMinMediaSize
medium.diskInfo().mediaType()
medium.diskInfo().diskState()
medium.actuallyRemainingSize()
The "wanted" values are supposed to be realistic. At least the value
of actuallyRemainingSize() will be insufficient. So best print only
once and use a static variable to prevent a flood of more messages.
It would also be helpful to assert that really the if-test in line 634
is reached and performed.
For that you could (very temporarily) insert a case before
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n632
// we have exactly what was requested (K3b never requests a specific
that prints a message and accepts any medium, state, and size.
} else if (1) {
// >>> print message that this line was reached
finishWaiting( medium.diskInfo().mediaType() );
While above print proposal would be helpful on Cristian's system, too,
this mindless accepter here is not suitable for tests with real media,
although it is supposed to let Critian's intended burn run start.
(Only good if the medium is the right one, inserted, and already recognized
by the drive.)
Without this accepter, you should look for the message from line 649:
qDebug() << "-- nothing useful found.";
which would prove that really all tests were made and none matched.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #14 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Leslie Zhai wrote:
> QEventLoop http://doc.qt.io/qt-5/qeventloop.html
This does not help much with understanding under which circumstances
the particular medium waiting loop shall end.
I searched for "waitingDone = true" which i find in
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n710
K3b::EmptyDiscWaiter::finishWaiting()
This is called in
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n210
K3b::EmptyDiscWaiter::slotMediumChanged()
which is also called before the loop.
So the beef must be in there.
Most of the finishWaiting() calls are in if-cases which apply to
non-BD-R media only.
Two calls remain. One is unlikely because of this comment
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n641
// this is for CD drives that are not able to determine the state of a disk
-
So ours must be in
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n634
else if( (d->wantedMediaType & medium.diskInfo().mediaType()) &&
(d->wantedMediaState & medium.diskInfo().diskState()) &&
(d->wantedMinMediaSize <= medium.actuallyRemainingSize() ||
IsOverburnAllowed( d->wantedMinMediaSize,
medium.diskInfo().capacity(), medium.actuallyUsedCapacity() )) ) {
finishWaiting( medium.diskInfo().mediaType() );
One can see how the criteria are set up in waitForDisc():
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n158
d->wantedMediaState = mediaState;
d->wantedMediaType = mediaType;
d->wantedMinMediaSize = minMediaSize;
Currently i fail to see the spot where this is called. So it would be
interesting to see by what values the loop gets programmed.
A print statement at that position would be of help.
In general we have three possible reasons for not accepting the BD-R
in the drive:
- A type is requested which does not match BD-R.
The text snippet "empty medium of size" indicates that K3B does not
look for MEDIA_WRITABLE_BD, because then it would say "Blu-ray medium".
- The BD-R is not in the desired state. (This is unlikely because we have
the statement in the screenshot that it is an empty BD-R and that the
waiter wants to see an empty medium.)
- The actuallyRemainingSize() is less than the required size.
So we are back at the question how much size is offered by the BD-R.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #12 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i have to correct a copy+paste error of mine.
It's not line 691
return i18n("Please insert an empty medium into
drive%1", deviceString);
but line 728
return i18n( "Please insert an empty medium of size %1 or
larger into drive%2",
My theory that the medium was not recognized is dwindling.
STATE_EMPTY means that the medium is blank, not that the tray is empty.
(According to libk3bdevice/k3bdevicetypes.h that would be STATE_NO_MEDIA.)
But the size is told because there is no particular medium type requested,
not because that size was too large for the given medium.
--
Now i ended up at the spot where Leslie put a comment in june.
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n146
K3b::Device::MediaType K3b::EmptyDiscWaiter::waitForDisc
I understand from a comment above
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n189
if( !d->waitingDone ) {
that this function is called even if a medium is already detected, and
that it should return immediately in this case.
Obviously it does not return.
It looks like the state
d->waitingDone
changes inside
https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n196
void K3b::EmptyDiscWaiter::enterLoop()
but currently i do not understand how this loop works and were the state
is changed.
Will try to get insight later today. But this looks like C++ idiom which
an old C programmer has difficulties to grasp.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #11 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the screenshot message
https://bugsfiles.kde.org/attachment.cgi?id=106037
does not really look to me as a complaint about lack of medium space.
It rather looks like the medium is not recognized at all.
---
The message probably stems from
https://cgit.kde.org/k3b.git/tree/libk3b/tools/k3bmedium.cpp#n691
return i18n("Please insert an empty medium into
drive%1", deviceString);
called by
https://cgit.kde.org/k3b.git/tree/libk3b/tools/k3bmedium.cpp#n647
toReturn.append(mediaRequestString( requestedMediaTypes,
requestedMediaStates, requestedSize, dev));
There are specific messages for lack of capacity, but they do not show up
in the screenshot.
So the output of dvd+rw-mdiainfo with the affected BD-R medium is of
high interest.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #10 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i would need to search for the 8.8.0 ISO, because now 9.1.0 is in the
"current" directory at the Debian download site.
Let's have a look at 9.1.0. It should suffice to get the 450 KB Jigdo file.
wget
http://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/debian-9.1.0-amd64-BD-1.jigdo
gunzip debian-9.1.0-amd64-BD-1.jigdo | less
reveils as final image size:
# Image size 22985682944 bytes
That's 11223478 blocks and should well fit into the 11826176 blocks of
a default formatted BD-R.
---
Questions:
- Do we know where in K3B the refusal message comes from ?
(The original message text might help to find it.)
- What is the exact size of your downloaded ISO ?
("22 G" is too coarse, i'd need to know the byte count.)
- What does dvd+rw-mediainfo tell about the BD-R medium ?
(Again, the info from the K3B screenshot is too coarse.)
Insert it and load the drive tray. Then run
dvd+rw-mediainfo /dev/sr0 2>&1 | tee -i >/tmp/bd_mediainfo.txt
and post the resulting file bd_mediainfo.txt.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 382941] Segfault from getSupportedWriteSpeedsVia2A
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #20 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
some final remarks about the comments:
---
This rumor can be deleted. It is not relevant in any way:
// Some CDs writer returns the number of bytes that contain
// the descriptors rather than the number of descriptors
Whereas this part is a wise precaution against mad drive replies of any
kind:
// Ensure number of descriptors claimed actually fits in the data
// returned by the mode sense command.
if (static_cast(numDesc) > ((data.size() - 32 - 8) / 4))
numDesc = (data.size() - 32 - 8) / 4;
---
The new comment in
if (data.size() > 32 + 8/* pageLen? */) {
does not explain the numbers 8 and 32. pageLen is a misnomer for data.size().
A better name in modeSense() would be "replyLen".
How about being more verbous:
// 8 bytes of MODE SENSE(10) header
// 32 bytes offset of speed descriptor list in Mode page 2Ah
// (MMC-3, table 361. Pages of MMC-1 and MMC-2 are smaller.)
if (data.size() > 8 + 32) {
// we have descriptors
It is necessary to mention MODE SENSE(10), because MODE SENSE(6) yields a
header length of 4.
---
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 382941] Segfault from getSupportedWriteSpeedsVia2A
https://bugs.kde.org/show_bug.cgi?id=382941 --- Comment #19 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, i was not really in patch mood yet, but still in the stage of making up theories. Nevertheless, the new commit should really fix the problem. Mark reports in https://bugs.kde.org/show_bug.cgi?id=382941#c8 that he gets data.size() == 34. Minus 8 header bytes this is mode page length 26. This means 6 mandatory bytes from MMC-3 table 361 are missing. In MMC-1 table 103 the mode page 2Ah is only 22 bytes long. MMC-2 table 137 has indeed 26 bytes. It obsoletes half of the MMC-1 definition. E.g. "Maximum Write Speed Supported" and "Current Write Speed Selected" at bytes 18 to 21. MMC-3 then adds again a field "Current Write Speed Selected" at byte offset 28 and the list of speed descriptors. So yes, with page length 26 and the wrong "if" condition, K3B picked two bytes as numDesc by unsigned int numDesc = from2Byte( mm->num_wr_speed_des ); which were not read from the reply of command MODE SENSE. It did not throw any error towards Mark when it was doing this. The error happened later when numDesc was the rolled-over unsigned representation of the negative number and caused a long and rampant loop until segfault by a large index "i". - But i still riddle about the original cause to make the problematic computation. It is not easy to imagine how a K3B developer could have mistaken the random number for a byte count and compute the descriptor count from the reply size without noticing that it becomes negative and then a very large unsigned int. So maybe this gesture is not a reaction to MMC-1 or MMC-2 compliant replies but rather a reaction to some other unexpected situation. I still doubt that any drive would really announce a byte count of the descriptor list rather than the item count of that list. But given my current assessment, i cannot recommed to remove this fallback computation. (I would like to. Really.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 382941] Segfault from getSupportedWriteSpeedsVia2A
https://bugs.kde.org/show_bug.cgi?id=382941 --- Comment #17 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the proposed cdrskin run has a wrong redirection sequence. It must be cdrskin -V dev=/dev/sr0 >/tmp/cdrskin_scsi_log 2>&1 (I tested mine with "| less". When changing this to "> /tmp/..." i stepped into the well known shell redirection puddle. Duh.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 382941] Segfault from getSupportedWriteSpeedsVia2A
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #16 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Mark's workaround justifies itself by mere arithmetics. The new "if"
prevents computation from being performed if it would yield 0 or less.
The remaining question is why this computation is made and whether
it is correct.
And if it is correct, then why can it become negative at all ?
So it would be interesting to see the SCSI transaction around MODE SENSE
for page 2A from the drive which caused the segfault:
cdrskin -V dev=/dev/sr0 2>&1 >/tmp/cdrskin_scsi_log
This yields for me with a CD-RW medium in /tmp/cdrskin_scsi_log
MODE SENSE
5a 00 2a 00 00 00 00 00 4c 00
From drive: 76b
00 4a 21 00 00 00 00 00 2a 42 3f 37 f1 77 29 23 1b 90 01 00
0f e0 10 8a 00 10 06 e4 06 e4 00 01 00 00 00 00 06 e4 00 01
00 00 06 e4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Please post the whole file. There will be more than one MODE SENSE in it.
Now let's see what K3B is doing this time what it should leave to burn
programs. :))
getSupportedWriteSpeedsVia2A() requests from the drive Mode Page 2A
"MM Capabilities and Mechanical Status Page". It is obsoleted since MMC-4,
but afaik still supported by all drives. (More modern is command
ACh GET PERFORMANCE in K3b::Device::Device::getPerformance().)
If a Mode Page is fetched by command 5Ah MODE SENSE(10), then it is preceeded
by a header struct of 8 bytes (SPC-3, table 240). This header tells in its
bytes 0 to 2 the number of bytes minus 2 which can at most be replied for
the given mode page.
From
mm_cap_page_2A* mm = (mm_cap_page_2A*)[8];
i conclude that "data" is the raw reply from the drive which now gets
overlaid by a C++ struct. (So i can only guess the mapping of specs to code,
from here on.)
Mode page 2A is described in MMC-3, 6.3.11.
In page 2A the number of speed descriptors is recorded in bytes 30 an 31
of the replied page. Their size is four bytes each. So in above example
from cdrskin there are
0x4a + 2 - 8 - 32 = 36
descriptor bytes.
I never encountered drives which tell descriptor bytes rather than
descriptor count. Can this be a rumor caused by other problems ?
There is some contradiction in
if( data.size() > 32 ) {
// we have descriptors
versus
numDesc = (data.size() - 32 - 8) / 4;
The "if" assumes that data.size() is the net mode page size.
The "numDesc" computation assumes that it is the combined size of header
and page.
Looking at k3bdevice_mmc.cpp line 676
bool K3b::Device::Device::modeSense( UByteArray& pageData, int page ) const
i get the impression that it is a generic function of the array and
reflects its size as recorded by
pageLen = 8;
if( cmd.transport( TR_DIR_READ, header, 8 ) == 0 )
pageLen = from2Byte( header ) + 2;
...
pageData.resize( pageLen );
So this is wrong in getSupportedWriteSpeedsVia2A() :
if( data.size() > 32 ) {
// we have descriptors
unsigned int numDesc = from2Byte( mm->num_wr_speed_des );
It should be
if( data.size() > 8 + 32 ) {
// we have descriptors
unsigned int numDesc = from2Byte( mm->num_wr_speed_des );
With the wrong comparison and if there are no descriptors, the value numDesc
might be taken from bytes which were not allocated by modeSense().
(Doesn't the fancy UByteArray have an overflow protection ?)
I now ponder whether this might be the reason for the rumor:
// Some CDs writer returns the number of bytes that contain
// the descriptors rather than the number of descriptors
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 383211] Blu-ray media sizes in fill widget are incorrect
https://bugs.kde.org/show_bug.cgi?id=383211 --- Comment #8 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, Leslie, i am crossing fingers for you and your health. My best wishes. Get well soon. > Then could I apply Henryk Hecht's patch? sorry for my reading function... Do it. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 383211] Blu-ray media sizes in fill widget are incorrect
https://bugs.kde.org/show_bug.cgi?id=383211 --- Comment #6 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > I experienced Brain spasm [...] > I feel really difficult to read and write English Go see a doctor. A good one, who does what is needed, not just what he can. > please give me some hint about how to get the correct > MediaSizeBluRay25Gb/MediaSizeBluRay50Gb value before the buring job. Let's look for occurences. Since i don't see a code search facility in k3b.git, i use the Debian source tree (which might be a bit outdated): https://codesearch.debian.net/search?q=package%3Ak3b+MediaSizeBluRay25Gb which yields: -- http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=729#L729 Here MediaSizeBluRay25Gb is used to detect the media type. The value to which it gets compared stems from KConfigGroup c.readEntry( "default media size", 0 ); For now i assume, that this function returns one of the sizes from the list where MediaSizeBluRay25Gb is defined. -- http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=373#L373 http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=375#L375 seems to set the displayed size to a caller defined value. (I riddle about the combination of exact sizes like MediaSizeDvd4Gb and naive values like 2306867. A normal single layer DVD has 2295104 blocks. DVD-RAM has less.) -- http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=585#L585 I really wonder where the value set by this function is used. -- http://sources.debian.net/src/k3b/2.0.3a-2/src/projects/k3bfillstatusdisplay.cpp/?hl=822#L822 seems to set the displayed size to one of the defined sizes, depending on media type and d->doc->length().lba(). The type of "d" is somewhere in the C++ spaghetti definitions. It seems to be a class which describes some device aspects. (Zorry, i am an old C programmer. Maybe we need a C++ expert.) -- All in all the symbols MediaSizeBluRay25Gb and MediaSizeBluRay50Gb seem not to be used for internal program control purposes but rather for display only. (I can be wrong. Better check yourself, too.) If so, then the change should beautify the user interface but not trigger decisions whether the intended data fit on the loaded media. So: The patch proposal looks good to me. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 383211] Blu-ray media sizes in fill widget are incorrect
https://bugs.kde.org/show_bug.cgi?id=383211 --- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, it's too early in the morning. My post needs mending: > The real size given the fact that growisofs always formats BD-R and that > all burn programs have to format BD-RE, a hardcoded size seems wrong > on the first hand. Ignore the first three words "The real size". They are remnants of an older attempt to phrase what i mean. > [code] Duh. Wrong wiki language. Well the marked text still looks readable enough on http:''bugs.kde.org. > format_defectmgt_max > format_defectmgt_min > blank=format_defectmgt_none > format_by_index_ > blank=format_defectmgt_payload_ They all need the prefix "blank=" in order to be recognizable cdrskin options: blank=format_defectmgt_max blank=format_defectmgt_min blank=format_defectmgt_none blank=format_by_index_ blank=format_defectmgt_payload_ Further i see that i first propose to examine the formatted sizes and later propose to enforce them. Both is appropriate depending on the formatting situation which K3B encounters. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 383211] Blu-ray media sizes in fill widget are incorrect
https://bugs.kde.org/show_bug.cgi?id=383211 --- Comment #2 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > ask Thomas for help :) Shouldn't that have been "asking Thomas for help" ? Your statement sounds like you urge Henryk to ask me. But you Cc'ed me to this bug. So i under stand that you ask me. (I guess a native speaker of english ROFLs all the day when seeing us foreigners stumbling through the language.) This change is an improvement over the wrong values which are hardcoded currently. The real size given the fact that growisofs always formats BD-R and that all burn programs have to format BD-RE, a hardcoded size seems wrong on the first hand. The BD payload size varies with formatting. One can ask the drive when a still formattable medium is inserted. Here with a blank single layer BD-R: [code] $ dvd+rw-mediainfo /dev/sr4 ... READ FORMAT CAPACITIES: unformatted: 12219392*2048=25025314816 00h(3000): 11826176*2048=24220008448 32h(0):11826176*2048=24220008448 32h(0):5796864*2048=11871977472 32h(0):12088320*2048=24756879360 ... [/code] or [code] $ cdrskin dev=/dev/sr4 --list_formats -toc ... Format status: unformatted, up to 23866.0 MiB Format idx 0 : 00h , 11826176s , 23098.0 MiB Format idx 1 : 32h , 11826176s , 23098.0 MiB Format idx 2 : 32h , 5796864s , 11322.0 MiB Format idx 3 : 32h , 12088320s , 23610.0 MiB ... Media blocks : 0 readable , 12219392 writable , 12219392 overall ... [/code] These sizes from 11 GB to 25 GB are only a rough overview what is possible. One may format to about any payload size. So one should examine where the values MediaSizeBluRay25Gb and MediaSizeBluRay50Gb are used, whether the medium is present and already formatted, and to which size it will be possibly formatted during the burn run. As said, growisofs formats all BD by default. One can force it to use maximum media payload size by option [code] -use-the-force-luke=spare=none [/code] dvd+rw-format has option "-ssa" which besides the documented "none", "default", and "max", also takes "min" or a number with suffixes "G", "M", "K" which it obviously treats as merchants GB, MB, KB with a block size of 2000 rather than 2048. An adventurous computation which is wrong at least with MB and GB. (KB depends on what Andy Polyakov intended "K" to be exactly: 1000 or 1024.) See: https://sources.debian.net/src/dvd%2Brw-tools/7.1-11.1/dvd%2Brw-format.cpp/#L273 cdrskin does not format BD-R by default. One would have to use an option from the following list [code] format_defectmgt_max format_defectmgt_min blank=format_defectmgt_none format_by_index_ blank=format_defectmgt_payload_ [/code] where "<number"> picks a size from the --list_formats output and "" is the decimal number of desired payload blocks. BD-RE must get formatted. If no blank=format_.., is given, then the default size as of format "00h" is used. Normally: 23098 MiB. Henyk Hecht wrote: > I think this bug is at least a couple of years old; I am surprised that > it is still around, and that no one has reported it. Both, unpatched and patched numbers, are not overly significant. Decisive is the payload size when burning begins. growisofs is not very good in this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699186 So on unformatted BD media K3B should decide which size it wants, enforce that size, and use it for its own calculations. On already formatted BD-R, it must use the currently formatted size. Already formatted BD-RE could be re-formatted to a different size. But that's unusual. (Dunno whether it does harm if done too often.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 383140] Write speed
https://bugs.kde.org/show_bug.cgi?id=383140 Thomas Schmitt <scdbac...@gmx.net> changed: What|Removed |Added CC||scdbac...@gmx.net --- Comment #1 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, the failure by > :-[ WRITE@LBA=7e70h failed with SK=6h/NOT READY TO READY CHANGE, > MEDIUM MAY HAVE CHANGED]: Input/output error is not necessarily caused by the high speed. (Although i have heard DVD+R derail inside the drive at 20x speed. What a noise.) The drive had a moment of inconsciousness and then reports to have recovered from that. Nevertheless its reply to the emergency exit by SCSI command FLUSH CACHE says again that it is busy or brainless. The progress messages say that drive speed had reached just 6.3x before the failure happened. About the speed setting: growisofs asks the drive for speeds and chooses what it deems best for the given speed wish of the user. Either the drive did not offer 8x speed or growisofs failed to properly choose that speed. Program dvd+rw-mediainfo will tell the speed values offered by the drive for the given medium. So insert a blank DVD+R from the same box or spindle. Close the tray. Then run dvd+rw-mediainfo /dev/sr0 and look for lines like Write Speed #0:16.0x1385=22160KB/s Write Speed #1:12.0x1385=16620KB/s Write Speed #2:8.0x1385=11080KB/s If there is no "8.0x" line, then the drive does not offer that speed. (It would still be ok to request it to use 8x, but it will probably not obey.) Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 382754] K3b complains about missing cdrskin at start up
https://bugs.kde.org/show_bug.cgi?id=382754 --- Comment #22 from Thomas Schmitt <scdbac...@gmx.net> --- 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 -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 382754] K3b complains about missing cdrskin at start up
https://bugs.kde.org/show_bug.cgi?id=382754 --- Comment #20 from Thomas Schmitt <scdbac...@gmx.net> --- 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_BYTES2 #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 -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 382754] K3b complains about missing cdrskin at start up
https://bugs.kde.org/show_bug.cgi?id=382754
--- Comment #18 from Thomas Schmitt <scdbac...@gmx.net> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
[k3b] [Bug 382754] K3b complains about missing cdrskin at start up
https://bugs.kde.org/show_bug.cgi?id=382754 --- Comment #15 from Thomas Schmitt <scdbac...@gmx.net> --- 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-de...@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 -- You are receiving this mail because: You are watching all bug changes.
