Thanks for the report and the log. I'll look into that before 0.7.0.

mmh, I don't see the logs actually; you seem to have forgotten to attach them.

oops sorry again. I didn't properly read the end of your comment. I do want to see the logs please, to attach them add them with the box below under the Additional Comments area; click on create a new attachment et voilà.

Created attachment 100698 [details]
Brasero and K3b logs

I had tried to, but the 6577 kilobyte plus first log was rejected as too big.  After trying renaming them as .txt, I put them back to logs and created a bzip-2 with Ark of the whole set of logs.  I added a K3b log of a successful burn.  Hopefully I did it properly.  The system accepted it, anyway.

Adding to the previous report, Brasero also could not continue a multisession using the created cdr's.  Neither could K3b while in Gnome.  It gave me the previous files while importing the session, but reported when attempting to burn that it could not retrieve them.

Then I logged out of Gnome and logged into KDE.  There, K3b had no problem importing the files and continued the multisession fine!  The burnt cdr verified as perfect as well.

Being that my Gnome is a fully upgraded Gnome with the GNOME:/STABLE and GNOME:/Community Build Service repositories, it is possible that there is something buggy going on in the latest Gnome packages that relate to cd/dvd burning.  I did try restarting the computer into Gnome, logging in and out, going from KDE to Gnome, Gnome to Gnome, all result in burning bugs happening using Brasero not reporting successful first burns even though they are, and not being able to continue multisession cdr's using either Brasero or K3b while in Gnome.  In KDE there is no such problem with K3b.

I have not tried using Brasero in KDE as of yet.  I sort of afraid to, being that one possibility is that Brasero made some sort of setting change that was the reason burning is somewhat messed up in Gnome.  Some setting in gconf or something.  Maybe it would do the same in KDE?  It's either that or something in Gnome that is interfering with burning whichever the burning program used.  That would make a test of Brasero in KDE safe.  But how do I know?

I don't know if you can tell what's wrong from the logs, but that would be nice!

All other things in Gnome are working fine, including ripping from cd's and dvd's.  These problems did not occur with the GNOME:STABLE versions installed until they were recently upgraded again.  I do a system upgrade daily so there's no telling which package may have caused it from memory.  They do not upgrade a lot, but enough not to know when it exactly started happening.

Thanks for the logs. There is something strange here: brasero doesn't read the two last sectors of the CDR and 12 sectors from the DVD which explains the problem.
I myself have never burnt video DVDs so I don't know exactly what the problem could be. I'd like to have a small log please.
Run "brasero -g > logfile 2>&1" in a console with the CD-R you burnt inside and close brasero once it's fully loaded. Do the same with the above DVD you wrote.
I'd like also to know the size of the image of the video DVD please (in bytes).
Thanks in advance.

I think I managed to fix the speed problem. There was a stupid bug in the code. But maybe that wasn't enough. Could you test that please?

Interesting!  I suppose the unread sectors are there since K3b was able to continue the multisession cdr, at least within KDE.  It was not able to continue it while running within Gnome.  And, the DVD-Video fully played.  Everything on it.  So even though the verification always fails right now, the burn itself appears to be fine.

I wiped everything for a complete system refresh for both hard drives, as well as changing videocard and soundcard and putting Vista on one, replacing 98SE and XP.  I wanted to check out the unofficial cd package for the Audigy 2 ZS on Vista that a fellow at the Creative forums has put out.  I also purchased the Fluendo full codec package and wanted to redo my Linux install along with LinDVD from my Mandriva PowerPack 2008.0 purchase.  Heh, the LinDVD package they have works fine on OpenSUSE as long as one re-does the link to the /usr/share/LinDVD (forgot the case)/lindvd instead of the /usr/bin/lindvd because the soundserver command doesn't exist on SUSE.  Since I love OpenSUSE, I'll just use that.  Nothing in PowerPack I can't get on SUSE, plus I gained legal dvd play in the USA (I did pay for the thing)! :)

I will do the same upgrading setup so the same problem will likely occur.  As soon as I'm setup I'll do the tests you asked for.  It may be a week or so as setting up both Windows and Linux and getting all my files copied is a long, tedious process.  Sure hope you don't mind!  It seems something to do with the latest Brasero in the most up to date Gnome, or some combination of such.  Hopefully it's just a simple tweak to Brasero that'll fix this up.  

Thanks for the attention to this.  I think it must be a bug not only on my system so fixing this is something that should happen and I'd like to continue to help.  I just have to get Linux installed again to be able to!

That's OK =). I'm not in a hurry. Thanks for your help.

Just to let you know I think I found the bug for CDR multisession.

