KM - Save device upgrade in RM format

cdhixson · Post by **cdhixson** » Tue Sep 30, 2003 7:47 am

Mark,

You changed the format of the Output worksheet in the newer versions of KM, but you didn't change the UpgradeSAVE_RM code to match these changes. Here are the changes you need to correctly save the code blocks. You could also just drop these code blocks because RM never uses them. Without these changes, the file created by this macro will not load into RM.

Thanks,
Chris

Code: Select all

Dim cell As Range

'device upgrade code
Print #fNum, ""
Print #fNum, "[Device Upgrade Code]"
For Each cell In ThisWorkbook.Worksheets("Output").Range("A6:A10")
    If cell.Value <> "" Then Print #fNum, cell.Value
Next cell

'protocol code
Print #fNum, ""
Print #fNum, "[Protocol Code]"
For Each cell In ThisWorkbook.Worksheets("Output").Range("A12:A14")
    If cell.Value <> "" Then Print #fNum, cell.Value
Next cell

'key move code
Print #fNum, ""
Print #fNum, "[Key Move Code]"
For Each cell In ThisWorkbook.Worksheets("Output").Range("A16:A18")
    If cell.Value <> "" Then Print #fNum, cell.Value
Next cell

Mark Pierson · Post by **Mark Pierson** » Tue Sep 30, 2003 4:10 pm

Thanks for the heads up, Chris. I'll make the changes and upload a new version.

gfb107 · Post by **gfb107** » Tue Sep 30, 2003 4:15 pm

Is this feature still needed, now that RM has the ability to import a KM upgrade file?

cdhixson · Post by **cdhixson** » Wed Oct 01, 2003 6:05 am

I found one thing that this feature can do that you can't with just the KM text files. In the latest KM, Mark changed the name of the Tivo Hacked protocol to Tivo (Advanced). The KM text file version only saves the name of the protocol and not the protocol ID. This text file won't read into RM correctly because the protocols.ini file doesn't have an entry for Tivo (Advanced). The Save as RM file feature saves the protocol ID and RM loads it fine.

gfb107 · Post by **gfb107** » Wed Oct 01, 2003 8:22 am

Bummer. I specifically recreated the protocols using the same names that KM uses, and now he's gone and changed one (maybe more?).
Because there are old device upgrade floating around out there, I can't just change the name RM uses.

I guess I'll enhance RM's import feature to be more forgiving when it can't find an exact match for the protocol, similar to what it does when it can't find an exact match for the remote.

cdhixson · Post by **cdhixson** » Wed Oct 01, 2003 8:47 am

gfb107 wrote:Bummer. I specifically recreated the protocols using the same names that KM uses, and now he's gone and changed one (maybe more?).
Because there are old device upgrade floating around out there, I can't just change the name RM uses.

I guess I'll enhance RM's import feature to be more forgiving when it can't find an exact match for the protocol, similar to what it does when it can't find an exact match for the remote.

I think your idea is a good one. Have you also thought about adding an alternate name section to the protocols.ini entry? Something like this.

[Tivo Hacked]
PID=00 41
AltName="Tivo (Advanced)","Tivo (Yet Another)"

In the future, somebody will probably want to change the name of a protocol, maybe more than once. We need some way to track the name changes. Of course, the protocol ID is the one thing that should never be changed.

gfb107 · Post by **gfb107** » Wed Oct 01, 2003 10:13 am

cdhixson wrote:Have you also thought about adding an alternate name section to the protocols.ini entry? Something like this.

[Tivo Hacked]
PID=00 41
AltName="Tivo (Advanced)","Tivo (Yet Another)"

In the future, somebody will probably want to change the name of a protocol, maybe more than once. We need some way to track the name changes. Of course, the protocol ID is the one thing that should never be changed.

I have though about it. It's probably what I'll have to do.

As far as I can tell, the KM .txt files don't have the PID in them, so I can't use that if there is no matching name. Hopefully I've just missed it and its actually there somewhere.

