JP1 Remotes

[vickyg2003]

I'm a few alphas beyond where you are(2.02 beta 1.3) , but when I follow these steps I'm not seeing any of this behavior. You might want to check your rmaster.err and see if anything kicked up a fuss.

You might also want to include some details about the system you are running on.

[3FG]

Ths happens on two computers, both running XP SP3 and Java 1.6.0_29.
Of course the .err file kicks up a fuss.

[vickyg2003]

Well I'm not getting that error.

[3FG]

I hadn't tried entering a keymove from a function, but it does the same thing. I've also tried many EFCs and keys. I haven't tried hex code entry. However, your comment does remind me that people do things differently.
1) Did you start with a freshly opened session of RMIR, and used File\New\Remote Image?
2) Used Denon Combo and not Denon or Denon Combo Official? The critical point here is to use an executor which is not resident in the remote, and hasn't already been loaded with an upgrade.
3) No files (neither RMIR nor RMDU nor KM) should have been opened during this process.

[vickyg2003]

[3FG]

Yes, for me when it is messed up, the keymoves don't display and I have to use Task Manager to kill it. This doesn't just happen with Denon Combo; I only used that as an example because that executor has been in use for a long time.

Anyway, I see the problem now. If the top line in the Device Upgrade Editor is blank, the user can't get to the Keymove tab. This appears to be true for any kind of executor, provided the keymove works against an upgrade.

And it seems to be reversible. Build up an upgrade with an entry at the top (don't know yet about the effect of blank intervening lines), and go to the Keymove tab. Assign a keymove, and it is displayed, Then go back to the device upgrade editor, highlight line 1, and click new. This inserts a blank line at the top. Click OK, and click on the Keymove tab. It doesn't open. Go back to the upgrade editor, delete the blank line, and now the Keymove tab will open.

The reason I ran across this is that I wanted to check if the advice I had given Andy Ross really worked, so I wanted to make keymoves from an empty or dummy upgrade. So I had no functions defined, and therefore plenty of blank lines!

A workaround for a dummy upgrade is to click Clean Up before exiting the upgrade editor.

BTW, and its not very important, when I use a function to enter in a keymove, the first button in the list of possible functions doesn't seem to be initially recognized. Nothing is shown in the notes box, and the keymove routine puts up a message box saying "You must select a function to perform". Selecting a different item on the list populates the notes. If you then select the first button on the list, the note is not changed, but the keymove is accepted, and is done correctly (I think), except that the note is wrong.

[vickyg2003]

[3FG]

Actually the bug I've been trying to report has always been the problem with a blank first line. All of my trials that failed had a blank first line, and that's also why I erroneously believed that upgrades loaded from a file would work. Of course, the ones loaded from a file don't have blank first lines, but I didn't notice that difference. So you discovered the bad EFC issue.

I wasn't sufficiently precise when writing that one can't get to the Keymove tab if the first line is blank. I should have written that one can't get there if a keymove is already defined and the first line is blank. When I was trying to set up a dummy upgrade and had no defined keymoves, I could get to the Keymove tab, but it wasn't able to draw itself once a keymove was defined.

So I think the basic bug is that RMIR can't redraw the Keymove tab when it encounters a non-parseable keymove or candidate for a function-style keymove. I suppose that it should issue a an error warning (e.g. turn the offending keymove red in the list of keymoves). It should also be able to ignore blank lines in the upgrade editor.

[mathdon]

I believe I have fixed the various bugs discussed above, and others reported to me privately by Vicky, and have uploaded RM/RMIR v2.02 Beta 1.5 with these fixes. This is just the .jar file, to replace that in the distribution of v2.02 Beta. There were versions Beta 1.1 through Beta 1.4 but these were distributed privately. Please test to make sure these bugs have been fixed, as there has been a mass of recent posts and I may have missed something.

This is the first version available on this forum since v2.02 Beta. It incorporates changes that have been made by Greg and Barf since the Beta was issued. One in particular needs to be noted, described in this post by Greg. It affects the location of the RemoteMaster.properties and rmaster.err files. If you are using MS Vista or later, and possibly some other users too, you may find that it says it can't find your Map and RDF files. If so, you need to copy the properties file from its location in <user>/AppData/Roaming/RemoteMaster and put it in your installation folder.

If the situation described in Greg's post is to remain for the final v2.02 then I think it is essential that if the properties file is not found in its "new" location then it is looked for also in its "old" location. We really can't have users having to search for a file they probably know nothing about that is in a location they have never heard of, and having to copy that file somewhere else.
_________________
Graham

[gfb107]

Sorry I haven't had any time for RM since making that change to how the .properties and .err files are located. It was a rush job.

Here's my current thinking on this:

• These 2 files should be located in the same folder. This is also the default folder containing the folders for the RDFs and Maps when we get around to implementing the SVN downloading and updating.
  
• If RM is installed into a 'normal' folder, the files should exist in that 'normal' installation folder
  
• If RM is installed into a sub-folder of "Program Files" or "Program Files (x86)" the files should be located in %APPDATA%\RemoteMaster. This will typically be C:\Users\Greg\AppData\Roaming\RemoteMaster
  
  I'd actually prefer the following, but I guess we'll stick with the above for historical reasons.
  
• If RM is installed into a read-only folder (typical for Linux, proposed by Barf for his Inno installer for Windows) they should be located in System.getProperty( "user.home" ) + "/.RemoteMaster". This will typically be /home/{user}/.RemoteMaster
  

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

[vickyg2003]

Hey Graham, Nice Work! I've been working with RM/RMIR v2.02 Beta 1.5 this morning. I would have had RMIR sick with what I'm doing, but all my windows behaved with this new version.

However after reading, I think there was a beta 1.5b that I haven't installed yet. You have been busy!

[greenough1]

Hi,
Not sure if you guys saw this thread since I confused the issue with the possibility of extender involvement.
http://www.hifi-remote.com/forums/viewtopic.php?t=13749

The extender is not the cause. it's something about the atlases and RM-IR. RM by itself is okay. A test upgrade is linked in the thread above that shows the issue.

Let me know if I can help.
Best and happy new year,
jeff

[3FG]

Jeff,
I think you're experiencing normal and expected behavior. Let's separate out the ways to get the device upgrade editor displayed.
1) Start RMIR and File\Open and choose a RMDU file. The upgrade editor opens, and you can choose among the various remotes for which you have an RDF file. But notice that there is no OK button in the upgrade editor--it's not possible to incorporate the upgrade onto the Devices tab. RMIR won't let you do that, because it doesn't have an underlying remote image. Of course you can paste the upgrade into IR--once IR has a valid remote image.

