Packaging Utility giving error "invalid password"

I am trying to package my application but packaging utility is continuously giving error “invalid password”. I have created many versions of my application with same password. I have also tried to rekey my device by generating a new dev key and then rekeying back to original with an older package file. Rekeying utility and Inspect utility are accepting same password and working fine but not the packaging utility. What can be the issue here?

Sounds as it may be firmware dependent, drop some info on player model#, firmware#, last system update date?

“EnTerr” wrote:
Sounds as it may be firmware dependent, drop some info on player model#, firmware#, last system update date?
Thanks, Here is the info:


Model: 3050X - Roku 2XD
Last updated at: Apr 7
Software Version: version 6.2 build 3321 

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

  • Joel

I am having the same problem and did the reset and still getting the same error message.

Same firmware roku 2

Also on my Roku 3 having the same issue after placing it in developer mode. I have to get this working ASAP!!!

Wondering could this be a firmware issue and should I get my other Player out of storage and try it?

Have you re-keyed your box? You’ll definitely need to do that if your using a different device than the one you used to package the channel originally, or if you’ve generated a new key anytime since then.

I did rekey my box and I switch to another box and still get the message. I am scratching my head and about to pull out a box that was not being used during the last firmware update hoping it does not update when I set it up. If I can prevent my 3rd box from updating I should be ok.

“Beacon333” wrote:
I did rekey my box and I switch to another box and still get the message. I am scratching my head and about to pull out a box that was not being used during the last firmware update hoping it does not update when I set it up. If I can prevent my 3rd box from updating I should be ok.

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”.

As a personal note, this happened to me recently And i just couldn’t figure out what the problem was - I tried to re-key the box and it worked fine with other pkg/password combinations but not the one I needed it too. Eventually It turned out I was using the wrong password. I store them as the title of a file in the project directory so I can easily copy and paste when i need it - and i just got mixed up. I’ve made a bunch of screensavers and they all have to have different dev keys ( Thanks Roku!) and so it was human error. Not saying that this is your problem but as Sherlock might say - “The balance of probability…”

“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.

“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.

“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.

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).

“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…

“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…

“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.

“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.

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.

“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

“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…