View Single Post
Copernicus's Avatar
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#882
Originally Posted by raily View Post
Just an idea, why not implement a in-app update for keyset? this came into my mind while checking the changelog of 1.1.18
Yes, I really should do that. It'd be a little painful to do so, though. The original reason I created Pierogi, way way back when, was that I was pretty well disgusted with the way that the available remote control apps worked; either they were hard-coded to support a single device, or they only allowed you to use a config file for one device at a time. The idea of having to download individual config files kind of turned me off; each config file is tiny, you should be able to store them all locally. I also knew that many manufacturers reuse their command sets over time (and often just copy the command sets of other manufacturers wholesale), so you could potentially save some space by not storing lots of config files containing the same data.

So, I went ahead and started building my own database of keysets. I started off by grabbing config files from the Linux Infrared Remote Control project, which has a massive collection and is the main resource for all things IR in the Linux world. Unfortunately, the file format they use, while flexible, is very poorly suited to my needs; you can either store the raw timing value for each on-off pulse of the IR, or use an extremely rudimentary format to store individual bit values. There's almost no built-in support for the "protocols" that each manufacturer uses, and I wanted to leverage those protocols to save space and make my life easier.

So, I started creating my own internal format. I am, in fact, still playing around with that format; I'm learning about the low-level details of IR programming as I go.

It wouldn't be impossible to create files that match my internal format. I could certainly follow the lead of the hifi-remotes.com website; those guys create config files for "JP1" universal remotes, and their file formats are much closer to what I would want, although they've got a lot of extra material dealing with JP1 assembler programming and EFC codes that are entirely unnecessary for me. But it'd probably take a bit of time to expose my protocol formats in such a way as to make them usable by others. (And converting from LIRC or other config formats to what I'm using wouldn't necessarily be trivial, either...)

Anyway, I've been thinking about it, but I'm not quite there yet.
 

The Following 4 Users Say Thank You to Copernicus For This Useful Post: