Roku Developer Program

[Hexamon]

These questions are regarding the Roku firmware update process. They were prompted by the recent 2.7 release:

1. Will Roku box automatically upgrade to the latest version of the firmware? I think the answer is yes, just confirming. Particularly, will it upgrade itself to the latest 2.7 release which was recently released?
2. Is there a way to stop this behavior? I don't mean to stop it forever but for a short time (while developing). The latest upgrade broke something (even though it appears to be due to a bug that was fixed in the firmware which now makes better checking of the mp4 files it tries to play)
3. My Roku player is actually set to firmware version 2.8. This is what the "Player Info" screen says. How is this possible? Is it getting it from some kind of beta or test server? Is there a way to change this behavior?

[Anonymous]

2.8 was rolled out over the last week. Yes the box will automatically upgrade when we start automatic upgrades for a release. It's not really possible to stop the upgrade without killing Internet access for the box altogether. Since virtually everyone is upgraded in a short period of time (typically less than a week), you should probably plan to develop on the latest public release anyway.

[Hexamon]

Thanks, this answers all my questions but one - I certainly want to develop on the latest stable version but what I don't want to is to develop on the latest unstable version. Since there was no announcement about 2.8, I assumed it is a beta version of some sort. Let me know if this is incorrect.

One more question (please, let me know if I should open a different thread on this) - when the player does not like something about an mp4 file (while buffering it), it spits out the following message in the debug window (the one you connect to with telnet):

play failed: An unexpected problem (but not server timeout or HTTP error) has been detected.

Is there a way to get more information on the specific error encountered? I understand this is caused by the mp4 file being ill-formatted somehow but it is really hard to figure out the specifics without more diagnostics (to make things more interesting, I have an mp4 file which does not play but when I extract a subset of it using MP4Box it plays fine (the subset). I compared these two files using "MP4Box -info" line by line but there appears no difference between the two other than the duration. I am trying other methods now but this is really confusing:))

[RokuMarkn]

The 2.8 release was announced on 11/4. The announcement is at the top of the General Discussion thread. Your box will never receive a beta firmware version unless you have signed up for a beta program.

Does your MP4 file have multiple audio tracks? Currently the Roku will only play a file if it contains one audio track.

--Mark

[Hexamon]

"RokuMarkn" wrote:
The 2.8 release was announced on 11/4. The announcement is at the top of the General Discussion thread. Your box will never receive a beta firmware version unless you have signed up for a beta program.

Thanks. Good to know, my bad.

Does your MP4 file have multiple audio tracks? Currently the Roku will only play a file if it contains one audio track.

--Mark

Here's what "MP4Box -info" shows for the file in question 00.mp4:

# MP4Box -info 00.mp4
* Movie Info *
        Timescale 600 - Duration 00:09:59.040
        Fragmented File no - 2 track(s)
        File Brand isom - version 1
        Created: GMT Fri Nov 12 17:17:58 2010

File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: AAC Profile @ Level 2 (0x29)
No streams included in root OD

Track # 1 Info - TrackID 201 - TimeScale 25 - Duration 00:09:59.040
Media Info: Language "Undetermined" - Type "vide:avc1" - 14976 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 512 x 384 - Profile Baseline @ Level 1.3
NAL Unit length bits: 32
Pixel Aspect Ratio 1:1 - Indicated track size 512 x 384
Synchronized on stream 1

Track # 2 Info - TrackID 101 - TimeScale 48000 - Duration 00:09:59.040
Media Info: Language "English" - Type "soun:mp4a" - 28080 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

Here's info for the file 20.mp4 which was derived by extracting a subset from 00.mp4 using "MP4Box -spit-chunk":

# MP4Box -info 20.mp4
* Movie Info *
        Timescale 600 - Duration 00:09:59.000
        Fragmented File no - 2 track(s)
        File Brand isom - version 1
        Created: GMT Fri Nov 12 17:27:20 2010

File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: AAC Profile @ Level 2 (0x29)
No streams included in root OD

Track # 1 Info - TrackID 201 - TimeScale 25 - Duration 00:09:59.000
Media Info: Language "Undetermined" - Type "vide:avc1" - 14975 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 512 x 384 - Profile Baseline @ Level 1.3
NAL Unit length bits: 32
Pixel Aspect Ratio 1:1 - Indicated track size 512 x 384
Synchronized on stream 1

