Version: 0.11.10 (using KDE 3.2.2, Mandrake Linux Cooker i586 - Cooker) Compiler: gcc version 3.4.1 (Mandrake Linux (Cooker) 3.4.1-0.1mdk) OS: Linux (i686) release 2.6.6-1mdk I burned the suse network installation cd (just a mere 23 mb) but k3b was unable to verify it. looks like this was due to the fact it ejected the cd, but before it was reloaded again, the md5sum check of the original 23 mb was ready, and k3b was unable to find the cd. So I guess, not allowing k3b to eject&reload after burn&before the verify whould solve this. and I guess it whould be nice to be able to check a cd afterwards, too. so these 2 things whould solve a few wishes and this bug ;-) btw thanks for the work, k3b is really great & getting better all the time!
so reloading the cd did not work and k3b did not ask to do it manually?
reloading did work (well, the cd went back into the reader, but before it was in the reader k3b already gave the error that the md5sums where incorrect(I guess because the img was just 23 mb, it had already finished hashing): unable to read data (or something like that). so it quit with an error, but I'm quite sure that was just because k3b didnt wait for the cdburner to finish reloading the cd. if the short time it takes to compute the md5sum is the reason for this problem, then when you whould have changed k3b so it whoulnt re-compute the md5sum when it has already done so before burning, all reloadings will go to slow for k3b so every data check will give an error. and it will already happen sometimes with small images on fast systems I think.
normally k3b waits for the media to be reloaded. Here it does with all drives. I will check into that.
well, it might be that something else went wrong... but it always works normally, so I thought it might be the small size of 23 mb (it was unable to read anything.. isnt that strange?). What else could it be? anyway, thanx for the work you put in k3b.
I guess the new k3b will have this fixed (more clever handling of md5sums). so i'll close this :D