jason

Sorry for the delay. I've updated the config for you. I will soon have something to do this for you. Thanks so much. flirc_config_fixed.fcfg

I'll have a fix for that soon. For now, send your configuration to me, I'll see if I can find it.

No problem Brian thanks for the positive feedback. I will have the ability to issue a suspend command with the next release of firmware. I will add media keys, pause/mute/volume up/volume down/eject/suspend etc. I have a handful on my plate, but I would say I'll have a release in the next few weeks. I have most of it done.

More info as just a heads up, this was because of the harmony profile and a bug on the 2.0. It should properly let you know that these keys are reserved for harmony and can't be removed. You can now dynamically map over them, and you can disable the profile all together in the GUI. Here is where the bulk of the conversation is taking place:

Sorry for the delay, update to the latest GUI, and then to fw 2.1. There is now a box in the advanced menu which allows you to disable built in profiles. That should fix it. Let me know.

I do plan on adding additional keyboards. It's in the pipe.

Great to know, thank you so much for following up.

Which operating system are you using? I'll get it sorted out.

Thanks so much for posting about that. I just posted an update, v1.1.4 should fix that, it's now built statically with all the libraries. So sorry about that. Thanks Ere.

Alright, I posted an update. I had a bug, where if you tried to delete a harmony button, which can't be done, it would actually corrupt your configuration. If you have ever done this, you should do a clear configuration and start over again. I'm really sorry about that. When I started digging into the code, I noticed that issue. Here is how it works, and it's a bit half baked, not completely what I want. I want to catch the use case for when a user gets a harmony remote, they load the flirc proflie on their harmony, and everything works out of the box with flirc and no additional software is required. In other words, the harmony-xbmc profile is and will be enabled by default. If you want to re-purpose one of the flirc harmony-xbmc keys, you can. That key will take precedence over what's currently in read only memory. You can delete the newly mapped key, and functionality will restore to the default key. If you try to delete the default, the gui will report that the key must have already been deleted, it's not found. (this is not ideal, I need a proper error code but didn't have time, I needed to get this release out because of the bug). You can disable the harmony profile entirely in the advanced menu. I've created an option for that as well as added an appropriate commandline setting. The flirc_util in the mac GUI is now statically built, so you wont get a missing libusb-1.0 library anymore. I really think you did a good job explaining this. I will try to polish the next release so that 1-4 are implemented to your description. As far as your desire for another profile. Yes, I promise that I will try and get a plex, wmc, and eyetv profile for the harmony in as soon as I can.

I've been missing your messages. Could you follow up with me: http://flirc.tv/contact/ I'll get this sorted out.

What an awesome post. Thank you so much. I have a friend that helps every once in a while, but it's really just me. Means a lot. Especially when people take the time to write in, it makes all the hard work worth it.

Thanks so much for the positive feedback, yes, you are exactly right. I will definitely figure out how to implement this, it is possible. Happy and healthy new years to you as well.

We'll get it sorted out, it's not bricked. It's just a driver problem. The beta's have been pulled for various reasons, the latest release is the result of all the beta testing. Let's try these: https://flirc.zendesk.com/hc/en-us/articles/200712548-Using-the-ZADIG-Utility Install the libusbk device for the bootloader. Then launch the most recent version of the GUI, it will fix itself.

If you could describe what happened, and what's going on, I'll get it fixed. But let's not insult me, this is just me, I work really hard, and take it to heart when it doesn't work as expected. No need to throw salt in the wound.

long presses can mean two things: Originally, when you held a button down on an apple remote, it wouldn't do anything. I now support this and commonly referred to this as long key presses, let's name this detecting button holds. Firmware 2.0 has this. Then there is this which will eventually make it to the firmware: https://flirc.zendesk.com/hc/en-us/articles/200837116-Long-Key-Presses

So sorry guys, I've been working so hard on updates and bug fixes. I finally got this one. v1.1.3 is fixed. Backwards compatible from 10.5 and up. Booya

Okay, cool. I think I'm going to start moving forward with option 2 today. I still had a number of bugs I needed to squash, all on the windows side. I hate windows so much. It's absolutely amazing how much more of my time is waisted looking at windows problems. Sorry...venting. I just pushed an updated version: v1.1.2. I did a fast forward on the version mainly because the GUI and the commandline versions were out of sync. It no longer made sense since they are both built together, use shared libraries, and should be deployed together. Now, I'll know immediately if someone is on an old version. I did follow your advice and I am deploying the flirc_util app in the Flirc.app/Resources directory. That was a great idea. I'll try and see if I can come up with an option in the GUI to automatically install that to the users path. I'll embed the next version in the GUI as soon as I'm done with it. Thanks so much for being patient, the support, help, and feedback. Means a lot.

Thanks for posting your findings. There is another thread on the same topic here: I will fix this shortly so at least the user understands what's going on. There is description of what will be done in that thread. Thanks again!

