JP1 Remotes

I think generally 2 sections is enough: Released and Development (or Beta, or Unstable, or Latest, or whatever name we feel is suitable).

There may be times when we want to have a "Release Candidate" section when there have been significant changes across a large number of files, and we feel there is a need to make that exact set of files available to users over a period of time without being impacted by ongoing development changes.

From a version control perspective, there really isn't anything special about the "Release Candidate" section - it's a tagged revision just like the Released section.

gfb107 wrote:I think generally 2 sections is enough: Released and Development (or Beta, or Unstable, or Latest, or whatever name we feel is suitable).

There may be times when we want to have a "Release Candidate" section when there have been significant changes across a large number of files, and we feel there is a need to make that exact set of files available to users over a period of time without being impacted by ongoing development changes.

From a version control perspective, there really isn't anything special about the "Release Candidate" section - it's a tagged revision just like the Released section.

Yes - I agree. We will leave the native hi-fi remote version (Development) there though so that people who do not want to do the SVN thing can develop there.

xnappo

"RDFs Latest Area - Lastest/Unstable verion of RDFs - Quality unverified!"

Spelling mistakes: Lastest = Latest, verion = version.

I thought, however, that the Development section was the unstable one and that the Latest section was supposed to be stable and ready for release. So it seems I am still unclear as to the precise differences and what is allowed where.
____________
Graham

mathdon wrote:"RDFs Latest Area - Lastest/Unstable verion of RDFs - Quality unverified!"

Spelling mistakes: Lastest = Latest, verion = version.

I thought, however, that the Development section was the unstable one and that the Latest section was supposed to be stable and ready for release. So it seems I am still unclear as to the precise differences and what is allowed where.
____________
Graham

Haha - can you tell I did that quickly? I will fix the spelling thanks.

So... The development area is for you guys to hack around and pass the RDFs around until they are ready for a user.

The 'Latest' area is after it is 'feature complete' but I have not yet run it through Vicky's checker tool.

Any suggestions on making that more clear are welcome.

Thanks,
xnappo

xnappo wrote:So... The development area is for you guys to hack around and pass the RDFs around until they are ready for a user.

The 'Latest' area is after it is 'feature complete' but I have not yet run it through Vicky's checker tool.

That's a good distinction. I would stick to Latest and Development as names but suggest changing the description of Latest to:

"RDFs Latest Area - Versions released or awaiting approval"

