JP1 Remotes

The URC-9960B01 remote (and the URC-6960 clone) uses a different keymove terminator than regular JP1 remotes. The keymove list is usually terminated with a zero byte, but for this remote it's terminated with an 0xFF byte. Mark added a new RDF parameter called SectionTerminator for this very reason (it's in the KASAKAS0 RDF).

However, it appears that the logic that imports keymoves as part of a device upgrade is not using this paramter, or at least, not using it properly, as we are experiencing problems copying over upgrades that include keymoves.

The problem surfaced in the following thread:
https://www.hifi-remote.com/forums/viewtopic.php?t=6567

The OP got a message stating that the keymove section is not terminated properly. When I tried doing it, I got a message stating that there are too many FAV/SCAN entries and when you try clicking OK, it loops back again. The only way to stop it is to terminate IR from the Task Manager.

... I hope that no follow-up to this post doesn't mean there are very few users with this problem...

Hope that Mark is keeping an eye on this forum/thread, and will be fixing this... I'm really enjoying my Kam 8 otherwise, and would hate switching to another remote...

Thanks for the attention, guys... ciao ciao!

Joe

This is fixed in the version 7.0 (currently beta) of IR.
The problem is not due to the $FF terminator, but to the "new" keymove format as indicated by the AdvCodeBindFormat=LONG parameter in the RDF. Previous versions of IR did not handle this format when importing key moves.
Note that the rdf for the 6960 should also have the EFCDigits=5 parameter set in order for IR to correctly display the imported keymoves.

Thanks a lot Alain...

Just going and checking my newly uploaded upgrade with keymoves in the 9960...

Thanks for the Beta Release made public

Ciao

Joe