RM Device Upgrade Corruption When Switching Assigned Remote

WagonMaster · Post by **WagonMaster** » Sat Sep 12, 2009 8:50 pm

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 · Post by **3FG** » Sat Sep 12, 2009 9:44 pm

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.

Post by **vickyg2003** » Sat Sep 12, 2009 9:58 pm

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.

WagonMaster · Post by **WagonMaster** » Sat Sep 12, 2009 11:05 pm

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 · Post by **gfb107** » Sun Sep 13, 2009 8:06 am

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.

WagonMaster · Post by **WagonMaster** » Sun Sep 13, 2009 1:21 pm

gfb107 wrote: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.

Aha! Thanks, Greg -- you're right. I just tried that and it seems to work fine. I didn't actually load and test the remote with the device upgrade (yet), but a cursory inspection of the saved RMDU file after following your procedure shows that functions which had been erroneously re-written/corrupted are now correct!

There's no way I'd have ever figured out that work-around on my own, with my current limited level of expertise. Thanks again!

Regards,
Bill

gfb107 · Post by **gfb107** » Tue Sep 22, 2009 6:52 pm

Give v1.97 a try.

WagonMaster · Post by **WagonMaster** » Wed Sep 23, 2009 4:00 pm

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

Bill