or words to that effect. I think that makes it clear that release versions are included if they are the latest ones and that for others, the developer has finished with it and submitted it for your approval (by Vicky's tool and/or any other means).

BTW I'm not trying to change the uses of these areas, just trying to clarify what your intentions were. I would expect RDFs to be deleted from the Development area (in the forum file section) when they are moved, by either the developer or you, to the Latest area (on SourceForge), so that Development genuinely means Unfinished/Unstable.

xnappo wrote:We will leave the native hi-fi remote version (Development) there though so that people who do not want to do the SVN thing can develop there.

I like that idea the best, as I too am one of the SVN-reluctant people I'm afraid.

The Robman wrote:

xnappo wrote:We will leave the native hi-fi remote version (Development) there though so that people who do not want to do the SVN thing can develop there.

I like that idea the best, as I too am one of the SVN-reluctant people I'm afraid.

Sure - only so much time to learn new tools.

Some day when you are feeling bored though, you really should try it out. It is pretty easy to use and a much easier way to stay in sync.

xnappo

Okay, I edited the descriptions again.

Thanks,
xnappo

As you know, I don't like using sorce forge either, but I don't see how you could do the "librarian" job without it. The revision control is awesome.

Ok, I need some advice on how to handle the Atlas OCAP extender situation.

As you have probably seen over the last couple of days, there were a lot of versions of this extender in general use during it's development. Along with the versions were various RDF files.

While it does not cause any permanent damage or anything, using an RDF that does not match the extender causes all sorts of weird behavior.

I could swear I remember a conversation between Bill and Vicky, or maybe Bill and Rob about how to handle this - and that it was changed in later versions of the extender to lock it to a particular RDF, but I can't seem to find that info.

What should I do for the RDF library? Having the really old extender RDF and NOT the latest (2.10) is definitely bad.

Should I:
1. Remove the old RDFs and add the latest stable one (2.10) perhaps leaving the old versions under revision control so people can find them in the future.

or

2. Add all the RDFs with the version they go with in the filename (note that at least for some versions, nothing stops the user from choosing the wrong one).

I am leaning towards #1.

Thanks,
xnappo

vickyg2003 wrote:As you know, I don't like using sorce forge either, but I don't see how you could do the "librarian" job without it. The revision control is awesome.

Y'all (can you tell I live in NC?) may not realize this, but once you've registered at Sourceforge and setup TortoiseSVN, you don't have to go back to the Sourceforge website. Updating your local files to the latest, or checking in your updates is done entirely on your desktop, simply by right-clicking on the folder you've set up and choosing the appropriate action.

You don't interact with the Sourceforge website at all for that.

I don't like the Sourceforge website either.

And yes, revision control is awesome.

Bump. Last chance before I go with #1 for the next release of the RDFs...

xnappo

xnappo wrote:Ok, I need some advice on how to handle the Atlas OCAP extender situation.

As you have probably seen over the last couple of days, there were a lot of versions of this extender in general use during it's development. Along with the versions were various RDF files.

While it does not cause any permanent damage or anything, using an RDF that does not match the extender causes all sorts of weird behavior.

I could swear I remember a conversation between Bill and Vicky, or maybe Bill and Rob about how to handle this - and that it was changed in later versions of the extender to lock it to a particular RDF, but I can't seem to find that info.

What should I do for the RDF library? Having the really old extender RDF and NOT the latest (2.10) is definitely bad.

Should I:
1. Remove the old RDFs and add the latest stable one (2.10) perhaps leaving the old versions under revision control so people can find them in the future.

or

2. Add all the RDFs with the version they go with in the filename (note that at least for some versions, nothing stops the user from choosing the wrong one).

I am leaning towards #1.

Thanks,
xnappo

vickyg2003 wrote: I missed the fact that the 11781178 10820N wasn't in the beta zip. Since I'm nearly done with the extender, it would be nice if the base RDF was in the next zip file.
...
http://www.hifi-remote.com/forums/dload ... le_id=7425

Are there maps/images for this RDF? I searched but did see any.

Thanks,
xnappo

All,

Vicky added a check to her tool to look for missing device type alias like the Atlas 1056 30333033 RDF which caused RM-IR to choke.

Below is the report.

Some of these look like the same error that was in the Atlas RDF - a real device type in the remote that is missing an alias. However others appear to possibly be entries in the [DeviceTypes] section that perhaps should not be there - for instance [HT, other, OEM, DevTypeX].

Any guidance on how to clean this up is appreciated!

xnappo


DevType problems

Report run 07/04/10 10:11:00


10621062 (URC-7780 One For All Stealth 12).rdf
NO ALIAS LIST HT

11311131 (URC-7781 One For All Digital 12).rdf
NO ALIAS LIST HT

1A251A25 (Atlas 5 Day URC-1055 JP1.2 Ext A7).rdf
NO ALIAS LIST VCR

30323032 (Atlas 5 Day URC-1055_11055 JP1.3 3032).rdf
NO ALIAS LIST VCR

30333033 (Atlas 5 Day URC-1055_11055 JP1.3 3033).rdf
NO ALIAS LIST VCR

3A003A00 (Atlas 5 Day URC-1055 JP1.3 3000 extender).rdf
NO ALIAS LIST VCR

3A333A33 (Atlas 5 Day URC-1055 JP1.3 3033 extender).rdf
NO ALIAS LIST VCR

98009800 (URC-9800 Learning Chip).rdf
NO ALIAS LIST TUNER

EBV0EBV0 (URC-7550_7560-B00 One for All).rdf
NO ALIAS LIST DevType4
NO ALIAS LIST DevType5

EBV0EBV1 (URC-7550_7552_7560_7562 One for All).rdf
NO ALIAS LIST DevType4
NO ALIAS LIST DevType5

EBX0EBV0 (URC-7560_7562 Extender).rdf
NO ALIAS LIST DevType4
NO ALIAS LIST DevType5
NO ALIAS LIST Special

ET80ET80 (URC-8550_5550 Topline Extender v2).rdf
NO ALIAS LIST @AMP
NO ALIAS LIST @TUNER

ET80ET80 (URC-8550_5550 Topline Extender).rdf
NO ALIAS LIST @AMP
NO ALIAS LIST @TUNER

ETPSTPS0 (Force - 2k version).rdf
NO ALIAS LIST xDev

GI97GI97 (Maestro II).rdf
NO ALIAS LIST MUSIC_CH

HT80HT80 (URC-8080_8090-B00 Producer 8).rdf
NO ALIAS LIST TUNER

HT80HT8A (URC-8080_8090-B01 Producer 8).rdf
NO ALIAS LIST TUNER

HT80HT8C (URC-8080_8090-B02 Producer 8).rdf
NO ALIAS LIST TUNER

HT80HT8C (URC-8080_8090-B02 with Time and Extender Support).rdf
NO ALIAS LIST TUNER

HUD0HUD0 (URC-9800_8800_8780 Producer 8 with Extender V1).rdf
NO ALIAS LIST TUNER

HUD0HUD0 (URC-9800_8800_8780 Producer 8 with Extender V2).rdf
NO ALIAS LIST TUNER

HUD0HUD0 (URC-9800_8800_8780 Producer 8).rdf
NO ALIAS LIST TUNER

KASAKAS0 (URC-9960 B01 One For All Kameleon).rdf
NO ALIAS LIST other

KASAKASX (URC-9960 B01 One For All Kameleon Extender).RDF
NO ALIAS LIST other

LF32LAT0 (URC-7650 One for All 5).rdf
NO ALIAS LIST DevType4
NO ALIAS LIST DevType5

OEM3OEM (ReplayTV Version1).rdf
NO ALIAS LIST OEM_Mode

OEM3OEM (ReplayTV Version2).rdf
NO ALIAS LIST OEM_Mode

OEM8OEM0 (Kenwood VR507).rdf
NO ALIAS LIST OEM

OUKAOUK1 (Dreambox V3 URC-39730 B02).rdf
NO ALIAS LIST OEM

RS70RS70 (RS 15-1995 7 in 1 wTime & Extender Support).rdf
NO ALIAS LIST TUNER
NO ALIAS LIST DVD

RS70RS70 (RS 15-1995 7-in-1 with More Memory).rdf
NO ALIAS LIST TUNER
NO ALIAS LIST DVD

RS70RS70 (RS 15-1995 7-in-1).rdf
NO ALIAS LIST TUNER
NO ALIAS LIST DVD

SAKAS0 (URC-9960 BJ5 One For All Kameleon).rdf
NO ALIAS LIST other

NON STANDARD ALIASES


11421142 (URC-8308 Kameleon).rdf
OEM mode

30653065 (URC-1060).rdf
Misc AUdio

31793179 (RCA RCRP05B black).rdf
DVR

BAL0BAL0 (Balboa Dolphin).rdf
OEM

EZP0EZP0 (URC-6540_6541 1K Version).rdf

OEM

OEM4OEM0 (Arcam CR80).rdf
AUX
AMP

OEM4OEM0 (Zap Station).rdf
AUX1
AUX2
AMP

RS00RS00 (RS 15-1935_1934 7-in-1).rdf
Home auto

STANDARD ALIASES

TV
Cable
SAT
Video Acc
VCR
DVD
Tape
Laserdisc
DAT
CD
Tuner
Home Auto
Misc Audio
Phono
Amp
PVR
OEM Mode

10621062 (URC-7780 One For All Stealth 12).rdf
NO ALIAS LIST HT

11311131 (URC-7781 One For All Digital 12).rdf
NO ALIAS LIST HT

HT is not really a device, and it does not show a setup code. It is Home Theater, and is present so that Home Theater can be included in a device slot in these remotes that use Soft Devices. It is governed by a SoftHT entry in the [General] section. I don't think a Device Alias would be appropriate. Its absence doesn't seem to cause a problem in RM or RMIR (and IR.exe doesn't use Device Aliases).

ET80ET80 (URC-8550_5550 Topline Extender v2).rdf
NO ALIAS LIST @AMP
NO ALIAS LIST @TUNER

ET80ET80 (URC-8550_5550 Topline Extender).rdf
NO ALIAS LIST @AMP
NO ALIAS LIST @TUNER

The aliases, I suppose, should be Amp and Tuner - though perhaps that causes a problem, since there are also device types AMP and TUNER that have these aliases. I've had nothing to do with those RDFs, though I have with the unextended RDF. In that, I omitted the @ signs, as much as anything because I don't understand them. They seem to be used to mark buttons and device types that are present on the URC-8550 (which I have) but absent on the URC-5550 (which I don't have). The oddity, to me, about the @AMP and @TUNER device types is that they have the same map and same device index as AMP and TUNER, differing only in the value that is put into the address given by the TypeAddr value in the [DeviceButtons] section. Can anyone enlighten me on what this value at TypeAddr actually does?