IrScrutinizer - Protocol not found?

[Barf]

I will only comment upon the possibilities to interpret an RMDU update in IRP format, e.g. for importing in IrScrutinizer.

The basic problem is that the information on how to map the RMDU info into IRP protocols and parameters is simply not there in a unambiguous, machine readable form. The Cmdtranslator and the DeviceTranslator maps between the "fixed data" and the RMDU user friendly parameters. These are close, but not quite the same as the IRP parameters, It is not that hard to "guess", but this then has to be programmed for each executor. Also the name of the IRP protocol needs considerable work to extract: For example, the executor named "NEC1" can generate IRP protocols NEC1, NEC2, and more ("send 2x then dittos...").

...
the simple name change of the protocol from what was imported by IRS from RMIR from "RC5" to "RC-5" meant that IRS didn't know what to do with the imported file. I should think that if IRS knew the protocol (executor) by name, it should have access to the proper executor and be able to import the data based on the known executor and thus populate the fields accurately. In this instance, IRS simply pulled in the file and put all the parameters into a single column, and since it could deliver no information on what those parameters were, it offered little in the way of guidance to a working device file.

No, The reason why it can import NEC1 (at least in some cases) but not RC-5 is mainly that the hex -> OBC function in the latter case is lsb+complement ("Translator(lsb,comp)"), which I have programmed in (ProtocolsIni.java) , which is not the case for the hex -> obc function for RC-5 "Rc5Translator()". There are 4600 lines of code in com.hifiremote.jp1.translate...

Essentially, if I'm understanding, the protocol tells us generally how the data is supposed to look, and the executor is a set of instructions on how each remote is going to be instructed to make our data look that way.

In the worst case, the the executor is a "recepie" written in a language we do not quite understand, including the meaning of its parameters. If we had an emulator, we could run it and put the result through DecodeIR, would basically solve the problem...

If exporting RMDU updates, the best bet would probably be to implement some sort of generic (e.g. Girr) export facility within RM. This would mean an extension to protocols.ini, for example on how to generate IRP names.

It is more curious to me still that when inputting data for a remote, I wanted to save it for later use in the format I saw in IRS. So I exported the parametric remote data as a Grrr, text and a few other formats, but on importing the very same files, in most every instance, the import fails and I have to re-input all the data again. In none of the formats was the import successful such that I could immediately use the file as I had saved it.

All this said, it's a really neat program, I just wish I could exploit more of it!!

Can you make that into a constructive suggestion?

[The Robman]

It is more curious to me still that when inputting data for a remote, I wanted to save it for later use in the format I saw in IRS. So I exported the parametric remote data as a Grrr, text and a few other formats, but on importing the very same files, in most every instance, the import fails and I have to re-input all the data again. In none of the formats was the import successful such that I could immediately use the file as I had saved it.

All this said, it's a really neat program, I just wish I could exploit more of it!!

Can you make that into a constructive suggestion?

He's looking for something similar to how IR and RMIR let u save a file in a format that keeps all your comments, etc. Even though that data doesn't make it into the raw data that gets loaded into your remote. So, in this case, if he's already done all the work of mapping codes, etc he wants to save it in a format that can be re-opened using IRS and have it look the same as when he saved it.

Regarding the other stuff with protocols and executors, would it be possible (or practical) to have some sort of .ini file for IRS that maps the various names in protocols.ini to the names in IRP that IRS uses?

[ncoig]

He's looking for something similar to how IR and RMIR let u save a file in a format that keeps all your comments, etc. Even though that data doesn't make it into the raw data that gets loaded into your remote. So, in this case, if he's already done all the work of mapping codes, etc he wants to save it in a format that can be re-opened using IRS and have it look the same as when he saved it.

What he said! This is precisely what I may have stumbled on my words with this AM. It isn't even so much to keep the comments (which would be ideal) - it would be great if it could just keep the basic structure.

The particular need that gave rise to this inquiry is the wonderful functionality you include for Anymote. Since once this is exported to that format and put in the phone, there's no easy way for me to manipulate that data, since there isn't an "IMPORT ANYMOTE" function. My solution was to just save it in a native formate that IRS could both export to and import from. In this way, I could pull up the upgrade and make changes to key names, etc. and easily export it out to Anymote again. Alas, exporting my information to any format yields a file that, while I can read it and see the data's there, IRS barfs (couldn't resist) on the import and fails entirely. As a result, if I want to change the label for one key, I have to re-import the file from RMIR, re-do the protocol names, re-key each OBC in, yadda, yadda.

-N

[Barf]

