vdr-sxfe --lirc from Unity launcher causes remote control keypresses to be detected twice or ignored

Bug #1001818 reported by TEN
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux-lts-xenial (Ubuntu)
New
Undecided
Unassigned
vdr-plugin-xineliboutput (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

xineliboutput-sxfe 1.0.7+cvs20111211.1625-1 is started from the Unity Launcher with a parameter of --lirc apparently by default.
However, VDR is already reading the same LIRC device/events as well.

The resulting perceived duplication of remote control keypresses causes some buttons to stop working entirely (e.g. Menu), whereas the arrow keys skip every other menu item/channel: http://www.vdr-portal.de/index.php?page=Thread&postID=1072906#post1072906

This is likely to cause widespread painstaking futile attempts to tweak LIRC configurations (already of considerable complexity anyway, cf. http://www.yavdr.org/documentation/de/EventlircdOrganigrammconfigfiles.png) even though LIRC and VDR themselves actually work fine according to irw and mode2, as well as when starting vdr-sxfe without --lirc from a console window (too well hidden as Ctrl-Alt-T).

Without a straightforward way to change the Unity Launcher settings (which are also missing a meaningful icon for vdr-sxfe in the default unconnected state, showing just "?" and a mouse-over text of "VDR X-Frontend"), there is no easy workaround for users to remove the --lirc parameter from the button for xineliboutput-sxfe 1.0.7+cvs20111211.1625-1 in Ubuntu 12.04 LTS :
http://askubuntu.com/questions/29553/how-can-i-configure-unity#101415

Tags: precise trusty
Revision history for this message
TEN (launchpad-20-ten) wrote :

Changes in /usr/share/applications/vdr-sxfe.desktop are ignored; they actually have to be made by
sudo nano -w /usr/share/app-install/desktop/xineliboutput-sxfe:vdr-sxfe.desktop
(cf. http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/p1072963-doppelte-tastenerkennung-im-vdr/#post1072963)
as the following lines are wrong (first one unless VDR itself is running on another machine; second always):
Exec=vdr-sxfe --lirc
Icon=_usr_share_icons_xineliboutput-sxfe

These should be:
Exec=vdr-sxfe
Icon=/usr/share/icons/xineliboutput-sxfe.svg

Removing --lirc takes effect immediately to make the remote control work properly again,
the icon change is seen after the next reboot (please feel free to add instructions on how to make the Unity Launcher re-read a specific .desktop file at runtime).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vdr-plugin-xineliboutput (Ubuntu):
status: New → Confirmed
Revision history for this message
TEN (launchpad-20-ten) wrote :

In 14.04 LTS, the bug is back to /usr/share/applications/vdr-sxfe.desktop, and Undecided, Unassigned as ever.

TEN (launchpad-20-ten)
tags: added: trusty
Revision history for this message
TEN (launchpad-20-ten) wrote :

Ubuntu 16.04.2 LTS still has a conflicting
Exec=vdr-sxfe --lirc
line in
/usr/share/app-install/desktop/xineliboutput-sxfe:vdr-sxfe.desktop
in spite of
--lirc
in
/etc/vdr/conf.d/00-vdr.conf
as well.

Revision history for this message
TEN (launchpad-20-ten) wrote :

...and removing this line from /usr/share/app-install/desktop/xineliboutput-sxfe:vdr-sxfe.desktop has no effect this time around, even after reboot.

BTW /usr/share/app-install/desktop/xineliboutput-fbfe:vdr-fbfe.desktop has it too.

Revision history for this message
TEN (launchpad-20-ten) wrote :

Ubuntu 16.04.2 LTS seems to be back to looking at ye olde /usr/share/applications/vdr-sxfe.desktop which has the same spurious --lirc parameter in addition to VDR's own.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.