Jump to content
Flirc Forums
doug

"Button already recorded", "No more space for new buttons", incorrect keys mapped

Recommended Posts

I'm seeing the same thing with the flirc that I received today (my first, and probably only at this point).  As far as I can tell, the internal memory eventually fills up and there's no way to clear it or erase the keys.  There's the menu item that's supposed to clear the configuration and the "erase" button to clear individual keys, but I'm now stuck in a spot where it thinks that all keys have been erased but I can't add any more.  This is with the 1.0.0rc6 firmware and v255.14 software on a Mac.  It seems like we're over a couple of months into this issue with no substantive fix or recent feedback.  What's the next step?

 

For what it's worth, I'm programming the flirc on my Macbook Pro (no hub).

Share this post


Link to post
Share on other sites

I am on RC 6 and I am having the same issue. Clear Configuration doesn't do anything. When I try to reprogram keys, it says Button Already Exists. I have also formatted via command line. This renders Flirc completely useless and I barely got it 2 days ago.

Share this post


Link to post
Share on other sites

Yes, I'm using RC6.  First oddity:

 

When I launch RC6, it "updates" the firmware to 255.14, and "flirc_util version" reports the following:

 

rcoleman-mi7-wifi:~ rcoleman$ flirc_util version

Flirc Version 1.0.7 [v1.0.0-rc.6]

   255.14 07-14-2013 [0xEA05E8B1]

 

Is that really the latest?

 

Second oddity:

 

I managed to format the device using flirc_util (a useful utility, it appears) and there are no keys stored in the Flirc (flirc_util keys).  Still, when I try to learn a button, I get "Button already exists" every time.  The following shouldn't happen, right?

 

rcoleman-mi7-wifi:~ rcoleman$ flirc_util keys

No Keys Found

rcoleman-mi7-wifi:~ rcoleman$ flirc_util record 1

 Press any button on the remote to link it with '1'

 

[E] fl_ver2_set_interrupt(571): Error: button alrdy exists

rcoleman-mi7-wifi:~ rcoleman$ flirc_util keys

No Keys Found

rcoleman-mi7-wifi:~ rcoleman$ 

 

If I press the "1" key on the remote, it does indeed produce a "1" on my terminal via the Flirc adapter.  It seems like there's a disconnect between the "learning" part of the adapter and what the firmware thinks is really in there.

Share this post


Link to post
Share on other sites

I'm still seeing exactly this issue, even with the release 1.05 OS X GUI and updated "v2.0" firmware.  My dongle is basically stuck with whatever keys I originally programmed and nothing I've done seems to properly erase keys or clear the configuration.  Do I need replacement dongle?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Just received flirc

Having similar problems

With kubuntu  - 0.95 never showed "connected"

With win7 - 0.96 never showed "connected"

With XP - 0.96 never showed "connected"

With XP - c1.05 eventually got "connected"

May be concidence but just after much wiggling USB connector - device coming and going in devices list....

Then first key train worked, 2nd etc failed "button already exists"

Cleared all function had not beneficial effect

Upgraded firmware to 2.0

Still would not proceed past first train attempt.

Did 2 things that made a change:

Changed value in advanced drop down from 6 -> 1 (I think from memory)

Started pointing remote so that line of site not available (pc under table, remote above table pointing well away)

Then process seemed to work - xmbc config, remote Humax foxsat HDR with DVD selected

All seemed to go ok - but result Fliirc does not work with RPI -> OpenElec -> Xbmc

Allready spent long long time. Not looking good.....

Share this post


Link to post
Share on other sites

I have just recieved my Flirc, and is also experiencing this problem, constantly getting "button already exists", even if i am not pressing any keys on the remote. Does not seem to clear, have upgraded to firmware 2.0 in Flirc v1.0.5.

 

It is basycally useless when i can't program it, did i recieve a faulty unit?

Share this post


Link to post
Share on other sites

Just received flirc

Having similar problems

With kubuntu  - 0.95 never showed "connected"

With win7 - 0.96 never showed "connected"

With XP - 0.96 never showed "connected"

With XP - c1.05 eventually got "connected"

