Updated RDF's Maps, and Images Version 1.28

[gfb107]

The name of the MAP file associated with each remote is in the RDF file for that remote.

For remotes with just one image, it's in the [General] section of RDF like this:

Code: Select all

ImageMap=URC-6820.map,URC-8820.map,URC-10820.map

For remotes with multiple images, it's in the [DeviceTypeImageMaps] section, with a list of images for each device mode, like this:

Code: Select all

SAT/CBL = (urc-8206-sat.map,urc-8206-sat-menu.map)
TV      = (urc-8206-tv.map,urc-8206-tv-text.map,urc-8206-tv-menu.map)
VCR     = (urc-8206-vcr.map,urc-8206-vcr-menu.map)
DVD     = (urc-8206-dvd.map)
CD      = (urc-8206-cd.map,urc-8206-cd-menu.map)
AUD     = (urc-8206-aud.map,urc-8206-aud-menu.map)

If the RDF points to a map file that doesn't exist, you get that Null Pointer Exception

[Capn Trips]

OK, I have completelly removed and deleted all references to RDFs, IMAGES, and REMOTEMASTER. Unistalled the program, deleted all created folders and remnants, deleted every RDF and Images folder and file from my computer.

Unzipped the RM distribution.
Unzipped the RDF distribution.
Unzipped the Images distribution.

All unzipped into the C:\\JP1 folder, into individual folders.

Fired up RM, it prompted me for RDF and IMages/Maps folders and I provided the pointers.

Symptoms are basically the same, although the NullPointer exception NOW has a MUCH longer string of data when it pops up.

All of the same remotes are affected (except for Charter, which are nowhere to be found at all now.)

RemoteMaster.properties file:

Code: Select all

#Mon Jan 28 13:43:39 EST 2008
ImagePath=C\:\\jp1\\Images
KMBounds=0,0,739,670
RDFPath=C\:\\jp1\\RDF
Remote.signature=30333033
Remote.name=Atlas 5 Day URC-11055 JP1.3 3033

RemoteMaster.err file

[Capn Trips]

Greg,

I roger what you are saying, and will go through each rdf for this check, but it seems that this is ONLY happening to me (and to a lesser extent, Vicky).

However, I am not altering the names or contents of the RDFs (or MAP files) in any way, so why does the identical rdf and map file work fine for others, but not for me?

[Nils_Ekberg]

OK, One error at a time

1) Replace the underscore with a space in the 10331033 rdf.

2) Delete the second KASAKASX RDF

Now on to the bigger problem.

Whenever you get to a multi image remote you are getting this error:

C:\jp1\RemoteMaster\Images\RS15-2138-VCR.map (The system cannot find the path specified)

Now that does sound like the path you set so I am not sure why you are getting that error if the map does in fact reside in the folder listed in the error. Verify that it is the correct path and that file is there.

Just curious but what version of RM are you running?

[vickyg2003]

Nils, I recently upgraded to the latest and greatest RM. If I put your new images in the Images below RemoteMaster it works like a charm. For some reason my remotemaster won't let these particular rdf's to be anywhere but the remotemaster\images folder.

[vickyg2003]

Could these //'s in the RDF be causing the problem

//ImageMap=URC-8204.map

//ImageMap=URC-6690.map

[Nils_Ekberg]

Could these //'s in the RDF be causing the problem

//ImageMap=URC-8204.map

//ImageMap=URC-6690.map

Should not be a problem. I believe the // is just a way to comment out the old image entry. I should however get rid of it if it is not needed.

[Capn Trips]

Success! I have multi-screens working in RM!

OK, One error at a time

1) Replace the underscore with a space in the 10331033 rdf.

2) Delete the second KASAKASX RDF

Got those. I presume they will be corrected in the next release.

Now on to the bigger problem.

Whenever you get to a multi image remote you are getting this error:

C:\jp1\RemoteMaster\Images\RS15-2138-VCR.map (The system cannot find the path specified)

Now that does sound like the path you set so I am not sure why you are getting that error if the map does in fact reside in the folder listed in the error. Verify that it is the correct path and that file is there.

Just curious but what version of RM are you running?

1.82, but that is/was not the issue. It is/was indeed the path.

The correct path for ALL of my images (which I set after prompted by RM) WAS:

C:\jp1\Images\

This worked fine for the SINGLE-image remotes. However, what you gleaned from the err file indicates that RM was/is looking for the MULTI-images in THIS folder:

C:\jp1\RemoteMaster\Images\

..well, no such folder existed (until I just created one).

So RM (as far as I can tell) was seemingly ONLY looking for the MULTI-screen images in an images subfolder in the Remotemaster folder, regardless of what images path one sets.

I moved my entire images folder from the JP1 folder into a newly-created JP1/Remotemaster folder, and (after the obligatory "no Images found!" pop-up and pointing RM correctly upon its next startup) all works fine.

I must underscore that I correctly pointed RM to the Images folder on EVERY occassion, and it was finding the SINGLE-screen map and image files OK, it was only these MULTI-screen maps that the pointer in RM was seemingly not "pointing" to properly.

