foo_lirc plugin, LIRC compatibile remote control plugin! Options

[seanyseansean]

but I didn't bother recompiling foo_lirc as I figured noone was using it.

Ooooh wrong, I definitely use it with my ATI Remote.

Thanks for the update

[dano]

Thanks for recompiling Phi
But I have a problem with your 0.2 version:
When I use "Playback/Next" or "Playback/Previous" via my remote it will skip one track and go 2 tracks further instead of only one (happens about every second time).
This did not happen with version 0.1, or maybe it is a problem of my remote receiver, it is not working so good anymore

[Phi]

When I use "Playback/Next" or "Playback/Previous" via my remote it will skip one track and go 2 tracks further instead of only one (happens about every second time).
This did not happen with version 0.1, or maybe it is a problem of my remote receiver, it is not working so good anymore

Hi dano,

This is probably foo_lirc's fault. There is a repeat rate field that WinLirc sends to foo_lirc when you hold down a remote button, but at the moment version 0.2 is ignoring it, so you get the command executed once for each repeat. I guess this is what is happening in your case.

The problem is, since this is actually useful for certain commands (like volume or seek for instance), I can't just ignore repeated presses. Version 0.1 had only a few hardcoded commands, so levsh could specify which commands needed to allow repeats and which didn't. Now that I've added arbitrary commands it becomes a little more complicated.

I'm a little busy studying right now, but when I get time I'll work something out to fix it. I'm thinking a checkbox next to each command that you assign (along the lines of "allow repeats") would probably be the best solution.

Ooooh wrong, I definitely use it with my ATI Remote.

Thanks for the update

No Problem. I'm glad people are putting it to good use

[Phi]

The problem is, since this is actually useful for certain commands (like volume or seek for instance), I can't just ignore repeated presses.

Well, I guess I can until I have a better solution...

foo_lirc-no_repeat.zip

This version ignores repeats so it should fix your problems with skipping too many tracks if you can live without sane volume/seek control for a while

[dano]

That's great Phi, thanks for your extra effort.

[Phi]

foo_lirc 0.2.2

• allows an action to be tagged "repeatable" (holding down a remote button repeats the assigned command)
• fixes infinite loop bug when LIRC is closed unexpectedly

foo_lirc-0.2.2.zip
foo_lirc-0.2.2-src.zip

Let me know if anything isn't working right.

[Safrax]

Whenever Foobar 2000 starts up, foo_lirc doesnt automatically connect to the WinLIRC server. I must manually go into the preferences dialog and put a tick in enabled before it will start.

[Phi]

Whenever Foobar 2000 starts up, foo_lirc doesnt automatically connect to the WinLIRC server.  I must manually go into the preferences dialog and put a tick in enabled before it will start.

Thats what I get for maintaining a component that I don't actually use

I'll release a fix in the next few days or so.

[Phi]

foo_lirc 0.2.3

• now connects at start-up like it's supposed to

foo_lirc-0.2.3.zip
foo_lirc-0.2.3-src.zip

This post has been edited by Phi: Jun 29 2004, 14:03

[Linkin]

thanks...you're the best

[Phi]

thanks...you're the best 

No problem

[jay7]

ding-ding, bug report here!
Well, may be I'm the last man on Earth still using eons ancient W95OSR2, but foo_lirc has problems under this OS-alike.
First, if i close and restart WinLIRC while foo_lirc is enabled and then press 'Connect' - fb2k crashes badly, often with the pitiful w95
If i set `enable` off then on and press 'Connect' - it is ok.
As i can see, that's because of setting a hook in StartLircClient() when StopLircClient was not called and the hook is already hooked. The simplest solution I see is to keep a flag like HookSet and act accordingly not to try set hook twice.
That was simple. Now to the sad part:
The plugin does nothing in my case! It configures perfectly, seeing all commands from WinLIRC and highlighting assigned actions. But besides that it does nothing.
Spy++ shows those 'DEAD FEED' messages pass to fb2k main window.
It is something with those hooks too, I feel it but the only w32 compiler i have is LCC and it knows nothing 'bout C++ so I'm just sitting aside
BTW, is all this hooking The Only Right Way, or it can be done more straightly?
slight offtopic
The only reason I keep windows on that ancient box for - fb2k.
Digged the net many times, coudn't find nothing comparable to it.
But don't expect me to buy a new box with bloody XP inside just to control fb2k with remote.

This post has been edited by jay7: Aug 1 2004, 20:26

[Phi]

ding-ding, bug report here! 

OH NO!S!1 I'll have a look when I get a chance. Most of my "bugfixes" have just been hacks on existing code, so I'll take the time to rewrite it in the next few days.

BTW, is all this hooking The Only Right Way, or it can be done more straightly?

There are definitely better/easier ways to do it. Posting messages to the main foobar window is pretty dodgy.

PS. come on, at least upgrade to an OS thats still supported by MS

[jay7]

OH NO!S!1 I'll have a look when I get a chance.  Most of my "bugfixes" have just been hacks on existing code, so I'll take the time to rewrite it in the next few days.