May be concidence but just after much wiggling USB connector - device coming and going in devices list....

Then first key train worked, 2nd etc failed "button already exists"

Cleared all function had not beneficial effect

Upgraded firmware to 2.0

Still would not proceed past first train attempt.

Did 2 things that made a change:

Changed value in advanced drop down from 6 -> 1 (I think from memory)

Started pointing remote so that line of site not available (pc under table, remote above table pointing well away)

Then process seemed to work - xmbc config, remote Humax foxsat HDR with DVD selected

All seemed to go ok - but result Fliirc does not work with RPI -> OpenElec -> Xbmc

Allready spent long long time. Not looking good.....

Silence, No feedback or reply or solution provided.

Regret that I will therefore have to return the product.

Pity, because if it worked, it is just what I want.

Share this post


Link to post
Share on other sites

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

 

Sorry for the delay - I didn't get an email when you replied.  I was using a flirc_util version from the beta release and I don't see one in the latest 1.0 release.  Can I assume that the older flirc_util will work properly with the new firmware?

 

Rob

Share this post


Link to post
Share on other sites

Sorry for the delay - I didn't get an email when you replied.  I was using a flirc_util version from the beta release and I don't see one in the latest 1.0 release.  Can I assume that the older flirc_util will work properly with the new firmware?

 

Rob

 

Jason, here you go:

 

rcoleman-mbp-enet:osx rcoleman$ flirc_util settings

Settings:

  sleep detection: Disabled

  noise canceler:  Disabled

  inter-key delay: 6

  keys recorded:   0

  keys remaining:  169

  memory used:     0%

No Keys Found

rcoleman-mbp-enet:osx rcoleman$ flirc_util format

Formatting Device, please wait...  Done!

rcoleman-mbp-enet:osx rcoleman$ flirc_util settings

Settings:

  sleep detection: Disabled

  noise canceler:  Disabled

  inter-key delay: 6

  keys recorded:   0

  keys remaining:  169

  memory used:     0%

No Keys Found

rcoleman-mbp-enet:osx rcoleman$ flirc_util record 1

 Press any button on the remote to link it with '1'

 

[E] fl_ver2_set_interrupt(571): Error: button already exists

rcoleman-mbp-enet:osx rcoleman$ 1

 

Note that the "1" on the last line is the flirc entering a "1" when I hit the appropriate button on the remote.

 

Here's another good one where I delete the code associated with "1" and then attempt to re-record it:

 

rcoleman-mbp-enet:osx rcoleman$ flirc_util delete

 The Next button pressed will be deleted, please press a button

 

  Button Deleted Successfully

 

rcoleman-mbp-enet:osx rcoleman$ flirc_util record 1

 Press any button on the remote to link it with '1'

 

[E] fl_ver2_set_interrupt(568): Error: no space left on device

rcoleman-mbp-enet:osx rcoleman$ flirc_util record 1

 Press any button on the remote to link it with '1'

 

[E] fl_ver2_set_interrupt(568): Error: no space left on device

rcoleman-mbp-enet:osx rcoleman$ 1

 

And again you can see the "1" from the button that I tried to delete.  Something is clearly wonky here.

 

Rob

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Thanks, Jason.  I have my Flirc, but not the remote control that I used to program it (I'm traveling).  Rather than mess it up more than it is, I'd prefer to wait until I get home to experiment with it.

 

It will be really helpful to have the command line version of the 1.07 OS X app - I'm usually more confident in the results that I get from the command line than I am with a GUI that's trying to outsmart me :)

 

Rob

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Ah, that makes sense. Yes, I'm using the Harmony profile. If it isn't possible, I'd expect the delete to fail with an appropriate error message :). Maybe you could send a pre-configured set of keys if the user selects it in the GUI, rather than having them live forever in the device. That way, you could start with a known set and change it without wasting space. I'd prefer to be in complete control over what's in the device, but I don't really care as long as it doesn't prevent me from doing something. Incidentally, this helps me understand why sometimes, inexplicably it would work. I must have tried different keys.

As far as the command line app, can it just live in the App package for the GUI? Maybe impossible, but that would keep them together.

