Bug 87267 - Constantly refreshing CD makes ripping very slow
Summary: Constantly refreshing CD makes ripping very slow
Status: RESOLVED FIXED
Alias: None
Product: kaudiocreator
Classification: Applications
Component: general (show other bugs)
Version: 1.10
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Gerd Fleischer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-15 21:31 UTC by Kevin McKernan
Modified: 2005-04-25 01:02 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin McKernan 2004-08-15 21:31:31 UTC
Version:           1.10 (using KDE 3.3.0,  (3.1))
Compiler:          gcc version 3.3.4 (Debian 1:3.3.4-7)
OS:                Linux (i686) release 2.6.8.1

KAudioCreator seems to be constantly accessing the CD drive while running. The drive lights up and spins about every second. The entire application runs very slowly, pausing completely between CD drive accesses.

When I try to rip a CD, it seems to go back and forth between ripping for about half a second then accessing. It took about 6 hours to rip the last CD I attempted (instead of the usual 10-15 minutes or so)

This occurs with every CD I have tried and both of my drives.

I tried putting an audio CD in each of my drives and as soon as I switched KAudioCreator from one drive to the other, the second drive began doing the same exact thing and the first drive stopped. The drive stops all activity the instant you close KAudioCreator.

Using cdparanoia from the command line (or any other ripping frontend) works without any issues at all.

I'm using the KDE 3.3 debs that were just put into Debian Unstable yesterday.
Comment 1 icefox 2004-08-16 05:43:44 UTC
Interesting, yes KAudioCreator polls every other second or so, but this is the first time I have seen this problem.  You should have probably seen the same thing in 3.2.  What hardware are you using and what kernel?  Anything exodic?
Comment 2 Kevin McKernan 2004-08-16 06:14:05 UTC
Interestingly enough, I actually didn't have this problem until I updated to the latest KAudioCreator yesterday. I use it quite often. It's my favorite frontend. :)

I don't think my hardware is anything too exotic. I have a 16x32x LG DVD-ROM drive and a 52x32x52x Lite-On CD-RW drive, both of which exhibited the same behavior. DMA is enabled on both drives, as well. I just updated my kernel yesterday, so this was happening with both 2.6.7 and 2.6.8.1.

In case it helps, I have an Albatron motherboard with an nForce2 chipset, an AMD AthlonXP 2800+ CPU, and 512MB DDR RAM (PC2700).

Thanks for your help!
Comment 3 icefox 2004-08-16 06:24:51 UTC
So with the same hardware/kernel, but kde 3.2 you didn't have any problems?
Comment 4 Kevin McKernan 2004-08-16 06:53:39 UTC
Nope. No problems at all.
Comment 5 icefox 2004-08-16 06:54:57 UTC
Running any other apps?  konq, kscd, k3b, grip?

- -Ben 

On Monday 16 August 2004 12:53 am, Kevin McKernan wrote:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=87267
>
>
>
>
> ------- Additional Comments From screamkev comcast net  2004-08-16 06:53
> ------- Nope. No problems at all.

Comment 6 Kevin McKernan 2004-08-16 07:12:15 UTC
None at all. I've actually even tried it on a freshly booted system running only what's necessary and the problem still occurs.

It starts as soon as KAudioCreator is executed (assuming there is a CD in the drive it is set to use) and stops as soon as it is closed. If there is no CD in the drive when you start KAudioCreator, the problem starts as soon as you put one in or specify a drive that does have one.
Comment 7 icefox 2004-08-16 07:32:04 UTC
Just to elimate audiocd from this problem, copy the wav file from audiocd:/  Also start kaudiocreator from the commandline and copy in the kaudiocreator debug info.  

kaudiocreator: Drive initialization return status: 6
kaudiocreator: No disk.
Comment 8 Kevin McKernan 2004-08-16 08:10:47 UTC
I had no problems copying the wav using audiocd:/ in Konqueror. Running kaudiocreator from the command line didn't give me anything, though.
Comment 9 Michiel de Bruijne 2004-08-19 11:42:47 UTC
Same over here, constantly polling every second, result is indeed very slow rip and it's slowing down my entire machine. Also can confirm that in KDE3.2.x this problem didn't occur. I'm using KDE3.3.0_rc2
Comment 10 Michiel de Bruijne 2004-08-19 11:57:07 UTC
BTW, you need to reevalute the default encoder configuration, because KAudioCreator now uses different variablenames for example albumnumber and albumtitle. The default encoder configuration hasn't been updated though.

