[Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning

Paul Menzel pm.debian at googlemail.com
Thu Jul 5 07:10:14 UTC 2012

Dear Thomas,

Am Donnerstag, den 05.07.2012, 08:47 +0200 schrieb Thomas Schmitt:

> i am currently the developer of libburn and libisofs.

thanks a million for your quick and detailed response.

> > https://bugzilla.gnome.org/show_bug.cgi?id=655601
> I know about such problems, but i do not know how to get into a
> discussion with Brasero developers.

        $ more /usr/share/doc/brasero/AUTHORS
        Philippe Rouquier <bonfire-app at wanadoo.fr>
        Report bugs at:

So unfortunately it looks like there is no list for Brasero and you need
to use the GNOME Bugzilla bug tracker.

> My impression is that the libisofs plugin causes libisofs to end
> prematurely. libburn is less of a suspect here.
> I have seen burn logs where burning ends after about 50 % of
> the expected output was produced by libisofs. I.e. libisofs would
> want to write more, but for some reason libburn is urged to finish
> burning (or falsely decides that burning is done).
>   https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
>   https://launchpadlibrarian.net/71440716/brasero_log.txt
> have:
> > BraseroLibisofs Finished track successfully
> > BraseroLibisofs disconnecting BraseroLibisofs from BraseroGrowisofs
> > ...
> > BraseroGrowisofs stdout:  3866984448/7761410048 (49.8%) @4.0x, remaining 12:06 RBU  40.9% UBU 100.0%
> > BraseroGrowisofs called brasero_job_get_action
> > BraseroGrowisofs called brasero_job_set_current_action
> > BraseroGrowisofs stderr: /dev/sr0: flushing cache
> > ...
> > BraseroGrowisofs stderr: HUP
> Note that libburn is not involved here. Only libisofs. Burning is done
> via growisofs.
> Further it seems that BraseroLibisofs is the one which decides when
> the connection between both shall end.
> But in
>   http://bugzilla-attachments.gnome.org/attachment.cgi?id=205344
> the work of libisofs seems to get completed.
> > brasero (libisofs)DEBUG : Processed 138390 of 138390 KB (100 %)
> So this might be two different problems.
> (In this run, libburn was indeed in charge of writing to media.)

rpnpif hinted in his original message, that the media was corrupted
because the wrong write speed was used.


> If somebody shows up who understands the code of the libisofs plugin
> and could make experiments, then i would be glad to help with finding
> the cause of the problem.

Thanks for that offer. Hopefully, rpnpif and Simon can chime in so that
this release critical bug can be resolved.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-libburnia-devel/attachments/20120705/68ff8931/attachment.pgp>

More information about the Pkg-libburnia-devel mailing list