RMIR: Prototype IR function in RM

[ElizabethD]

OK, which IR file opens issue is a non-issue. No files dragged in, it was just description text from IR I got myself confused. I haven't yet tried saving as .rmir file. Next stage.

Regarding Panasonic to Denon-K translation,

The "import raw upgrade" function is not perfect. It won't always pick the right protocol, because there isn't enough information to uniquely identify it in all cases.

I don't think I understand why there isn't enough information to id the protocol when a functioning IR file is opened, but perhaps I don't need to IF this really is because we're in a prototype. Maybe it's in the meaning of "import raw upgrade" or "all cases".

[johnsfine]

I don't think I understand why there isn't enough information to id the protocol when a functioning IR file is opened,

1) A given PID (protocol ID) may represent multiple executors.

On importing a raw upgrade, there is no info in the device upgrade to tell which varient of the PID is used. If it is a whole .IR file and/or includes a protocol upgrade, then there is enough info to identify the varient, but I have no idea whether or how well RM identifies varients.

2) A given executor (PID:varient) can be used to generate more than one protocol.

Denon-K and a combo version of Panasonic vary the same bits and use the same check-byte computation. So the same exact executor could be used. The fixed data would be different (which could help RM distinguish). The rules for translating OBC etc. into hex commands are different, but THAT can't help RM in this case, because it only has the hex cmds, not the OBCs.

The basic approach to distinguishing protocols in such cases is to translate from fixed data to setup parameters and then translate back. If something is lost along the way then it is probably the wrong translation, meaning the wrong protocols.ini entry, generally meaning the wrong protocol.

But often the main protocol entry (which would be the Panasonic Combo entry in this case) has some extra setup parameters to allow the user to override portions of the fixed data that normally wouldn't vary. So you could translate a Denon-K upgrade to Panasonic combo with those upgrades and not lose anything translating back.

[gfb107]

Panasonic Combo and Denon-K are actually the same protocol. They have the same PID and the same protocol code.
They use and compute fixed data the same way. The difference lies only in the command hex.

When more than one protocol with a given PID is able to regenerate the fixed data cirrectly, RM simply uses the first match. In this case it used the wrong one.

[johnsfine]

Probably this (case of getting the wrong protocols.ini entry) will never be a big issue. Any experts who think otherwise, please jump into this thread and explain.

If it were ever a big issue, I think we should add some syntax to protocols.ini to distinguish strong defaults from ordinary defaults. The OEM fields in the various Kaseikyo protocols would all be strong defaults.

If you change any of these OEM fields you aren't really in the same protocol anymore. We allow you to change the OEM fields in Denon-K and Panasonic to cover the moderately likely case that some third manufacturer will be close enough in its Kaseikyo layout to use one of those before or instead of adding specific support to protocols.ini.

But in decoding a use of that PID:varient combination, mismatching the strong default fields is a very good hint that you're picking the wrong protocols.ini entry.

If we had time to improve such obscure details, we would change the rules so that RM picks the first entry in which the strong defaults match and only failing that drops back to the first entry that works at all.

If we went to the trouble of supporting strong defaults, we might also want a beginner warning of some kind to pop up when a beginner types in an override for a strong default.

[ElizabethD]

I guess the complexity is much greater than I ever imagined, and believe me, I appreciate the difficulties and admire how spiffy and convenient RM-IR really is becoming
But at this point I'm not sure if what I see is due to it being prototype or what might be permanent design features.
So even if I come in with IR file containing fixed bytes for Panasonic Combo (as I detailed on page 3 of this thread), it'll always default to Denon-K where fixed bytes are different in protocols.ini and it'll report that this file uses Denon-K and main device 10?

I'm also missing two other points: the importance of the use of hex, not OBC, in this instance, and the talk about changing defaults. Panasonic default devices, for instance, are 2 and 32. Nothing changed.
Forgive me if I'm totally out of line here.

[gfb107]

It isn't a prototype issue. The same thing would come up if you used RM (classic) to import this particular device upgrade. It may or may not be a permament design feature. That is TBD.

