Dear Thomas,
Am Donnerstag, den 11.10.2012, 11:40 +0200 schrieb Thomas Schmitt: > staring at lines 201, 202, and 216 of > http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c > > i realize that this loop drops every second block ! > > ---------------------------------------------------------------- > read_bytes = priv->libburn_src->read_xt (priv->libburn_src, buf, > sector_size); > while (priv->libburn_src->read_xt (priv->libburn_src, buf, sector_size) == > sector_size) { > > ... process block that was read by while() statement ... > > read_bytes = priv->libburn_src->read_xt (priv->libburn_src, buf, > sector_size); > } > ---------------------------------------------------------------- > > This would well explain why block 17 ends up at block 8. > > > It is tempting to also claim victory over the 50 % bug, but i > cannot yet make up a plausible explanation. With the 50% bug > https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117 > it is libisofs which reports 50 % progress, when loop or libburn > close the shop. > > The many CD complaints in this Ubuntu bug could well be caused > by above killer loop, though. As already spoilered in my reply to #690207 [1], with the libburn output patch attached it confirms that half of the bytes are missing. BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature end of input encountered. Missing: 48709632 bytes These are around 47 MB and indeed comparing the sizes yields the following. $ du -sh folder 94M /home/joey/folder $ du -sh /tmp/my_emulated_drive 47M /tmp/my_emulated_drive So all the bugs seem to be the same and Brasero just displays the error differently or it is not noticeable with smaller amounts that the progress bar stopped earlier. I will try to cook up a patch for fixing the loop now. Thanks, Paul [1] http://bugs.debian.org/690207
signature.asc
Description: This is a digitally signed message part
