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. Both burns where done with K3B in the same system. K3b can use any of growisofs or cdrecord. I used 2 blank BD-R from the same spindle and burned exacly the same 3 files into them. I have burned ~ 50 BD-R using K3B with cdrecord and 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. Basically growisofs is useless for BD-R. CDrecord should be the default or at least an easy to use option. Right now (and since BD-R where invented) you need to add a PPA and use K3B to actually burn BD-R. -- 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