However, it should be pointed out that using RMIR to import a .IR file without immediately loading the "full" RM/KM device upgrade over the top of the imported upgrade is an unlikely usage scenario. The whole point of moving to RMIR is to get the integrated RM function.

Here's the issue. RMIR has only the raw upgrade to work with:

CD 00 FE 3E 42 9E C1 BF FB FA C7 67 C7 F7 C7 77
C7 B7 C7 37 C7 D7 C7 57 C7 97 C7 17 C7 E7 FF FB
FF 7B F7 B3 C7 C0 C7 40 C7 43 C7 AE C7 55 F7 3E
AF 7F FF BC C7 22 FF 42 FF C2 C7 DE C7 AD C7 6D
AF AF AF AF C7 40 C7 C0 C7 FF C7 26

We can parse this out to see that the PID is 00CD and the fixed data is BF FB FA.

RM knows (from protocols.ini) that both Denon-K and Panasonic Combo have PID 00CD. It also has rules for each for converting the fixed data into Protocol Parameter values, and rules for converting Protocol Parameter value into fixed data.

RM tries to eliminate the ones that don't reproduce the fixed data by converting the fixed data to protocol parameter values and back again.
Unfortunately, both Denon-K and Panasonic Combo pass that test. So RM gives up and just picks the first one defined in protocols.ini.

In this particular case, RM's choice could be improved by giving preference to the protocol with the highest numer of imported protocol parameters values matching their default values, but there are scenarios where even this could result in the wrong choice.

[ElizabethD]

Got it. Many thanks Greg & John.
It's in the meaning of "Raw upgrade", of course. Sorry to waste your time, I must have been asleep driving through all this.

[ElizabethD]

RM1.66 - I played some more with the IR section now that I know more what to expect and how to work it. I noticed few things but I think only #3 might be an issue, the rest are marginal or known at this point:

1. Free keymove bytes miscount somewhat similar to what Capn Trips reported about non-system keymoves migrating over to devices.
Always starting from the same IR file or .RMIR file,
> when a 5 byte keymove is deleted, free bytes of keymove area can go negative (-12 free bytes)
> adding a macro can increase the free keymove space
> deleting a Fav macro of 20 bytes results in a free space drop of some 30 bytes

2. I'm sure this section isn't done yet, but in RawData were "..." entries among the red bytes.

3. At some point during the meter watch, above, Special Functions and Macro button names got converted to button numbers, decimal (ouch!). I could not revert back to button names.

Questions:
1. Sometime after normal exit from either RM or RMIR (not sure which was last), javaw.exe remained in the Task Manager list. Is that RMIR, RM or my XP problem?
2. IR always insists on the Scan/Fav sheet that a Fav macro device has to be selected (to this day I have no idea why). Device index goes to $30 and I see a correct value for RCVR (06). But I don't see a slot in RMIR to enter/show that device. Is it really needed?
3. If you build a Fav macro as a keymove, really bound to a device, can we count on it being BEFORE the macro section, i.e. compliant with the sequence IR now uses? Reason I ask is related to the question Capn Trips asked before, since I haven't used it on a device.

[jetskier]

1. Sometime after normal exit from either RM or RMIR (not sure which was last), javaw.exe remained in the Task Manager list. Is that RMIR, RM or my XP problem?

I too have noticed that javaw.exe remains in memory after closing RM. I discovered it when I tried to update RM from an old version to the latest. Windows immediately said it couldn't update the file because it was still in use. After terminating the javaw.exe, it overwrote the file. This has happened for the past couple of updates.

[gfb107]

1, Bytes used/free is still a work in progress. RMIR also doesn't yet stop you from adding too much stuff.

2, OK

3, I hope you can figure out how you got the button names to show up as numbers, 'cause I am clueless on that one. If you see it again, stop and save the rmaster.err file as it might provide a clue.


Answers
1. I don't know.
2&3. RMIR doesn't yet support Fav/Scan. I made it so it doesn't choke on a Fav/Scan during import, since it's part of the advanced code area. It'll show up as a keymove or macro (depending on the remote), but don't expect it to be handled correctly. It is my intention to keep things in the same order as IR.

