Notices

Cool! (Was this the same Daewoo that I just never could find a keyset for? Might have been a bug in one of the existing keysets that eventually got fixed...)

Yes, I think this would be very doable, with the caveat that I really haven't stopped messing around with the keyset structures yet. So, for example, what was Philips TV Keyset 1b in version 1.0 might end up being split into Philips TV Keysets 1b and 1c in version 1.1, or possibly even get merged back into keyset 1. I'm still trying to reorganize the keysets as efficiently as possible under the hood, so it's hard to perfectly maintain keyset labels across releases.

Still, that's no excuse not to have keyset labels, just a warning that what you labeled last week might not exist next week. Let me see how much work it would take to add it in...

for some reason I have to be very close to the box for it to work with the current version. It used to work at a further distance. I am using the motorolla stb settings

Interesting! Is this only with the Motorola set top box, or is this a problem with all devices? There's been a similar on-going problem with Sony TVs; I'm almost certain it has to be a problem with the IR protocol I'm using (as normal universal remotes work just fine with Sony TVs, so far as I know), but I haven't been able to pin down exactly what is going on.

Can you tell me the model name of the set top box? Thanks!

it's tv keyset 5 that works

Ah, that one is using a protocol called "Proton" (and so far is the only keyset I've found using it. ) I'm not even sure where I found that info. Actually, Proton is a fairly nice little protocol -- it's a very stripped-down version of the ever-popular NEC protocol, and as such was pretty easy to implement...

Hey nice to see you back again.

Other than the recently reported "/dev/lirc0" issue posted by DAZYD2F there has been no reported issues here.

I have had no issues with the latest Devel version.

I have been keeping on top of the request wiki, you will probably notice it's increased in size a fair bit.

Will be nice to see updates for Pierogi again

Sorry it's taken so long for me to get back to Pierogi work! I've checked into the Strong satellite receivers, and I've found half a dozen different keyset config files, no two of which match each other. I'll throw a few of these in, but I'm not going to make any guarantees that any of them will work...

I realize this message is several months old, but let me answer it anyway:

I'll take a look around; I should be able to find something for it. Toshiba products are fairly well represented in the various universal remote sites.

Actually, I've decided not to retrieve any keyset data from the Psiloc irRemote website. I'm not entirely certain what their exact policy is on the use of config files downloaded from their site, but they certainly don't seem to be interested in free and open source software. (Even though, if you look at the format used by their config files, it's pretty obvious that it's been ripped straight out of the LIRC project. I'll bet they're even running the LIRC server inside their program...)

In any case, I suspect most of the available keyset data out there has already made its way into either the public LIRC project, or into the massive database of JP1 config files at the www.hifi-remote.com website. I doubt I'm missing much by excluding the Psiloc data.

(However, let me note that the QtIrreco project is itself built on top of the LIRC server, so Psiloc config files could be used with that project with only minimal reformatting, if you'd like to give it a try.)

This is, unfortunately, a bit of a problem. I really only started the Pierogi project for my own personal use, to let me play around with keyset data and try to merge commands for many different products into a smaller number of super-keysets. As such, I've not really bothered trying to create a user-friendly keyset management scheme; I've really just been hard-coding all the data directly into my source files. This does have the beneficial effect of allowing a lot of keyset data to be stored in a very small amount of space (which is, indeed, very good for a mobile machine; I'd love to see how much space the Psiloc program would take up if they tried to load every single one of their config files at the same time). But yeah, it doesn't make adding new keyset data easy for anybody who hasn't had their nose deep in the code for a while.

Honestly, I have to say I probably won't be changing this any time soon; I'm still having too much fun messing around with keyset data and trying to merge similar command sets together. Pierogi really is a different kind of beast than QtIrreco, irRemote, or any of the other LIRC-inspired (or -derived) IR programs; where they have focussed on flexibility, I'm concentrating more on size and efficiency. Anway, that's my excuse.

Many remote controls do overload the arrow keys with the channel and volume controls; where this is the case, Pierogi does indeed support using both the channel/volume controls for cursor movement and the arrow keys for channel/volume control. Otherwise, though, I'll prefer to keep them separate; even if we're talking about a device that, say, has channel controls but doesn't support arrow keys, I'd prefer to avoid repurposing the Pierogi arrows for channel control. For now, I'd like to have the Pierogi keys match the original remote keys as closely as possible...