ATT VIP1200 - Upgrade file fails to load

[alanrichey]

I'm having a problem with an upgrade file for this box. It uses the Nokia32 protocol so it needs the Protocol upgrade as well.

The user has a very old Slingbox Classic that uses the JU file (only the second one ever that I have dealt with). The upgrade file runs to 166 bytes and I was wondering if that was too large ? I recall during the discussions about the XMP protocol that someone (Rob?) mentioned the maximum size of upgrade file the Slingbox could accept.

I have gone for the absolute minimum number of buttons (numbers, ch+/-, transport and arrows) just to get it this level.

I should add that the associated PL file loads perfectly well on my Slingbox Classic so perhaps the older JU models have a smaller capacity ?

Any thoughts ?

[The Robman]

166 should be small enough to load. I would need to see files in order to help any further.

[alanrichey]

Thanks Rob

RMDU and BIN files at https://www.hifi-remote.com/forums/dload ... le_id=8065

The user tells me that no RV or PL file has ever loaded but he can load other JU files without a problem (although they don't control his device). And he bought the Slingbox in 2005 so that does seem to prove he needs a JU file.

But when he tried to install the C2010_JU.BIN file for this device he got the 'Custom Remote not found' message. And he sent me a screen shot proving the file was in the \SBAV\ folder.

Now I have never had to produce a JU file before so I never got around to updating the RDF file in the same way I did with the PL & RV RDF files so I am using a very old one. So maybe it could be an error in that file ? It would explain why other JU files produce by other people load OK.

Maybe you could produce a JU BIN file from the RMDU and we could test that and compare it with mine ?

Cheers

Al

[The Robman]

What is his IR blaster version (in the Slingbox Properties dialog)? For JU it should be 1.

I don't see anything wrong with your RMDU file or your BIN file.

I notice that the PL version requires a protocol also.

If you really want to eliminate the chance that the upgrade is too big, strip out all buttons except the POWER button and maybe the CH+/- buttons.

If it does turn out that the upgrade is too big (which I'm really not expecting), there's a lot of code in the protocol itself that I could strip out to make it smaller.

[alanrichey]

Yes, his IR Blaster version is 1.

Tried the stripped down version, still won't load at 149 bytes so I guess we can forget that as a problem.

I did notice from the screen shot he sent that all the 'successful' JU BIN files were produced 5 years ago, which still leads me to believe that it connected to changes in the JU RDF file. I'll have a hunt around and see if I can find an old version.

Cheers

Al

[alanrichey]

More information When he said that ALL other JU files loaded without an error I hadn't clicked that all the other codes were below 2000.

Correct me if I am wrong, but if you type in a code such as C0162, Slingplayer will look in the \SBAV\ folder and if it doesn't find the right BIN upgrade file will simply use the built-in C0162. So the ONLY time you get an error is if the code is above 2000 and there is no BIN file.

If that is right, then basically his Slingbox is not seeing the BIN file in the \SBAV\ folder (although he has shown me a Screenshot that proved it is there).

I've suggested he tries a hard reset and then running the setup again. Otherwise he is going to buy a Pro

Al

[The Robman]

The 2000 number is meaningless. The upper code number limit is 2047. If a code is not found, it's not found, regardless of whether the code number is 0000 or 2000 or anything else.

When he says that JU codes have loaded, is he referring to BIN files that he's loaded himself?

[alanrichey]

Actually I think you are wrong (ducks head below barrier just in case )

I just ran the setup routine on my Slingbox, with a completely empty \SBAV\ folder and typed in V0162 as the Alternative code, and there was no error message.

I know 0162 is the DirecTV protocol, so maybe that is built-in ? So it could be that the more common protocols are built-in ? And maybe all the 'below 2000' codes he experimented with are known protocols so were accepted even though there was no BIN file?

Fascinating stuff

Cheers

Al

[alanrichey]

More information : I just accessed his Slingbox remotely with all 3 BIN files (RV, PL & JU) using C2011 in my \SBAV\ folder and using 'Cable', 'Other' and C2011 gives the 'Custom Remote not found'.

So we know he is blameless and the problem lies with his Slingbox and/or the JU file.

I guess his next recourse is a hard reset, but that will sometimes fry the box so I am not going to recommend it

Al

[The Robman]

Wow Al, you're really allowing yourself to mix a decimal setup code with a hexadecimal protocol id? $0162 is the hexadecimal protocol id for DirectTV, it is used by setup codes like SAT/1377 (or S1377 in the Slingbox world). VCR/0162 (or V0162 in the Slingbox world) is a Panasonic VCR code, which I have used myself many times. I don't know what C0162 is (aka CBL/0162) as I've never heard of UEI using 0162 as a cable code. But keep in mind that Sling Media have added many bin files themselves, so they might have added it. And when Sling Media adds BIN files, they don't put them in the SBAV folder anymore, they hide them somewhere else, so you can't see them.

If you want to see how the Slingbox reacts when you try to use a code that is not present, try code 0999 as that's not a UEI setup code and I'm not aware of Sling using it. Try it with any device type (eg, S0999, C0999, V0999, etc).

The 2000 code has no special meaning and it's not a limit. I'm guessing you don't believe me, and that's OK, but it's a fact, so it's my duty to repeat it.

If you create an upgrade that uses the same setup code as a built in setup code, and your upgrade is rejected by the Slingbox it will default back to the built-in setup code. (It works the same way in remotes).

Back to the VIP1200, we've come across this device before:
https://www.hifi-remote.com/forums/viewtopic.php?t=10674

Anyway, I did some research and the only American remote that I can see that has the Nokia32 protocol pre-loaded is the Radio Shack 15-135, where it's used by setup code VIDACC/0858, so then I looked in the manual to see what brand uses that code and it's AT&T, so I suspect that this is the right setup code for this box. The fixed data for this code is "01 23 40 26", which in RM translates to device: 35, sub: 64, X: 38 and High X-bit: Toggle".

Here's my attempt at a JU bin file (called C0858_JU.bin):
https://www.hifi-remote.com/forums/dload ... le_id=8071

[alanrichey]

you're really allowing yourself to mix a decimal setup code with a hexadecimal protocol id? But keep in mind that Sling Media have added many bin files themselves, so they might have added it. And when Sling Media adds BIN files, they don't put them in the SBAV folder anymore, they hide them somewhere else, so you can't see them.

OK, now I am beginning to understand more:-) So I was partially right in that some codes are effectively 'built-in' which explains why he could type in some Alternative Codes and not get an error message. I had just assumed that ALL codes between 0000-1999 had been allocated and were built-in.

In fact since Slingplayer 2.0.3 Slingmedia hold all the remote data centrally on their servers so I guess that is where they have put those BIN files.

The 2000 code has no special meaning and it's not a limit. I'm guessing you don't believe me, and that's OK, but it's a fact, so it's my duty to repeat it.

I believe you It's just that when I was writing the article I got the impression from you (I think) that 0000-1999 where normally used for specific devices and that 2000-2047 where not generally used, particularly by Sling, so we could use them for user-defined Custom Remotes. So I had incorrectly assumed that ALL the codes between 0000-1999 had been defined and where built-in. I didn't realise that only a percentage of them had been built-in.

If you create an upgrade that uses the same setup code as a built in setup code, and your upgrade is rejected by the Slingbox it will default back to the built-in setup code. (It works the same way in remotes).

OK, I thought that was what I said in my post. (acknowledging that I now realise that not all codes are built-in)

The fixed data for this code is "01 23 40 26", which in RM translates to device: 35, sub: 64, X: 38 and High X-bit: Toggle".

That makes sense. I am running another thread on that protocol asking if I should put 166 or 38 in the X= box on RM. I guess that answers the question.

Here's my attempt at a JU bin file (called C0858_JU.bin):
https://www.hifi-remote.com/forums/dload ... le_id=8071

Many thanks. I'll pass it onto the user, although I think he is getting sick of testing now

Cheers

Al

[alanrichey]

Rob

User has confirmed that your file exhibits the same symptom, so I guess we can be confident he has a problem with his Slingbox.

But on the positive side, it's been a useful learning experience for me, so thanks for your help.

Cheers

Al

[The Robman]

I may have recommended that we use 2000 thru 2047 for setup codes that we've created, because at the time UEI hadn't started creating codes over 2000, so 2000 just seemed like a nice logical break for us. My point above was that, apart from any special meaning that we might have given 2000, it has no special meaning as far as the software is concerned.

At some point, Sling started putting all of their bin files into password protected zip files, renamed as .sbav files IIRC. They may have changed again since then.

[alanrichey]

At some point, Sling started putting all of their bin files into password protected zip files, renamed as .sbav files IIRC. They may have changed again since then.

Yes I am sure they have, from V2.0.3. You will see in later versions that there is no \Remote\ sub-folder, the \Skin\ subfolder just has a couple of file sin and the \SBAV\ folder is empty.

I think the logic was that by holding the remote BIN files and skins centrally they dramatically shrunk the size of the download for new versions (true) and it would also allow then to add devices more quickly rather than having to roll them up into major upgrades every few months. Not sure that has worked as we still see a steady stream of requests from people with unsupported boxes.

[The Robman]

I do know that they are actively adding new upgrades all the time because they often seek my help with some of the more tricky protocols, but I can't speak to whether they're responding to corporate clients or customers as I just don't know.