jason

I’m almost done redoing all my build tools so this will be included in the release.

Had you recently done a firmware upgrade? Was it ever able to connect? Did it specifically happen on an update?

I missed it, I invited you to slack so we make less noise and can debug better.

okay, just tried, and I'm able to pull logs. Can you send me your app logs?

I think as long as you are no longer seeing the remote crashing, it's good. I'm not sure about the log issue, I will try and reproduce this. Can you post your applog? Maybe that will show us something. What is different in the behavior from before? And how is it acting now? Did you update your GUI settings?

@infrb We are finding issues specifically on windows. It's really silly, it's all caused due to me updating the firmware version to the correct board. Customers have A6. If you have a mac, it should be fine. Otherwise, we should have an update soon. Sorry about this.

@infrb Windows and Mac

Oh yeah. Let me give you a new gui to try. Hang on.

@infrb okay, I think I found a few issues that could have caused this. I also added an animation during macro playback. I also block all key presses during this playback, and no longer queue keys, since this was causing a lot of issues. (You don't know you are still playing back, and then you could queue up another macro playback and your remote seems stuck). I fixed several other bugs and other issues. If your xfinity is not responding during this playback, it probably has something to do with their receiver. Increase the repeats we send out, not so much the delay. Let me know how this goes. I have a few more things I want to add before really pushing this to a wider audience, but I have to make sure we get rid of the crashes. skip.1s.a06.release-4.12.13.bin

Okay. I made some progress. Memory corruption faults are hard to solve. They can happen a completely different area. But I think I found the cause and am doing a few things to prevent this from happening. I should have an update today with a few improvements.

Make sure ADB debugging is off.

I'm unable to reproduce this. If you reproduce it again, can you grab a log. I see the crash line, I'm not certain the cause yet or the calling function of the problem. Before I add a bit more logging, I'd like to see if it's consistent. Also, please help a bit with what buttons pressed before crashing. How long was the remote sitting there. Which activity were you in, and what buttons did you press? How long was it 'okay' before crashing. I have a funny feeling the original problem has been fixed. A lot of people reported crashing here, and it's gone silent after I put in a bunch of other fixes.

Thank you, this is very helpful. Can you post your config? When you hit 'b' does the activity 'b' light up showing you the profile is enabled? Do you hit the power button in A, or C, before hitting B?

I will get the raspberry pi versions up to date this week

I’m going to help you out with better tools in a sec. I have another app that does a better job at this.

i can send you the previous firmware, but would also need to include support for the comma delimited sendir command, is that correct?

The only thing I see is that your battery is low. Lower your battery to 10% brightness for both profile and ring. Let me know if you see it again.

This was long overdue, and should be fixed in an update I just pushed: Now supports pronto codes or the raw format that is printed directly from the GUI. Examples below. Just put the code in a string. Just a note, interkey delay is built into pronto codes. You can specify it, but it will be ignored. Also pronto codes should work with comma's or spaces. Sorry, it was batshit stupid before, especially with the leading zero needed. This is much easier to comprehend. sendir --pronto="0000,006D,0022,0002,0154,00A9,0014,0014,0014,0014,0014,0040,0014,0014,0014,0014,0014,0014,0014,0014,0014,0014,0014,0040,0014,0040,0014,0014,0014,0040,0014,0040,0014,0040,0014,0040,0014,0040,0014,0014,0014,0014,0014,0014,0014,0014,0014,0014,0014,0014,0014,0040,0014,0014,0014,0040,0014,0040,0014,0040,0014,0040,0014,0040,0014,0040,0014,0014,0014,0040,0014,0608,0154,0056,0014,04F" --repeat=4 sendir --raw="+8840 -4394 +520 -520 +520 -520 +520 -1664 +520 -520 +520 -520 +520 -520 +520 -520 +520 -520 +520 -1664 +520 -1664 +520 -520 +520 -1664 +520 -1664 +520 -1664 +520 -1664 +520 -1664 +520 -520 +520 -520 +520 -520 +520 -520 +520 -520 +520 -520 +520 -1664 +520 -520 +520 -1664 +520 -1664 +520 -1664 +520 -1664 +520 -1664 +520 -1664 +520 -520 +520 -1664 +520" --ik=23000 --repeat=10

I think it's current state is a bit broken. Don't worry, I'm going to push an update soon that cleans this up.

That's not possible, that's the reason behind their terrible software is enormous security measures to prevent anyone from getting their codes, which is absolutely the best database. But learning their codes should be possible. Working hard on this right now and have. a proof of concept ready for the firmware. However, I will push some updates for Flirc USB to make it easier to get pronto codes directly (the tools I use). I have seen this, emailed the author, it is not maintained. Our database is much larger than ours is commercially licensed. We get updates throughout the year. As far as converting these codes, I can do that. I plan on building a lot of infrastructure to allow us and customers to analyze, grab, copy, codes.

This is a more native and universally accepted form of the IR pattern. I'm going to update the software shortly so that you can specify the string in this format. Hang tight.

In the bottom, my remote's name is 'broken'. It is connected. Make sure your remote is connected. Hit refresh on that tab.

In the admin panel there is a device log you can dump. Yes. Please it would be extremely helpful

Yeah I don’ t have a solution right now as it’s a limitation in the actual code from the database. But will have a workaround

When it happens. Just put the remote down. Give it 30 seconds without pressing any buttons. And it should be responding again. Once it responds, you can grab the logs. Any pattern of events when this happens? Is it after not touching it for a few minutes or in the middle of operation?