Track # 2 Info - TrackID 101 - TimeScale 48000 - Duration 00:09:58.997
Media Info: Language "English" - Type "soun:mp4a" - 28078 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

And finally here's a diff between the two:

# diff /tmp/00.info /tmp/20.info
2c2
<       Timescale 600 - Duration 00:09:59.040
---
>       Timescale 600 - Duration 00:09:59.000
5c5
<       Created: GMT Fri Nov 12 17:17:58 2010
---
>       Created: GMT Fri Nov 12 17:27:20 2010
13,14c13,14
< Track # 1 Info - TrackID 201 - TimeScale 25 - Duration 00:09:59.040
< Media Info: Language "Undetermined" - Type "vide:avc1" - 14976 samples
---
> Track # 1 Info - TrackID 201 - TimeScale 25 - Duration 00:09:59.000
> Media Info: Language "Undetermined" - Type "vide:avc1" - 14975 samples
21,22c21,22
< Track # 2 Info - TrackID 101 - TimeScale 48000 - Duration 00:09:59.040
< Media Info: Language "English" - Type "soun:mp4a" - 28080 samples
---
> Track # 2 Info - TrackID 101 - TimeScale 48000 - Duration 00:09:58.997
> Media Info: Language "English" - Type "soun:mp4a" - 28078 samples

00.mp4 does not play and gives out the charming "Unexpected problem" message, 20.mp4 plays fine.

Thanks for your help!

[Hexamon]

I also used ffmpeg to compare their infos, here's the diff:

sh-3.2# diff /tmp/00.ffmpeg.info /tmp/20.ffmpeg.info
11c11
< Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '00.mp4':
---
> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20.mp4':
16c16
<   Duration: 00:09:59.04, start: 0.000000, bitrate: 900 kb/s
---
>   Duration: 00:09:59.00, start: 0.000000, bitrate: 900 kb/s

[Hexamon]

I got some more info on this issue. I am starting to suspect there's something weird going on with the way the player deals with the interleaving settings of the mp4 file. In particular, given the file 00.mp4 (which is not working), I generated a new file from it using "MP4Box -cat" the only thing I changed was the interleaving setting: "MP4Box -inter 1000 -cat 00.mp4 -new 20.mp4". This worked fine, 20.mp4 played without errors. I then used an interleaving setting of 500 (ms), this is a default setting and the problem reappeared. After playing around with this setting, I figured out that some of them work and some don't. For example, anything from 450 to 950 range doesn't work, 1000-1400 works, 1500-1900 doesn't. It seems to work better on high (several thousand ms) settings. I am currently setting it to 2000 ms.

I don't think this is the end of it though. The problem probably has something to do with the network latency, while it seems to work fine in my local network, it might behave differently from a remote host. I can't test that right now but I'll do it (test from a remote host) in a day or two. It will be interesting to see the results.

Here's the most important part - I don't believe this problem existed prior to the Roku 2.8 firmware update. In fact, I am quite sure it didn't exist because I can no longer play the files (since Nov 09, 2010) I used to be able to play. I wanted to positively confirm this. In order to do so, I needed to downgrade to the previous version. I don't think there is a "legit" way to do so. I tried resetting the box but it seems to either not reset the firmware version or update the firmware upon the first initialization. Either case, I couldn't get back to a release prior to 2.8. If someone could let me know how to do so, I'd really appreciate it.

This circles me back to the original question - is there a way to find out more (from the logs, special undocumented features, etc.) when the following error is encountered?

"play failed: An unexpected problem (but not server timeout or HTTP error) has been detected"

If I could determine why changing those interleaving settings in an MP4 container causes this problem, I could be able to open a meaningful bug report.

[Hexamon]

I'll post this info in another thread, it is no longer appropriate here. Thanks,

[RokuKevin]

Hexamon,

Do you have a public url of content that used to play on v2.7 and no longer plays on v2.8?

I'd be happy to look into if you have content I could look at.

--Kevin

[Hexamon]

Thanks Kevin. Unfortunately I don't have any public contents published at this point. Also, I continued this discussion in a different thread which seemed more appropriate to the question due to the similar problems observed:

viewtopic.php?f=34&t=33731

I think all the questions relevant to the issue raised in this thread can be considered addressed. Thanks,