Version: (using KDE KDE 3.2.0) Installed from: SuSE RPMs OS: Linux I have irkick running in the tray of kicker. After right-klicking and selecting "Configure...", I get the configuration dialog. The Remote Control is correctly shown as "Hauppauge". Loaded Extensions on the second tab are "Applications": "KDE Program Launcher", "Kaffeine", "Konqueror", "Noatun". Klicking on "Add Action..." freezes the dialog. The buttons do not work any longer, and after minimizing the window, it does not redraw itself. This behaviour is always reproducable. Klicking on "Add Actions..." (note the 's'!), I get a window "Select Profile to Add" with "Profile Names" "KDE Program Launcher", "Kaffeine", "Konqueror", and "Noatun". Selecting one and clicking OK closes the window, but does not lead to any effect in the configuration dialog. This behaviour also is always reproducable. On the other hand, irkick blinks when I press any button of the remote (so at least something is working), and the infrared plugin for Noatun also works: I can successfully enable and configure it from within the Noatun configuration. In general, lirc using ~/.lircrc with mplayer, xmms, and irexec works fine as well. What else do you need to know?
> Klicking on "Add Action..." freezes the dialog. The buttons do not work any > longer, and after minimizing the window, it does not redraw itself. This > behaviour is always reproducable. sounds baaaaad. > Klicking on "Add Actions..." (note the 's'!), I get a window "Select > Profile to Add" with "Profile Names" "KDE Program Launcher", "Kaffeine", > "Konqueror", and "Noatun". Selecting one and clicking OK closes the window, > but does not lead to any effect in the configuration dialog. This behaviour > also is always reproducable. by the looks of it the haupage remote control does not include any standard playback buttons that kdelirc (or any intelligent person, really) would need to be able to associate any of the buttons to obvious and useful functions of playback orientated apps like kaffeine/noatun. this pretty much explains the problem that it does nothing. > What else do you need to know? right; this might be a tricky one to track down as it's completely unreproducable at my end. can you run the kcm under gdb and tell me the backtrace? to do this you'll eed to open a konsole, type: gdb --args kcmshell kcmlirc then enter: run it should start the kdelirc configuration applet, where by you can reproduce the problem. when it freezes, press ctrl-c in the konsole and it should tell you which function it's stuck in. then enter: bt which should give you a big long list of functions that it went through to get there. it may be most helpful if you could attach the full output from gdb to this bug. bish bosh, gav
Created attachment 4815 [details] Backtrace of the point where it freezes This is the output of "gdb --args kcmshell kcmlirc" -> run -> Click "Add Action..." -> Strg-C -> bt.
this doesn't look much like a bug in kdelirc - from what i can see, it's doing exactly what it should do; looks more like a problem with dcop. do you have an up to date kdelibs/kdebase? also are they the same version as kdeutils? do you have any old versions of kde hanging around that may be causing problems? has your packager released updated builds of kde since you installed? have you been seeing strange behaviour in other kde apps? gav
I just upgraded to 3.2.1 (from SuSE's ftp server: ftp://ftp.suse.com/pub/suse/i386/supplementary/KDE/update_for_9.0), and the problem still exists. I don't have any major problems or strange behaviour in other kde apps. There is no KDE package from older KDE versions (like 3.2.0 or 3.1.x).
does irkick (the system tray app) freeze/crash too? you can check this by right-clicking on it - make sure it's running before also, then check it again when the configuration has frozen. gav
After trying again, it finally works! I don't know why I thought it still didn't work after the update to 3.2.1 (I think it froze again, but I'm not so sure any longer), but now the problem seems to be gone.
irkick seems to work nice (icon flashes when pressing configured buttons). in the configuration dialog (kcmlirc), appears my remote entry in the list on the left. when i press the "add action" button, the dialog hangs and won't respond to any further input. i traced the problem down to theAddAction::updateObjects() method in addaction.cpp. i did not find out what the problem is in there (it doesn't seem to be some infinite loop). i commented out the whole function (line 333 - line 356), but the last line (updateFunctions()). this seems to be a fair enough workaround, the dialog appeared, i could add several different Actions and they do work flawlessy (well it would be nice if one could put programs with arguments in a "KDE Program Launcher" action, but this issue can easily be circumvented with a script), i use them on a daily basis and never stumbled over problems - but still it's some hack. :) maybe you wanna fix that. i'd do it my own, but this stuff is a bit over my skills.
uhm: i'm using the suse rpms and it didn't work for neither 3.2.1 nor 3.2.2, btw. and irkick is *not* frozen, only the configuration dialog.
this is really hard for me - i keep looking at the code, but it works fine at my end; then it "magically" fixes itself for uli9999 - it's all very strange. the best thing i can suggest is if you could put some qDebug(...) statements in between each of the lines in updateObjects to show where it gets to, and what the variables are. this would help tremendously in figuring out what is wrong. cheers, gav
Reporting that it works was a little bit too early: most of the time, the configuration dialog freezes again, but it works sometimes. In the meantime, I updated from 3.2.1 to 3.2.2 (always SuSE rpms), and it is the same behaviour after the update (works only sometimes). As Magnus said, irkick never freezes.
Still the same with 3.2.3.
I have the same problem ever since this feature has been added to kde (3.2.0 if I am not mistaken?). Since I am using Gentoo I was always able to "fix" it by just reemering kdeutils once more. Don't ask me what happens then, but after I did that, it works. The problem still occurred on 3.2.3, so I just tried the same old trick, and it worked. It works perfect afterwards.
Still the same with 3.3beta2. Lately, I have not been able to add a new action, but I did not try very often.
Fixed in CVS. Turned out to be due to an alteration in the naming of anonymous processes, and the fact that DCOP will hang if you pass it a dud process name. Should be in 3.3.0
I have exactly the same problem with irkick on kde 3.4.0: the dialog freezes when I push the "Add Action" button...
BUG is not resolved. I have Polish KDE and when I swich to English, everything is all right. Changing: if(!QString(*i).find(i18n( "anonymous" ))) continue; to if(!QString(*i).find( "anonymous" )) continue; and compiling module again resolves my problem. Probably it is because Polish translation is not complite or some anonymouse processes are not using i18n :) maybe it should be: if(!QString(*i).find(i18n( "anonymous" ))) continue; if(!QString(*i).find( "anonymous" )) continue; ?? This would be the best idea for English and non-english users.
I have the same problem with irkick (hangs at Add..). I use Gentoo & Kde with Polish language. It hangs sometimes, but I can reproduce this. I've noticed, that it hangs, when there is: kio_http ...... in "ps -ef" output. So invoking Konqueror (Akregator in my case) makes me unable to add new actions (until all kio_http will finish). As a workaround, I call: killall kio_http and it simply unfreezes irkick configuration window.
Seems it isn't solved.
Same problem here. Killing kio_http doesn't help. After doing a world update, it works though! Seems like some weird dependency problem?!
It can't work because of ane line in kcmlirc/addaction.cpp if(!QString(*i).find(i18n( "anonymous" ))) continue; should be: if(!QString(*i).find( "anonymous" )) continue; if(!QString(*i).find(i18n( "anonymous" ))) continue; autor is not responding... :(
On 21 Oct 2005 23:29:55 -0000, "Konrad Materka" <kmaterka@wp.pl> said: [bugs.kde.org quoted mail] can anyone verify that this fixes the bug generally? if so i'll commit asap... gav
I know that this fixes it for me. if(!QString(*i).find( "anonymous" )) continue; if(!QString(*i).find(i18n( "anonymous" ))) continue; Simply this rejects all "annonymous" AND "anonimowy" { == i18n("anonymous") in Polish }. I shouldn't breake the application, because both were working in some conditions. To explain: some applications are using i18n and kdelirc "Add action button" won't work with them. Some are not using (for example Polish KDE) and kdelirc will hang with them. Look that this is only one line more, which is quite clear in form. And this fixes at least problem for Polish users. Won't break german, Dutch etc. KDE's
Committed. Expect it in the next release of 3.5
Problem still exists in 3.5 (built from source). I noticed that everything is OK when starting KDE for first time (for newly created user). This is very odd.
Interesting... It doesn't seem as irkick bug. If I start KDE session as another user ("guest" in my case, unprivileged) "Add Action" dialog opens. I tried to start KDE with my home directory cleaned, and problem was gone for a while. It suddenly reapeared again, and I can't tell why. Cleaning all KDE temporary files didn't help. There's also some behavior of my remote control, that *might* be related to this problem. After starting KDE from cleaned home directory problem was not present for a while. My CH_UP key on remote was set as Repeatable, and it was assigned Channel Down action in kdetv. CH_DOWN was also repeatable, and was assigned Channel Up action in kdetv. That way, pressing CH_UP would shift from 2 to 3. After reapearing of the problem, behavior of my remote was changed. Pressing CH_UP key changed channel from 10 to 6, and CH_DOWN changed from 1 to 5. The reason for this is the fact that my remote control always sends series of 4 codes to lirc. So, to fix that behavior, I had to disable Repeatable option in irkick and to properly assign CH_UP to Channel Up action, and CH_DOWN to Channel Down action. I'm not sure if this change in remote control behavior is related to the freezing problem.
Update: I commented lines 353-356 in addaction.cpp and problem is gone. I don't know what are long term consequences of commenting these, but I'll continue using this workaround, until problem is resolved completly. ;)
Here's some more update. As I figured it out, there's some running application that doesn't respond to DCOP calls, so irkick window freezes. At the same time irkick window freezes, kdcop application also freezes. Here's test you can use to find the application: $ for app in `dcop` $ do $ dcopfind "$app" $ done In my case listing hanged at kalarmd, so I killed kalarmd and irkick (and kdcop also) window unfroze. Can anyone tell me if it's DCOP or kalarmd or <?> problem?
As I did it before. I found, that 'anonymouse" applications are the problem, so I added one line: if(!QString(*i).find( "anonymous" )) continue; This skips that applications in "while" loop in addaction. Problem is with applications which are using DCOP, but do not provide proper interface to use it, so DCOP hangs (and then irkick too). void AddAction::updateObjects() is now rewritten (if i remembered it correctly), but still are problem with it. Try to switch to Englich KDE for a moment, and chceck if it works now. Try to replace: if(!QString(*i).find(i18n( "anonymous" ))) continue; with if(!QString(*i).find( "anonymous" )) continue; if(!QString(*i).find(i18n( "anonymous" ))) continue; (if shitching to English KDE works). Your script is working in my system. I have Kubuntu and KDE 3.5. konrad@ubuntu:~$ ./skrypt DCOPRef(kwin,) DCOPRef(kicker,) DCOPRef(kded,) DCOPRef(kmix,) DCOPRef(knotify,) DCOPRef(kio_uiserver,) DCOPRef(konsole-8009,) DCOPRef(klauncher,) DCOPRef(khotkeys,) DCOPRef(kbluetoothd,) DCOPRef(kdesktop,) DCOPRef(katapult-7798,) DCOPRef(klipper,) DCOPRef(ksmserver,) DCOPRef(kaccess,) konrad@ubuntu:~$
In 3.5 version of KDE that function is fixed like you wrote, but irkick still hangs. I'm using English KDE. I'm pretty sure that kalarm/kalarmd is causing the problem in my case, because it hangs when I configure it in a specific way, it doesn't start with KDE, dies when applying configuration changes, etc. I informed Kalarm author, and I'm waiting for a response.
Same here. KDE 3.5.2, Fedora Core 5. In my case, it was kwordtrans who was blocking DCOP. Is there a way to timeout this loop to avoid locking in these brain-dead applications?
seems the new version of kdelirc work good