Last but not least; KAudioCreator doesn't respect the Ogg Vorbis Encoder settings that are defined in Control Center (Sound & Multimedia/Audio CDs).
Comment 11 icefox 2004-08-19 15:46:30 UTC
"BTW, you need to reevalute the default encoder configuration, because KAudioCreator now uses different variablenames for example albumnumber and albumtitle. The default encoder configuration hasn't been updated though." 

 The defaults changed from 3.2->3.3 and there is a update script that should have run.

"Last but not least; KAudioCreator doesn't respect the Ogg Vorbis Encoder settings that are defined in Control Center (Sound & Multimedia/Audio CDs)."

This has already been reported.
Comment 12 Michiel de Bruijne 2004-08-19 16:46:25 UTC
>"BTW, you need to reevalute the default encoder configuration, because KAudioCreator now >uses different variablenames for example albumnumber and albumtitle. The default encoder >configuration hasn't been updated though." 
> 
>  The defaults changed from 3.2->3.3 and there is a update script that should have run. 

This is from a clean install, never had 3.2.x on this machine before.
Comment 13 icefox 2004-08-19 16:49:27 UTC
Just making sure, but you have dma enabled right?
Comment 14 Michiel de Bruijne 2004-08-19 17:01:15 UTC
yep, dma is enabled, with other CD-ripping tools I have no problems, only with KAudioCreator, can you reproduce the "every second refresh problem"?
Comment 15 icefox 2004-08-19 17:23:24 UTC
Just to clarify, KAudioCreator has always polled every second to see if there is a new cd in the drive.  If the ID changed it then does a bunch of stuff.  It sounds like KAudioCreator is always getting a different id or something, but if that was the case it should have spit out that fact to the command line.  So yes I have seen it always polling, but no I havn't had any problems with it.
Comment 16 Michiel de Bruijne 2004-08-19 17:33:37 UTC
Is it also polling when a "rip-job" is active?

Now that you mention it (the changing ID-thing), in the new release I get a popup to select a CD (if more entries are found in freedb). I noticed that although I have selected a CD that is correct I get the same question again if I put in the same CD. This doesn't happen in KDE3.2.x.
Comment 17 Michiel de Bruijne 2004-08-19 17:51:36 UTC
Just tried to rip a CD that isn't known on the freedb, but I have the same performance problems, goodbye theory that lookup with more entries on freedb might be a problem.
Comment 18 icefox 2004-08-19 19:54:59 UTC
Yup, that is a new feature in 3.3 (the ability to select the cddb entry), before it always just choose one by default.  Try turning off cddb?
Comment 19 Michiel de Bruijne 2004-08-19 20:29:41 UTC
ok, tried it without cddb lookup, same problem.

I'm pretty sure it's due to the fact that KAudioCreator is polling while it's ripping. The first song of one of the CDs I have tried takes kinda long with KAudioCreator (about 4 minutes) compared to other rippers e.g. konqueror audiocd-ioslave or K3B (about one minute). But the last song takes more then 5 minutes for one percent!!! compared to 2 minutes for the entire song with other rippers. Before the last track is found it get's an polling-request and goes back to the beginning of the CD.

I think you need to have a very fast CD-drive that is able to rip the last song and go back to the beginning of the CD every second.

Polling is ok, but definitly not while ripping a CD, there is no reason to do this anyway because I'm not able to rip and replace a CD at the same time.
Comment 20 Michiel de Bruijne 2004-08-19 20:35:28 UTC
> Yup, that is a new feature in 3.3 (the ability to select the cddb entry), before it always just choose one by default.

Nice feature btw, I only wish that once I have made a selection it's stored somewhere so that I don't get the dialog everytime for the same CD.
Comment 21 Tim Wunder 2004-08-21 17:04:48 UTC
I also experience this problem. It also doesn't automatically start ripping after successful cddb lookup.
After removing kaudiocreatorrc and creating a new one, the automatic ripping started working again, but the slowness continued.
I also tried removig my .cddb file to see if that changes anything, but it didn't.

