Hi everyone, I know there have been some reports of various playback issues with the 2.8 software. The good news is that this seems to affect a very small percentage of our users, but of course, that isn’t of much comfort when it’s your channel that’s affected. To that end, we’d like to ask your help in characterizing the issues and reproducing them.
To that end, please perform a manual update to 2.8, if you haven’t already. Then, please check your channel (or for that matter any other channel you want to test). If you encounter a problem, please post here or send me an email (pellis@roku.com) with the channel, the failure, and the steps to reproduce (specific titles).
We are working to have fixes for these issues released asap.
1.) One simple thing to add is that i noticed my sound effects stop playing for some reason when i click around the channel lineup. then after shutting off and on the sound effects (clicking) comes back
To that end, please perform a manual update to 2.8, if you haven’t already.
This may be a dumb question, but I can’t find any info anywhere.
How do I do a manual update of my firmware?
To that end, please perform a manual update to 2.8, if you haven’t already.
This may be a dumb question, but I can’t find any info anywhere.
How do I do a manual update of my firmware?
In the settings, I believe under player info, you can check for a new firmware release. If found, it automatically updates.
Khan Academy appears to show all videos with an incorrect aspect ratio under 2.8 on my hd tv. It looks like 1:1, it should be 4:3. I also have some new (unreleased) hd content that is encoded at 1280x720, that also shows up squished in 1:1 format. It should display in 16:9.
I tried rebooting in SD mode, I get the same behavior. I have N1100 hardware.
Under 2.7 I used to have mp4 clips which worked fine. They are no loner working now. I did some digging on this and finally got them working. It has something to do with the interleaving setting in the clips. 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.
NOTE: I can’t post any channel or title names at this point because I haven’t published any channels (public or private) yet. Sorry…
It’s great to see that you guys are on top of this problem. Would it be that crazy to go back to 2.7 until all of the problems have been rectified? I know my Roku experience has taken a hit from the update. Slow buffering times, channels not playing at all, audio missing from time to time (rectified by pressing the repeat button). I was planning on buying two more boxes but won’t now.
When you say “The good news is that this seems to affect a very small percentage of our users” what exactly is this based on? Are you basing this solely on feedback here? I don’t think that’s a great barometer when you have 500,000 units out there. The percentage of users who actually post or call support is minimal. I would suggest that this problem is more widespread. Is every user accessing multiple channels or are they more than likely mainly using the Roku for Netflix (which appears to be unaffected by the update for the most part).
I’m really hopeful that this will be resolved the Roku is a great idea at a great price and when it works it’s fantastic. With so many new and established options I’d hate to see this product slide downward. Thanks for reading.
There appears to be a problem with files that have been encoded with mp4 encoding (for example files encoded for an ipod touch). Prior to the 2.8 upgrade these files played correctly (2.6 and 2.7 code), now if you have a 16x9 file it seems to get squished in to the 4x3 space so the people in the picture and really thin and tall.
As a Test I encoded the same video 2 different ways the setting below show what worked and what didn’t.
(the encoder settings that I have an issue with are below, this is how all of my existing mpeg4 files are encoded)
The mp4 encoding I used was mpeg4 + aac
Video fixed Bitrate 1337kbps
Audio 64kbps Dolby ProLogic II
Frame Resolution 720x310
(the encoder settings that seem to work, I tried this just as a test)
mp4 (h264 + aac)
Fixed Bitrate 1009kbps
Audio 32kbps 5.1 Multichannel
Frame Resolution 720x312
I opened a ticket with the Roku support desk and they had me do a hard reset of the box which didn’t make any difference and are now telling me to call support to RMA the 2 boxes that I have. Roku may want to make their technical support desk more aware of the known problems that exist with the 2.8 code before they start to send out a lot of replacement boxes and customers find that the problem isn’t resolved with a hardware change.
“jwentzel” wrote:
There appears to be a problem with files that have been encoded with mp4 encoding (for example files encoded for an ipod touch). Prior to the 2.8 upgrade these files played correctly (2.6 and 2.7 code), now if you have a 16x9 file it seems to get squished in to the 4x3 space so the people in the picture and really thin and tall.
Have you updated to build 1158? The original 2.8 release had the issue you described, but the new 1158 build should have addressed most cases of the squeezed video.
Hate to be a pain with this but given all these issues, wouldn’t it be a good idea to:
Provide better diagnostics for the developer community (or better documentation on understanding how to use the exiting ones) in identifying the issues related to the player?
Provide a way to either temporarily disable automatic updates of the firmware or a mechanism to fall back to a known-to-be-good version of it?
“renojim” wrote:
Build 1158 addressed the HLS problem, but not mp4 files as noted in this thread: viewtopic.php?f=34&t=33885&start=0
HLS is still MP4, so I can’t imagine they’d only have addressed HLS exclusively. I understand that they didn’t address all issues with HLS and MP4, but jwentzel didn’t mention which version of the firmware he was running. If not the latest, then his report may or may not be valid anymore.
“Hexamon” wrote:
Hate to be a pain with this but given all these issues, wouldn’t it be a good idea to:
Don’t worry, I’m sure I’m a pain all the time.
Provide better diagnostics for the developer community (or better documentation on understanding how to use the exiting ones) in identifying the issues related to the player?
There’s supposed to be some enhancements coming to the debugger soon (maybe some are in 2.8? I should look). See viewtopic.php?f=34&t=32853
I think the best thing we can do as developers is get into the beta program and make sure to test extensively there. This may mean getting a second unit so one can be in the beta and one not for better test coverage, but at $60 for a base model it shouldn’t be too hard to get that second model.
Provide a way to either temporarily disable automatic updates of the firmware or a mechanism to fall back to a known-to-be-good version of it?
This has been discussed extensively. I think if you really think about the ramifications of allowing people to hold their player back from newer firmware releases, you’ll come to the same conclusion I did (and Roku has, obviously). I think a group of users running an ever expanding set of different firmware releases complaining about features not working, bug that were long ago fixed, and inconsistent look and feel would greatly outweigh any benefit gained, especially when more active participation in the beta will probably keep most of the problems from this release cycle from happening again.
P.S. You can say temporarily, but I think in practice if it’s available to users they will find a way to make it permanent.
