https://bugs.kde.org/show_bug.cgi?id=124514
Ph. Marek <phil...@marek.priv.at> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WAITINGFORINFO |---
Status|NEEDSINFO |REPORTED
--- Comment #4 from Ph. Marek <phil...@marek.priv.at> ---
Still happens -- renaming the copy destination breaks the copy process.
And the whole behaviour hasn't improved in the 17 years.
Simply opening a konqueror window with an audio cd in the drive hurts -- it
spins up, it spins down, it spins up, seeks, spins down, spins up, ...
When copying from the Ogg Vorbis folder on the CD to a local SSD I'd expect the
whole 60x speed that the drive is capable of --
after all, the simple transcode to MP3 or OGG isn't the bottleneck any more,
and even if it was, a modern machine can cache
quite a few audio CDs in RAM (simply in the Linux buffers) before breaking a
sweat.
But instead of having a full copy of the CD in a minute or so, the window for
_a single file_ is open for 15 seconds (with a 100% progress bar!)
while the drive is clicking on and off before the progress bar resets and then
starts to move.
The seeking sounds continue.... ISTR that the number of parallel KIO threads
was configurable with KDE 3.5 or so, is that still possible somewhere?
Sorry (a bit) about the rant.
--
You are receiving this mail because:
You are watching all bug changes.
