22 Oct
2014
22 Oct
'14
7:54 a.m.
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/