JP1 Remotes

[WagonMaster]

I've run into an odd problem with RemoteMaster (v1.96) that I cannot explain. It's easy to reproduce, though....

Basically, I downloaded this device upgrade file for the Philips DVDR3576H/37 DVR (which should really be in the 'PVR' device upgrade section, not the 'DVD' one, IMHO), loaded it into RM, changed the remote control from the device upgrade's default of RS 15-1994 to RS 15-135, and saved that setup as a device upgrade file. When I then compare the newly saved device upgrade file to the original, I see a major corruption of the "Function.__.hex=__" lines! Of course, several of the "Button.__=____|____|____" lines have changed, but that's expected, due to the change of remote type.

Why is this happening? This seems like a bug in RM to me.

In fact, the above description greatly simplifies the actual process I went through trying to figure out why my device upgrade wasn't working right. It took me a while to figure out what was really happening.

Eventually, I just copied the entire block of "Function.__." lines from the original RMDU file, replacing those in my RMDU file. That fixes the problem nicely -- everything started working again -- but it's obviously an ugly hack.

Thinking maybe this might have something to do with a bad RDF file, I later went back and tried loading the original RMDU file and changing from the RS 15-1994 remote to a URC-8820. Same problem -- massive corruption of the "Function.__.hex=__" lines! In fact, the entire block of "Function.__" lines were identical in both the RS 15-135 and URC-8820 RMDU saved files, with just the "Function.__.hex=__" lines corrupted (identically). That leads me to believe that it's probably not a problem with the RDF file(s).

I tried to look into this problem myself by examining the Java source code for RemoteMaster, but with over 270 (!) source files, I don't even know where to begin!

To be thorough, I fired up RM and loaded a different device upgrade file (one from the forums for a Magnavox TB100MW9 DTV converter box). I switched the target remote from URC-10820 to RS 15-135 and saved that as a new RMDU. When I compare the 2 RMDU files, there is NO CORRUPTION of the 'Function.__' lines at all! So why is this happening for the device upgrade file whose URL is listed above? Beats me.

Anyway, I'd sure appreciate some suggestions as to what might be wrong here. I suppose I could be doing something wrong, but I've tried this several times, under Linux and Windows, and the results are always the same.

Regards,
Bill

[3FG]

I tried it and saw corruption also. I notice that in changing to the 15-135 (or other newer remotes) that the RC-6 protocol displays 4 rather than the original 2 bytes of fixed data. Switching from the 1994 to a URC-860x leaves the fixed data alone and there isn't any corruption.

I edited the original RMDU file to make the protocol 00 5A, NEC, protocol params 50 null null, and 3 bytes of fixed data. With just those 4 lines changed, no corruption occurs when switching to a 15-135.

So it is probably related to the RC-6 protocol and the apparent need to change from 2 bytes to 4 bytes of fixed data.

[vickyg2003]

Yes this seems to happen whenever there are more than one version of a PID. I usually have 2 RM's open at the same time and then just copy the functions from one to the new one.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

[WagonMaster]

Thanks for the replies, guys....

I'm too new to all these user issues and I'm not smart enough about the protocol stuff to know, but it almost sounds like you're talking about 2 different issues. Or am I misunderstanding?

I may have to play around a bit more and think before I fully appreciate what you're both telling me. Either way, it's nice to know it's not just me seeing this!

I guess I'm also left wondering -- is this a bug in RM? Or is it something that RM can't do much about, implying that I should just deal with it, make my device upgrade with the hack I mentioned, and move on?

Bill

[gfb107]

It's a bug. The code for recomputing function hex when switching protocols (even different variants of the same protocol) didn't allow for named functions without assigned commands.

I'll release a fix soon.

The workaround is to open the original .rmdu, go to the Functions tab and click the "Clean up" button to get rid of the functions without command values, then change the remote.

That's much easier than manually copy'n'paste the function lines between the rmdu files.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[WagonMaster]

[gfb107]

Give v1.97 a try.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[WagonMaster]

Just a confirmation.... I've now tested the new v1.97 release and the problem is indeed fixed! Thanks!

Bill