I don't immediately see your email address on the site (forgive me if it's obvious), so I'll submit another support request and that'll have my email address in it.

Thanks,

Rob

Share this post


Link to post
Share on other sites

Ah, that makes sense. Yes, I'm using the Harmony profile. If it isn't possible, I'd expect the delete to fail with an appropriate error message :). Maybe you could send a pre-configured set of keys if the user selects it in the GUI, rather than having them live forever in the device. That way, you could start with a known set and change it without wasting space. I'd prefer to be in complete control over what's in the device, but I don't really care as long as it doesn't prevent me from doing something. Incidentally, this helps me understand why sometimes, inexplicably it would work. I must have tried different keys.

As far as the command line app, can it just live in the App package for the GUI? Maybe impossible, but that would keep them together.

I don't immediately see your email address on the site (forgive me if it's obvious), so I'll submit another support request and that'll have my email address in it.

Thanks,

Rob

 

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

Share this post


Link to post
Share on other sites

I see the conundrum. If you could hold the whole keymap in read/write memory, then I'd say just send the whole thing based on what the user says he wants in the GUI. If you can't do that because it won't fit, then I can see how you came to the conclusion that you did. I do think that an error message that essentially says "Can't delete that key because it's built-in, but it doesn't consume space in the 160 key 'user area'" would be good. It's the faux success that threw me off, not that I really wanted to delete the "1" key in my example.

i would prefer Option 2 because I can see the benefit in not having to learn every single command for the common use case, but would also like the opportunity to remap those keys if I want. XBMC is very flexible at keymapping on the app side, so it would be nice to have that same flexibility in flirc. Just make it clear what's being done for the user and what they need to do if they don't like it.

As far as distributing flirc_util, I was suggesting that it live somewhere in the flirc.app package, not in the DMG. Like in the "Resources" directory. If the update mechanism updates the entire App package, then you'd get a new one along with the new GUI. You may have to stick it in there manually after you build the app (or maybe not?), but that would keep the GUI and flirc_util app together.

Rob

Share this post


Link to post
Share on other sites

I see the conundrum. If you could hold the whole keymap in read/write memory, then I'd say just send the whole thing based on what the user says he wants in the GUI. If you can't do that because it won't fit, then I can see how you came to the conclusion that you did. I do think that an error message that essentially says "Can't delete that key because it's built-in, but it doesn't consume space in the 160 key 'user area'" would be good. It's the faux success that threw me off, not that I really wanted to delete the "1" key in my example.

i would prefer Option 2 because I can see the benefit in not having to learn every single command for the common use case, but would also like the opportunity to remap those keys if I want. XBMC is very flexible at keymapping on the app side, so it would be nice to have that same flexibility in flirc. Just make it clear what's being done for the user and what they need to do if they don't like it.

As far as distributing flirc_util, I was suggesting that it live somewhere in the flirc.app package, not in the DMG. Like in the "Resources" directory. If the update mechanism updates the entire App package, then you'd get a new one along with the new GUI. You may have to stick it in there manually after you build the app (or maybe not?), but that would keep the GUI and flirc_util app together.

Rob

 

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.

Share this post


Link to post
Share on other sites

I bought 2 flircs after seeing that the harmony profile is builtin.  Trying to get the 1st flirc working.  Didn't work initially but, after doing force fw upgrade in the gui, it now mostly works.  Everything I want to use so far in the harmony profile works except ESC and M.  (There's probably more but I haven't gotten that far yet.)  I can't seem to get past the button already exists problem.  I've tried using the XBMC and full keyboard sections of the gui.

 

Does button already exists mean that it's part of the builtin harmony profile or the flirc thinks it's learned but it's not?  If it's part of the harmony profile, which keys are ESC and M in the profile.  If I knew that, it'd be so much easier.

 

I'm running GUI Firmware v2.0 and Flirc v1.0.9  Harmony One & Raspberry Pi/openELEC/XBMC.

 

I realize that this should be easy, but, so far, it's not. Please point me in the right direction, i.e. how to get past the button already exists problem.

 

Thanks.

Share this post


Link to post
Share on other sites

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.

 

