JP1 Remotes

Nothing special about that pause. You can get rid of it.

Ah, but what are you doing about the Pause that came with the RCA remote? That one has a different PID because UEI has claimed the standard pause pid as their own. Imagine that!

vickyg2003 wrote:Ah, but what are you doing about the Pause that came with the RCA remote? That one has a different PID because UEI has claimed the standard pause pid as their own. Imagine that!

I wish they would stop doing that! Really those just need to into the special protocols area...

xnappo

alanrichey wrote:I see the sourceforge site still has the original versions of the Slingbox RDF files. These are a bit buggy and not designed properly for RM.

My revised versions (along with an updated image), which have now been proven over the last 6 months, are at https://www.hifi-remote.com/forums/dload ... le_id=7201

Al

Al,

I updated these - however I am assuming the protocol.ini updates are in sourceforge already. If not we can get that done too - just let me know.

Also - since you seem up on the SlingBox stuff - I would greatly appreciate it if you could look at the SlingBox RDFs in the RDF Development section and let me know what should be merged for the next release and what is junk...

Thanks!
xnappo

xnappo

xnappo wrote:I updated these - however I am assuming the protocol.ini updates are in sourceforge already. If not we can get that done too - just let me know.

Not sure about that, I was only ever a tester for the new entries I don't have the understanding to produce protocols. But compared with all the copies of PROTOCOLS.INI I can find, mine has working and proven versions of XMP(Slingbox) and TDK. I think you need to confirm this with the experts who built the protocols.

xnappo wrote:Also - since you seem up on the SlingBox stuff - I would greatly appreciate it if you could look at the SlingBox RDFs in the RDF Development section and let me know what should be merged for the next release and what is junk...

I can certainly put my newest versions into the RDF Development area, as long as 'binky123', who uploaded the present versions in 2007 has no objection?

Later: Sorry, just figured out what has been done in the RDF Files area. Now that the revised RDFs have been added to the 'Ready for next Release' area you/I can delete all of the Slingbox RDF files in the Development area as they are not relevant any more.

alanrichey wrote: Later: Sorry, just figured out what has been done in the RDF Files area. Now that the revised RDFs have been added to the 'Ready for next Release' area you/I can delete all of the Slingbox RDF files in the Development area as they are not relevant any more.

Thanks Alan.

xnappo

Okay guys,

Time for the beta testing to begin!

First thanks SO MUCH to Vicky for helping me get up to speed on what needed to be done, and for her great tool to update the RDFs. She really did all the heavy lifting here.

So, here are three areas to check out the new RDFs:

RDFs merged from Development area:
http://controlremote.svn.sourceforge.ne ... _20100504/

RDFs merged from Development with updated protocols sections:
http://controlremote.svn.sourceforge.ne ... _20100504/

RDFs merged from Development with updated protocols and setup sections:
http://controlremote.svn.sourceforge.ne ... _20100504/

Please try the last one first, and let me know if you run in to any problems.

Thanks!
xnappo

So each rdf has to be downloaded individually? Is there not a zip containing all of them? Or a way to "select" multiple rdf's for download?

Although I am confident that the CONTENT of the rdf's is improved, I'm not sure that downloading them one at a time is a great improvement.

Or am I missing something obvious?

EDIT: I figured out that a "tarball" was a zip file of sorts. Sheesh! Anybody teach these SourceForge folks about clarity of communication?

Capn Trips wrote: Or am I missing something obvious?

EDIT: I figured out that a "tarball" was a zip file of sorts. Sheesh! Anybody teach these SourceForge folks about clarity of communication?

Sorry guys, I didn't think people had that many remotes to test! I can certainly make a zip of each if you want to look at a bunch of them.

But yeah,you should also be able to use the 'Download GNU Tarball' link - but if that is any issue just let me know.

xnappo

xnappo wrote:Sorry guys, I didn't think people had that many remotes to test!

It's not a question of how many remotes we have, its that we need to read .ir files from many remotes, as users with problems often need to provide the .ir file that is causing problems. The only safe thing is to have a complete set of the latest RDFs.

But yeah,you should also be able to use the 'Download GNU Tarball' link - but if that is any issue just let me know.

I call that an issue! We tell users that all compressed uploads must be zip files, not other compression methods. Please can we keep to our own rule for downloads. Also, I don't want to have to learn Linux-based techniques such as Tarball (it is from the Unix/Linux world, is it not?). This is part of the reason I was apprehensive about Subversion and the whole move to SourceForge.
_______________
Graham

mathdon wrote: I was apprehensive about Subversion and the whole move to SourceForge.
_______________
Graham

Guys,

As I said before, when I release the RDFs it will be just as it has been in the past - there will be a zip file to download!

My intention for the beta test was for people to download RDFs for remotes that they owned to test them, so I did not think a zip file was needed.

I can generate one if you want. I will say though that almost all zip tools can open .tar.gz files.

Thanks,
xnappo

xnappo wrote:I will say though that almost all zip tools can open .tar.gz files.

While that may be true for after-market tools like 7zip and WinRar, etc the tools that most people have on their PCs (ie, WinZip or Windows Explorer) will only process zip files. Given that all of the after market tools have the ability to create zip files, there's really no need to complicate matters by using non-zip compressions for our files.

Perhaps you could create a zip of the beta RDFs and save it either in SF or here in our file section.

Another way to get all the RDFs at once is to use TortoiseSVN to checkout folder. You don't even have to unzip. Then just point IR/RM to the right folder.

Obviously this would not be the normal process for a release, but it is the process RDF/MAP developers would use, and is a good test case for checking the instructions provided.

The URL to use for checkout of RDFs merged from Development with updated protocols and setup sections:
https://controlremote.svn.sourceforge.n ... e_20100504

The Robman wrote: Perhaps you could create a zip of the beta RDFs and save it either in SF or here in our file section.

Sure, I will do that tonight - not a big deal. Again I didn't think people would want to beta test more than a couple.

Though.. WinZip does work with .tar.gz files. Windows Explorer does not.

Thanks,
xnappo

Though WinZip technically supports tar/gz files, the WinZip install defaults make it unusable for anything but text files due to the "smart" cr/lf translation imposed on ALL files, even binary. The option to turn that off, is not that easy to find. I work in a mixed Windows/Unix shop and we finally had to ban WinZip because stupid users couldn't follow directions and kept corrupting binary files extracted from tar/gz.

A.A.