GNOME Bugzilla – Bug 556449
Session error : Insufficient space on media when copying an audio CD (same problem with trunk)
Last modified: 2008-12-14 15:38:32 UTC
Please describe the problem: When trying to copy an audio CD it fails just when empty CD is loaded I attach the log and also the file generated when running brasero -g Thanks a lot Steps to reproduce: 1. Try to copy an audio CD 2. When brasero ends of reading original CD, put empty CD 3. Load it Actual results: It fails Expected results: Does this happen every time? Yes, nautilus-cd-burner also failled at same stage, but its error was much more useless (at least for me). On the other hand, k3b recorded it succesfully Other information:
Created attachment 120670 [details] brasero-session-trunk.log
Created attachment 120671 [details] brasero-trunk.log.bz2
Thanks for the report. I have a request: could you run "brasero -g > log 2>&1" in a terminal, please, and redo the whole operation. If you can't (you may not want to burn for the 14th time the same audio disc ;)), could you at least insert a blank CD like the one you used and just start "brasero > log 2>&1" and then close it. I suspect brasero's got some difficulties with properly initializing information about your disc and the above command should tell me more about it. One last thing, please, use trunk. Thanks
It's already attached in comment #2 , an it was taken with trunk :-)
No, ;), you packed the exact same file as in comment #1.
Created attachment 120731 [details] brasero-trunk.log.bz2 Ups, sorry This should be the correct file
Thanks. I committed a fix to trunk. It should work, but I'd really like to know why MODE SENSE (a very common SCSI function) fails with your medium. I added some additional debug to try and catch the problem so please create a new log file and attach it.
I am now suffering a different problem and I cannot reach this stage for testing if this one is fixed: http://bugzilla.gnome.org/show_bug.cgi?id=556691
Now bug 556691 is fixed, but this bug is still present
Created attachment 120833 [details] log.bz2 This is the new log, it still fails with: (brasero:9784): BraseroBurn-DEBUG: At burn.c:2537: Session error : Insufficient space on media (0 available for 208413) Thanks
Sorry, I committed the real change I intended to make (I misread the initial log you sent and took MODE SENSE for MODE SELECT which is the culprit). Please, could you try again and attach a log whether it works or not. Thanks
Created attachment 120841 [details] log.bz2 The error is now different, it also occurs just after I put the blank CD
I can confirm this with 0.8.2 (from getdeb.net). Inserting an empty medium results in Brasero reporting "0 min free" immediately, and expectedly trying to write an audio project to this disc fails directly after all files have been converted. AFAIK this worked without problems in 0.8.0, which I had installed before.
@Pacho: the problem here is related to the one you had earlier. Earlier, brasero tried to set TAO write mode before retrieving the medium leadout size. In doing so (setting write mode), it failed since your drive didn't want to do as told for whatever reason with MODE SELECT SCSI function. Now I worked around this by simply ignoring any failure to set the write mode. But now, cdrdao is having the same problem as brasero when trying to set DAO mode and fails ("Cannot set write parameters mode page")... What I'd like to know is why it doesn't want to change its write mode. I added some more debugging to brasero could you please retry and attach a new log? @Karsten: please could you try SVN trunk and attach a log file (brasero -g > log 2>&1) to this bug please. If you don't want to build trunk, at least could you provide a log file with your current version?
Created attachment 121344 [details] Debug log from 0.8.2 session.
As requested, attached a log file from the 0.8.2 version. HTH.
Created attachment 121377 [details] log.bz2 New log with latest trunk Thanks :-)
Thanks both for your logs and sorry to get back to you so late. @Pacho: the problem is the same here but with cdrdao. For an unknown reason, cdrdao (as brasero before the patch) can't set the write modes. And that's why cdrdao fails. It'd be interesting to know if cdrecord or wodim can do better. Could you please try with cdrdao disabled and see what happens (make sure wodim and readom or cdrecord/readcd are on). @Karsten: you're bug is really the same but I couldn't see the beginning of it since it probably got lost in the console (brasero's logs can be very long). But still could you try the same as Pacho please? Thanks.
Created attachment 122157 [details] log-wodim.bz2 Seems to work fine with wodim instead of cdrdao :-)
I seem to have also this bug, as several other users of Ubuntu: https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/181703 If it can help: - I did not have the problem before I updated my Hardy 32 bits to last Intrepid 64 bits (though I do not know exactly what version was in Hardy) - Same CD-R are burned properly by Rhythmbox - With Brasero, these CD-R fail in one or another of my two very different drives (a "recent" DVD+-RW burner and an old Yamaha CD burner) - With Brasero, I tried these kinds of disks and they all work: CR-RW 700Mb/80min, DVD+RW, DVD+R, DVD+R DL - Once I have burned a CD with Rhythmbox, then the problem does not show anymore until I reboot I attach 2 log files that I get when inserting a CD: one for a non working CD-R and one for a working CD-RW
Sorry I mixed this bug with number 557561. Is it the same? I don't know but anyway I uploaded my log files to this other bug report. http://bugzilla.gnome.org/show_bug.cgi?id=557561
@David Cavallini: Thanks for the log. The fact it works with CD-RW is not a surprise as we retrieve the size in a different way. The problem here is that for an unknown reason brasero fails with blank CD-R when asked to retrieve size with GET_TRACK_INFO SCSI command. I worked on it and I may have found a fix and committed it to trunk SVN (which is basically 0.8.3 which has just been released and the fixes). So please everyone build from trunk and report the results. Also, please even if it does work (and it should hopefully), provide a log of brasero starting with the blank CD-R inside (as usual "brasero -g > log 2>&1"). Also use cdrdao to check if it works as well. Thanks in advance.
(In reply to comment #22) Should I also recheck with latest trunk or this is for bug 557561 ? Thanks for info
Created attachment 122351 [details] Successfully burned CD-R with trunk version
So I managed to compile from the trunk after figuring out which packages are mandatory and what are their names in my Ubuntu Intrepid Ibex. The resulting version segfaults a lot but at least this particular problem seems solved (log attached): my CD-R is successfully burned! Note that as with Rhythmbox, once I have used the trunk version to burn a CD, then I can open the previous version and the bug has disappear!
@Pacho: It's for both bugs as far as I understand they are triggered by the same problem. So yes, if you could test latest SVN, I'd appreciate. @David Cavallini: That's great news. I'd be interested in having a stacktrace of your segfault please. Run brasero in gdb ("gdb brasero"), type "run" on the console and when it crashes type "thread apply all bt" copy all the output to a file and attach the file to the bug please (file a new one please). Thanks in advance. NOTE: the behavior you're describing is probably related to the fact that brasero properly resets the drive write modes.
Cannot reproduce the segfaults. I had several the first time I build and launched the program directly from src dir (without having "make install"). But if I have it again, I will report it. Merci pour ce joli bout de soft, bon boulot!
Created attachment 122606 [details] log.bz2 Works fine now, thanks :-D
Excellent news. Your log looks good to me as well. I think I can close this bug now. As usual, should you run into the problem again, please, feel free to reopen it. Thanks all.
Created attachment 122822 [details] Segfault log Here is the log for a segfault I had with the last version as you asked for. It is really possible that I did not do something right on my side though... cheers David
David, Thanks for the crash report. I fixed the crash itself but it's very strange, as this crash is triggered by the fact that HAL doesn't return a string for the device path ("/dev/sr[something]"). There's something fishy with your HAL install (or maybe it's in brasero ???). Test apps like nautilus-cd-burner or sound juicer to see how they behave. Anyway thanks, and please test if it still crashes. NOTE: next time, please open a new bug report, please, that's easier to keep track of the issues.