Dan Youngquist composed on 2014-10-21 20:26 (UTC-0700): > On 10/21/2014 08:14 PM, Felix Miata wrote: >> Other than selecing source and destination, and deselecting create/delete >> image (aka on-the-fly), I used only defaults, resulting in (auto) writing >> speed 22713KB/s (16.49x) in the upper pane. > I don't know why the write failed, but just thought I'd point out that > writing at max speed will make a lot more coasters. I always write at 1/2 > the max speed of the media or the drive, whichever is slower, and get more > reliable copies and never a coaster. You might give that a shot and see if > it helps. Makes sense, but didn't help, and took much longer than double the time to reach failure. I selected 8x, but it seemed unable to get more than 4X at best, dropping at times to 1.9x: K3b Writing DVD copy stopped @00:17:05h/Remaining 23:45:38, 4136 of 4144 MB. :-( Disk space is apparently unrelated, as before and after starting, / consumption stayed @87%. :-p Next, @8x again, I tried writing tmp file, then burning to SATA drive read from. That claims to have succeeded in 18:08. Next, @8x again, I tried letting it write tmp file, burning to PATA drive after creating the file from SATA. That claims to have succeeded in 15:42. Next, @8x again, I tried writing tmp file, then burning to PATA drive read from. That claimed to have succeeded also in 15:42, and plays back OK in a DVD player. Next, @8x again, I tried letting it write tmp file, burning to SATA drive after creating the file from PATA. That claims to have succeeded in 16:03. Next, @8x again, I reversed the original failed source/destination configuration, reading from SATA, writing directly to PATA without first writing to a temp file. That produced another coaster @00:07:34h/remaining 00:00:04, 4217 of 4251 MB, with the target drive continuing to spin at high speed until I killed K3b. Next, @8x again, I repeated the original failed source/destination configuration, reading from SATA, writing directly to PATA without first writing to a temp file. But this time I first booted openSUSE 12.3, with KDE 4.10.5 and K3b That ended @remaining time 00:00:00, 4231 of 4231 MB, without any closure messages or ejection attempts, with K3b again needing to be killed. I tried it in two different players. Both show title menu and play all title's starts, and find and play from each of the index marks, and the end of the last title. Based on that sampling, I have to think it's a complete copy. That made me try the "coasters" in a player. All play like the one already tried. So, it appears there's probably a bug in the on-the-fly process in K3b 3.5.13.2 aka 1.0.5-1.oss131.opt.x86_64 in openSUSE 13.1 that's a bit worse than a similar one in 12.3's k3b-2.0.80git20140929.1916-1.1.x86_64. Maybe the drives don't like the several years old CMC MAG/AM3 media, or maybe the problem is in the genisoimage or other underpinnings of the two app versions, genisoimage-1.1.11-16.1.3.x86_64 on 13.1. ??? https://bugs.kde.org/show_bug.cgi?id=322096 and https://bugs.kde.org/show_bug.cgi?id=291649 look like could be related to this, but I don't find either a KDE4 or a Trinity bug directly on point. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/