Roku Developer Program

[Biggytv]

I have an audio applications that waits to update roImageCanvas with a Push until the audio is playing.

On my debug screen, I can see that msg.GetIndex reaches 100 (I am dividing by 10), but the progress indicator gets stuck at 75% so the roImageCanvas push is never triggered. I am reusing code that has been post it before, so I don't understand why it is stuck.

The stream is from StreamOn and it starts to play and triggers a "start to play" roAudioPlayer event.

This inside an EventLoop.

        msg = wait(0, m.port)
        if msg <> invalid
            'If this is a startup progress status message, record progress
            'and update the UI accordingly:
            if msg.isStatusMessage() and msg.GetMessage() = "startup progress"
                m.paused = false
                progress% = msg.GetIndex() / 10
                if m.progress <> progress%
                    m.progress = progress%
                    m.paint()
                end if

I then check to see the value of m.progress and if it is less than 94 I can continue to show the loading screen. The problem is at while msg.GetIndex reaches 100 (again I am dividing by 10) m.progress never does so the addition code is not triggers.

    if m.progress < 95
        list.Push({
            Color: "#000000"
            TargetRect: { x: 75, y: 475, w: 200, h: 100 }
        })
        list.Push({
            Text: "Loading..." + m.progress.tostr() + "%"
            TargetRect: { x: 75, y: 475, w: 200, h: 100 }
        })
    else  'Audio is currently playing

This is killing me, so any direction is appreciated. I promise I have spent over 12 hours trying to debug this issue.

[RokuJoel]

Perhaps the type conversion is a factor, because m.progress is an roInteger and progress% is an Int. However that doesn't seem to be a problem in my testing:

BrightScript Debugger> progress%=95.5
BrightScript Debugger> ?progress%
 95
BrightScript Debugger> ?type(progress%)
Integer
BrightScript Debugger> m.progress=progress% 
BrightScript Debugger> ?type(m.progress)
roInteger
BrightScript Debugger> 

You could try ditching the type-casting and just use progress=int(msg.getindex()/10)
I think it is more likely that something else is going on in your code, If I was to guess, something in your logic is preventing the line where m.progress is assigned the value of progress% from executing, although I'm not sure what. I suggest posting the rest of your loop, sanitize it for any URLs and then it will be easier for someone to plop it into a project, find a usable mp3 url from the internet and test it.

if msg.isStatusMessage() then
   if msg.getmessage()="startup progress"
         m.paused = false
         'lets ditch the forced typing for an int() statement
         progress = int(msg.GetIndex() / 10)
         print "progress index value: ";progress
         if m.progress <> progress then             
             print "m dot progress: ";m.progress;" progress: ";progress
              m.progress = progress
              m.paint()
         end if
   else if msg.getmessage()="start of play" then 
       'index must be 1000 even if I'm not getting it from the startup progress on this iteration
       'so we can act as if we hit index=1000 even if we never got that message
   

I would suggest a liberal use of print statements might also help.

- Joel

[belltown]

I don't know if it matters in your case, but I've noticed that it can take several minutes for the "startup progress" messages to finish (index = 1000) and the "start of play" message to occur, at which time the audio starts playing. The stream should start playing when the (undocumented - type 20) IsStreamStarted message is received, which occurs when the "startup progress" index reaches 330; there's also an accompanying (undocumented - type 33) IsFormatDetected message at this time. This behavior of not starting to play the audio stream until 2 or 3 minutes after the IsStreamStarted message seems like a Roku bug to me. It's been like that for years though. As a workaround, I pause then resume the audio player on receipt of the IsStreamStarted message, which occurs almost immediately, and the audio starts playing as soon as the resume is issued.

Like Joel said, judicious use of debugging statements (i.e. print every audio event) will help you see what is going on.

Also, you're not very clear on how you're setting up your image canvas. You have a couple of Push statements, but what are they pushing into? Are you re-drawing the progress bar layer each time or trying to add something on top of what's already there each time you get a progress message. Most likely your problem lies somewhere in the code you've not posted.

[Biggytv]

RokuJoel / belltown-

Thanks so much for your recommendations.

I found this issue, which was unrelated to the loading status. I was making a call to bring an image from a url into the Canvas. Sometimes that images was not available and it was tripping up the code.

I have created a function to check if the images exists and if it does not to put a local image in its place.

Thanks!

Kyle