Anticipated Nov 2009 Update of RDF/Map/Image Files

[WagonMaster]

I've started a new thread to discuss issues related to an upcoming update to the RDF/Map/Image files.

I anticipate a Nov 2009 release, barring any major problems. Notice I intentionally don't say when in November.

I'll start this 1st post with a description of the first couple of problems I've encountered since taking over the maintenance of these files a couple days ago.

Problem #1:

Inspired by a user-friendly application/tool that Vicky wrote to detect problems in the RDF/map/image files, I've written a tool of my own (using a simple Unix shell script). It's cruder, less-friendly, and less-featured than Vicky's tool, but it's much lighter, runs under my favorite OS (GNU/Linux), and is already pointing out several shortcomings in the current set of RDF/map/image files that her tool is not catching, presumably because of its Windows heritage/centrism, not due to any fault on her part.

There are many, many cases where the text case (uppercase, lowercase) within filenames and file references is causing problems. This is seemingly not apparent when running under Windows but it's very noticeable in non-Windows environments. In fact, as a relative newcomer to the whole JP1 scene, when running RemoteMaster (RM), I was under the mistaken impression that many remotes just didn't have image files because they came up blank when I selected them from the drop-down list in RM. I had a "forehead-slapping moment" just today when I ran my tool because I immediately realized that, like all other users of RM under non-Windows environments, I'm not seeing many of those images because they're not being located due to errors in the text case of some of the file names! I ran RM under Windows and Linux and some remotes that appear fine under Windows fail to appear under Linux, presumably because Windows does not distinguish text case in filenames, while Unix-based OSes most certainly do. Note that this is a problem for many of the map files too, not just the image files. Non-Windows users of RM might pick a remote from the drop-down list only to have RM report that it cannot find the associated map file.

Anyway, I'll obviously be fixing all of those cases before the Nov 2009 release, but I wanted to mention this now in case any other non-Windows RM users have encountered this and, like me, just blithely assumed that the image and/or map file wasn't available.

Problem #2:

There's another odd issue I've encountered by running my RDF-checker tool.

I see that there are 18 RDF files (all variants of the 'Kameleon' remote) in the set I'm working on which have an entry something like this:

Code: Select all

[DeviceTypeImageMaps]
CBL     = (urc-9960-cbl-main.map,urc-9960-cbl-menu.map)
TV      = (urc-9960-tv-main.map,urc-9960-tv-menu.map,urc-9960-tv-pip.map)
VCR     = (urc-9960-vcr-main.map,urc-9960-vcr-menu.map)
DVD     = (urc-9960-dvd-main.map)
CD      = (urc-9960-cd-main.map)
PVR     = (urc-9960-pvr-main.map)
AUDIO   = (urc-9960-aud-main.map,urc-9960-aud-sur.map,urc-9960-aud-menu.map,urc-9960-aud-preset.map)

But I don't see a description for any such "[DeviceTypeImageMaps]" section in the RDF v4 Specification document! A quick check of the source code of RM/RMIR and 'IR.exe' shows that only RM seems to be using this. Why do we have an RDF entry in active use that's not in the official RDF spec? Am I missing something?

Anyway, that's a good start for getting this whole "update the RDF/map/image stuff" going. I'm sure I'll have more to report and more questions as this progresses. As always, any input on these issues is appreciated.

Bill

[alanrichey]

Hi Bill

For the last few months I've been doing a lot of work on the Slingbox forums, using RM to provide users with Custom Remotes for unsupported devices.

As part of this I have fixed a number of bugs in the 2 main RDF file (PL & RV chips) and also produced a new IMG file that looks like the latest generic remote.

If you want to check these and possibly use them, they are at https://www.hifi-remote.com/forums/dload ... le_id=7201

Cheers

Al

[mr_d_p_gumby]