Hi Rob - I saw your email, it's just me here. Anywhere you send it would get to me. I figure I would first respond here in case other people wanted to chime in before I sent you an image to try. I unfortunately can't have some keys pre-configured and then allow them to be changed. They are hard coded into the version of firmware and my firmware isn't allowed to reprogram it's own flash. A firmware update could changed the saved mappings, but you wouldn't be able to do it dynamically. I save dynamically mapped keys in a read/writeable section of the processor, however, there isn't enough space to keep the harmony there. That's the ~160 key limit. This all started because I wanted to get the use case for for people that want the easiest support possible. Buy a flirc, select the harmony profile, and bam, everything works with XBMC. You don't need to download any software from me. So I'm conflicted about what to do.... Do I disable harmony by default and have the user enable it, or leave it as is hoping the majority users want out of the box support for harmony-xbmc? Here are my options, please weigh in... Option 1: Allow people to re-record harmony profile buttons to the dynamic section. That section will be searched first, if found, that will take precedence over the pre-saved button. Option 2 Leave it as is, and have a disable feature to allow you to re-asign these keys. No pre-recorded keys would be there, you would have to map them all to your liking. As soon as possible, I also need a proper error code. Something along the lines: "Error: Key is reserved for the harmony-xbmc profile, can't re-map" I could then have another message telling the user they can disable the harmony profile. Even though Option 1 is more obvious, it's much less intuitive for people who have no idea what's going on. For example: Option 1, they install the flirc harmony profile, record keys, don't understand that these keys are already on the device. They delete the key, BUT that key is still mapped to the original key when they hit the button again. This then leads them back to this forum posting saying that they can't delete keys. I get a ton of emails, pull my hair out, change the way it works, and then piss everyone else off. I'm leaning towards Option 2 because of this. It's tough, I have to play out these scenarios in my head and sometimes I can't always think of them. That's why I get into situations like this and sometimes, on occasion, I'm stuck with a decision I made 3 years ago during the product's inception. Here is another, if I include flirc_util in the mac dmg file, that's certainly fine, however, when the app opens up it checks for updates. It uses the sparkle framework (every app on the mac uses it, even the ones still in the app store) But if the flirc_util lives in the dmg, than the commandline app wont get updated when the GUI self-updates. That would be horrible for reasons I mentioned above. Anyways, let me know what you think. I can whip that up, push it out later today. -- Jason

Okay, I think I know what's wrong. I have a bunch of keys pre-saved on the device which are for the harmony profile. Are you guys using a harmony remote? These can not be unmapped. When it complains about no space left on the device, I need more info regarding that, but let's do one thing at a time. Not sure where to stick the commandline app for the mac, I'll figure out how to do that. Rob, if you could email me, I'll send you an experimental firmware image that disables the harmony profile to see if that does the trick.

Guys, thank you so much for posting, and I'm so sorry for my absence. It's just me, and I had some extremely huge issues with the last GUI released. Not enough people gave me feedback on the release candidates and after releasing to the masses, I had a ton of issues. I've been staying up all night every night for an entire month trying to fix it. It was a disaster, the GUI would brick devices on a good percentage of machines/and operating systems. I finally reproduced all the issues, and just released v1.0.7. I'm so relieved, but at the same time, had been seeing these threads. I promise I'm going to fix it, you don't have bad units, I again didn't receive enough feedback so there are probably issues that I missed. I have to test multiple versions of firmware, multiple versions of operating systems, multiple architectures of the same operating system (32 bit vs 64 bit), etc. With the release of windows 8.1, that made it ever more challenging. Again, it's just me doing this alone, but the more help you give me, the faster I can fix it. Now that the GUI is in a good spot, I'm dedicating my full attention to this. Rob, thank you so much for posting that, that was extremely helpful. Okay, let's all do the following so we are on the same page. Only use my latest release, that includes the commandline version. Don't use a commandline from the beta release, it may not be compatible with the new firmware. I don't have a commandline available yet for the mac published, I will do that. So: First update to Flirc-v1.0.7 Do not use a legacy version of the GUI or commadline with version 2.0 of the firmware, it wont work. That would explain most of this crap you are seeing. I should just pull them all. Try programming with the GUI. Let me know if you see the same results. If you have the commandline from the release package, you can use that too. Try that, let me know if that works. If it doesn't work, tell me this: Operating system: 64 bit, 32 bit Remote control (if you are using a universal, what profile). As a user pointed out on this forum, flirc is sensitive. Don't hold your remote in front of the device when pairing. I hold mine up at the ceiling. If you do, that can cause problems too. I'm watching this thread all day.

I will address this over my break, don't worry.

Can you record some stuff, then when it forgets, record it again, and upload your config. Can you also try another remote. I'll give this more attention as soon as I squash these rather severe bugs in the GUI.

Windows 8.1 isn't supported at the moment. I still have to get my own copy. I'll add notice to the downloads sections. K2man. If the keys are not working but they say already recorded in the GUI, close the GUI. It shouldn't be opened in normal use. If that doesn't work, close it, restart, unplug/plug the device.