GNOME Bugzilla – Bug 655601
Brasero finishes without error but unusable media
Last modified: 2018-09-21 17:21:24 UTC
this report has been filed here:
"When I burn a DVD (4,7 and 8,5 GB) Brasero show the progressbar till about 30-40% (exact point is randomly) and than says, that it is finalizing the media. This finalizing messages is showing for the rest of the burning process (~10min @8x 8,5GB). After that, it ejects the media without any error. But when I insert the media again, nothing happens, except, that the DVD-Drive disappears from the "computer:///" location in nautilus.
This problem only exists when burning On-The-Fly. Burning ISO Images or automatic creation of ISO Images before burning works without problems. The burning speed doesn't matter to this problem. I test 8x, 4x and 2x. All the same problem. On-The-Fly burning using K3B works quite well @8x speed.
One thing I also notice is, that Brasero uses 100% CPU on one core, while K3B uses just about 5-15%.
I attached the last Brasero log. I don't know, why it just says, that it was only at 49% and then says it's finished. The burning took about 28 minutes. The media was unusable on all my three devices (Linux/Windows)."
I confirm this bug on Brasero in Ubuntu Oneiric beta : when I want to burn a data DVD, if I select option "burn directly without saving on hard disk", burning progress until 100%, Brasero tells me it has succeeded, but when I run the DVD, nothing appears in the file manager (as if there was non DVD), in Ubuntu (tested on 2 computers), Windows...
If I do the same burning, but unthick the option and save on the disk before, burning works well and DVD is readable.
Created attachment 197480 [details]
Brasero burning with on-fly option leads to unreadable data DVD
Is there any advance on this bug?
This bug affect me, too.
Latest 3.x version on Ubuntu 11.10 32 bit, also with CR-R and CD-RW.
OK, I've made some additional tests. Now, for me it's clear that:
- the bug started on Brasero version 2.32.1 and it's still present in 3.2.x. It was not present in version 2.32.0.
- it happens on all hw, and all current distros
- it happens only with on-the-fly burning, which is the default option by the way.
I'm attaching debug logs, from Ubuntu 10.10 (without the problem) and Ubuntu 11.04 + Fedora 16 (with the problem).
They were obtained with the standard ISO placed on a bootable USB stick, after having disabled all plugins, trying to write on-the-fly a single 135 Mb file. According to the program window, the burn process always completed succesfully.
Created attachment 205342 [details]
Ubuntu 10.10 log without problem (Brasero 2.32.0)
Created attachment 205343 [details]
Ubuntu 11.04 log with problem (Brasero 2.32.1)
Created attachment 205344 [details]
Fedora Live 16 with problem (Brasero 3.2.0)
How is it possible that this bug is still UNCONFIRMED when 27 peoples report it on launchpad? Also, its importance should be higher because the loss of physical CD and DVD cost money to every users...
Is there any Brasero dev here???
I created an unreadable backup one week ago. So glad I discovered this bug since it would be a disaster if I had discovered it while trying to restore a backup. Please put some attention on this. What makes it extra serious is that there's no error indication after burn.
There is a simple fix, lowering the libisofs priority - see the Launchpad bug for details!
Thanks, I found that fix and it works. I still wonder why that fixes it though, if it's a fix or a workaround.
Created attachment 214393 [details]
Patch to reduce the priority of liburn.
Review of attachment 214393 [details]:
Sorry -- attached wrong file.
Created attachment 214394 [details] [review]
Patch that disables libisofs and libburnia based plugin.
(In reply to comment #16)
> Created an attachment (id=214394) [details] [review]
> Patch that disables libisofs and libburnia based plugin.
You are not expecting we would accept this patch right ? This you can do using dconf no need for patches.
The libburn based plugin is broken across platforms but is the default one chosen. It seems to make sense to disable it by default until the code is fixed.
A similar bug report is on Debian , but it is not known yet if all talk about the same cause the original reporter was seeing.
Anyway the libburnia developers stepped up and cooked up some patches for you to try please to gather some more information what goes wrong.
So please apply Georges patch  and post the result to the discussion (on the Debian bug tracker, since they are doing the work currently) doing the following to keep threading.
$ sudo aptitude install devscripts
$ bts show --mbox 617409 # downloads the messages from the archive \
# quit possible opened mail client like mutt by pressing key q
Now import that file from `$HOME/.devscripts_cache/bts/` into your mail program. Choose George’s message and hit reply to all and write your results (quote properly and delete unimportant stuff in George’s message) and attach the log files.
PS: I do not see the messages sent to the brasero list in your archive. Is the list moderated?
Created attachment 226266 [details] [review]
[PATCH] Libburnia plugin: Fix while loop in `brasero_libisofs_write_image_to_fd_thread()` (#655601)
This is the patch fixing this problem for me and others.
1. Please apply this to *all* versions since 3.x as otherwise burning on the fly does not work.
2. Without Thomas Schmitt and Michael Biebl this patch would not exist. So please consider donating to the libburnia project  (and to Debian and GNOME).
3. I hope everything works now. ;-)
Review of attachment 226266 [details] [review]:
Thomas Schmitt pointed out  that the patch cannot fix the problem described by the original reporter. Therefore I opened a separate bug 685983, where I also pasted the error message I was seeing without the patch.
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/brasero/issues/190.