But I don't see a description for any such "[DeviceTypeImageMaps]" section in the RDF v4 Specification document! A quick check of the source code of RM/RMIR and 'IR.exe' shows that only RM seems to be using this. Why do we have an RDF entry in active use that's not in the official RDF spec? Am I missing something?

This is obviously something that was added to RM to address one of the peculiarites of the Kameleon remotes: the visible buttons change from one mode to another. I don't recall when this was introduced, but it seems to have eluded inclusion in the RDF4 spec, and no one noticed it during the spec review period. It will have to be added in a subsequent revision.

[WagonMaster]

... but it seems to have eluded inclusion in the RDF4 spec, and no one noticed it during the spec review period. It will have to be added in a subsequent revision.

OK, thanks for the info. I just wanted to be sure that the "[DeviceTypeImageMaps]" capability was "official" and that if it was, that fixing the spec (a document on which I'm heavily relying to understand things, even more now that I'm maintaining the RDF/map/image files) was part of the plan.

Bill

[WagonMaster]

Hi, Al!

Thanks for the update files -- much appreciated! I'll definitely include them in the Nov 2009 release.

Aside: There are probably more of these sorts of files which, for various thoroughly logical reasons (e.g. aggregation with other non-RDF files), are not in the "RDF Files" section of the "Files --> Tools" section of the forum. But since that's the only section in which I know to look for updated RDF files, I ask that anyone who knows of other such files lurking in the "crevices" of the forum (whether they be RDFs, map files, or image files), please let me know about them so that I can get them in the next update cycle. Thanks!

Al, I know nothing about the Slingbox other than what I gleaned from your useful 'Readme.txt' file. But your changed files raise several questions and I want to make sure I get this right....

Should I replace the existing 'BINPL' and 'BINRV' RDFs with your versions? Given your reference to "fixed a number of bugs", I'm assuming that I should.

I'd like to know more about the changes you made to the "[ButtonMaps]" section in both files. Were those outright bugs or were they just the required changes to accommodate the new-style remote?

If I'm supposed to replace the RDFs with your new ones, then I assume that I should add your map file for the new remote as a 2nd map file in the RDF (please see '(URC-6820_8820_10820).rdf' for an example in the unlikely event that you don't understand me), allowing the RemoteMaster user to select between the 2 remote images whenever that RDF is loaded. Is my assumption correct? Or does the new remote go (all by itself) with the 2 RDFs you updated, leaving the old remote only for the other Slingbox RDFs?

Regardless of the answers to the above questions, we need a different name (e.g. 'Slingbox-v2') for your map/image files since they directly conflict with the current names. Any preferences here? Maybe something more indicative or distinctive than my example?

Thanks for any guidance you can provide....

Bill

[WagonMaster]

I've been working on the RDF files and encountered a small discrepancy that I need some advice on.

I have multiple versions of each of the 3 RDFs for the similar Radio Shack 15-13x models (-133, -134, -135). The newest version that I got from Nils Ekberg is missing the following line, which is in another version of these files that appears to have been an update:

Code: Select all

PauseParams=Pause,2/1,10

I'm pretty sure that the line should be there because there is a "Pause=01FB" line in the "[SpecialProtocols] section, but I want to make sure that Nils didn't intentionally remove it before I add it to the "master" RDF. These are JP1.3, S3F80 remotes. Assuming that the line should be there, are those values correct for said processor? Again, I think the answer is yes, but I'm proceeding cautiously.

Any experts care to comment, please?

Bill

[mdavej]

I'm no expert, but I'm the main author of those RDF's (with lots of help from the real experts). I added that entry fairly recently to support a new feature in IR8 that shows the pause value in seconds. It works and needs to stay.

That parameter should probably be added to many RDF's. I don't recall the rules exactly, but the values will vary by processor.

I also have some notes in the included readme that would be useful to keep somewhere in the new distribution.

[WagonMaster]

It works and needs to stay.

And so it shall. Thanks, Dave!

That parameter should probably be added to many RDF's. I don't recall the rules exactly, but the values will vary by processor.