FWIW, I did an 'strace -f kaudiocreator' and posted it here:
http://www.thewunders.org/files/kaudiocreator.strace

Comment 22 icefox 2004-08-22 00:06:21 UTC
 Nice feature btw, I only wish that once I have made a selection it's stored somewhere so that I don't get the dialog everytime for the same CD. 

Well what if you selected one with really back input?
Comment 23 icefox 2004-08-22 00:45:28 UTC
On my box I just tried disabling the timer (1.500 seconds btw) and it took just as long to rip.

And sense you arn't seeing this:

kdDebug(60002) << "Drive initialization return status: " << status << endl;

The problem must be in wmcd.   Are you on bsd?

int status = wm_cd_init( WM_CDIN,
  (char *)qstrdup(QFile::encodeName(device)), NULL, NULL, NULL);
if( status == dstatus ) {
	wm_cd_destroy();
	return;
}
Comment 24 icefox 2004-08-22 00:53:12 UTC
Here is a good test, open kscd (which will poll once a sec) and try coping from audiocd:/  If that breaks then we know libwm is the problem
Comment 25 Michiel de Bruijne 2004-08-22 01:35:10 UTC
Here is a good test, open kscd (which will poll once a sec) and try coping from audiocd:/  If that breaks then we know libwm is the problem

it's not possible to play an audiocd with kscd while ripping something with audiocd:/ because kscd pauses immediately when ripping a cd. With kscd in the paused mode ripping with audiocd:/ goes very fast.
Comment 26 Michiel de Bruijne 2004-08-22 01:36:51 UTC
 Nice feature btw, I only wish that once I have made a selection it's stored somewhere so that I don't get the dialog everytime for the same CD. 
 
 Well what if you selected one with really back input?

I don't understand what you mean by this.
Comment 27 Michiel de Bruijne 2004-08-22 01:40:25 UTC
forgot to mention; I'm using Linux not BSD.
Comment 28 icefox 2004-08-22 01:46:59 UTC
For example some cddb entries are badly formated, with spelling errors etc, but there is another cddb entry that is correct.  If you select a bad one you want to be able to reselect it right?
Comment 29 Michiel de Bruijne 2004-08-22 01:56:23 UTC
Good point, however I would prefer the dialog again on a manual query and not after startup or switching a cd.
Comment 30 icefox 2004-08-22 02:02:34 UTC
"Good point, however I would prefer the dialog again on a manual query and not after startup or switching a cd."

Good idea.  I'll put that down in the TODO file to explore further.  Now back to this problem..... :D
Comment 31 icefox 2004-08-30 02:17:02 UTC
Still unknown as to why this problem is occuring...
Comment 32 peter 2004-08-31 11:36:21 UTC
I also experience this bug. Ripping from KAudioCreator is so slow as to be unusable (~ 1 minute per every few percent). It might also be worth observing that the GUI becomes extremely unresponsive during ripping grip works very well on the same hardware. Copying the .wav files using the audiocd ioslave is also very fast.