Jason, when I read above, my first impression is that if the GUI was informative about below, I think many misunderstandings could be avoided and less frustration would be created if you choose implementing Option 1:

 

  1. that a native Flirc XMBC profile are available for Harmony remotes and it's enabled as default in the Flirc settings, OR let the user easily activate the native profile directly from the XBMC Controller view in Flirc

     

  2. when a user map a new code to an existing native key, ask if the user want to re-map/overwrite the native key and also provide link to more information about how it works with the native key mappings (URL to the Wiki?). 

     

  3. Make it possible to re-load the native key mappings and remove the users key mappings for those. But don't touch other key mappings the user did for other remote codes.

     

  4. In general, do not show an error message for "remote key already exists" without also showing which key code that is already mapped. And why not ask the user if they want to overwrite this remote code with the new key code?

     

Personally, I'm also using the same Flirc together with WMC as it is my PVR, Obviously, I would also like to have a similar native Harmony profile for WMC... XBMC supports the most of the used WMC keyboard shortcuts, I would the only need to add the few XBMC specific that I personally use. Or if your native profiles can use different remote codes and both can be activated simultaneously in the Flirc device, I can easily use one XBMC and one WMC device profile in Harmony. Any chance you will implement this?

Source for Windows Media Center keyboard shortcuts: http://windows.microsoft.com/en-us/windows/media-center-keyboard-shortcuts#1TC=windows-7

Share this post


Link to post
Share on other sites

It would also be nice to see what's already mapped, even for the built-in keys.  Maybe an option to dump out the user-programmed keys, the built-in (and un-remappable) keys, or all of them together.  To be honest, I wasn't aware that any keys were automatically programmed in the device and that led to some of my confusion.  I see now that you have a FAQ entry about Harmony that says:

 

Do you play well with harmony?

 

Yes, very well. In the latest version of the firmware, we added a default XBMC profile so as long as you are running that release, your flirc will work with the harmony without any additional pairing.

 

That makes it somewhat clearer, but some feedback in the app (similar to what Videonisse is requesting) would be very welcome.

 

On a completely unrelated topic, this website very often hangs when I try to post.  It just did it again (the fourth or fifth time it's happened on different days), and like always, I see that my post has indeed been posted when I manually refresh the page.  It just sits there "Saving post...", sometimes with an animation, and doesn't come back.  This is with Chrome on my Mac and I haven't tried it with another browser or machine yet.

 

Rob

Share this post


Link to post
Share on other sites

Yes I like the harmony profile although i really would really like a wake button. as well as power off button command. These are  the last two pieces for me, I assume thats all BrianAz is doing. Happy new year jason. Random sidenote I cannot the get the poweroff command to work, but one step at a time. Harmony one, Windows 7, XBMC

Share this post


Link to post
Share on other sites

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.

 

Jason, when I read above, my first impression is that if the GUI was informative about below, I think many misunderstandings could be avoided and less frustration would be created if you choose implementing Option 1:

 

  1. that a native Flirc XMBC profile are available for Harmony remotes and it's enabled as default in the Flirc settings, OR let the user easily activate the native profile directly from the XBMC Controller view in Flirc
     
  2. when a user map a new code to an existing native key, ask if the user want to re-map/overwrite the native key and also provide link to more information about how it works with the native key mappings (URL to the Wiki?). 
     
  3. Make it possible to re-load the native key mappings and remove the users key mappings for those. But don't touch other key mappings the user did for other remote codes.
     
  4. In general, do not show an error message for "remote key already exists" without also showing which key code that is already mapped. And why not ask the user if they want to overwrite this remote code with the new key code?
     

Personally, I'm also using the same Flirc together with WMC as it is my PVR, Obviously, I would also like to have a similar native Harmony profile for WMC... XBMC supports the most of the used WMC keyboard shortcuts, I would the only need to add the few XBMC specific that I personally use. Or if your native profiles can use different remote codes and both can be activated simultaneously in the Flirc device, I can easily use one XBMC and one WMC device profile in Harmony. Any chance you will implement this?

Source for Windows Media Center keyboard shortcuts: http://windows.microsoft.com/en-us/windows/media-center-keyboard-shortcuts#1TC=windows-7

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.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×