I'll look into it some more a bit later on.

I also have some notes in the included readme that would be useful to keep somewhere in the new distribution.

I'll see if I can come up with some logical way to preserve people's notes that they often include with their self-released RDF/map/image files. I'd really like to substantially clean out that "RDF Files" forum directory sometime after the new RDF release and I hope folks might be more willing to delete their zip files containing now-obsolete (or simply redundant) RDF/map/image files if I preserve their still-valuable notes somehow with the "master" set of files. I recall distinctly as a JP1 newbie how confusing it was to see a mass of files there and wonder why there was also a big zip file of RDFs too. I'd like to eliminate that potential for confusion. In my mind, the "RDF Files" directory should only have newly-released RDF (and maybe map/image) files since the last "master" release.

Another question as I massage the RDFs and maps, that is probably right up your 15-13x alley, Dave....

I'm seeing that some of the map files put the (hex) button code (matching the one in the RDF "[Buttons]" section) on each line, but most do not. I assume that buys one some extra functionality in RemoteMaster, but I cannot immediately see where.

I ask because I have 2 versions of the RS 15-135 map file, one with and one without hex button numbers. I assume I should use the one with them, but I'd like to better understand the real purpose.

Bill

[alanrichey]

Hi Bill

Should I replace the existing 'BINPL' and 'BINRV' RDFs with your versions? Given your reference to "fixed a number of bugs", I'm assuming that I should.

Yes. You will find that in the 'official' RDF package there are actually 4 Slingbox RDF files. But the only ones currently in use are the PL & RV ones. The PK chip never made it into production and the JU chip was discontinued some years ago and I have never found anyone who needed a remote based on that chip. So I only corrected the 2 current RDF files.

I'd like to know more about the changes you made to the "[ButtonMaps]" section in both files. Were those outright bugs or were they just the required changes to accommodate the new-style remote?

They were definitely bugs, in that some codes were inaccurate. For example, the code for 'Setup' was in a couple of the maps instead of 'Menu', which meant the Menu button was permanently disabled. No changes were needed to the [ButtonMaps] to accommodate the new remote, that just needed a new image file.

If I'm supposed to replace the RDFs with your new ones, then I assume that I should add your map file for the new remote as a 2nd map file in the RDF (please see '(URC-6820_8820_10820).rdf' for an example in the unlikely event that you don't understand me), allowing the RemoteMaster user to select between the 2 remote images whenever that RDF is loaded. Is my assumption correct? Or does the new remote go (all by itself) with the 2 RDFs you updated, leaving the old remote only for the other Slingbox RDFs?

I don't think you need to do that, they can be one-for-one replacements for the existing files, as the old remote image is never used now, all options use the new design (If I recall the image changed when Slingmedia went from V1.2 to V1.3, about 2 years ago. We are now up to 2.0.3 ).

I am tempted to say you could also remove the JU and PK RDF files but that maybe a step too far

Regardless of the answers to the above questions, we need a different name (e.g. 'Slingbox-v2') for your map/image files since they directly conflict with the current names. Any preferences here? Maybe something more indicative or distinctive than my example?

As they are replacements I don't think that is necessary. The old RDF files were definitely broken, so there is no reason to keep them, and the new image is the ONLY one now used so can replace the existing one. As such there is no conflict ?

Mainly for your information, I also made a fair number of cosmetic changes to the [Buttons] part of the file to improve the system:

1. I renamed some of them ('Guide' and 'Last_Ch' for example), so that the Auto-Assign function worked properly.

2. There were some buttons labelled INPUT01-INPUT09 and FP01-FP09. In practice these appeared on the Slingplayer remote as CUSTOM10-CUSTOM29, so I changed the names in the RDF files to match this.

3. In the new Remote 'skin' Slingmedia added 5 colour buttons. So I changed the names of CUSTOM22-CUSTOM25 (the codes they used) to the correct colour names.

