JP1 Remotes

[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,

[johnsfine]

[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.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[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.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

[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.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[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.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

[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.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

[jetskier]

[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.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[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.

[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.php?action=file&file_id=3562
It's more logs than you'll ever need, I'm sure. Holler if too muddy.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

[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.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[ElizabethD]

[gfb107]