strace reveals that the kaudiocreator process is spending most of its time 
in ioctl() calls:
ioctl(14, CDROM_GET_CAPABILITY or SNDRV_SEQ_IOCTL_UNSUBSCRIBE_PORT, 0xbfffed80) =3801071
ioctl(14, CDROM_SEND_PACKET, 0xbfffed80) = -1 EPERM (Operation not permitted)
ioctl(14, CDROM_GET_CAPABILITY or SNDRV_SEQ_IOCTL_UNSUBSCRIBE_PORT, 0xbfffed80) =3801071
ioctl(14, CDROM_SEND_PACKET, 0xbfffed80) = 0
ioctl(14, CDROM_GET_CAPABILITY or SNDRV_SEQ_IOCTL_UNSUBSCRIBE_PORT, 0xbfffed80) =3801071
ioctl(14, CDROM_SEND_PACKET <unfinished ...>

I'm using an Athlon 64 3200+ CPU, 1Gb RAM, and a TEAC DV-W58G-A DVD+/-RW
drive on a parallel ATA interface on an nForce 3Gb chipset. There is nothing else on that IDE channel (in fact, there are no other parallel ATA devices in the machine).

I'm using KDE 3.3 from Debian unstable, and linux kernel 2.6.8.1. I am not using the ide-scsi driver (it is deprecated in 2.6).
Comment 33 icefox 2004-08-31 15:30:33 UTC
Wild guess here, but is everyone using AMD 64?
Comment 34 Jan Jitse Venselaar 2004-08-31 18:44:50 UTC
I am using an Athlon 2400+ (non 64) and I've got the same problem. 
I also noticed that doing a cdparanoia (command line) rip, and starting kaudiocreator resulted in a significant slowing down of the cdparanoia ripping.

I also have the problem that the kaudiocreator gui is very unresponsive when there is a CD selected, I have to wait a few seconds before the display refreshes, not just during ripping.
Comment 35 Jan Jitse Venselaar 2004-08-31 19:03:42 UTC
Hmm.. Just tested it on my other CD driver, and it works absolutely fine there. 
Working fine:
Unknown brand DVD drive (rather old)
Working not so fine:
ASUS CDRW 48x/16x/48x

Now rebuilding with debug, hope to get some more info.
Comment 36 Michael Denio 2004-08-31 20:08:53 UTC
Some more information.  This is also new for me in 3.3.  I don't have an Athlon but an Intel Xeon.

Comment 37 icefox 2004-09-01 01:45:54 UTC
"I also have the problem that the kaudiocreator gui is very unresponsive when there is a CD selected, I have to wait a few seconds before the display refreshes, not just during ripping."

This ^ is probably because the cd drive that it is pointing to in the combo box isn't the drive that it is reading from.  If the drive that it points to (in the combo box) is invalid it scans the system for the cd drive.  Is that correct?  When you swap between the good and bad drives do you change the combobox?
Comment 38 Jan Jitse Venselaar 2004-09-01 11:06:26 UTC
No, it happens when I have a CD in /dev/cdrw (the ASUS one), and the combobox points to /dev/cdrw. When I don't have a CD in the drive, or the combobox is pointed somewhere else, the GUI is responsive.
Comment 39 Kevin McKernan 2004-09-02 01:42:43 UTC
Yes, it's the same for me. KAudioCreator is very unresponsive for as long as the combobox points to a drive with a CD in it. If I take the disc out or switch it to a drive with no CD, it runs fine.
Comment 40 Jan Jitse Venselaar 2004-09-02 12:39:23 UTC
OK, the problem seems to be related to the CD drive, as I have it with one CD drive and not the other (on the same computer).
Some more info:
Working CD drive:
hdd: _NEC DV-5700A, ATAPI CD/DVD-ROM drive
hdd: ATAPI 40X DVD-ROM drive, 256kB Cache, UDMA(33)
"non"-working CD drive:
hdc: ASUS CRW-4816A, ATAPI CD/DVD-ROM drive
hdc: ATAPI 48X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)

hdc is master, hdd is slave
Comment 41 Michiel de Bruijne 2004-09-13 22:55:28 UTC
> Wild guess here, but is everyone using AMD 64?

Nope, Athlon XP
Comment 42 Andrey Shytov 2004-09-13 23:25:03 UTC
I also came across this bug. My hardware is Dell Inspiron 5100, CD drive is: HL-DT-STDVD-ROM GDR8082N, IDE-ATAPI, no scsi emulation, x86, CDROM is /dev/hda. The bug occurs only in KDE 3.3.0,  and not in KDE 3.2.3. cdparanoia works fine. Copying tracks from konqueror also does not create any problems. 

I investigated this bug, and found that it is due to different behaviour of libwm in KDE-3.2.3 and KDE-3.3.0. In KDE 3.2, libwm remembers the drive state after wm_cd_destroy (). In KDE 3.3, libwm forgets everything. Look into in kscd/libwm/cdrom.c for KDE-3.3.0: 

int wm_cd_destroy( void )
{
    // .....
    drive.proto = NULL; // In KDE-3.2.3, there is nothing like that. 
}

Now, what happens when  we query drive status on the next poll: 