Oh, I'm really sorry to bother you, but it's definitely unreal to run MSVC++ on my p1-166. There's no need to rewrite, just several fixes.

There are definitely better/easier ways to do it. Posting messages to the main foobar window is pretty dodgy.

Then let's take away all those hooks!
patch can be as following, although I can't check it

CODE

*** foo_lirc.cpp.old    Tue Jun 29 15:40:42 2004
--- foo_lirc.cpp    Tue Aug 03 23:55:22 2004
***************
*** 32,38 ****
 bool config_mode;
 HWND hConfigWindow;
 HWND hMainWindow;
- HHOOK lirc_hook;
 
 static HWND status_wnd;
 
--- 32,37 ----
***************
*** 129,135 ****
       }
       else
       {
!        SendMessage(hMainWindow, WM_REMOTE_KEY, 0xDEAD, 0xFEED);
       }
   }
     }
--- 128,134 ----
       }
       else
       {
!        g_actions.process_keypress(lirc.key_name);
       }
   }
     }
***************
*** 331,348 ****
 
 static cfg_action g_actions("Assigned actions");
 
- LRESULT CALLBACK LircHook(int nCode, WPARAM wp, LPARAM lp)
- {
-  PCWPSTRUCT msg;
-  msg = (PCWPSTRUCT)lp;
-
-  if (nCode == HC_ACTION && msg->message == WM_REMOTE_KEY &&
-      msg->wParam == 0xDEAD && msg->lParam == 0xFEED)
-  {
-      g_actions.process_keypress(lirc.key_name);
-  }
-  return CallNextHookEx(lirc_hook, nCode, wp, lp);
- }
 
 bool StartLircClient()
 {
--- 330,335 ----
***************
*** 355,366 ****
   return false;
     }
 
-  lirc_hook = SetWindowsHookEx(WH_CALLWNDPROC, LircHook, NULL, GetCurrentThreadId());
-  if(lirc_hook == NULL) {
-      MessageBox(hMainWindow, "Failed to set Hook", szAppName, MB_OK);
-      return false;
-  }
-
     lirc.thread_id = _beginthread(LircClient, 0, &lirc.socket);
     if(lirc.thread_id == -1) {
   MessageBox(NULL, "Failed to create thread, foo_lirc will be disabled.", szAppName, MB_OK);
--- 342,347 ----
***************
*** 371,377 ****
 
 void StopLircClient()
 {
-  UnhookWindowsHookEx(lirc_hook);
     lirc.client_running = false;
 }
 
--- 352,357 ----

[Phi]

OH NO!S!1 I'll have a look when I get a chance.  Most of my "bugfixes" have just been hacks on existing code, so I'll take the time to rewrite it in the next few days.

Oh, I'm really sorry to bother you, but it's definitely unreal to run MSVC++ on my p1-166. There's no need to rewrite, just several fixes.

It's no bother, I've actually already done most of the work.

Then let's take away all those hooks!

Well, the whole point of posting messages to the main window (and hooking it to intercept them) was to ensure that process_keypress() (and subsequently, menu_manager::run_command()) was called from the main thread. I'm not sure how mm::run_command() actually works, and whether its safe to call it from the socket thread as you have done here.

Anyway, I've rewritten the code to use an asynchronous socket so this won't be an issue in the next release.

[Phi]

Anyway, I've rewritten the code to use an asynchronous socket so this won't be an issue in the next release.

foo_lirc 0.3

• big rewrite, should fix bugs mentioned earlier

foo_lirc-0.3.zip
foo_lirc-0.3-src.zip

[Linkin]

thx Phi

I appreciate your work

[Phi]

thx Phi

I appreciate your work

No problem

foo_lirc 0.3.1

• added support for "context/now playing" commands
• minor ui improvements

foo_lirc-0.3.1.zip
foo_lirc-0.3.1-src.zip

[jay7]

Hooray, it works!
grabbed 0.3.1 and now I'm totally satisfied!
skipped 0.3 because of weekend, just didn't give it a try
Hooray to Phi!
Thanks, really.

[SBeaver]

How do I set a button to scroll around in the playlist as if I had pressed up/down arrow?

edit: now have the cursor keys of my remote tied to previous/next playlist for right/left and works great. I'll try another program to bind the remote buttons up/down to cursor keys and see if that works better

This post has been edited by SBeaver: Aug 22 2004, 16:04

[Phi]

Yeah, unfortunately there are no standard commands available in foobar to scroll the playlist up and down.

[Betse]

I know this is a bump from nowhere, but i really like this plugin.
Greatly appreciated here!
Keep up the good work

[Spi]

wow, i didn't know of foo_lirc > 0.2 ;(
i only checked the sourceforge site.

but now im in need of a version for 0.9

This post has been edited by Spi: Mar 20 2006, 22:54

[Betse]

I've got to support you on that one Foobar just isn't complete without it

[cirrus]

Yeah. I really cant live w/o my remote. Anyone know how to fix it / know if there is any new version out?