[ElizabethD]

Thanks for the answers. I'll be watching javaw.exe. I've only seen it once, but i never look really. This time PC was too busy and noisy and I needed to see what was doing me in.

I hope you can figure out how you got the button names to show up as numbers

Still on RMIR v1.65. All evidence in this zip file, replicated key name -> number change http://www.hifi-remote.com/forums/dload ... le_id=3540

Having done all this, I just reread page1 here. Turns out I've been working partly on unimplemented features. Thing is , RMIR is so cool, it's hard to resist pushing all available buttons and messing with it

Greg, am I making it up that sometime in the past the .err file had info in it about what file you've been working on. It would be useful to see when you collect evidence, as things can get confusing. Also RM version would be cool to see.

[ElizabethD]

RMIR v1.67. Still not 100% clear what should work, but just in case,
1. Recheck of the switch of button name to button number situation from above under v 1.65 or 66. It replicates over both IR and RMIR versions. To rule out/in the FAV macro presence in the 8910, I usd it on 6131 and 7800. Same thing. Adding keymoves does it. I also tried on the original, official, 8910_ext1 IR file (txt renamed to IR), as that would also be in a typical workflow for starting up. Same thing.
7800 error log: rmaster(7800overRMIR).err
For 8910, see the tail end of the .doc file.
and error log: rmaster8910_ext1-AddKeymove.err
One disclaimer - in this version it took longer to reproduce than in 1.65 but I haven't followed up.

2. New item: Attempt to save 8910_ext1 as RMIR does something goofy - it does not refresh the active window, and the SaveAs dialog is all grey. The file saves.
See the first, main part of .doc file for screen shots.
Also error logs: rmaster(Word detour).err, rmaster8910_ext1savingAsRMIR.err, rmaster(SavedAsRMIR).err, result of save in 8910_ex1.rmir

3. New item: External functions. I open IR file that contains external functions on the keymoves sheet. I then loaded in an upgrade (KM or RM, don't recall) where those functions were defined as part of an upgrade. I presume that the existing external keymoves would have moved to the upgrade, as that's where they were coded. They did not, so I see them in both places, right? wrong?.
Error log: rmaster(6131+extFchk).err

4. Wish list item: I'd like to see in the log the name(s) or opened/loaded/imported files and datestamp in case the filedate gets lost after the original event.

I hope I haven't mixed up logs with events - all in zip file
http://www.hifi-remote.com/forums/dload ... le_id=3562
It's more logs than you'll ever need, I'm sure. Holler if too muddy.

[gfb107]

Liz, I've got a handle on all your issues.

What you see for External Functions is to be expected, since I haven't written the code that would scan through the existing keymoves and remove matches when installing a device upgrade.

You have to remember that the "Import IR file then load the real upgrade files" mode of operation really isn't the intended normal usage of RMIR. We use it a lot right now because there's a lot of function missing in RMIR, and because those of us testing RMIR have IR configurations and we don't want to have to put a lot of effort into recreating those as RMIR files.

BTW, next time please include some .IR or .RMIR files you used to recreate the problems in your .zip file, or provide links to them in your post.

[ElizabethD]

Liz, I've got a handle on all your issues.

Thanks. Great news. I know you would.

You have to remember that the "Import IR file then load the real upgrade files" mode of operation really isn't the intended normal usage of RMIR.

Not my place to argue, but I have a feeling that mode will be convenient in the future to have.

BTW, next time please include some .IR or .RMIR files

I gotta run. But I could've sworn there were some in both of those ForRMIRevidence zips. Sorry about it. Do you still need'm - if so, I'll upload from home.

[gfb107]

You have to remember that the "Import IR file then load the real upgrade files" mode of operation really isn't the intended normal usage of RMIR.

Not my place to argue, but I have a feeling that mode will be convenient in the future to have.

I didn't say I was going to remove that feature. It is an important and useful one. It is also necessary because it is exactly the same as decoding a download from a remote, except that in that case there are no comments.

I'm just saying that after the initial switch to RMIR (if/when it's ready), it won't be the normal or typical user scenario, and that it may require some manual tweaking.