jason

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.

The battery could be dying, it's really sensitive to changes in timing. Which remote are you using? Has that at all changed? Do you experience the problem with any other remote?

Thanks for the heads up. I will compile a 64 bit version and post that tonight.

apt-get install ia32-libs

I'll take a look, let me see if I can reproduce this.

Can you format the device and post the configuration? It's possible. Don't worry. I'd get you a new one.

Which version of the firmware are you using? It could be your remote losing battery life. Flirc is so timing sensitive, as the signals drift over time, that would trigger re-learning. Save the configuration in a known working state, then when it breaks, save it again and post both files. What's your firmware version?

Okay, how about just doing the following in the terminal: /Applications/Flirc.app/Contents/MacOS/Flirc I'm still trying to get the previous versions...

I'm going to get 10.7 and 10.6. Seems to be fine on 10.8. I'll get to the bottom of this after I reproduce it. Could I trouble you to launch the app through the terminal: ./Flirc.app/Contents/MacOS/Flirc This will spit out a bunch of logging information. Thanks so much for all the help Loop.

I released an update, could you guys let me know if that worked? Until I get a machine running the previous OSX, I can't know for certain, but I had a mistake that was fairly obvious and I'm nearly certain this will fix it. Please let me know.

As soon as I get all these v1.0.0 bug fixes out, I will return to firmware. I'll have a blog post on the newer features that will be implemented.

Okay, next release has been posted, v1.0.2 This will auto-update your device to the correct image. ** EDIT ** It will only auto-update should it see that you are on one of the latest release candidates.

Thanks so much for the acknowledgment, a bit exhausted, so it means a lot. posting here as well as your original thread, anyone on the release candidate versions will automatically get updated to the correct version with the v1.0.2 release.

I had a bug in my v1.0.0 GUI on certain devices, can you guys try the latest release: Direct link: Flirc Setup.exe [ v1.0.1 ] Please let me know if that fixes it, I haven't gotten any feedback.

The windows 1.0.0 release has been publish, try that and let me know.

Hey, you caught me in the middle of trying to post an update, could I trouble you to try again?

I've fixed this but I haven't finished my packaging scripts. Just follow up with me at support@flirc.tv and I will send you a binary to fix this. I published the mac version, and will follow up with the windows and linux versions shortly.

I've released a 1.0.0 version of the mac, I'm trying to get the windows and linux versions out.

Thanks so much!