Roku Developer Program

[ekortright]

We have an app that plays live audio streams, among other things.

Before the upgrade to version 7, one could start the playback and then when the screensaver came on, the sound would continue to play while the screensaver displayed the moving image.

Now, when the screensaver comes on, the app crashes. I can see from the debugger that an event is fired (type roSpringboardScreenEvent; msg.isScreenClosed() returns true). The audio stops playing, there is a lot of flicker (rapid alternation between the screensaver screen and the home screen), and after the screensaver is running if you press a remote button to interrupt the screensaver you can see that we are no longer in the app, but at the home screen.

We have been forced to tell our listeners to disable their screensaver, but we would prefer not to do that to avoid burn-in issues on older screens.

I have tried side-loading the sample "audioapp" after modifying it to use our stream's URL. The screensaver works without any problems and the audio continues to play in that case. The debugger shows no events fired at all as the screensaver comes on.

Is there anything I can try or debug to see what could be causing this behavior on our app? I suspect that the screen close event is actually fired after the app has stopped, so at that point it would be too late to use the debugger to find out what has happened.

This happens on both Roku 2 XS and Roku 3.

Thanks for any help you can give us.

[ekortright]

UPDATE:
=======

I have just found that the screensaver actually crashes our app even when it's not playing anything. I simply opened the app and waited for the screensaver to turn on. When it did, the screen began to flicker (alternating home view and screensaver). After pressing the home button on the remote, the screensaver froze. Pressing another button dismissed the screensaver and showed that the app was no longer running.

I then discovered that the sample "audioapp" also suffers from exactly the same problem:

1. I side-loaded the audioapp sample (without making any modifications to it). After the app started, I left it in the initial screen. Debugger output so far:

------ Running dev 'Audio App' main ------
Entering Main
Saving Cover Art URL: yoyoma
Enter PosterScreen getsel

2. I waited for the screensaver to turn on. At that point, the debugger reported an event:

posterscreen get selection typemsg = roPosterScreenEvent

then the screen flicker began, and the screensaver started. After pressing the home button, the screen saver froze. After pressing another button, I could see that the app had died.

[belltown]

I've noticed some really weird things going on with screensavers and side-loaded channel development with fw7. Just now, for example, I exited out of my side-loaded channel back to the Home screen, then started running the TuneIn Radio channel. After the screen saver had been running for a while, I pressed a remote key to exit the screensaver, then immediately found myself inside my side-loaded channel again, which wasn't even supposed to be running; the TuneIn channel had just disappeared, and I never even went back through the home screen.

On other occasions I've noticed something akin to a split-screen effect when working with a side-loaded channel at about the same time that the screensaver would have kicked in - part of one channel on the top or bottom half of the screen and part of another channel, or the home screen, on the other half. It's been very random, and I haven't yet been able to ascertain the exact conditions under which this happens. These types of effects have not generally been associated with running an audio player, however.

[ekortright]

Unfortunately, this problem is not limited to side-loaded apps, or to live streaming audio.

Our public app, installed from the channel store, also crashes either when playing live streaming audio, audio on demand, or just sitting in the main menu.

Others have reported that other channel store apps also crash just by opening the app and letting it sit in the main menu view until the screensaver turns on.

[ekortright]

OK, I figured out the problem.

Our app is based on the sample audioapp. It turns out that that app includes its own screensaver. The reason that it kills the app when leaving the app in the main menu is that the RunScreensaver() function actually does a return when it can't find any image to display (images are set when the user selects a file/stream to play). I am not sure why a return actually kills the app when the default screensaver is invoked, but in any case you can delete this code to have a default image be selected and allow the app's screensaver to run instead of exiting the app.

Our screensaver was not initializing a file that the screensaver code checks for to make sure the app is running when it is invoked (otherwise it just exits, which again kills the app if it is running).

Anyway, one valuable thing I learned (now I can't remember where I saw this) is that you can debug the screensaver; all you do is connect to the device at port 8087 instead of 8085 (you can connect to both at the same time if you want). I hope this helps some other poor soul out there.