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.
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?
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!
So with the same hardware/kernel, but kde 3.2 you didn't have any problems?
Nope. No problems at all.
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.
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.
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.
I had no problems copying the wav using audiocd:/ in Konqueror. Running kaudiocreator from the command line didn't give me anything, though.
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
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).
"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.
>"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.
Just making sure, but you have dma enabled right?
yep, dma is enabled, with other CD-ripping tools I have no problems, only with KAudioCreator, can you reproduce the "every second refresh problem"?
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.
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.
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.
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?
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.
> 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.
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
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?
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; }
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
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.
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.
forgot to mention; I'm using Linux not BSD.
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?
Good point, however I would prefer the dialog again on a manual query and not after startup or switching a cd.
"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
Still unknown as to why this problem is occuring...
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).
Wild guess here, but is everyone using AMD 64?
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.
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.
Some more information. This is also new for me in 3.3. I don't have an Athlon but an Intel Xeon.
"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?
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.
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.
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
> Wild guess here, but is everyone using AMD 64? Nope, Athlon XP
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).
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.
I applied the patch to normal kdemultimedia 3.3.0, and it now works perfectly with both CD drives. Many thanks for fixing this!
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.
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).
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 !
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
"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?
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.
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.
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
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.
Recently tried to rip a new CD on KDE 3.4, and the bug is also back for me :(
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.
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