int
wm_cd_status( void )
{
    static int oldmode = WM_CDM_UNKNOWN;
    int mode, err, tmp;
    if(!drive.proto) {
        // After wm_cd_destroy drive.proto == NULL, so we arrive here
        // every time kaudiocreator calls wm_cd_status . 
        // Therefore, oldmode == WM_CDM_UNKNOWN, always. 
        oldmode = WM_CDM_UNKNOWN;
        err = wmcd_open( &drive );
        // ...
    }
    // ...
}

One can see from this code, that every time kaudiocreator polls the drive
(TracksImp::timerDone), oldmode == WM_CDM_UNKNOWN (I added some 
fprintf for debugging, and see that indeed oldmode == WM_CDM_UNKNOWN 
on every call to wm_cd_status from kaudiocreator, no matter what).  
For that reason, wm_cd_status will read TOC (about ten lines below): 

if(WM_CDS_NO_DISC(oldmode) && WM_CDS_DISC_READY(mode)) {
   // ...
   if(read_toc() || 0 == thiscd.ntracks)  
   // ... 
}

In contrast to that, in KDE-3.2.3 libwm does not set drive.proto to NULL, 
and thus remembers the result of the previous poll. As a result, 
wm_cd_status does only ioctl (CDOMSUBCHNL, ...), and does not read TOC.
(I straced kaudiocreator both in KDE-3.2.3 and KDE-3.3.0)

Reading TOC is very time-consuming, because it requires repositioning
(on my CDROM drive, it is also makes a very distinct and annoying sound). 

From what I found, it is not clear how one can cope with this problem. 
Currently, the way libwm opens and closes /dev/cdrom seems to be completely incompatible with kaudiocreator polling approach. 
As a workaround, one can probably disable polling in kaudiocreator during the ripping process.  (If, for example, the user will remove disc from the drive, audiocd ioslave will probably complain, right? So it is not clear to me why the polling  is necessary during the ripping process. When the drive is idle, polling does not cause that much trouble, because it does not require repositioning).
Comment 43 icefox 2004-09-14 05:18:54 UTC
Thank you Andrey Shytov.  That was a very informative post.  In cvs I have reworked the code to stop init and destroying it every second.  But like I said before my hardware doesn't seem to cause the problem so I really can't test.  So I need someone else to try and confirm it works or does not.
Comment 44 Jan Jitse Venselaar 2004-09-14 15:59:18 UTC
I applied the patch to normal kdemultimedia 3.3.0, and it now works perfectly with both CD drives. Many thanks for fixing this!
Comment 45 Andrey Shytov 2004-09-14 16:12:55 UTC
OK, Benjamin, I checked out the new version from CVS and compiled it. Now, the drive does not make this annoying clicking, and the ripping speed is incredibly reasonable. (I also traced kaudiocreator while ripping, and the only ioctls to cdrom are now CDROM_LOCKDOOR and CDROM_SUBCHNL, so repositioning is gone.) I also checked that it is still possible to remove the disc from the 
drive while kaudiocreator is idle. 

Thanks for the fix, the bug made kaudiocreator nearly unusable, and now it is works again. 
Comment 46 icefox 2004-09-15 04:04:39 UTC
Yah!  Ok I have backported it to the 3.3 branch.  Many thanks to everyone for providing all the info to help me track this down.  Sigh, too bad I hadn't caught this for 3.3.  3.3.1 will be out soon (next month i think).
Comment 47 Thibauld Favre 2004-10-02 17:01:15 UTC
The old code (that makes kaudiocreator slow) could be useful to track another bug. Here's what I just responded to the author of this comment on dot.kde :

http://dot.kde.org/1096390465/1096441014/
---------------------
"[..on my laptop] kaudiocreator just didn't succeed in ripping the cd tracks. I have the same problem here : it happens from times to times (espacially when I try to rip a cd all in 1 go) that kaudiocreator freezes. I then have to open a console an kill the kaudio_cd process related (you can also kill the kaudiocreator process). Then it _looks_ like everything is back to normal : you try re-ripping the cd and, let's say, this time everything goes ok. You open your <ogg-reader>, load the files : everything looks fine but you can't hear a thing. WTF ? I made some searches and I found that the wav file extracted by kaudiocreator is also "speechless". The only solution I got to be able to rip cds again is to reboot the entire system !!!
 
 I think there are 2 problems :
 1) The first one is how kaudiocreator deals with the CDrom drive (see the bug reported earlier http://bugs.kde.org/show_bug.cgi?id=87267 (which I just found out)
 2) I think that this kaudiocreator behavior pushes the CDROM drive driver to its limits and that the kaudiocreator freeze is due to the CDROM driver getting "mad". When you kill the application, the driver is left in a "weird" state and cannot rip cds anymore... 
 My CDrom drive driver is built-in my kernel so I cannot test if unloading/reloading the kernel would solve the problem (and validate my theory). Also it could be that, with <bug1> solved, <bug2> won't appear anymore.
 