Cool!  I have Vista and Debian Lenny installed now.  I'm glad it was a reproducible bug that could be fixed.  I looked at what Debian does with Brasero and noticed that it has the Fluendo mp3 Gstreamer codec as a recommends and Aptitude installs recommends automatically.  Actually, even Apt does that now too.

I actually bought the whole Fluendo package, yet I just used that as an excuse to install the "questionable" gstreamer plugins and w32codecs since I paid in. :)

I wouldn't want to mess it up with the Fluendo installation as I have mp3 playback and encoding working as it is.  I think I'll figure out (I do have the Aptitude manual printed out so it should be easy) how to install an app without its recommends before installing Brasero. 

It's just great that you found out what went wrong.  Hopefully a fix won't be that difficult to do.  It's pretty important as whatever it was doing with the drives, it was confusing K3b on Gnome as well.  It effected more than just Brasero itself.

The fix is just for CD multisession it was committed yesterday so you can test it. As for DVDs, the problems must come from the fact they are Video. When video DVDs are no longer in Iso format but UDF. That may come from the UDF thing. I'll test a few UDF images today and see.

I use ubuntu gutsy and brazero 7.0 and I found a situation when writing several *.avi files to a dvd+r disk _always_ fails because of interity check of the _last_ file in a sequence. At least I wrote two disks with the same result (before I used Nero and have written ~20 the same disks in the same burner.

p.s. After writing second disk my cd burner looks like dead - it does not react on mount/umount and an eject button does not work either.

(In reply to comment #13)
> I use ubuntu gutsy and brazero 7.0 and I found a situation when writing several
> *.avi files to a dvd+r disk _always_ fails because of interity check of the
> _last_ file in a sequence. At least I wrote two disks with the same result
> (before I used Nero and have written ~20 the same disks in the same burner.
> 
> p.s. After writing second disk my cd burner looks like dead - it does not react
> on mount/umount and an eject button does not work either.
> 

It's probably because brasero has it locked.  Try closing brasero normally, then ending task by doing killall brasero in a terminal.  Then perhaps su to root and do umount "whereever your drive is mounted, like /media/cdrom or /dev/cdrom, etc, try them all."  Doesn't work?  Try restarting the computer.

It may be some of the programs brasero and other software are actually using that are causing some problems lately.  You know, growisofs, makisofs, wodim, icedax, whatever.  I've found that even K3b can not successfully run its verification anymore either.  I just never put a check in verify when finished anymore.  

Hopefully the reasons for these problems will be found soon.  I just have a feeling it's not all brasero causing the bugs.

Funny, Debian just removed brasero from Lenny yesterday.  They left the previous version in Unstable, and there's no sign of 1.7 in Debian yet.  Have no idea what's going on there.

More information:

1. Only restart have helped to return cdrom to life.
2. I have checked - the last file in these dvd+r's is really damaged! So that is why interity failed.
3. I have noticed that this dvd drive was using in VirtualBox (WinXP guest, idle state) as well. May be it was the reason. But - K3b detected it and gently asked me that I should disable using of drive by VirtualBox. May be Brazero should do it as well?

As a result I have moved to 0.6.1 and it works OK (except slow integrity checking).

(In reply to comment #15)
> More information:
> 
> 1. Only restart have helped to return cdrom to life.
> 2. I have checked - the last file in these dvd+r's is really damaged! So that
> is why interity failed.
> 3. I have noticed that this dvd drive was using in VirtualBox (WinXP guest,
> idle state) as well. May be it was the reason. But - K3b detected it and gently
> asked me that I should disable using of drive by VirtualBox. May be Brazero
> should do it as well?
> 
> As a result I have moved to 0.6.1 and it works OK (except slow integrity
> checking).
> 

Further theorizing.  Maybe what we really need is the bug fixed, improved 0.7 new upstream version to find its way into Debian.  A lot of work was done to fixing several things, including the stuff in this bug report, for the new version.  I can't understand why the Debian maintainers don't start working with the new version.

I'm tempted to compile it myself since I removed, purged the Debian brasero from my system since they removed it from Lenny.  I try to do that when they remove things.  I figure they have a good reason.

Regarding the Virtualbox holding onto the drive, I sure wouldn't keep a virtual machine active while burning with Linux programs on the host system.  Not unless I had the automatic mounting of a cdrom drive turned off in the Virtual Machine settings.  If it has it mounted, then your guest operating system is in control of the drive and not your host system.

At least your integrity check works.  K3b (latest) nowadays just freezes when trying to verify a burn so I don't bother trying to.  Hopefully this is a wodim/makisofs/growisofs/icedax problem that will be fixed by those folks.

I'm using KDE mostly since the last time I used brasero in Gnome it destroyed a multisession cdr after importing and burning from a previous session.  Never has K3b do that, so for that and other reasons I made KDE default again.

If I want to try compiling brasero I'll switch back to Gnome and check out how things work.  Who knows?  Maybe just using brasero 0.7 a few times will change a few backend things that'll fix this verifying problem even in K3b.  It's possible the older brasero changed the configuration of them and that the new one will change it back so verifying works.  I wouldn't have a clue how to mess with the configuration of wodim and friends myself, but the frontends (like brasero) might fix it for me.

Okay, I made sure I had all the dependencies development files except for the libburn stuff and compiled and installed the brasero 0.7.

I did it because Gnomebaker could not verify a new cdr multisession project it had successfully burned, nor import the session when attempting to add to it.  I then opened K3b (in Gnome, wasn't switching back so soon after setting all those update-alternatives and making gdm and gnome my defaults).  K3b imported the previous session fine and burned, although I didn't try to verify it.  The files are all there and fine.

Now for Brasero.  I took the same cdr with 2 sessions on it, successfully imported the previous session and added to it.

It again failed in verification, claiming there were some corrupted files on the disc.  However, seeing that Brasero comes with a nice Verify option that can be used on any disc, not just those it just burned, I clicked on that and it verified perfectly that all files on the disc seem fine.  

When trying to verify initially, it seemed to try and try, spinning the disc frantically until it finally just gave up and reported the files must be corrupted thing.  This was unlike Gnomebaker which didn't seem to even try, and did not spin the disc at all.  That was similar to what it did when trying to import the previous session.  It just immediately popped up a message that it couldn't.

I am attaching a tar with the brasero log for the failed verification which also includes the whole burn process.  Note that when clicking specifically to verify a disc following this, the same disc spun up and verified fine.

Created attachment 103096 [details]
Brassero 0.7 log of good burn but failed verification

Here's the new log of the good burn but failed verify, which then verified fine afterwards when clicking verify in a separate process.

I thought I would share the results of my findings.
Apparently TAO mode adds two sectors (called "run outs") after a track and DAO doesn't. From that comes all our problems since NO SCSI COMMAND can account for them and there is absolutely no way to tell which track was recorded in SAO/DAO and which in DAO.
For the time being, I'm thinking about reading the volume size like we do for track under 300 kio.
Another solution would be to try reading the last two sectors but that means having READ CD command implemented.

I committed a fix to stable (unfortunately too late for 0.7.1)

It's great that fixes are coming fast and furious!  :)

Somehow K3b, which has some troubles itself but mostly handles verification if a user sets its properties to not eject the tray after the burn (though sometimes it freezes anyway), is handling things slightly better than brasero at this point.  Gnomebaker is a total failure at even importing a multisession cdr's previous sessions.  

Brasero 0.7.0, last time I used it, said it had successfully added files to a session and burned it, then failed to verify and the cdr was turned into a coaster.  Apparently it did something that made the previously fine multisession cdr fail to be able to be mounted anymore.

I then switched to KDE and K3b for a time.  A few days ago Debian returned Brasero 0.6.1 to Lenny. Trying to stay within what Debian offers, I make uninstall the 0.7.0 and install 0.6.1 from Debian again.

Haven't tried it yet, but I'm in Gnome now so will shortly.  Whatever the result, it's kind of pointless until Debian catches up to where you are in Stable releases, now 0.7.1 plus a coming version I guess with the latest fix reported here.

I checked the Debian maintainer site and 0.7.0 is in his "Watch" list, whatever that is.

Why don't they take your latest releases and put them into Sid like they are supposed to?  That way more folks can see and report the bugs and possibly even contribute to fixing any that are found.  There is one Debian bug report for Brasero that they have relegated to a "wish" item that asks them to use your latest releases.  I just don't understand them.  I'm sure 0.7.1 likely has more features and fixes than the old 1.6.1 they just returned to Debian testing.

I only use GUI tools to burn stuff and this project looks like it is where it's at for Gnome users, but all of these do need help working with the Wodim/Genisoimage/IceDax fork of cdrkit everyones using.  The distro maintainers really should pay more attention to it so that things can get fixed and working at a quicker pace.  Keeping older versions around is not the way to do that.

There's been many improvements lately to all the checksuming part of brasero. 0.7.90 has just been released on ftp.gnome.org. I'd appreciate if you could test it and tell me if all the problems you raised are solved.
Thanks in advance.

I think all problems you mentioned are now fixed. Closing this bug. Feel free to reopen it if it isn't fixed.