JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Adding Slingbox support to RM
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Mon Aug 15, 2005 7:23 pm    Post subject: Reply with quote

Rob,

We can certainly put something in the RDF to indicate that the remote supports binary upgrade files, and the Java class name of an encrypter/decrypter (endec, like codec) to use when writing/reading files for that remote.

Unfortunately, RM doesn't read all the RDFs ahead of time. It builds a list of supported remotes using just a directory listing, in much the same way IR does. It only reads the RDF for a remote when it has to (when a user changes the selected remote, or when loading a device upgrade). This is done to speed up start up time, and to reduce RM's memory foot print.
So, unless the user has already selected the desired remote before selecting "Import Binary Upgrade...", RM won't know which remote can use that binary file.

What could be done easily, though, is to only enable the "Import Binary Upgrade..." menu item when the currently selected remote has the entry in its RDF that indicates it supports it. It could also filter the list of binary upgrade files to only allow those that match the encryption type.

This would force the user to select the appropriate remote before being able to import the binary upgrade file, especially if tags really end up being a useful way of distinguishing binary upgrades.

Another choice is to use a seperate file that lists the endecs (much like OldRemoteNames.ini we use for mapping KM remote names to RM remote names), and the remotes that use them.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Mon Aug 15, 2005 7:31 pm    Post subject: Reply with quote

John,

You've convinced me that this approach is adequate, and that the "switch and switch back again" scenario isn't one we should be worrying about.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Mon Aug 15, 2005 8:37 pm    Post subject: Reply with quote

Hey Greg,
I think I probably didn't explain what I was getting at clearly enough. I'm not suggesting that there be a Bin=Yes type indicator in the RDFs, which would indeed require that RM read all the RDFs in advance.

I was suggesting that the name of the RDF should indicate that it's for bin files and the name should also tell you which ones.

The names could be something like...

BINJU (RDF for the UEI JU chip).rdf
BINPL (RDF for the UEI PL chip).rdf

I this is the naming convention that we agree on, when importing a binary file, RM would look for RDFs that begin with "BIN", then it would use the suffix of the file name to select the right RDF. If it can't find an exact match, it could present a list of all the BIN RDFs.

If we wanted to customize an RDF for a given device, we could just change the part in the parens, or maybe add a suffix to the "sig" part, eg...

BINJU (RDF for the UEI JU chip).rdf
BINJU (RDF for the Slingbox).rdf
BINJU01 (RDF for some other device).rdf

In this case, if the user were to import a JU bin file, RM could present them with the choice of the 3 RDFs.

With the RDFs setup like that, we could include an entry in the RDF that states whether the data is encrypted and what encryption is used.

Back to business, I just tried the latest build of RM and it seems to be working just fine.

Btw, I noticed that everytime when I imported a file, I had to keep changing the Windows folder back to the one where I keep the bin files as it kept defaulting to the last folder that I'd opened an RMDU file from. So I copied an RMDU file over to my bin folder and opened it, then whenever I would import a bin file it would default to the right folder. So, would it be possible to have the default directory updated when you import a bin file? Does RM keep track of more than one default directory? (ie, could it remember where you get your bin files from and where you get your RMDU files from) ?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Mon Aug 15, 2005 10:25 pm    Post subject: Reply with quote

Oh. I get it now.

I don't have any specific problems with using the remote signature to encode the support for binary files, but I can't say I really like it.

I preferred using an RDF entry to enable the import and export or binary files once the user has selected the correct RDF. And, since RM remembers the RDF last used, the user might only have to select that RDF once.

But I don't have really strong feelings about it.

Am I correct in assuming that a given chip uses only one type of encryption?
So all devices that use the JU chip could share the same JU RDF and the same set of JU binary upgrade files?

RM keeps track of 2 paths: The RDF path, and the (RM) device upgrade path. I can add the binary upgrade path easily enough. I've considered adding a path for KM upgrade files as well.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Mon Aug 15, 2005 10:37 pm    Post subject: Reply with quote

gfb107 wrote:
I preferred using an RDF entry to enable the import and export or binary files once the user has selected the correct RDF. And, since RM remembers the RDF last used, the user might only have to select that RDF once.

But why force the user to make a selection where RM has all the info it needs to make the selection for them? Also, if we move the encryption indicator into the RDF, and a Slingbox user were to randomly select JU and PL upgrade files, RM would need to know when to switch RDFs.

