Version: 3.4.2 (using KDE 3.4.2, Debian Package 4:3.4.2-4 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.8-2-686 When ripping audio CDs by copying them from audiocd:/MP3 in Konqueror, the amount of time and space it seems like it will take is always far less than it actually does. The "(Copying)" window reaches 100% with "00:00:00 remaining" time (and, e.g. "50.3 MB out of 50.3 MB complete"), but often a number of files still remain (e.g., "11/14 files", meaning that although it appears complete at 100%, there are still 3 tracks to rip). The amount of data copied, and to be copied then continue to rise in unison ("50.4 MB out of 50.4MB", and so on), until it finally finishes. It would be good if Konqueror/kfmclient/audiocd/whoever _overestimated_ how big the files will be, so that rather than _appear_ to be finished, and then force the user to wait, confused as to why the progress bar is stuck at 100%, it would simply finish early in most cases. I figure the easiest way to do this is assume the absolute worst compression ratio for MP3 (or other compressed formats audiocd:/ supports, such as OGG)... rather than assuming whatever it is assuming now. ;^) Thanks! We're happily ripping all of our CDs... just... more slowly than we expected due to these underestimates. ;^)
I agree; the listDir sizes in mp3/ should include the overestimation (which is currently only done in get).
Yah, it actually does, but kio in 3.5 doesn't like me changing the estimation all the time on it. Need to figure out why.
You can't change the estimate of a listDir or stat, since this is only called once. I'm not talking about the changing-estimate during get(), that's another matter. But when listing the directory (mp3/ for instance), shouldn't the sizes be made bigger?
*** Bug 120737 has been marked as a duplicate of this bug. ***
Even if the time measure is correct, when
Even if the time measure is correct, when I rip a cdaudio to mp3 using kdemultimedia-kioslaves (drag the mp3 folder to hdd), it takes __so__ long to do it. A cdaudio with aprox 60 mins of audio takes about 30 minutes to encode to mp3 in a 3800+ dual core syste (!!)
*** Bug 194258 has been marked as a duplicate of this bug. ***