AudioPlayer - bad URL causes reboot

Archived
1

I have been trying to debug an roAudioPlayer issue and I have finally been able to replicate it. It’s due to setting the URL to a NON audio file. The AudioPlayer will realize this and print the error:


AudioPlayer Status Event - startup progress
AudioPlayer Status Event - startup progress
AudioPlayer Status Event - startup progress
starting song: 0
AudioPlayer Status Event - startup progress
AudioPlayer Status Event - startup progress
AudioPlayer Status Event - startup progress
ignored event type: 20
ignored event type: 33
AudioPlayer Status Event - startup progress
AudioPlayer Status Event - Error parsing stream data.
failed to play song: 1
FullResult: End of Playlist
AudioPlayer Status Event - end of playlist
end of playlist (obsolete status msg event)

After it fails, the ROKU locks up and reboots.

Is this a bug or are we supposed to verify the AudioFile before we set the URL? If the later, how does one verify the URL is a valid audio file.

audioapp if needed: http://rarflix.com/test/audioapp.zip

  • Once you load the app, go to MP3’s and you will see a link for “Bad”, “Good”, “Empty”. The bad/empty will reboot the roku
2

Thanks for posting, we will take a look at it.

  • Joel
3

I had this happen to me with a good URL but missing file (wrong filename) it crashed the app, and froze the Roku (2XS), requiring a manual reboot, it did not reboot itself. Happened several times so not a fluke.

4

Yea bad topic :slightly_smiling_face: That is what I meant by bad url; It will reboot as long as the result is not a valid audio file. Thanks for more confirmation though!

5

I know it’s only been 24 hours, but any word?

Thanks,
Rob

6

Not yet.

  • Joel
7

Bump?

8

So, this is definitely a bug in 5.1 firmware, but as far as I can tell on Roku 3 only - tried the example on a 2XS and did not get the same behavior. However, the channel itself does sometimes crash and become partially unresponsive in this case, hitting Home takes a while to take effect.

As to a workaround for now, you could try using roAudioMetadata to check if the mp3 is really an audio file.

You can also encounter this when attempting to skip forward / backwards in a corrupt audio file. I’ve tested with the upcoming firmware release and it seems to be fixed there. There is another way to get the same kind of crash which is to skip through an audio file that is partially corrupt.

As I said, this appears to be fixed in an upcoming firmware update.

  • Joel
9

Joel, you have made my day. Two issues I have with a fix and anticipated fix coming soon!

Thanks for the info about roAudioMetadata, but I am dealing with a URL and it looks like that only deals with a file. So I’d have to download the file to tmp to verify it, which would not work well. I will patiently wait for 5.2 :slightly_smiling_face:

I am glad you mentioned the fwd/rwd seek could cause issues as I was able to crash/reboot the roku 3 with I was playing with seeking - although that was with a valid mp3 file. I was just chalking that up to the fact it seems the audioPlayer is a bit touchy.

Much Appreciated,
Rob

“RokuJoel” wrote:
So, this is definitely a bug in 5.1 firmware, but as far as I can tell on Roku 3 only - tried the example on a 2XS and did not get the same behavior. However, the channel itself does sometimes crash and become partially unresponsive in this case, hitting Home takes a while to take effect.

As to a workaround for now, you could try using roAudioMetadata to check if the mp3 is really an audio file.

You can also encounter this when attempting to skip forward / backwards in a corrupt audio file. I’ve tested with the upcoming firmware release and it seems to be fixed there. There is another way to get the same kind of crash which is to skip through an audio file that is partially corrupt.

As I said, this appears to be fixed in an upcoming firmware update.

  • Joel
10

“ljunkie” wrote:
Thanks for the info about roAudioMetadata, but I am dealing with a URL and it looks like that only deals with a file. So I’d have to download the file to tmp to verify it, which would not work well. I will patiently wait for 5.2 :slightly_smiling_face:
Could you do a HEAD request on the URL and check the content type header?

11

“TheEndless” wrote:

“ljunkie” wrote:
Thanks for the info about roAudioMetadata, but I am dealing with a URL and it looks like that only deals with a file. So I’d have to download the file to tmp to verify it, which would not work well. I will patiently wait for 5.2 :slightly_smiling_face:
Could you do a HEAD request on the URL and check the content type header?

I didn’t notice head request was an option. Thank you for the idea and I now see roUrlTransfer allows for it. Good stuff. That should fix this issue until the 5.2 firmware release.