Roku Developer Program

[EnTerr]

Dear Development Application Installer at port 80,
I have to get this off my chest: I hate your passive-aggressive guts, when uploading a bundle and seeing your smug nuh-uh
"Application Received: Identical to previous version -- not replacing."

It does not help how fickle (or fecal) Roku dev environment is. Last few days i had to hard-restart the player innumerable times because it will wedge itself in catatonic stupor during bundle uploading and mumble "Install timeout. Results unknown.". Which looks like this: player will not respond to physical remote, ECP half-works (returns channel list, confirms keypresses but they do nothing, can't launch anything); reboot watchdog never kicks in nor do Konami codes work. And after power-cycling the player and waiting to load, you give me attitude?!

DevInstaller: I don't care if the zip is identical or not - and even less do i care about your snarky remark. Don't question my reasons, how about you just do it? I am asking you to replace the existing bundle and start the app - and you should do just that, costs you 0.0000005 kWh tops (less than 1/1,000,000 of 5 cents; which i will pay). You've got the brawn, I've got the brains - let's make lots of money?
People should think - machines should work

[TheEndless]

"EnTerr" wrote:
Dear Development Application Installer at port 80,
I have to get this off my chest: I hate your passive-aggressive guts, when uploading a bundle and seeing your smug nuh-uh
"Application Received: Identical to previous version -- not replacing."

It does not help how fickle (or fecal) Roku dev environment is. Last few days i had to hard-restart the player multiple times because it will "wedge" itself in catatonic stupor during bundle uploading and mumble "Install timeout. Results unknown.". Which looks like this: player will not respond to physical remote, ECP half-works (returns channel list, confirms keypresses but they do nothing, can't launch anything); reboot watchdog never kicks in nor do Konami codes work. And after power-cycling the player and waiting to load, you give me attitude?!

I don't care if the zip is identical or not - and even less do i care about your snarky remark. Don't question my reasons. I am asking you to replace the existing bundle and start the app - and you should do just that. You've got the brawn, I've got the brains - let's make lots of money? People should think - machines should work

That's actually come in quite handy for me on numerous occasions. The first time you package and install a "new" build without realizing you didn't save one of the source files, you'll thank Roku for saving you the frustrating 30 minutes you'd otherwise be spending fruitlessly trying to track down why the fix you just implemented didn't correct the behavior you were seeing. By telling you it's identical, you know you haven't made any changes to it, so you'll know that any fix you might have implemented didn't make it into the build you're about to test.

If it really bugs you, you could always add a "/launch/dev" curl command to the end of the makefile to force it to launch regardless.

As for your box wedging, it's very rare that I see that during normal development/testing. My Roku 3 will respond (or not respond, rather) to ECP that way for the first 30 seconds or so after a reboot, but I don't recall ever running into that at any other times. Is it possible your Roku is losing its network connection intermittently?

[EnTerr]

"TheEndless" wrote:
The first time you package and install a "new" build without realizing you didn't save one of the source files, you'll thank Roku for saving you the frustrating 30 minutes you'd otherwise be spending fruitlessly trying to track down why the fix you just implemented didn't correct the behavior you were seeing. By telling you it's identical, you know you haven't made any changes to it, so you'll know that any fix you might have implemented didn't make it into the build you're about to test.

Not really: No point in thanking Roku nor other deity, since Zip already tells me that ("Archive is current"; i run it with -FS, 'tis faster too).
And if it really bugs you, you can always add "diff" in your makefile, no?

I would not mind DevInstaller bitching if it did install and run the bundle nevertheless. No harm in doing that, is there?!

"TheEndless" wrote:
As for your box wedging, it's very rare that I see that during normal development/testing. My Roku 3 will respond (or not respond, rather) to ECP that way for the first 30 seconds or so after a reboot, but I don't recall ever running into that at any other times. Is it possible your Roku is losing its network connection intermittently?

I assure you, the wedging happens very reliably and i was not doing abominable things. As we speak, Roku stays wedged:

• roScreen frozen on screen


• does not respond to PHYSICAL remote (BT, IR) in any way


• Installer repeatedly (subject to tickling the zip) says "Application Received: 167656 bytes stored. Install timeout. Results unknown.". PS. here is curious tid-bit: it alternates between 30sec and 0.5sec delay (i.e. every other time) before returning the install timeout message


• ECP "kinda" works, as i described above but cannot un-wedge the player. Well maybe it could have, if Konami codes were allowed in ECP (which they aren't)


• Network connection is fine. IMO what you have observed in your reboots is working network but no event loop

[TheEndless]

"EnTerr" wrote:
I assure you, the wedging happens very reliably and i was not doing abominable things. As we speak, Roku stays wedged:

• roScreen frozen on screen


• does not respond to PHYSICAL remote (BT, IR) in any way


• Installer repeatedly (subject to tickling the zip) says "Application Received: 167656 bytes stored. Install timeout. Results unknown.". PS. here is curious tid-bit: it alternates between 30sec and 0.5sec delay (i.e. every other time) before returning the install timeout message


• ECP "kinda" works, as i described above but cannot un-wedge the player. Well maybe it could have, if Konami codes were allowed in ECP (which they aren't)


• Network connection is fine. IMO what you have observed in your reboots is working network but no event loop

I can't recall ever having seen the behavior you're describing, and I'm developing on my Roku darn near 24 hours a day. What model Roku are you seeing this on?
You say "roScreen frozen on screen". Any chance you've overrun the available video/bitmap memory? The box can behave very strangely and unpredictably when that happens. Have you tried telnetting into port 8080 and looking at the results of r2d2_bitmaps to see how much memory is used/available when this happens?

[EnTerr]

"TheEndless" wrote:
I can't recall ever having seen the behavior you're describing, and I'm developing on my Roku darn near 24 hours a day. What model Roku are you seeing this on?
You say "roScreen frozen on screen". Any chance you've overrun the available video/bitmap memory? The box can behave very strangely and unpredictably when that happens. Have you tried telnetting into port 8080 and looking at the results of r2d2_bitmaps to see how much memory is used/available when this happens?

Oh come on, you know one not experiencing an issue does not mean it does not exist 😛
Box is 3100 with 5.4.3182
The code is slightly modified version of SDKs "SimpleAnimatedSprite" , which i use as test bed for historical reasons. There should be no problem with memory, all it does is turn small image at leisurely pace of 1 FPS and i even added sleep(1000) to avoid pointless loopiness.
What is r2d2_bitmaps? I saw someone mention it here and then RokuJoel gagged them as "NDA".
I just tried from clean reboot - all i need to do is while dev channel is running to initiate dev.installer upload and it hangs reliably. But that also happens when i have it interrupted to console.

[RokuMarkn]

Can you post the complete code that causes this, or PM it to me?

--Mark

[EnTerr]

"RokuMarkn" wrote:
Can you post the complete code that causes this, or PM it to me?

Certainly: http://sourceforge.net/projects/rokusdk ... Sprite.zip
For a clean-room experiment, just now i: re-downloaded the example, unzipped in a folder and w/o modifying it, zip/deployed to roku - saw it working - then re-deployed. Player wedged on cue.

PS. my deploy script is not fancy

[TheEndless]

"EnTerr" wrote:

"TheEndless" wrote:
I can't recall ever having seen the behavior you're describing, and I'm developing on my Roku darn near 24 hours a day. What model Roku are you seeing this on?
You say "roScreen frozen on screen". Any chance you've overrun the available video/bitmap memory? The box can behave very strangely and unpredictably when that happens. Have you tried telnetting into port 8080 and looking at the results of r2d2_bitmaps to see how much memory is used/available when this happens?

Oh come on, you know one not experiencing an issue does not mean it does not exist 😛
Box is 3100 with 5.4.3182

I didn't say a problem didn't exist. Obviously it does, but I'd have expected to have run across it at least once, but that "Install timeout" message is completely new to me. I've had curl timeout communicated with the box, but never seen it timeout after it received the app. Weird.

"EnTerr" wrote:
What is r2d2_bitmaps? I saw someone mention it here and then RokuJoel gagged them as "NDA".

I don't think it's an NDA thing. I found out about it on these forums, and a search for it returns a number of posts referencing it that are still around. Joel's welcome to gag me if I'm wrong.. :? It basically dumps a list of everything currently consuming graphics memory along with a used/available total at the end. Extremely useful for troubleshooting 2d API development issues.

"EnTerr" wrote:
I just tried from clean reboot - all i need to do is while dev channel is running to initiate dev.installer upload and it hangs reliably. But that also happens when i have it interrupted to console.

Sounds like you're on a beta firmware (5.4 hasn't been released, yet), so it could be related to that. Did it just recently start happening, or has it always happened with that particular dev channel?

[squirreltown]

"Install timeout. Results unknown.".

I've seen this message. 3100 5.3 3063. I can't give an exact description because i never paid much mind to it. Every type of digital box I've ever used has hung and crashed at one time or another, but in general after working for some number of hours repeatedly side-loading a project the box will hang, ( no response to remote) usually i don't notice and am not paying attention to it until I actually hit the upload button ( I do it manually, no makefile stuff) and then you get that message. In my case I know that the box will reboot in a minute and it does. The pkg always seems to go through and get side-loaded though because its there on the reboot.

[EnTerr]

"TheEndless" wrote:
It basically dumps a list of everything currently consuming graphics memory along with a used/available total at the end. Extremely useful for troubleshooting 2d API development issues. ... Did it just recently start happening, or has it always happened with that particular dev channel?

It has happened months ago too but i cannot quantify it, i did not get annoyed as much (maybe because i did not use Dev.Installer often). Since i reproduced it with the SourceForge example, perhaps you can replay it? Telnet 8080 is also alive, this coma is amazing:

>r2d2_bitmaps
RoGraphics instance 0x2ee696c1
address    width height bpp     size name
Available memory 38000000 used 0 max 38000000
RoGraphics instance 0x4c6e3ac1
address    width height bpp     size name
0x70b9d511    64     64   4    16384 
Available memory 37983616 used 16384 max 38000000