Bug 260271 - Kremotecontrol daemon not working
Summary: Kremotecontrol daemon not working
Status: RESOLVED UPSTREAM
Alias: None
Product: kremotecontrol
Classification: Applications
Component: daemon (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Michael Zanetti
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-16 13:12 UTC by fatgerman
Modified: 2011-04-07 09:07 UTC (History)
1 user (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 fatgerman 2010-12-16 13:12:26 UTC
Version:           unspecified (using KDE 4.5.85) 
OS:                Linux

Am trying to get kremotecontrol to work with my remote (built in to a Hauppauge DVB USB stick). Lirc is working correctly - it works with mythtv. My remote is configured as a 'devinput' type in lirc.

The kcm module recognises button presses on my remote. I also see messages from lircd in /var/log/daemon.log when I start the kcm module saying that a client has connected. So that bit works. But I create some actions (eg for Amarok) and they do not work.

There seem to be two wierd things going on. 
Firstly, in systemsettings the K Remote Control Daemon is shown as 'not running' when it definitely is. I modified kremotecontroldaemon.desktop so that it contains 'X-KDE-DBus-ModuleName=kremotecontroldaemon' instead of 'X-KDE-DBus-ModuleName=krcd'. This solved this one problem but didn't get me any further.

Secondly, when I stop and start the K Remote Control Daemon I don't see any messages in /var/log/daemon.log saying that any clients have connected or disconnected to lirc. Is the daemon actually listening to anything?

Reproducible: Always




I'm not familiar with how to get debug printfs out of kde daemons but I'm happy to be told :-)
Comment 1 Michael Zanetti 2010-12-16 22:56:17 UTC
(In reply to comment #0)
> The kcm module recognises button presses on my remote. I also see messages from
> lircd in /var/log/daemon.log when I start the kcm module saying that a client
> has connected. So that bit works. But I create some actions (eg for Amarok) and
> they do not work.

What do you mean by "The kcm module recognises button presses"? If you open the dialog for configuring actions and press some buttons on the remote, is the combobox for the button updating accordingly?
 
> There seem to be two wierd things going on. 
> Firstly, in systemsettings the K Remote Control Daemon is shown as 'not
> running' when it definitely is. I modified kremotecontroldaemon.desktop so that
> it contains 'X-KDE-DBus-ModuleName=kremotecontroldaemon' instead of
> 'X-KDE-DBus-ModuleName=krcd'. This solved this one problem but didn't get me
> any further.

This is indeed wrong in the .desktop file. Thanks for pointing it out!

> Secondly, when I stop and start the K Remote Control Daemon I don't see any
> messages in /var/log/daemon.log saying that any clients have connected or
> disconnected to lirc. Is the daemon actually listening to anything?

OK... I'm not yet sure what the problem could be... Lets debug that a little further:
- Is the icon for kremotecontrol sitting in the notification area (aka system tray)
- If yes, is it flashing when you press any buttons?

> I'm not familiar with how to get debug printfs out of kde daemons but I'm happy
> to be told :-)

Lets start with the basics then:
- open "kdebugdialog" and verify that the "kded4" is checked
- kill and restart kded4 from Konsole to obtain its debug output
- You can load the daemon using "qdbus org.kde.kded /kded loadModule kremotecontroldaemon" and stop it with the same but "unloadModule" instead of "laodModule". To list the currently loaded modules use "qdbus org.kde.kded /kded loadedModules"

Please attach the output of kded4 when loading the kremotecontroldaemon module and pressing any buttons.
Comment 2 Michael Zanetti 2010-12-16 22:58:46 UTC
SVN commit 1207084 by mzanetti:

Fix module name in desktop file

CCBUG: 260271



 M  +1 -1      kremotecontroldaemon.desktop  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1207084
Comment 3 fatgerman 2010-12-17 00:44:37 UTC
OK I've started investigating like you suggested but what I've discovered is that the problem is not quite as I described because there are some more fundamental problems that were confusing matters.

Firstly there's some sort of issue with the remote initialising when I boot - I have to unplug the receiver and then plug it back in in order to get it to work at all with any application *except* the dialog for configuring actions, which always works even directly after a boot. So this makes me wonder if something in KDE has 'locked' my receiver out. Certainly there's a very long pause after log in (30 seconds) during which nothing happens and then the kremotecontrol icon appears in the system tray. This only happens directly after the initial boot.

So having done that I can get certain actions to work - I can now control Amarok for example, but I can't get any of the Sound Mixer actions to work, which is what I was originally testing. The system tray icon flashes when I push the volume buttons, but nothing else happens.

(My volume controls do work if I disable kremotecontrol. They even work if I stop lircd. I think this is because my receiver is being driven by both 'devinput' and 'kbd' kernel modules. I mention this in case it's relevant but I don't think it is)

Sorry for the long post. To sum up, kremote controldaemon *does* work provided my receiver is properly initialised but:
(a) Something prevents my receiver from initialising properly - could kremotecontrol or Solid be the culprit? How do I find out?
(b) The sound mixer template appears not to work (could this be because I have pulseaudio running?)
Comment 4 Michael Zanetti 2010-12-17 08:30:21 UTC
(In reply to comment #3)
> Firstly there's some sort of issue with the remote initialising when I boot - I
> have to unplug the receiver and then plug it back in in order to get it to work
> at all with any application *except* the dialog for configuring actions, which
> always works even directly after a boot.

Thats kinda strange, because also the configure actions dialog gets the button presses from the kremotecontroldaemon... If the dialog works, everything should work... The daemon is the only instance talking directly to lircd and disatches the button presses to either the config dialog or the action-executionengine.

> So this makes me wonder if something
> in KDE has 'locked' my receiver out. Certainly there's a very long pause after
> log in (30 seconds) during which nothing happens and then the kremotecontrol
> icon appears in the system tray. This only happens directly after the initial
> boot.

Verify if the icon is there earlier, but crossed out and hidden behind the arrow. If there is no connection to lircd, the icon is hidden in the inactive icon area.

> 
> So having done that I can get certain actions to work - I can now control
> Amarok for example, but I can't get any of the Sound Mixer actions to work,
> which is what I was originally testing. The system tray icon flashes when I
> push the volume buttons, but nothing else happens.
> 

OK... I just have checked the mixer actions and it seems KMix has changed its D-Bus API lately. I'll have to fix the Volume actions. In the meantime you can workaround this like this:
- call: qdbus org.kde.kmix /Mixer0 masterDeviceIndex 
- copy the resulting string (something like "alsa_output.pci-0000_00_1b.0.analog-stereo") and paste it into the argument value of the configured volume action instead of the text "Master:0"

> (My volume controls do work if I disable kremotecontrol. They even work if I
> stop lircd. I think this is because my receiver is being driven by both
> 'devinput' and 'kbd' kernel modules. I mention this in case it's relevant but I
> don't think it is)

Not sure... I have no experience with devinput infrared devices. 

> Sorry for the long post. To sum up, kremote controldaemon *does* work provided
> my receiver is properly initialised but:
> (a) Something prevents my receiver from initialising properly - could
> kremotecontrol or Solid be the culprit? How do I find out?

I doubt its KRemoteControl or Solid. They only access the socket file reading. No locks etc involved. Currently I'm not really sure what I should advice to further debug this except trying to better understand how everything works and re-read all the debug output with the newly learned things... If you want to learn more about debugging, you can also contact me privately to prevent flooding the bug report with non related stuff. I'm always willing to help users that have the will to learn some stuff to produce good bug reports.

> (b) The sound mixer template appears not to work (could this be because I have
> pulseaudio running?)

I'll fix this for 4.6. Please use the above mentioned workaround in the meantime.
Comment 5 fatgerman 2010-12-17 12:02:35 UTC
(In reply to comment #4)
> 
> Thats kinda strange, because also the configure actions dialog gets the button
> presses from the kremotecontroldaemon... If the dialog works, everything should
> work... The daemon is the only instance talking directly to lircd and disatches
> the button presses to either the config dialog or the action-executionengine.

Very odd, because when I open the configure dialog I get a 'client connected' message from lircd in /var/log/daemon.log, and when I close the dialog I get a 'client disconnected' message there.

I'll do the workaround for the volume control. I don't have much time right now to look at the rest of it. It does seem to me as if it's some strange startup/race kind of condition and probably nothing to do with kremotecontrol.
Comment 6 Michael Zanetti 2011-03-14 21:35:42 UTC
Any new findings on this one? It really sounds like some sort of race condition when starting up the machine...

btw. The Sound Mixer problem should be gone by now. KMix seems to have fixed their API again, so the above mentioned workaround shouldn't be needed any more.
Comment 7 fatgerman 2011-03-14 23:21:08 UTC
Sorry I haven't been able to do any more tests on this since I last posted, been on holiday :-)

Your theory about a race condition sounds feasible though, I do recall having issues that the DVB adapter sometimes didn't work unless I removed and reinserted if after a cold boot. If I get a chance I'll update this bug report, but that's not likely to happen in the immediate future.
Comment 8 Martin Riethmayer 2011-03-20 16:36:32 UTC
Confirming this bug on openSUSE 11.4, Kernel 2.6.37, KDE 4.6.0, LIRC 0.9.0-pre1 with driver 'devinput', lircd set to auto-start on boot (runlevels 2, 3, 5), irw working correctly at all times

After reboot, the remote control is not working with kremotecontrol

First try:
1. Reboot
2. Remote control not working, the icon in the systemtray is not flashing.
3. Open Remote-Control config dialog: Buttons are picked up during the config, the sys-tray icon is not flashing
4. Close Remote-Control config dialog: No button activity (see 2)

Second try:
1. qdbus org.kde.kded /kded loadedModules, output includes kremotecontroldaemon
2. Unload kremotecontroldaemon with qdbus, result: tray icon disappears
3. Re-Load kremotecontroldaemon with qdbus, result: tray icon re-appears
4. No button activity at all, not even in config dialog

Third try:
1. kill kded4, result tray icon disappears
2. restart kded4 (with debug output enabled), result http://pastebin.kde.org/7743/
3. No button activity in config
4. Buttons work as expected outside the config


Hope that helps. If you need more info, I'll gladly submit it. 

Thanks for the great work on kremotecontrol! Other than this bug, it's a real pleasure to work with!
Comment 9 Michael Zanetti 2011-03-20 20:24:02 UTC
(In reply to comment #8)
> Hope that helps. If you need more info, I'll gladly submit it. 

Hi Martin,

I'd like to see the debug output of the daemon on a run where it failed to connect to lircd. The log you put on pastebin just tells that everything is fine.

> Thanks for the great work on kremotecontrol! Other than this bug, it's a real
> pleasure to work with!

Thanks a lot. I'm glad you like it! Such kind words are always appreciated by the devs.
Comment 10 Martin Riethmayer 2011-03-23 22:14:21 UTC
Hi Michael, 

sorry for the late reply. 

I've switched back to lirc 0.8.7 and also found a mistake in my config of XBMC: I set "Remote control sends keyboard presses" to yes - which prevents kremotecontrol from picking up any of the key-presses from the remote.

So for me, all is working great now. 
Thanks for your help - your debugging advice made me realize my mis-configuration of XBMC.
Comment 11 Michael Zanetti 2011-03-23 22:50:36 UTC
Thanks for reporting back...

As this behaviour seems to be caused by third party applications and both setups are working now, I'll close this bug as invalid.
Comment 12 Martin Riethmayer 2011-03-31 22:45:48 UTC
I'm sorry, but I'm afraid I would like to request to re-open this bug.

At the time I wrote my last message, everything was working as expected - only to stop working the next day. So instead of always ruining my "real" system, I decided to finally set up a VM (VirtualBox 4.0.4, Host Windows 7), with a clean install of openSUSE 11.4, all updates applied as of March 30th, no further repositories or software installed. 
(Kernel: 2.6.37.1, kremotecontrol 4.6.0, lirc 0.8.7, kde 4.6.0)
Then I took the following steps:

0. Kill kded4, enable debug output for it and start it from konsole again

1. Configure lirc (/etc/sysconfig/lirc and /etc/lirc/lircd.conf)
-> set Driver="devinput", Device="dev/input/by-path/pci-0000:00:06.0-usb-0:2:1.0-event" and copy /usr/share/lirc/remotes/devinput/lircd.conf.devinput to /etc/lirc/lircd.conf

2. Install kremotecontrol (No kded4 output after about 1 minute, so continuing)

3. Starting lircd and testing with irw
-> Works (still no kded4 output, so continuing)

4. Start kremotecontrol Config dialog
-> The remote "devinput" is available and active
kded4 output:
kded(6449) LircClient::isConnected: theSocket QObject(0x0)
kded(6449) LircClient::connectToLirc: lircd >= 0.8.6 socket found...
kded(6449) LircClient::connectToLirc: updating remotes
kded(6449) LircClient::connectToLirc: waiting for lirc
kded(6449) LircClient::connectToLirc: reading...
kded(6449) LircClient::slotRead: "LIST"
kded(6449) LircClient::slotRead: ("devinput", "devinput")
kded(6449) LircClient::slotRead: "LIST devinput"
kded(6449) LircClient::slotRead: Remotes read!
kded(6449) Solid::Control::ManagerBasePrivate::loadBackend: Backend loaded:  "Lirc"
kded(6449) LircRemoteControlManager::createRemoteControl: unknown interface: "devinput" creating it
kded(6449) KRemoteControlDaemon::KRemoteControlDaemon: connecting to remote "devinput"
kded(6449): registerObject() successful for  "kremotecontroldaemon"
kded(6449)/kded4 Kded::loadModule: Successfully loaded module "kremotecontroldaemon"

5.Trying to configure one of the buttons (e.g. to start up Amarok)
-> Config dialog is not picking up buttons, Tray icon is not flashing
kded4 output:
kded(6449) KRemoteControlDaemon::ignoreButtonEvents: muting remote "devinput"
kded(6449) KRemoteControlDaemon::considerButtonEvents: unmuting remote "devinput"

6. Press apply anyway
-> Tray icon states that the configuration has been reloaded.
kded4 output:
kded(6449) Remote::masterMode: Master mode not found
kded(6449) Remote::masterMode: Master mode not found
kded(6449) KRemoteControlDaemon::reloadConfiguration: starting notifier item

7. Stop lirc, re-open config dialog
-> The remote "devinput" is available but inactive (cursive) - however, I can still start the wizard to assign buttons to it. Of course it's not picking up buttons in this state. The tray-icon stays in active state.
kded4 output (when opening and closing the wizard to assign buttons):
kded(6449) KRemoteControlDaemon::ignoreButtonEvents: muting remote "devinput"
kded(6449) KRemoteControlDaemon::considerButtonEvents: unmuting remote "devinput

8. Start lirc, re-open config dialog, assign button to open amarok, save, close:
-> The remote is available and active, the wizard picks up button presses. One of the buttons is now configured to start amarok. 
kded4 output:
kded(6449) KRemoteControlDaemon::ignoreButtonEvents: muting remote "devinput"
kded(6449) KRemoteControlDaemon::considerButtonEvents: unmuting remote "devinput"
kded(6449) Remote::masterMode: Master mode not found
kded(6449) KRemoteControlDaemon::reloadConfiguration: starting notifier item
-> Tray icon does not flash, assigned action (start amarok) not working

9. Stopping lirc
-> Tray icon stays active

10. Starting lirc
-> No changes

11. Unloading kremotecontroldaemon from kded4
kded4 output:
kded(6449)/kded4 Kded::unloadModule: Unloading module "kremotecontroldaemon"
kded(6449) StatusNotifierWatcher::serviceUnregistered: Service  "org.kde.StatusNotifierItem-6852-1" unregistered

12. Loading kremotecontroldaemon for kded4
kded4 output:
kded(6449) Remote::masterMode: Master mode not found
kded(6449) KRemoteControlDaemon::KRemoteControlDaemon: starting notifier item
kded(6449) KRemoteControlDaemon::KRemoteControlDaemon: connecting to remote "devinput"
kded(6449): registerObject() successful for  "kremotecontroldaemon"
kded(6449)/kded4 Kded::loadModule: Successfully loaded module "kremotecontroldaemon"
kded(6449) StatusNotifierWatcher::RegisterStatusNotifierItem: Registering "org.kde.StatusNotifierItem-7064-1/StatusNotifierItem" to system tray
-> Buttons can be assigned in the control dialog
kded4 output (don't know if this is actually related, but it happened when I pressed some buttons):
Fetched layout groups from X server:    layouts: ("de")      variants: ("nodeadkeys") 
kded(6449) LayoutMemory::layoutMapChanged: Layout map change from external source: clearing layout memory
Fetched layout groups from X server:    layouts: ("de")      variants: ("nodeadkeys")

13. Restarting kded4
-> No buttons picked up in config dialog, tray icon not flashing, buttons not working
kded4 output:
kded(7197) LircClient::isConnected: theSocket QObject(0x0)
kded(7197) LircClient::connectToLirc: lircd >= 0.8.6 socket found...
kded(7197) LircClient::connectToLirc: updating remotes
kded(7197) LircClient::connectToLirc: waiting for lirc
kded(7197) LircClient::connectToLirc: reading...
kded(7197) LircClient::slotRead: "LIST"
kded(7197) LircClient::slotRead: ("devinput", "devinput")
kded(7197) LircClient::slotRead: "LIST devinput"
kded(7197) LircClient::slotRead: Remotes read!
kded(7197) Solid::Control::ManagerBasePrivate::loadBackend: Backend loaded:  "Lirc"
kded(7197) Remote::masterMode: Master mode not found
kded(7197) KRemoteControlDaemon::KRemoteControlDaemon: starting notifier item
kded(7197) LircRemoteControlManager::createRemoteControl: unknown interface: "devinput" creating it
kded(7197) KRemoteControlDaemon::KRemoteControlDaemon: connecting to remote "devinput"
kded(7197): registerObject() successful for  "kremotecontroldaemon"
kded(7197)/kded4 Kded::loadModule: Successfully loaded module "kremotecontroldaemon"

14. Rebooting, starting lirc
-> Tray icon stays inactive (red cross). Config dialog has remote active (i.e. not cursive), not picking up any buttons

15. Killing kded4, starting manually
kded4 output: see 13
-> Tray icon now active, not flashing, config dialog not picking up button presses

For me, only in very rare cases kremotecontrol works - sometimes config and actions, sometimes actions only. The config dialog works more often then actually performing the actions. 
I haven't found any pattern that would make the actions work reliably, nor one that would make the config work reliably.
YMMV, sometimes restarting lirc helps, sometimes restarting kded4 helps, closing and reopening config dialog never helps - it's not 100% reproducible, but it's not working correct about 95% of the time.

If you want me to try any other sequence, my VM is ready and waiting :-)

Cheers
Comment 13 Michael Zanetti 2011-04-02 23:30:00 UTC
Thanks a lot for this great testing. I have been able to reproduce this now and after some debugging I am a step closer:

It seems this is caused by the default lircd.conf for the devinput remote controls:
- The default lircd.conf for devinput contains all 446 possible buttons
- KremoteControl tries to read all those buttons from lircd directly after connecting
- After reading about 350 of those buttons lircd just closes the connection without telling any reason.

I still have no idea why this happens, but I noticed that if I throw out all unneeded buttons from the lircd.conf and leave just the 20 really used buttons in the file, the connection works again.

Please remove all unneeded buttons from your lircd.conf and let me know if this works around the issue for you too. I will try to figure out why exactly this happens.
Comment 14 Martin Riethmayer 2011-04-05 13:39:05 UTC
My lircd.conf even had an additional set of entries (although a comment right above stated that they were obsolete)
After removing all unneeded entries, kremotecontrol now again works like a charm across reboot and s2ram - thanks a lot for this info. 
If you can not figure out why lirc stops responding after some 300 entries, it could be an idea to suggest to the lirc package guys, that they should include one devinput-lircd.conf per remote, instead of one devinput-lircd.conf for all possible remotes. 

Thanks again!
Comment 15 Michael Zanetti 2011-04-06 00:21:50 UTC
This behaviour is reproducable using the default lircd.conf.devinput and executing:

irsend LIST devinput "" ""

This seems to be a lircd issue.
Comment 16 Michael Zanetti 2011-04-07 09:07:18 UTC
The issue in lircd is identified and will be fixed soon (next lirc release). Everyone having this issue please use the above mentioned workaround in the meantime.

For more information look here:
http://sourceforge.net/mailarchive/forum.php?thread_name=F8BBA0D1-689F-4DD0-B25A-C0B638D87412%40wilsonet.com&forum_name=lirc-list