Sounds like an RM problem to me.

Now, other niggles:
(1) I still get the raft of NullPointer Exception errors for the 30323032 RDF. I've compared it line-by-line to the 30003000 and 30333033 rdfs, and the calls to map files are identical, so I'm really stumped;
(2) There are 2 Atlas DVR-PVR maps. One of them is missing a space between Atlas and DVR in its name. The one without a space appears to be associated with an obsolete version of the SA_7SA_7 RDF (see (3)). Recommend deleting it;
(3) Related to (2) above, there are THREE SA_7SA_7 rdfs. The first two are for the 1K and 2K variants, whilst the third looks like an antiquated version of the 1K and should be deleted (obviating the need for that duplicate map file in (2));
(4) You have TWO 102151025 rdfs for the same version of the Atlas URC-1055. I believe that Vicky has already pointed out that the SECOND of the two is obsolete and should be deleted;
(5) Similarly, you have TWO 30003000 rdfs for the Atlas URC-1055 JP1.3. The second of THESE should also be eliminated.

[Nils_Ekberg]

I think I just came to the same conclusion on the path name going back and forth in a PM with Vicky.

Hopefully Greg sees this since what I think is happening is that when a single image is called it use the image path that is set in the properties file correctly. When a multi image map is needed it is not always using the path set in properties and defaulting to the long name that was in the error and of course is not finding them.

That begs the question as to what is triggering it to use the long name since it works for me with the properties set path for both single and multi images.

Greg When the RDF's were converted for multi images the old entry was left in the rdf with a // in front of it. Could that be triggering an error in RM?

[Nils_Ekberg]

Now, other niggles:
(1) I still get the raft of NullPointer Exception errors for the 30323032 RDF. I've compared it line-by-line to the 30003000 and 30333033 rdfs, and the calls to map files are identical, so I'm really stumped;
(2) There are 2 Atlas DVR-PVR maps. One of them is missing a space between Atlas and DVR in its name. The one without a space appears to be associated with an obsolete version of the SA_7SA_7 RDF (see (3)). Recommend deleting it;
(3) Related to (2) above, there are THREE SA_7SA_7 rdfs. The first two are for the 1K and 2K variants, whilst the third looks like an antiquated version of the 1K and should be deleted (obviating the need for that duplicate map file in (2));
(4) You have TWO 102151025 rdfs for the same version of the Atlas URC-1055. I believe that Vicky has already pointed out that the SECOND of the two is obsolete and should be deleted;
(5) Similarly, you have TWO 30003000 rdfs for the Atlas URC-1055 JP1.3. The second of THESE should also be eliminated.

OK, fixed 2 thru 5

On #1 change this line

ImageMap=Atlas-5-PVR-Day.map

to this line

ImageMap=Atlas-5-PVR-DAY.map

Map names are case sensitive.

[Capn Trips]

(1) I still get the raft of NullPointer Exception errors for the 30323032 RDF. I've compared it line-by-line to the 30003000 and 30333033 rdfs, and the calls to map files are identical, so I'm really stumped;

On #1 change this line

ImageMap=Atlas-5-PVR-Day.map

to this line

ImageMap=Atlas-5-PVR-DAY.map

Map names are case sensitive.

Did that - same result. Doesn't fix it. In fact the EXACT same line is present in the Atlas URC-1055 30003000 and 30333033 rdfs (with "PVR-Day") and those work fine, so case-sensitivity does not impair those two rdfs.

Only the 30323032 rdf barfs for me.

[Nils_Ekberg]

OK I will have to dig deeper on that then since it works for me with that change and did not before.

By the way, you have to get out of RM whenever you change an RDF, map or image since it caches them.

[Capn Trips]

By the way, you have to get out of RM whenever you change an RDF, map or image since it caches them.

Yup. Got that. Been doing it throughout.

By the way, I'm just reporting what I see (and because I like to be contrary). There is (for me, at least) no urgency, since I don't have any 30323032 Atlases so it doesn't directly affect ME, Al Franken.

Thanks for digging.

[Nils_Ekberg]

By the way, I'm just reporting what I see (and because I like to be contrary). There is (for me, at least) no urgency, since I don't have any 30323032 Atlases so it doesn't directly affect ME, Al Franken.

Thanks for digging.

No problem. I appreciate it since it has been awhile since there was a distribution and there are a lot of new RDF's in it that may or may not have been completely tested or finalized. Plus a lot of new maps and images. And, this was the first distribution of the RM multi images function and even though it all worked for me there was likely to be some problems on different configurations.

So, I am happy it is being tested.

[Capn Trips]

Well, for what it's worth, here is my latest err file. The only problem I currently have is with the 30323032 rdf.

The 30323032 rdf worked OK PRIOR to this update, but unfortunately, I do not have that old 30323032 rdf any more. I notice that the one in this distribution was modified by kupakai (at least, he provided you something on Sunday, so I assume you included his updated variant).

If you have the PREVIOUS one around, I'll be happy to try it to see if RM lieks it better.