jason

I'm sorry, I missed your post it was in the wrong category. Try the latest update, it should unbrick it.

No it's not being ignored. It's generally very hard to stay on top of everything, since this was a duplicate issue in the beta firmware forum. I thought I was communicating with everyone in the topic, and did not see this. Should be fixed, you should have received an update notification in the app along with a firmware update once downloaded. New firmware resolves quite a few issues.

I'm sorry, it's been increasing You are awesome and completely validated. I'm really sorry. It's been really rough. I'm working with a huge supplier and I'm lucky they are working with me, but I'm at their mercy. Dates are meaningless to them. I get promised a date, we go past it, they claim there is a problem, we solve it, then it's something else, like a defect in a part made, we solve it. I'm shipping again, I started two weeks ago. They should have sent all 3,500 at once, but they are a bunch of fuckheads and I'm getting them in small batches. I'm sending the same day they come out, and I have shipped 300 since this started a couple of days ago. I'm being promised another 2,000 will be ready to ship to me on Tuesday. I believe they will this time because they were waiting on USB cables they forgot to order, and I know they have them from the supplier because I escalated directly with them. Last shipment was received in about 4-5 days. They got the cables, they have them in the boxes, and we have a pick up scheduled. But I've held my breath before. Since starting, I've shipped close to 2,000 units (yup, me). Once I get the rest, every single pre-order should ship and I should have no more stock issues. I'll have help, and it should take about two days to ship them all out. The last thing I said to my CM who's managing the schedule was: "I have broken the trust and confidence of my customers. I have never done this or had this happen with a supplier." She had no response. I'll never do this again. I'll have units in hand prior to selling. It's the worst feeling watching someone pull the rug out from underneath you. Lesson learned. But, their quality assurance has been by far the best of any supplier I've ever worked with. Usually, I get angry because they fuck something up. So far everything has been very well received. Will be back by tuesday to confirm shipment. Grateful for the support along with the criticism. Well deserved.

I've pushed updates. My effort was focused on fixing auto-updates, linux builds, pi builds, deb packages, etc. I don't know where I left flirc_util, however another utility is now included called irtools. This is my go to app for debugging protocols, transmitting, etc. Since it runs on a different interface, you can run it along side the flirc GUI and both apps will be able to open and communicate with the device. You can use irtools to listen in raw mode. You can also live decode showing the results of my own decoder, the arduino decoder, and decodeir (similar to irscrutinizer) You can listen and print out pronto equivalent codes You can transmit using raw codes, or pronto codes. I do not support transmitting with protocols yet (XMP, HEX: 0x21314) for example. I do not do any edge cleanup. Meaning, if I successfully decode a protocol, I will eventually take the signal, clean up the edges so they are idealized against what the protocol specifies, and reprint those out. I will also eventually turn this into a library.

The default brightness is too high, you should lower it to 30%. The new firmware you are using has low voltage protection. If the LEDS are fully bright, and you hit to transmit, it will appear buggy and turn off if the batteries are not high enough to support the current. Without this, we run the risk of restarting the firmware, losing your current profile, or memory corruption. Once you have the new firmware, lower the brightness, newer batteries, things will be much more stable and last a lot longer. When you unplug the remote, the leds auto shut off. This is what you are seeing. The reason is the remote is lighting LEDS based off what you are doing in the GUI. Once disconnected, to protect the batteries and power drain, the LEDS are shutoff, regardless if it was on from the GUI, or if you pressed a button on the remote. All versions are still available in the forum. USB upgrades was delayed since January because of various windows issues. We've spent a long time on it, tested months. It's very likely there are issues we haven't caught, but there is nothing we can do, I can't delay firmware forever, never upgrade, and leave features unreleased because of windows bullshit. So we do as much as we possibly can, release it, and as soon as we hear about something like this, we will focus on it to catch a corner case we couldn't reproduce. I'm sorry to everyone having trouble. I just saw this in the forums, and will now focus on it. I know it appears we are this massive company, I've got 4 people, I do all the firmware, and only one developer doing the GUI now. The other full time people are not technical. My experience and adversity will shine through, and I'll help resolve this. Again, so sorry for the initial disappointment. I'll follow-up again soon.

If you go to system information, do you see the remote under USB devices? Hold down option, click the apple icon in the upper left corner. Click on System Information.

I'm not sure, this is new. If you right click the msix, and 'run as administrator', does anything different happen? Did you have any previous version installed ever? If so, did it work? I'm running on the same version in windows 11. Everything online points to a windows error when this occurs, but like everything, is unhelpful about resolution...

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