2) Start RMIR and either download a remote image from your remote or do a File\New\Remote Image. On the Device tab, do New and then Open in the upgrade editor. In this case, RMIR expects you will be uploading the image to the remote, and so the upgrade editor doesn't allow you to change the remote model. The remote model used in the upgrade needs to match the image.

So to use RMIR to upload a non-extended remote configuration to an Atlas 1056, start by doing a download from the 1056 (non-extended). If you want to instead do File\New\RemoteImage, that's also fine, but use this RDF for a new Remote Image, because it properly sets the value of $61C-- the RDF in the 1.32 distribution provides a non-functional image). Make sure that you use a 1056 RDF for the new remote image.

Of course, you can run through the same process to upload to an extended remote.

[greenough1]

Hi and thanks. I think I'm getting the zen of RM-IR now. I think the issues I was having was that there was no remote image defined.

I just did a simple test.
* 981 reset an atlas 1056
* download it into RM-IR
* ExtInstall with the v 2.14 extender, telling RM-IR which rdf to use when prompted
* added an upgrade from the device tab and saved.

There was some java error spew, after the extinstall, but it didn't seem fatal or to affect anything I was doing later.

Thanks for your help.
Best,
jeff

[greenough1]

Let me amend the above test and if someone with an Atlas 1056B01 (black, backlit, learner)

*open RM-IR, v2.02 beta (latest rdf's and maps and images)
* connect USB interface to remote and computer
* attempt to download from the remote without accessing any other tab, menu, etc., in RM-IR

If I do that I get an error that "no rdf for remote with signature" is shown.

However, if you go to the device tab, then try the download it succeeds.

Is this a bug? I did 981 resets several times and for this test, it kept failing.

Best,
jeff