Jump to content
Flirc Forums

rccoleman

Members
  • Posts

    10
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by rccoleman

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. This is fairly old topic, but I just noticed something that may be interesting to others.  I was having all sorts of trouble with phantom keys on my Macbook Pro (2010 model), both with and without noise cancellation, and I noticed that it only happens when I have the power cord plugged in to the laptop.  Even in a dark room, I get phantom keypresses if power is connected.  When I disconnect power (run on battery), I stop getting phantom keys even in a reasonably bright room.

     

    I saw that it got better when I relocated my laptop to a different space earlier this week, but I didn't make the connection to the power supply until now.

     

    Rob

    • Like 1
  7. 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.

  8. 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).

×
×
  • Create New...