Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)

[Thomas Schmitt]

Hi,

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

Well, there is a list, the last entry is of january 2012, and it
complains about the burn errors which seem to have emerged in
spring 2011.
  https://mail.gnome.org/archives/brasero-list/2012-January/thread.html

I tried to contact Brasero developers in december 2011 when i finally
had implemented CD-TEXT, a feature which they missed in libburn when
they adopted it. No reaction.

We'd need somebody who wants to maintain at least the plugins for
libisofs and libburn. I myself am a command-line guy and thus heavily
unsuitable for that job.


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

I doubt, but cannot completely outrule this for the runs which report
libisofs progress up to 100 %.
The drives take the speed instructions only as a hint. Then they decide
what speed to use. Of course, the drive can still do it wrong, when
it gets the speed request. But that would be an individual firmware flaw.
Those are often related to particular types of media (brands, manufacturers).
One can find out the media producer by
  xorriso -outdev /dev/sr0 -toc | grep 'Media product'
which will tell something like
CD:
  Media product: 97m15s35f/79m59s74f , Nan-Ya Plastics Corporation
DVD:
  Media product: RITEK/004/48 , Ritek Corp
BD:
  Media product: VERBATIM/IM0/0 , Mitsubishi Kagaku Media Co.

If there is suspicion, that the drive does not like the media brand, then
try to get some which shows a different "Media product:". This might be
not easy because most brands sell media from varying manufacturers.
(Hint: Verbatim only sells Mitsubishi media. So if the current media are
       not "Verbatim" or "Mitsubishi Kagaku" then Verbatim media will
       surely be different from those ones. The same is mostly true vice
       versa.)


Surely speed or media incompatibility is not the reason for those runs
where libisofs progress reached only about 50 %.


libisofs and libburn were not free of bugs during the last year.
But none of the resolved ones would explain what Brasero users report.


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

I hate to say it, but it seems to be easiest to just disable the libisofs
plugin. I understand that Ubuntu already moves into that direction.

xorriso could step in by its emulation of mkisofs and cdrecord (single
data track only).
cdrskin could step in as a more versatile emulation of cdrecord (audio,
multiple tracks in one session).

This would of course not have the advantages of using the two libraries
with their message queues and well definded APIs.


Have a nice day :)

Thomas