All devices that have the "JU" chip (for example) have exactly the same chip, so for our purposes "JU" is in fact the signature of this chip, the only difference is that the sig is encoded in the file name rather than being stored in an EEPROM. However, any other devices that use this chip may be set up a little differently than how the Slingbox is set up (ie, the buttons on the virtual remote may have different names, etc). It's kinda like how 2 different remotes can have the same chip inside but look different on the outside. So, we may find it necessary in the future to create 2 different RDFs for the same chip because the devices that use them are sufficiently different to warrant it.

So, if we're in agreement that we can follow this approach, can we agree on a naming standard? My suggestion is to use the naming standard I outlined earlier, but if you have an alternative suggestion, it's fine with me.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Mon Aug 15, 2005 11:03 pm    Post subject: Reply with quote

The Robman wrote:
Also, if we move the encryption indicator into the RDF, and a Slingbox user were to randomly select JU and PL upgrade files, RM would need to know when to switch RDFs.
I was only going to let the user choose from the JU files, 'cause that's the only kind supported by the selected remote.
Quote:
So, if we're in agreement that we can follow this approach, can we agree on a naming standard? My suggestion is to use the naming standard I outlined earlier, but if you have an alternative suggestion, it's fine with me.

I don't see the point of adding a suffix to the signature part of the file name, so let's just stick with:

BINee (name).RDF

Where
  • ee is the encryption type, which we may prefer to call the chip designator. The currently valid values are JU and PL.
  • name is a descriptive name for the device or chip.


When exporting a bnary upgrade, I intend to force the proper file name. So if a BINJU RDF was used to create the upgrade, exporting to binary would create/overwrite a *_JU.bin file.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Aug 16, 2005 6:51 am    Post subject: Reply with quote

gfb107 wrote:
The Robman wrote:
Also, if we move the encryption indicator into the RDF, and a Slingbox user were to randomly select JU and PL upgrade files, RM would need to know when to switch RDFs.
I was only going to let the user choose from the JU files, 'cause that's the only kind supported by the selected remote.

But can we say that, moving forward, we are not requiring the user to first select a remote and that RM will select the correct RDF based on the suffix of the file name?

gfb107 wrote:
The Robman wrote:
So, if we're in agreement that we can follow this approach, can we agree on a naming standard? My suggestion is to use the naming standard I outlined earlier, but if you have an alternative suggestion, it's fine with me.

I don't see the point of adding a suffix to the signature part of the file name, so let's just stick with:

BINee (name).RDF

Where
  • ee is the encryption type, which we may prefer to call the chip designator. The currently valid values are JU and PL.
  • name is a descriptive name for the device or chip.


When exporting a bnary upgrade, I intend to force the proper file name. So if a BINJU RDF was used to create the upgrade, exporting to binary would create/overwrite a *_JU.bin file.

In this case, "ee" isn't the encryption type, but is in fact the "signature" or "tag" used to designate which version of the chip is being used. I'm betting that the "PL" version is the first version that uses encryption, so if we eventually discover devices that use older versions of the chip, they will need different RDFs but they won't use any encryption.

If we setup the RDFs like this, I would really like to move the encryption indicator into the RDF, so that when the next chip is discovered, I can handle everything just by creating an RDF without needing to ask for an RM change, unless a different encryption is used of course! Smile

To that end, if you think you can come up with a syntax where the encryption formula itself can also be in the RDF, that would be even better, but it's not thatimportant.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Wed Aug 17, 2005 9:34 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Tue Aug 16, 2005 8:06 am    Post subject: Reply with quote

I think inventing a syntax for the encryption formula is more than I want to take on.

I think we can just add a line to the RDF that names a Java class that is used to encrypt/decrypt. I'll set up a base class that defines the methods the encrypter/decrypter (encdec) will have to implement, and then one of us can simply write a new encdec whenever a new encryption type is discovered. I'll write the encdecs which anyone can use as a reference when writing a new one. Here's what I expect the PL encdec to look like (so you can see it isn't very complicated):
Code:
package com.hifiremote.jp1;

public class PLEncrypterDecrypter
  implements EncrypterDecrypter
{
  public int encrypt( int val )
  {
    int val1 = ( val >> 2 | val << 6 ) + 111;
    val1 &= 0x00FF;

    int val2 = ( val & 0x80 ) & ( val << 7 );
    int rc = ( val1 ^ val2 );
    return rc;
  }

  public int decrypt( int val )
  {
    int val1 = ( val + 145 ) & 0x00FF;
    int mask = ( val1 << 1 ) & ( val1 << 2 ) & 0x80;
    int val2 = val1 ^ mask;
    return ( val2 << 2 | val2 >> 6 ) & 0xFF;
  }
}


