Description of problem: K3B checksum report ok Written data < data to burn Incorrect md5sum /dev/sr0 Version-Release number of selected component (if applicable): 1 How reproducible: y Steps to Reproduce: 1. Burn an iso image
Any error reported by k3b?
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaudSummary: Error report. => k3b didn't burn the whole ISO
@ M GT Please reply to the question above within two weeks from now, to avoid this bug being closed as OLD.
CC: (none) => marja11
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Status: NEW => RESOLVEDResolution: (none) => OLD
Actually, I was unaware of this bug report, but I have seen this happen recently in both ways. Both k3b and brasero have a habit of reporting false checksum errors ( https://bugs.mageia.org/show_bug.cgi?id=2329 ), so I typically do a "cmp" between the source ISO and the contents of the burned /dev/srX to verify. The comparison always comes up exact (unless there really *is* an error). When gvfs stopped automounting DVDs and blanks, brasero wouldn't work under KDE, so I switched to k3b to burn 2 ISOs. When I ran the compare in the first case, the ISO hit EOF before the burned disk, and in the second, the burned disk hit EOF before the ISO. I have the disks and the original ISOs if anyone thinks they can tell from them why k3b wrote too much in one case and not enough in the other. In both cases, "verify written data" was on, and k3b reported the verify was successful. Note that as reported in bug#2329, both k3b and brasero try (or have tried in the past) to do a "quick-verify" by comparing checksums of blocks larger than the device sector size computed during the original read of the ISO to checksums computed by reading back from the burned disk, and that the underlying cause of 2329 was believed to be that the ISO didn't exactly fill a number of such blocks. Since in these cases, k3b reported no errors, I wonder if someone didn't try to fix k3b for the 2329 bug and went a little too far.
CC: (none) => ftg
I just tried burning one of the ISOs with brasero, got no errors on the checksum, but a "cmp" got EOF on the ISO, just as with k3b. Reopening, because *something's* going on here. Does anyone know of a tool to check the internal integrity of an ISO ?
Status: RESOLVED => REOPENEDResolution: OLD => (none)
CC: (none) => tmb
Got it. This is a k3b bug, but only of a sort. The problem occurs with DVDs of a certain season of a certain TV show (at least for me) and only with ISOs copied from the original disks using k3b. If the ISOs are copied using DVDFab (which is bleeding-edge at defeating oddball DRM techniques used to confuse copying programs), the ISOs burn fine. So, at least in my case, this is a case of k3b falling prey to some intentional corruption of the ISO by its manufacturer. Closing again, unless the OP wants to pursue it.
Status: REOPENED => RESOLVEDResolution: (none) => OLD