I'm using k3b to backup data DVDs on Debian Etch, with KDE3.5.

In the past, I've always used the "verify written data" option. Under this option, after k3b burns the data, it ejects the disc and reloads it. Then, it proceeds to read the disc and confirm whether the data matches.

However, the behavior now is to reload the disc and immediately fail upon the first file it attempts to read and give up entirely. I think it might be because KDE isn't letting k3b access the disc immediately, or something.

The first time I tried it, KDE popped up with a window when the disc was reloaded asking what to do with it. I thought this was interfering with the operation of k3b, so I told it to do nothing whenever a DVD was inserted.

Nevertheless, the exact same thing happened the next time with k3b failing immediately on trying to read the first file. This time, KDE didn't pop up with any window, but nevertheless I suspect that it "locked onto" the disc or something at first, so k3b failed to get access.

Any ideas on how to get KDE to ignore the disc being reinserted, or to otherwise get k3b's "verify written data" option to work?

Alternatively, is there any way to verify data on a disc that has been written? I'd rather not have to use diff to individually verify each directory manually, but if that's the only way...

Argh! This is so frustrating! What was once a really useful program has turned into a nightmare!

md5sum of the iso / dvd, would it do?

But that does not solve the k3b issue

There's no md5sum to check against. I'm not trying to burn a .iso file, I'm trying to back up data files. Even if there were an md5sum to check against, I'd still rather know which files weren't backed up properly.

In your source directory, md5sum * will tell you the md5sums of all your files.
Do the same to the backup directory on your cd. If the sums match, so do the files.

HTH

Is there some advantage to doing that and manually checking each and every checksum, compared to using diff manually on each directory?

Note that since my data is much larger than a single DVD, I use k3b's GUI interface to pick and chose sub-directories to roughly fit 4.3gigs. There isn't just one directory I need to check.

Not that I can see. Go ahead and use diff if you like.

Maybe k3b would verify the data properly if it didn't spit out the DVD once it has been written: k3b-> Settings-> Configure-> Writing-> Advanced-> [+] Do not eject medium after write process

HTH

Hey, that might work! During my searching around, I actually looked at that option several times. For some reason, I had it stuck in my head that this only meant whether to eject the disk after the whole process was complete...

...I'm going to feel stupid if that works. ^_^;

Thanks again! I'll post results after I get a chance to burn another disc...

That option only changes the behavior after the disk finished.

I'm having the same problem. After burning the disk gets ejected and reinserted automatically. However, more often than not, verification fails after that. "Verification job improperly initialized. Can't find track1" or something like that it says. I have no idea how to fix it.

Checking checksums manually would be a pain in the arse for me, and I can't be bothered to write script to replace something that oughta work anyway

Any news on this issue? I'm using a Samsung S203N writer connected to my onboard nForce controller via SATA

What kernel are you guys using? For me the K3b verification has been broken on all .24 kernels.

Interesting, I'm using 2.6.24 too. Finally some info I can use
Do you have any additional info about that?

Not really. Here is the bugzilla link:

Since it is a kernel issue it should apply to any distro.

That's correct. Changing the setting of whether or not the disc is ejected had no effect whatsoever on the problem.

I see that I never did report the results in this thread. Well, better late than never...

It didn't work. As 1N4148 said, all it does is change whether or not the disc is ejected at the end of the job.

I don't really remember how the issue was solved, but I'm still using Debian Etch and it works perfectly now. I think the problem was solved by an apt-get upgrade, meaning whatever bugs were causing the problem were fixed. I think this fix occured while Debian Etch was still Testing, and that by the time Etch went Stable, the bug was fixed.

I use only kernels used by Debian 4.0. On some machines, I think it's 2.6.18-4; on others I think it's 2.6.18-6. None of them use 2.6.24 or above.

I have the same problem with Fedora 9, kernel 2.6.25.3.18.
I did not have any problems with k3b verification with Fedora 8 though.

Anyway, I am glad I have found this thread, with all the info, because I was wondering what was going on, especially after I discovered that the burned ISO's were completely in order.