I don't know how KM manages to find the correct protocol in cases like these.

cdhixson · Post by **cdhixson** » Wed Oct 01, 2003 11:17 am

gfb107 wrote:I have though about it. It's probably what I'll have to do.

As far as I can tell, the KM .txt files don't have the PID in them, so I can't use that if there is no matching name. Hopefully I've just missed it and its actually there somewhere.

I don't know how KM manages to find the correct protocol in cases like these.

The .txt files definitely do not have the PID in them. KM has a hidden worksheet called Old2New that contains the old protocol names and their new names. Here are the ones listed in KM 7.53. The old names are on the left with the new names on the right.

Code: Select all

ReplayTV Hacked             ReplayTV (Advanced)
ReplayTV 1994               ReplayTV (Advanced)
ReplayTV Official           ReplayTV (Official)
NEC Generic                 NEC1
RCA Combo                   RCA Combo (Official)
Panasonic JVC               JVC-48
Tivo Hacked                 Tivo (Advanced)
Tivo Official               Tivo (Official)
Panasonic Combo (Official)  Panasonic Combo

Mark Pierson · Post by **Mark Pierson** » Wed Oct 01, 2003 12:25 pm

gfb107 wrote:Bummer. I specifically recreated the protocols using the same names that KM uses, and now he's gone and changed one (maybe more?).

Blame Rob for all that!

As things have evolved, there's several protocols (and remotes) that have had their "labels" changed. As Chris mentioned, KM can handle it all because of the Old2New sheet. If KM reads an "old" file, it looks for a normal match. If one's not found, it turns to Old2New.

johnsfine · Post by **johnsfine** » Wed Oct 01, 2003 12:46 pm

cdhixson wrote: In the future, somebody will probably want to change the name of a protocol, maybe more than once. We need some way to track the name changes. Of course, the protocol ID is the one thing that should never be changed.

I've alread changed protocol ID's and I think we'll need to again on rare occasion.

I haven't looked at what KM stores when exporting to RM format, but a little more info is generally nice and maybe RM itself should be storing more info (from the selected protocols.ini entry) in the upgrade so things won't be as confused later when an old upgrade is used with a new protocols.ini.