If you need any more information, or you need a 'sub-contractor' to maintain the Slingbox files, please don't hesitate to let me know. Without wishing to appear big-headed I think I can now be regarded as the primary expert (outside of SlingMedia) on Custom Remotes for the Slingbox.

I suspect you are much too busy, but if you do need a bit more background on the subject I have written a short article about it at http://www.slingcommunity.com/article/3 ... ingPlayer/

Cheers

Al

[mdavej]

I'm seeing that some of the map files put the (hex) button code (matching the one in the RDF "[Buttons]" section) on each line, but most do not. I assume that buys one some extra functionality in RemoteMaster, but I cannot immediately see where.

An early version of mine had the hex codes in the map file before I knew what I was doing simply because the example I used had them. Greg will need to confirm, but it appears the hex seems to take priority so the button names don't have to match the RDF exactly. Personally I found it to be more trouble than it's worth to create and maintain, and ended up removing the hex codes. Unless others have a good reason, I'd leave them out.

You may also notice that some RDF's use decimal button codes, and others use hex, depending on the author's preference. Doesn't mean anything needs to change, just something I thought you should be aware of.

As for cleaning out the RDF folder, please keep me in the loop. I'm going to try to update the remote chart the same time you update the RDFs. If a remote is in the RDF folder, I know it's not on the chart yet (after a certain date). If they get blown away, I'll lose that info. So wait until we're both done to delete them. If you've made any handy dandy lists of the new RDF's you could share, that would be greatly appreciated.

I wouldn't try to reconcile Nils version and my version of the RDF/Map/Image. I imagine he just grabbed what was the latest several months ago. They've gone through a lot of changes subsequently during extender development and IR8's release. You'd just be adding back in old stuff that was intended to be removed. The latest ones of mine are the ones you should use, unless Nils has found problems I'm not aware of.

Dave

[WagonMaster]

Thanks for all the Slingbox info, Al -- very helpful!

I don't think you need to do that, they can be one-for-one replacements for the existing files, as the old remote image is never used now, all options use the new design

I'll do exactly as you suggest and simply replace the old map/image/RDFs with your new files.

Feel free to have a hearty laugh at my ignorance (I sure did!), but I thought that these were physical remotes and I'm only now understanding that they're virtual, on-screen remotes! Initially, I was wondering why you said I could delete the old remote's image/map and use the new one, thinking that someone must still have such a device, but now I (think I) understand.

Wikipedia mentioned that there's something called "SlingCatcher" that does come with a physical remote, but I'm guessing that it doesn't come into play here. Please correct me if I'm still confused.

I am tempted to say you could also remove the JU and PK RDF files but that maybe a step too far

I'll leave them in place for now. If the time ever comes where you think I should remove them, just say the word.

Thanks again for setting me straight on these issues and for the link to your excellent tutorial. I didn't read it all just now, but I'm definitely keeping the URL for future reference -- nice job!

Bill

[WagonMaster]

Personally I found it to be more trouble than it's worth to create and maintain, and ended up removing the hex codes. Unless others have a good reason, I'd leave them out.

That sounds wise to me. I'll leave them out.

You may also notice that some RDF's use decimal button codes, and others use hex, depending on the author's preference. Doesn't mean anything needs to change, just something I thought you should be aware of.

I hadn't noticed that, actually. I assumed they were hex and had scanned for '$' in the set of map files. Armed with this new information, a new scan shows that only the 'URC-8080.map' file (of those in the set Nils sent me) uses decimal button codes (which matches the decimal-specified codes from the RDF, which oddly uses a mix of decimal and hex!). And, as a further oddity, the 'URC-8080.map' only uses the button code on a few of the buttons! Looks like the hand of more than 1 author was at play there -- or maybe a single schizophrenic author.

As for cleaning out the RDF folder, please keep me in the loop.

Will do.

If you've made any handy dandy lists of the new RDF's you could share, that would be greatly appreciated.