He's looking for something similar to how IR and RMIR let u save a file in a format that keeps all your comments, etc. Even though that data doesn't make it into the raw data that gets loaded into your remote. So, in this case, if he's already done all the work of mapping codes, etc he wants to save it in a format that can be re-opened using IRS and have it look the same as when he saved it.

Ok, it is clear now. Thank you. Sorry I did not get it earlier. What happens is that if "Raw" or "Pronto Hex" is selected on the export/Girr pane, AND the signal is not renderable (like an unknown protocol) the exporter gives up completely. This is not a very good situation, and something I will fix. Without this fix, you can just de-select "Raw" and "Pronto Hex", and it should work as you expect, including preserving the commands. Please let me know if this is the case or not.

Regarding the other stuff with protocols and executors, would it be possible (or practical) to have some sort of .ini file for IRS that maps the various names in protocols.ini to the names in IRP that IRS uses?

No, the problem of mapping protocol names is harder than that (see my comments on NEC1), and it is just one of several problems.

Alas, exporting my information to any format yields a file that, while I can read it and see the data's there, IRS barfs (couldn't resist) on the import and fails entirely.

Please upload one such to the diagnostic area, and describe in detail what you did. If a program generates something it cannot read, that is bad.

Bengt

[Barf]

Try this testversion to see if it solves the problem. If "Raw" or "Pronto Hex" is selected, and the signal cannot be rendered, it still does all the other stuff, including the parameters.

(Overwrite existing IrScrutinizer.jar (or IrScrutinizer-jar-with-dependencies.jar) with this file.)

[Barf]

... there isn't an "IMPORT ANYMOTE" function.

While I am pretty happy about the procedure for adding export formats (just add to the text file exportformats.xml), the same is not true for the import formats.

However, it would be a rather simple exercise to write a little stand-alone proggie for translating Anymote files to girr, using for example a language like Python (or Visual Basic, or ...). Would that be helpful?

[ncoig]

Ok, it is clear now. Thank you. Sorry I did not get it earlier. What happens is that if "Raw" or "Pronto Hex" is selected on the export/Girr pane, AND the signal is not renderable (like an unknown protocol) the exporter gives up completely. This is not a very good situation, and something I will fix. Without this fix, you can just de-select "Raw" and "Pronto Hex", and it should work as you expect, including preserving the commands. Please let me know if this is the case or not.

I tried deselecting "PRONTO HEX" and "RAW" (which wasn't previously selected) on doing a Girr export. The result is here:
http://www.hifi-remote.com/forums/dload ... e_id=13559

On import, I get "IrpMasterException: Command A1: MasterType is parameters, but no protocol found".

Alas, exporting my information to any format yields a file that, while I can read it and see the data's there, IRS barfs (couldn't resist) on the import and fails entirely.

Please upload one such to the diagnostic area, and describe in detail what you did. If a program generates something it cannot read, that is bad.

See above, I have other export formats as well, but the error is the same.

-N

[ncoig]

Try this testversion to see if it solves the problem. If "Raw" or "Pronto Hex" is selected, and the signal cannot be rendered, it still does all the other stuff, including the parameters.

(Overwrite existing IrScrutinizer.jar (or IrScrutinizer-jar-with-dependencies.jar) with this file.)

Is this to test the exporting or importing, or both? (I only ask because I have to rebuild the file each time I run the test because I have to exit IRS to start the importation process, so I want to know which aspect I'm looking at before testing)

Thank you,

-N

[ncoig]

... there isn't an "IMPORT ANYMOTE" function.

While I am pretty happy about the procedure for adding export formats (just add to the text file exportformats.xml), the same is not true for the import formats.

However, it would be a rather simple exercise to write a little stand-alone proggie for translating Anymote files to girr, using for example a language like Python (or Visual Basic, or ...). Would that be helpful?

While very kind, that's completely unnecessary - if I can find a way to import from any of the formats you already support, it would be effortless to export it to Anymote on a successful opening of a file in IRS. having it stored natively in that format would seem to me a waste of your talent.

-N

[Barf]

I tried deselecting "PRONTO HEX" and "RAW" (which wasn't previously selected) on doing a Girr export. The result is here:
http://www.hifi-remote.com/forums/dload ... e_id=13559

On import, I get "IrpMasterException: Command A1: MasterType is parameters, but no protocol found".

You must select "Parameters" for the export. But that shows another problem: it should not be possible to perform an export with all the formats deselected.

See above, I have other export formats as well, but the error is the same.

If this is not covered by the previous problem, please tell me exactly what you do and upload an example file. I am not very good at guessing...

Is this to test the exporting or importing, or both?

It contains a fixed export function, that can export the parametric form also if raw or pronto hex fails.