Hi, > It is not that simple. > The same burn that failed with growisofs here > https://bugs.launchpad.net/ubuntu/utopic/+source/dvd+rw-tools/+bug/1113679/comments/13 > finishes correctly with cdrecord. > [...] they all burn > flawlessly at 4X (1 GB/s). K3B using growisofs (besides never burning > correctly), burns at 2X (and reports it as 4X) while keeping the > burner's hardware buffer below 50%. > K3B with drecord keeps is at 97+% all the time while burning.
That's all because cdrecord does not automatically format BD-R before writing. (Neither do libburn based programs like xfburn, cdrskin, or xorriso.) You can achieve the same effect with growisofs by option -use-the-force-luke=spare:none In previous versions of K3B there was a menu to set options for backend programs ... "Setup External Programs", "User Parameters". > Basically growisofs is useless for BD-R. Ah no. I am a competitor of growisofs, but would not say that. Actually growisofs has more clue about the MMC aspects of BD media than cdrecord. It's just that Andy wanted to be smart with auto-formatting and regrettably quit maintaining of growisofs before he could iron out the consequential bugs. Have a nice day :) Thomas -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to dvd+rw-tools in Ubuntu. https://bugs.launchpad.net/bugs/1424215 Title: growisofs BD-R overflow error despite capacity check Status in dvd+rw-tools package in Ubuntu: New Bug description: Hi, firstly: thanks for taking care of https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1113679 Secondly: I hate to say it now, but i think a Debian user just complained about the problem's little brother: http://forums.debian.net/viewtopic.php?f=10&t=120566 reports that an oversized burn attempt used up the medium and finally ended by :-[ WRITE@LBA=b87400h failed with SK=5h/END OF USER AREA ENCOUNTERED ON THIS TRACK]: Input/output error I believe that the not-yet-aware bug reporter in forums.debian.org tried to squeeze data for the capacity of an unformatted BD-R into a then formatted BD-R with not enough capacity. growisofs.c has code to prevent the start of such a burn: off64_t capacity=0, ... ; ... if (ioctl_handle!=INVALID_HANDLE) capacity = get_capacity (ioctl_handle); ... if (capacity && progress.final > capacity) { fprintf (stderr,":-( %s: %"LLD" blocks are free, " "%"LLD" to be written!\n", ioctl_device, (capacity-outoff)/2048,tracksize/2048); ... pwrite64_method = poor_mans_setup (ioctl_handle, outoff+tracksize); But the BD-R gets automatically formatted not before the call to growisofs_mmc.cpp : poor_mans_setup() case 0x41: // BD-R SRM if ((disc_info[2]&3) == 0) // blank bd_r_format (cmd); This lets the capacity shrink from 25,025,314,816 to 24,220,008,448 = 0xb87400 * 2048. I will have to think about possible remedies. Problem is that one has to reliably predict the formatted capacity in order not to format the BD-R and to then say "Hey ! Now your data do not fit any more !" But that would mean to derive a predictor function from bd_r_format(). This will not be as small a patch as the one in bug 1113679. And not be developped in half an hour, i fear. It does not only have to predict the size but also whether auto-formatting will happen at all. In any case i'd need a tester who's willing to burn a few tightly filled BD-R (hopefully sucessfully). Have a nice day :) Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1424215/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