Once that's been done, it's just a matter of compiling it and adding it to the .jar file, or distributing the generated .class file.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Tue Aug 16, 2005 11:09 am    Post subject: Reply with quote

OK, Rob,

I've added code for determining binary upgrade support from the RDF signature, and for determining the encryption from a new entry in the RDF.
I've also added support for exporting to a binary upgrade file.

Here's what you need to try it out:
RemoteMaster.jar
BINJU (Slingbox with UEI JU Chip).rdf
BINPL (Slingbox with UEI PL Chip).rdf
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)


Last edited by gfb107 on Sun Aug 28, 2005 8:04 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Aug 16, 2005 12:17 pm    Post subject: Reply with quote

Thanks Greg, I'll test these when I get home.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Aug 16, 2005 8:38 pm    Post subject: Reply with quote

Hey Greg, I gave it a quick spin and it looks good (it remembered the bin folder, nice).

I notice that you've added the Export function already, so what are the parameters for making this work? I notice that if I open a regular RMDU upgrade file, the export option is disabled. If I import a JU file, it will only let me export a JU file, and likewise with for the PL files. Is this intentional?

The main purpose of the export function is to allow people to reformat existing KM and RM upgrade files and then save them as binary files. A secondary purpose might also be to edit JU files and then save them as PL files (or vice versa).

You could also default the file name for the user too, as they might not know the format. As you may have already noticed, the first letter of the file name tells you the device type. The chart is as follows:

T = TV
C = Cable
N = Video Accessory
S = Sat
V = VCR
L = Laser Disk
Y = DVD
R = Receiver
AM = Amp
D = CD
H = Home Auto
K = Cassette / Tape

While I certainly don't want to force the user to save the bin files using the correct name, if they want the bin file to work with their Slingbox, they will have to use the right name, so pre-formatting it for them would certainly be a good idea.

Also, just FYI, that list above does correctly describe the full list of device types supported by the chip (and in that order). I have keymaps for these now that I still need to add to the RDFs.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Thu May 04, 2006 8:16 pm; edited 2 times in total
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Tue Aug 16, 2005 9:09 pm    Post subject: Reply with quote

In order to export to binary, the currently selected remote must support binary upgrade files (i.e. the signature part of the RDF name must start with "BIN"). It will only allow saving that upgrade using the encryption supported by that remote. Otherwise your users could load an .rmdu file for a URC-6131, and immediately click export to binary and end up with a binary file that isn't compatible.

So the format for the default name is <device type abbreviation><setup code>_<chip tag>.bin

Can we stick these abbreviations in the RDF too?
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Aug 16, 2005 9:59 pm    Post subject: Reply with quote

gfb107 wrote:
In order to export to binary, the currently selected remote must support binary upgrade files (i.e. the signature part of the RDF name must start with "BIN"). It will only allow saving that upgrade using the encryption supported by that remote. Otherwise your users could load an .rmdu file for a URC-6131, and immediately click export to binary and end up with a binary file that isn't compatible.

Oh I get it, I should have changed the selected remote first, duh!

gfb107 wrote:
So the format for the default name is <device type abbreviation><setup code>_<chip tag>.bin

Yup.

gfb107 wrote:
Can we stick these abbreviations in the RDF too?

I don't think there's any need. The letters used for the device types are standard across the board. The RDF tells you which device types are supported, so when RM converts the selected device type into the appropiate device type for the selected remote, it can also look up the correct letter. (I know these names are standard because whenever someone at UEI sends me a list of advanced codes, those letters are used in the file names).
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Tue Aug 16, 2005 10:34 pm    Post subject: Reply with quote

The Robman wrote:
gfb107 wrote:
Can we stick these abbreviations in the RDF too?

I don't think there's any need. The letters used for the device types are standard across the board. The RDF tells you which device types are supported, so when RM converts the selected device type into the appropiate device type for the selected remote, it can also look up the correct letter. (I know these names are standard because whenever someone at UEI sends me a list of advanced codes, those letters are used in the file names).

Yes, but the standard device type names (and aliases) aren't hard coded in RM. They're read from the RDFs. RM has no builtin idea of what a "VCR" device type is. It just reads the name from the RDF and associates it with the appropriate keymap and device index number.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Wed Aug 17, 2005 7:28 am    Post subject: Reply with quote

Okee Dokee. I suppose the [DeviceTypeAliases] section would make the most sense as this is an RM-only section, but as long as it gts added in a way that doesn't affect IR, I don't really mind how it gets added. What do you think is the best way to add it?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
Page 3 of 10

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control