As I found nobody else that had the same pb, I gave up and was waiting for the new 2.6.9 kernel to test my theory.[..]"
----------------------

Is anyone here experiencing the same problem ? that is, basically, kaudiocreator crashes when you try to rip too many files in 1 go ? For me the only solution is not to rip more than 10 minutes of music in 1 go. I let you imagine how "emmerdant" (french but you probably understood the meaning) it is !
Comment 48 Thibauld Favre 2004-10-02 17:11:27 UTC
Sorry I forgot to give my config :
IBM T40p laptop with 512RAM / Pentium-M 1,6Ghz
hdc: UJDA745 DVD/CDRW, ATAPI CD/DVD-ROM drive
kernel : 2.6.7 / gcc 3.2.3 on Debian unstable
kaudiocreator version 3.3.0-1 from debian unstable (problem was already present in KDE 3.2)

thibs
Comment 49 icefox 2004-10-02 21:33:33 UTC
"kaudiocreator crashes when you try to rip too many files in 1 go?"
 
In the configure dialog you select 10 or something for the number of songs to rip at once? 
Comment 50 Thibauld Favre 2004-10-02 21:44:41 UTC
Nope, only 1. When I say "too many files in 1 go", I don't mean "simultaneously", I mean for example selecting _all_ tracks to be ripped and encoded. On my system, they are ripped sequentially. I usually avoid to select more than 2 or 3 tracks : I select like 2 tracks, I launch the ripping and encoding process. Then I wait for my Cd-rom drive to become silent before selecting 2 more tracks and launching the ripping process.. etc... until I ripped the entire Cd.
Comment 51 icefox 2004-10-02 22:28:24 UTC
kaudiocreator version 3.3.0-1 <- /me wonders what they changed.  Sense it was happening with 3.2 it might be a different issue, but as this issue is very driver/hardware related.  How about when you upgrade to 3.3.1 (tagged today, released shortly) you see if the problem still persists.  If it does then open a new bug report with all the information that you can think of.
Comment 52 Woodhouse 2005-04-03 14:56:55 UTC
Kaudiocreator is also unusable for me:

Archlinux on Athlon XP, Via chipset
Aopen CD burner.

For me it started after updating kde from 3.3 to 3.4
Comment 53 Diogo 2005-04-03 20:54:21 UTC
I can confirm that this bug is back after upgrading from KDE 3.3 to 3.4.

Using slackware-current with kernel 2.6.11 and the ripper device is an Asus CD-RW  (CRW-5224A). The problem is basically the same as reported before, with KAudioCreator becoming sluggish and unresponsive as soon as you insert an audio CD.

With another drive present on the system, and old no-brand DVD drive, the problem only occurs when a ripping job starts.
Comment 54 Jan Jitse Venselaar 2005-04-05 18:17:31 UTC
Recently tried to rip a new CD on KDE 3.4, and the bug is also back for me :(
Comment 55 Brian Jonas 2005-04-20 04:01:52 UTC
Just for the record, I upgraded KDE to 3.4.0 from 3.3 and am now experiencing the very  rips, and the sounds of the CD drive frequently repositioning. This wasn't a problem at all prior to the KDE upgrade. I'm using KAudioCreator 1.12 

I was really pleased with it prior to the upgrade -- I hope Benjamin has a chance to take a look at the scripts.
Comment 56 icefox 2005-04-25 01:02:03 UTC
Just noting that those who run across this bug, it was for an earlier version of Kaudiocreator and a different bug, 98477 has been opened with the same effects which is for 3.4 and will be fixed for 3.4.1