jason

Okay, I'm still not seeing this. Could be a problem with the fact that I'm doing this in a VM. I'll post new drivers this weekend. Thanks so much guys. Sincerely, Jason

Sorry guys, I wasn't getting updated of thread events. In windows 8, go into device manager. Right click flirc, and update driver. You need to say have disk, and point to the files I attached. So sorry for the confusion, the attached isn't an executable. Did you guys who received an error try the same method? Let me know. I'll try and get to the bottom of this. Yes, I'll update the installer once I can confirm it works for people other than myself.

I'm trying to incorporate the updated drivers in the installer, but for now, try the following. Windows Signed Drivers I'd appreciate some feedback before sending this to the wild. These are much updated in many respects. Thanks everyone.

@burke, thanks for the reply, makes sense, BaggaDonuts, let us know if that helped.

You are absolutely justified, and it's easily perceived as though I've neglected the project. I promise it's not the case. I'm working so hard behind the scenes so that I don't waste time on repetitive tasks, that it's taken time away from being able to keep up with development. But I'm pretty much done with that. I do this alone, and on the side of a full time job. But, every second of free time I have goes into this project because I absolutely love it and the supportive customers. I wish so much that I can do this full time, it's truly my passion, but I wouldn't be able to support my family. This is not an excuse, but just an explanation. Not only will I address the windows 8 issue immediately, but expect more frequent updates as I'm pretty much knee's deep in development again. A special thanks to Chris for always notifying me of forum updates, which I sometimes miss. Again, I will post an update on this thread as soon as I figure out how to get a signed driver in my app. Expect firmware issues to be resolved, better documentation, and more features. My sincerest apologies for the lack off communication, I'm going to make a commitment to update my blog once a week.

I'll take a look next weekend when I return. Thanks Selym.

Just a tip, after you've recorded a signal, open up a text editor and try out the key with your remote to see if the record has worked.

I see the problem, you definitely have spurious signals recorded. You have 5 signals paired with Backspace You also have two signals paired with 'i' I deleted all instances of those, please record backspace and 'i' again. Remember, if the GUI says successfully recorded and you don't feel like you've recorded the key, hit the 'delete' button and wait for that same signal to be deleted. I'm going to fix this in the next firmware release. Find the modified config attached. Let me know how it goes. MJMC_modified_config.bin

If you haven't already re-recorded your commands, could you upload your config?

Please let us know how it goes. I'm going to try and figure out how to prevent this, I have a few ideas..

Since there is standard yet for RF, but as soon as there is, you'll see that version of flirc.

For those interested in this topic, we solved this together outside of the forums. The problem was in the harmony one software. We had to decrease the number of repeats. "Device > Troubleshoot > 'Device responds to some commands either too many times or only occasionally'" http://www.remotecentral.com/cgi-bin/mboard/rc-harmony/thread.cgi?7814

I'm really sorry, I was in Los Angeles all week, my grandmother passed away. = ( Yes, let's get you up and running. Why don't you ping me on gchat, we'll get this resolved much quicker.

I'm so sorry for the delay, I'm going to try your remote this weekend. I'll get back to you when I do.

Thank you Chris for responding while I've been out of town. Yes, I agree, from the above post you mentioned you only thought you had to close the GUI and re-open it. Did you unplug and re-plug in the flirc. No need to close the GUI. Here is how it actually works. The sensitivity changes my algorithm to make things a bit more 'sensitive'. This actually gets stored as a configuration bit, so if you were to save your configuration from the GUI, this 'sensitivity' would be embedded in the GUI. Configuration values only get 'loaded' when you turn on the device. I should have also changed the firmware to load new values when they change, although easy, I have to many firmware images floating around to create another one. For each sensitivity, you need to record new button presses. The algorithm changes the capturing of remote signals, so they may not match the ones already saved on the device, which is why you have to re-record. However, having said that, you don't really have to format. Your previous sensitivity values are still saved, and 'shouldn't conflict with the new ones. It's good practice to start clean again, but you can switch back and forth once saved only having to unplug and plug. Also, what remote are you using? Can you post your configuration at each sensitivity? Please format in-between as I wont be able to distinguish which saved button was at which sensitivity.

I think during the recording process ghost keys were recorded. Fire up the GUI and hit delete. Be patient and let the phantom signal show up and it will be deleted from memory. Keep doing that until phantom signals go away. Let us know if that does the trick.

thank you chris, drift, let us know if that helps.

And there is of course the amazing community, I'm humbled every day by everyone's help, and participation.

You'll need the latest release of the media_center keys beta firmware. I just uploaded a long overdue version that should fix the last issue which crashed in windows.

@Videonisse - Are you referring to the Media Keys, play/pause/next chapter that work out of the box with programs like iTunes?

Have you tried clearing your configuration and starting fresh?

Another suggestion would just try changing the profile of the universal remote. Instead of XBMC, try Pioneer or another one. Thanks, let us know how it goes.

Unfortunately, no. I may figure out a way to store the uncompressed versions somewhere, but think of my method right now as a one way compression. It wasn't done to protect anything, just merely a way to get the data and store it on the device's 'eeprom' which you are actually dumping when you save and load your configuration. I will have something to make that file human readable in a future release.

Hey Mick - Got your mail and will reply shortly. Yes, postage kills me. In order for me to do anything cheaper, it requires a lot of filling out forms by hand, which I can't do. I already spend the majority of my free time filling orders, I literally have zero time for development right now. The beauty of the postage box I chose, is what you mentioned, I can stick about 10 in there and the cost stays exactly the same whereas another method will rise with weight. All this being said, I have found another option which is first class, it will be $3-5. I couldn't explore this previously because of all the work I had to do by hand, however, I found a module for the e-commerce store I use (lemonstand), called shipstation. They support batch printing first class labels, I expect to have this on the store within a couple weeks. However, shipping times will probably be 8 weeks and it's not ideal. As you mentioned in your mail, distribution will be the best method for customers. Thanks for posting this.

Hey Amnesiac - I actually don't use the traditional method, so unfortunately any database we build in the flirc community wont be consistent with anyone else's. That's not because I wanted to be proprietary, and a jerk, it's because I came up with a way to ignore protocols and compress the long datastream. Which is also why you can store buttons on the device, and it doesn't require a large memory chip. Does that make sense?