Roku Developer Program

[TheEndless]

"squirreltown" wrote:
And good luck preventing the box from updating, you'd have to unplug it every time you stopped using it

Even that wouldn't work. The box checks for updates during boot up, so it would update the next time you plugged it in.

[squirreltown]

"kc8pql" wrote:

"squirreltown" wrote:

And good luck preventing the box from updating, you'd have to unplug it every time you stopped using it...

That won't work either. Checking for and installing updates is part of the boot process. I does it every time the device is powered up.

Well I was just projecting my own situation, and should have said "unplug the ethernet cable" but obviously that won't work if you are on wireless. The main point stands - the Update Zombies are gonna get ya.

[belltown]

If your router has website blocking functionality, you can block access to roku.com from the Roku device that you don't want to update. That should prevent firmware updates (at least it worked for me a while back when I didn't want one of my Rokus to get updated).

[squirreltown]

"belltown" wrote:
If your router has website blocking functionality, you can block access to roku.com from the Roku device that you don't want to update. That should prevent firmware updates (at least it worked for me a while back when I didn't want one of my Rokus to get updated).

Duh! thats a really good idea. I wish Roku would allow devs to turn off firmware updates temporarily. But then, it's not like anyone would be working on an audio app and a firmware update would blow away a long-standing feature like looping.....wait...

[TheEndless]

"squirreltown" wrote:

"belltown" wrote:
If your router has website blocking functionality, you can block access to roku.com from the Roku device that you don't want to update. That should prevent firmware updates (at least it worked for me a while back when I didn't want one of my Rokus to get updated).

Duh! thats a really good idea. I wish Roku would allow devs to turn off firmware updates temporarily. But then, it's not like anyone would be working on an audio app and a firmware update would blow away a long-standing feature like looping.....wait...

In that scenario, wouldn't you want to get the firmware update, so you knew the feature had been borked? Ideally, Roku would give developers access to upcoming firmware releases a few weeks in advance (once it's reached the RC stage), so they could test their channels before such a breaking change was made. That would be beneficial to both parties.... but I think we're veering off topic now...

[squirreltown]

"TheEndless" wrote:

"squirreltown" wrote:

"belltown" wrote:
If your router has website blocking functionality, you can block access to roku.com from the Roku device that you don't want to update. That should prevent firmware updates (at least it worked for me a while back when I didn't want one of my Rokus to get updated).

Duh! thats a really good idea. I wish Roku would allow devs to turn off firmware updates temporarily. But then, it's not like anyone would be working on an audio app and a firmware update would blow away a long-standing feature like looping.....wait...

In that scenario, wouldn't you want to get the firmware update, so you knew the feature had been borked? Ideally, Roku would give developers access to upcoming firmware releases a few weeks in advance (once it's reached the RC stage), so they could test their channels before such a breaking change was made. That would be beneficial to both parties.... but I think we're veering off topic now...

Absolutely - if "Ideally" was in play , but we know it's not. And to answer your question - if the feature was as in my example - looping, then no, I would want to continue on developing as if the Co was aware of their mistake and were going to fix it at the next available increment, which is what I believe to be the case there. If the case were say... fixing roScreen to not show an empty buffer on creation - then I would be most happy to discover that later or read about it here, I don't think anyone is going to complain about actual improvements in the tools we use. I've spent a lot of years building things with computers, and not updating the firmware/software in the middle of a job is as basic a rule as I can think of.

[TheEndless]

"squirreltown" wrote:
I've spent a lot of years building things with computers, and not updating the firmware/software in the middle of a job is as basic a rule as I can think of.

I would argue that that's only true when you have the ability to dictate the version of the firmware your app will be running on. Developing on a platform where you and the end user have control over updates to the OS (e.g., Windows, Mac, iOS, etc.) is different than developing on a platform where you don't (e.g., Roku, FireTV, etc.). If you were to continue developing on an older version of the firmware, that your channel will never run on in production, then you're opening yourself up to a number of issues... not the least of which being the inability to identify problems and/or new features introduced by the new firmware that could potentially save or cost you time fixing and/or implementing.

[Beacon333]

When you say "re-keyed" do you mean you generated a new key with genkey, and then the new password is not accepted? Or do you mean you re-keyed from an old pkg file and password? Because obviously that wouldn't be successful if it did not accept your password. There are a lot of folks here with that Roku model and that firmware so I'm reluctant to believe the firmware is the issue. And good luck preventing the box from updating, you'd have to unplug it every time you stopped using it, and if you forget once - Well you've probably seen "Invasion Of The Body Snatchers".

Done both and got "Success" on the rekey and success on the new "Genkey" I am working on about 20 channels and need to get them in test phase. What would be great is to eliminate the "password" all together in the packaging stage we already have to login to enter that part so why have that second layer in the first place?

Now I do store my passwords in a doc file and will match the information based on the unit. I've cut and pasted and typed and still get the message. Hopefully ROKU Joel will chime in. What would also be nice is a emergency packager program that will allow us to send the tested channel to either a section of the site or on our systems to streamline this process.

[EnTerr]

"Beacon333" wrote:
... Now I do store my passwords in a doc file and will match the information based on the unit. I've cut and pasted and typed and still get the message.

I am a bit fuzzy on this - are these Roku unit generated passwords? Do they contain special characters (non-alphanumerics) and can some of them changed? Things like "straight" quotes being turned in “educated” ones by the text editor. Or maybe server-side stopped accepting some of them

[scorpiontahir02]

"RokuJoel" wrote:
Try resetting the device to factory defaults, relinking it and then enabling developer mode again.

- Joel

Ok, I did reset my device to factory defaults, relinked it and enabled developer mode. Then I rekeyed my device with a previous package and password. It accepted the password and successfully rekeyed. Then I tried to create a new package and again got same error "Invalid Password". Why does it accepts password when rekeying but not accepts when creating package. I am thinking only packaging utility might be broken????? When rekeying utility is working fine...