robroy87010

Yes, like the title of this thread, basically a regex (remove pos/neg signs, add commas) and add preceeding '0,'. Next version Jason releases likely to address/simplify. w/kind regards, Rob

Hi, We do NOT need the prior version firmware, just proved that regex will reformat the capture string. duh that was the title of the post! The capture is imprecise, have to try a number of samples before finding the one that works for each code. I dont see any TV codes for ONN anywhere, when I finish testing these, where is the database to push to? With kind regards, Rob

Hi, That would be great! No support (for comma delimited sendir) required since I can roll back the GUI software to 3.26.0 Our use case for FLIRC is programatically sending IR codes. These IR codes are a large variety of TV codes which depends on which TV(s) the customer has installed. On a lot of TVs that we dont have in our database, or for some reasone they dont work, we have to capture the IR codes, assemble them into a group/database, and then we are able to use these programatically with flirc_util -sendir as needed. We need to improve the current capture process, opening the FLIRC GUI Device Log IR Debugging, pressing the remote, copying the captured ir code, pasting into a database/file, verifying operation by replay, and adding meta data .... it is not automated at the customer end currently. As a result we cannot scale product sales due to tech support hours required (not all tech support hours are for this process but it would signifcantly help) Is it possible to extend flirc_util record (or record_api) to produce the captured codes either in a file or as console output? Or there is a better way that we are just not seeing?

Hi, I have a short term problem. Our software we are using only sends the --pattern= in the exported command line. So now that I have upgraded the firmware (there is no going back right? possible to flirc_util upgrade oldfirmware x?) I dont (currently) have a path to convert the --raw= current captured codes to the --pattern= codes (b/c our current software database and execution is dependent on / hard coded --dont shoot me pls! We will fix just takes time!) Any options like: GUI secret setting? command line capture to specific format? With kind regards, Rob

No worries, it is a minor complaint compared to a bug! No rush to this below question: I don't see any explanation why 3.26.0 is now broken with fully up to date Win 11 22H2. Testing 3.26.0 using the command line repeatedly verified this on several machines. These machines were minimal-ist machines (Minisforums N40 mostly). No easily accessible method to raise the priority of the command line to see if that would improve. Is there a flirc_util command line switch for verbose that might offer a better error enumeration than >> [E] util/flirc_util/src/cmds/ir_transmit.c sendir(96): Error: invalid length, must be even

Windows 11, seems that this version is required otherwise mostly get failures on flirc_util --sendir --pattern=...... when using 3.26.0 Updated the software, but found on capture that format has changed (maybe for the better) but where I used to get: 0,8954,4446,581,508,575,1647,578,512,571,1652,573,516,577,1646,579,1644,570,1652,573,1649,575,1647,578,1645,579,510,573,517,577,513,580,1642,573,1650,574,1648,606,1617,579,511,572,518,576,514,579,511,572,517,577,513,580,510,573,517,576,1647,578,1645,580,1642,572,1651,574,1659,566,1646,579 which I could cut and paste into flirc_util --sendir --pattern=0,8954,4446,581,508,575,1647,578,512,571,1652,573,516,577,1646,579,1644,570,1652,573,1649,575,1647,578,1645,579,510,573,517,577,513,580,1642,573,1650,574,1648,606,1617,579,511,572,518,576,514,579,511,572,517,577,513,580,510,573,517,576,1647,578,1645,580,1642,572,1651,574,1659,566,1646,579 now IR capture displays -39942 +8990 -4421 +596 -493 +601 -1624 +570 -520 +604 -1620 +574 -517 +577 -1648 +577 -1648 +578 -1646 +599 -1625 +600 -1624 +570 -1654 +571 -520 +604 -487 +597 -493 +579 -1645 +601 -1623 +571 -520 +604 -1620 +574 -517 +577 -513 +601 -1624 +601 -489 +605 -1619 +574 -517 +577 -1647 +599 -492 +602 -1622 +605 -1619 +604 -487 +575 -1650 +607 -483 +579 -1646 +579 I dont see anything in the ini file to "old school" this capture, and the flirc_utility doesnt yet appear to accept the new capture stream. Comments anyone? Where is this going? With kind regards, Rob