I think a protocols.ini entry should have a way to suggest a replacement protocol (to be used in various cases where that entry isn't appropriate). I also think a protocols.ini entry should have a way to indicate that it is obsolete, which is ONE of the reasons RM would look at its suggested replacement field.

Then we just add some dummy entries for "old" protocol names which suggest the new ones. But the feature is more general and will cover other situations as well.

Post by **The Robman** » Wed Oct 01, 2003 12:52 pm

While the protocol id isn't stored in a nice clean stand alone field, it can be derived from the data. The first byte of the "Upgrade Code" data is the second byte of the protocol id. To get the first byte, you would have to take the setup code hex (eg, the "21 2c" in "Upgrade Code 0 = 21 2C (DVD/0300)" and convert it to binary, the MSB (ie, rightmost bit) is the first byte of the protocol id.

As for why protocol names change, let's stick with the Tivo example. When UEI created the original Tivo protocol they made it use 2-byte variable data, which in turn meant that it didn't support advanced code. So we called this protocol "Tivo Official", we then created our own version that uses 1-byte variable data and called it "Tivo Hacked".

Then, after constant nagging from me, UEI changed the official protocol to use 1-byte variable data. At this point, the old names no longer made sense. So, I wrote to Mark and suggested the he change "Tivo Hacked" to just "Tivo" and "Tivo Official" to "Tivo 2-byte". Both versions would use the "01 11" protocol id rather than the redundant "00 43" id.

The idea being that people with newer remotes that already have the 1-byte protocol installed would not need to install a protocol upgrade each time. People with remotes that have the 2-byte version installed, would have the choice of whether to use a protocol upgrade or not.

Post by **The Robman** » Wed Oct 01, 2003 12:58 pm

OK, here's a follow up on how I think the Tivo protocol is currently implemented in KM.

There doesn't appear to be any support for the 2-byte version anymore (which is no big loss).

If you select "Tivo (Official)" for a remote that has the 2-byte version of the protocol installed, KM will offer up the 1-byte protocol upgrade. If you select this with a remote that does have the 1-byte protocol installed, no protocol upgrade is offered.

The "Tivo (Advanced)" protocol is the old hacked protocol. The only reason you would want to use this is if you have a remote with a FAV/SCAN button and you want to assign a function to that button.

Mark Pierson · Post by **Mark Pierson** » Wed Oct 01, 2003 5:13 pm

cdhixson wrote:The .txt files definitely do not have the PID in them.

The Robman wrote:While the protocol id isn't stored in a nice clean stand alone field, it can be derived from the data. The first byte of the "Upgrade Code" data is the second byte of the protocol id. To get the first byte, you would have to take the setup code hex (eg, the "21 2c" in "Upgrade Code 0 = 21 2C (DVD/0300)" and convert it to binary, the MSB (ie, rightmost bit) is the first byte of the protocol id.

While I could (and maybe should) add the PID to the saved KM txt file, I haven't simply because it wouldn't help any of the existing files out there. That's an important consideration I make anytime I change something in the file format.

My foremost concern with saved KM files is not their ability to feed data to RM, but to maintain backward compatability with prior versions. IMHO, RM needs to overcome these limitations/omitions on it's own, because there's no way all those existing files are going to get updated (what would be the point?). Therefore, Rob's suggestion about decoding the PID from the Upgrade/Protocol data makes a lot of sense.

johnsfine wrote:I think a protocols.ini entry should have a way to suggest a replacement protocol (to be used in various cases where that entry isn't appropriate). I also think a protocols.ini entry should have a way to indicate that it is obsolete, which is ONE of the reasons RM would look at its suggested replacement field.

As for the protocol name changes, I'll try to post them as they occur. That way, John's suggestion about including obsolete ones in the protocol.ini file and/or the above PID issue should do the trick.

gfb107 · Post by **gfb107** » Wed Oct 01, 2003 5:31 pm

I'll definitely add support for an ObsoleteNames attribute to a protocol, and will search through the ObsoloteNames for a match if there is no match using the name from the saved KM file. This would also apply to loading older save RM files.

Storing the protocol definition in the RM saved file is possible, but will come later. I'll have to think about some of the issues it would introduce.

gfb107 · Post by **gfb107** » Thu Oct 02, 2003 8:40 am

The Robman wrote:OK, here's a follow up on how I think the Tivo protocol is currently implemented in KM.

There doesn't appear to be any support for the 2-byte version anymore (which is no big loss).

If you select "Tivo (Official)" for a remote that has the 2-byte version of the protocol installed, KM will offer up the 1-byte protocol upgrade. If you select this with a remote that does have the 1-byte protocol installed, no protocol upgrade is offered.

The "Tivo (Advanced)" protocol is the old hacked protocol. The only reason you would want to use this is if you have a remote with a FAV/SCAN button and you want to assign a function to that button.

I'm going to try to recreate this behavior in RM. I've already coded up the changes for parsing the oldnames from protocols.ini, and searching those if a normal match isn't found.

Now I'm going to update protocols.ini, and I'm not quite clear on what to do. Here's what I'm thinking:

1. Copy the protocol behavior (device parms, cmd parms, protocol code, etc.) from "TiVo Hacked" to "TiVo Official", leaving the PID as 0111.

2. Rename the "TiVo Hacked" protocol to "TiVo (Advanced)", leaving the PID as 0041. Add the line
OldNames=TiVo Hacked
So that old KM and RM upgrade files can still be read.

3. Remove the 0111 PID from the [Protocols] section of the RDFs for remotes that have the 2-byte TiVo protocol. Where can I look in RM to see which remotes have the 2-byte 0111 protocol and which have the 1-byte 0111 protocol? I assume there are no remotes that have the 0041 protocol built in.