No list yet, but will share with you as soon as I make one.

I wouldn't try to reconcile Nils version and my version of the RDF/Map/Image. (...) The latest ones of mine are the ones you should use, unless Nils has found problems I'm not aware of.

OK, I'll do as you suggest, watching carefully for any possible errors along the way.

Thanks much!

Bill

[alanrichey]

Feel free to have a hearty laugh at my ignorance (I sure did!), but I thought that these were physical remotes and I'm only now understanding that they're virtual, on-screen remotes!

I would never do that I always forget not everyone knows about the Slingbox. As you surmised, we are only talking about 'virtual' remotes. Basically you tell the Slingbox which device you are controlling and it accesses the Slingmedia server and, provided the remote has been designed and coded by SlingMedia, it downloads the codes and 'skin' into the Slingbox so it can be displayed on screen. But for the devices they haven't done they provide a generic image 'skin' which we can code using the normal JP1 tools.

Wikipedia mentioned that there's something called "SlingCatcher" that does come with a physical remote, but I'm guessing that it doesn't come into play here. Please correct me if I'm still confused.

Correct, this is not relevant. In practice, the physical remote send a code to the Slingcatcher, which passes the command to the Slingbox and that generates the correct code for your device based on what has been programmed.

Cheers

Al

[mr_d_p_gumby]

Personally I found it to be more trouble than it's worth to create and maintain, and ended up removing the hex codes. Unless others have a good reason, I'd leave them out.

That sounds wise to me. I'll leave them out.

Personally, I prefer to include the button codes in the map file. What has happened in the past is that the button names in the RDF file get altered for any number of reasons, and then the linkage to the map file becomes broken. If the button codes are there, then the linkage remains intact.

You may also notice that some RDF's use decimal button codes, and others use hex, depending on the author's preference. Doesn't mean anything needs to change, just something I thought you should be aware of.

I hadn't noticed that, actually. I assumed they were hex and had scanned for '$' in the set of map files. Armed with this new information, a new scan shows that only the 'URC-8080.map' file (of those in the set Nils sent me) uses decimal button codes (which matches the decimal-specified codes from the RDF, which oddly uses a mix of decimal and hex!). And, as a further oddity, the 'URC-8080.map' only uses the button code on a few of the buttons! Looks like the hand of more than 1 author was at play there -- or maybe a single schizophrenic author.

Hex is generally preferred, thought the RDF spec does sanction hex or decimal values in the RDF proper. I suppose one could assume the same rules applied to the map file, even though it is not spelled out.

[WagonMaster]

Personally I found it to be more trouble than it's worth to create and maintain, and ended up removing the hex codes. Unless others have a good reason, I'd leave them out.

That sounds wise to me. I'll leave them out.

Personally, I prefer to include the button codes in the map file. What has happened in the past is that the button names in the RDF file get altered for any number of reasons, and then the linkage to the map file becomes broken. If the button codes are there, then the linkage remains intact.

Well, I'll leave the ones that are there in place for now. But I won't be adding any new ones because, frankly, I think having button codes in addition to button names within the map file is a bit hokey if the hex codes are just there to prevent broken linkages, making them essentially redundant. On the other hand, if the hex codes provide some benefit to RemoteMaster, that's another story, but I haven't heard Greg say anything about it, one way or the other.

In fact, in defense of removing these codes from the map files, I must point out that one of Vicky's reports from her very useful 'RDF Analyzer' tool will catch this sort of error (button defined in map file for which no definition exists in RDF), but I haven't worked my way up to fixing all of the flaws found by her tool yet. There appear to be over 600 such cases of this "No button in RDF" error alone!

The RDFs, since they're all needed by everyone, should be under strict control. No broken RDF/map files should ever be released, especially when these things are so easy to check in an automated way. And if someone is using unofficial and/or tweaked RDF/map files, they do so at their own risk, IMHO.

Bill