I have run into a problem. I have developed a private channel that requires a instr() function to locate a string position that is the start point of extraction for a url. I can run the channel on a Roku2 Model 3050X and the position located in the file works perfect. The Instr() locates the position, a mid() is used to cut the string perfectly. I then load the same channel to another Roku2 Model 3050X. When executed, the channel does not play. I review the debug terminal during play and see that the Instr() position is off by 4 places. On the working roku the string position is 225. On the roku that doesn’t work the string position is 221. The file being search is created during run time. I also have another 2 Roku2 and 1 Roku3 which places the script as originally designed. How and why would the one Roku be off by the 4 places?
They’re all on the same firmware, right?
Yes same software version and build.
I would bet a large amount of money that you’re just mistaken about what’s happening. I’m sure you’re using different strings on the two units with different behavior. Try printing all the strings involved, and if you still don’t see the problem, post your code and the debug information.
–Mark
Nope same string. I can run the script on the roku the script was designed on and it picks the correct location. I run the exact same script on another and where the instr occurs is 4 places short. I can change the instr start location by 4, run the script and it works. I have checked this several times. The length of the file and location of a particular phrase always occurs at the same location.
“btpoole” wrote:
Nope same string. I can run the script on the roku the script was designed on and it picks the correct location. I run the exact same script on another and where the instr occurs is 4 places short. I can change the instr start location by 4, run the script and it works. I have checked this several times. The length of the file and location of a particular phrase always occurs at the same location.
Are you reading the file from the same location on both boxes? Is it packaged with the channel, or are you reading it from a web server? If it’s packaged with the channel, are you side-loading the exact same zip or are you building it new for each box?
What you’re describing doesn’t make sense for two virtually identical boxes, and it’s not something I’ve ever seen in nearly five years of developing on this platform (with the exception of how unicode strings are handled in 3.x vs. 5.x firmware), so there’s definitely something amiss.
I certainly won’t figure something out that Endless and Mark haven’t but just thought I’d mention registry settings. It’s the one thing I can think of that will make two “identical” boxes act differently.
“squirreltown” wrote:
I certainly won’t figure something out that Endless and Mark haven’t but just thought I’d mention registry settings. It’s the one thing I can think of that will make two “identical” boxes act differently.
Very good point, squirreltown. To elaborate, if your channel is relying on data stored in the registry, then you’d need to ensure that data is identical (and present) on both boxes. It doesn’t sound likely that that’s the case here, but it’s definitely worth noting.
“squirreltown” wrote:
I certainly won’t figure something out that Endless and Mark haven’t but just thought I’d mention registry settings. It’s the one thing I can think of that will make two “identical” boxes act differently.
Oh hello squirreltown, welcome back!
Interesting idea about registry. In addition i would suspect network settings: are both players on the same LAN segment, have about the same IPs, DNS, names… anything that can be different between the two. Hard to be specific since we don’t know what exactly he is doing but to quote the classics, “when you have eliminated the impossible, whatever remains - however improbable - must be the truth”
@btpoole - there IS a difference between the two players that causes this, try to find it. If they have the same hardware and firmware, it’s not that. But maybe you uploaded different version of the bundle; “touch” (modify) the zip to bump the timestamp and re-upload on both places, test again. Or you are parsing xml that changes from player to player. Find the difference. And let us know 
I’ll give an up date to the situation. Doing some more looking into problem. The bundle is the same for each. The file being cut is a text file that is obtained thru GetToFile command, saved as a temp then read. I am looking into something else that could have a bearing on the results.
Ok update. Boxes same, same firmware. Same package on all boxes. I run the package on a box getting service from Comcast script does not execute. Change the box to get service from wireless hotspot or a dsl provider and package runs. As stated earlier, I can change the Instr point from 225 to 221 and it will run on the Comcast connection. The script was developed using a dsl connection and works with the wireless hotspot connection also. Would the Comcast connection be altering the return of the GetToFile in some way?
Thanks
It kind of sounds like it’s getting modified somehow. I assume you’ve tried to print out the file, or at least the start of it? If it could be some kind of non-printable stuff, I’d read the file in to a byte array and print out the first several bytes to see if you can figure out what’s getting added/modified by the Comcast connection. Something like:
ba = CreateObject("roByteArray")
ba.ReadFile("tmp:/myfile")
for i = 0 to 10
print ba[i]
end for
For what it’s worth, you’d probably be better off using a regular expression to extract the URL. It would be more flexible and wouldn’t depend on some fixed offset.
-JT
