Roku Developer Program

[markhood]

"RokuPatrick" wrote:
We think we've identified the issue with the squeezed video and are working to get a fix released ASAP.
Patrick

Have you figure out why the MyMedia channel no longer works with 2.8? The problem there isn't squeezed video, but no display at all; still, could the problem have to do with using Handbrake CLI to transcode to mp4? If there are recommend parameters to Handbrake CLI that could solve this problem, please let us know.

Also, can you confirm if blocking api.roku.com at the DNS level would be effective in allowing owners of the Roku devices to block the final 2.8 push if it still breaks MyMedia? The blocking seems to have some effect in that the Channel Store is no longer available, and nothing else seems to be affected, but of course I'm not going to try the manual update procedure in order to test it 😄

I understand that Roku put some text in the EULA where you reserve the right to update the firmware as you please, but are you intent on enforcing it or will you provide a way to opt out? Anybody who opted out of course would no longer be eligible for support from developers or from Roku unless they install the latest firmware.

The best solution would be to fix 2.8 so that MyMedia and other local streaming channels still work, but I understand that might not be possible if MyMedia in fact is doing something wrong that only worked accidently with 2.7.

Thanks!

[renojim]

It's looking more and more that the myMedia issue is not Roku's fault. I apologize to the the good people at Roku for assuming it was. The buffering/retrieving seems to have changed significantly from 2.7 to 2.8 and it exposed a couple of bugs in el.wubo's Python server. I'm still working on it and should have it fixed in the next day or so. I haven't been able to test the squished video issue, but I don't know why myMedia would be immune to it.

-JT

[markhood]

"renojim" wrote:
It's looking more and more that the myMedia issue is not Roku's fault. I apologize to the the good people at Roku for assuming it was. The buffering/retrieving seems to have changed significantly from 2.7 to 2.8 and it exposed a couple of bugs in el.wubo's Python server. I'm still working on it and should have it fixed in the next day or so. I haven't been able to test the squished video issue, but I don't know why myMedia would be immune to it.

-JT

Excellent news JT! It's much better to know that there are bugs in MyMedia then some fundamental incompatibility with the firmware. In fact I edited my previous post just moments before I saw yours because I didn't want to put all the blame on 2.8. I'm very glad that it seems I won't have to fight what will probably be a losing battle to keep 2.8 out of my device!

I didn't know you were working on MyMedia. I've been thinking of diving in myself as a good excuse to learn Python. I'm more interested in the server side than the BrightScript stuff, so perhaps when I get more familiar with the language we can collaborate and make sure MyMedia stays viable.

Best regards!
Mark

[kbenson]

"renojim" wrote:
It's looking more and more that the myMedia issue is not Roku's fault. I apologize to the the good people at Roku for assuming it was. The buffering/retrieving seems to have changed significantly from 2.7 to 2.8 and it exposed a couple of bugs in el.wubo's Python server. I'm still working on it and should have it fixed in the next day or so. I haven't been able to test the squished video issue, but I don't know why myMedia would be immune to it.

This wouldn't happen to be open ended range requests with RST packets sent to stop the request after a few thousand bytes are retrieved? I'm (finally!) getting around to actually streaming some video in a channel I'm developing, and was trying to figure out why it looked to be taking so long. Examining the packet dump of the request shows some... interesting behavior.

Then again, for I know about network video delivery, maybe that's the norm.

[renojim]

It probably is something similar, but I haven't looked at exactly what's going on because I just got the Python server to handle range requests properly (but it still doesn't work 😞 ). From what I'm seeing, it requests the whole file twice (probably sending RST or something similar), then it sends an open ended range request starting at offset 28 (which probably also gets stopped somehow), then sends another request for the whole file. Then I get the "unexpected problem" error message on the console. Of course, all of this was before I got (I think/hope) the range requests working properly, so it may not apply. I'm just about to delve back into Wireshark to see if I can figure out anything more.

I can say that a packet dump from 2.7 looks nothing like one from 2.8. It also looks like 2.8 is more particular about incorrect responses and/or server timeouts.

-JT

[renojim]

Off topic...

"markhood" wrote:
I didn't know you were working on MyMedia. I've been thinking of diving in myself as a good excuse to learn Python. I'm more interested in the server side than the BrightScript stuff, so perhaps when I get more familiar with the language we can collaborate and make sure MyMedia stays viable.

Best regards!
Mark

Yep, el.wubo has moved on. I'll get back to you when I start working on repackaging it as a private channel. It's kind of a pig because all of the graphics are packaged with the client when they really don't need to be. The choice of "skins" makes it a little harder to repackage. I'll probably choose one or the other (most likely, "high contrast"). At some point I'd really like to move the shuffle feature to the server. The server should be able to walk the directory structure much more quickly than the client and it would give a more random shuffle. I'm pretty adamant about not having any requirement to index one's music collection.

-JT

[retrotom]

Renojim,

Are you sure about those requests you're seeing? I think I posted on here about the perceived behavior with MP4 streaming. While developing Gabby, we noticed that it requested the entire file once so that it could find out where the moov segment was. So, unlike Chrome and a lot of browsers, etc. that will ask for the first 1024KB or something with a range request, the Roku asks for the entire file and the quickly ends the request when it finds what it's looking for. If you're slow about responding, then you'll get a multiple requests for the same data. After that, it usually would do one or two range requests at the end of the file in order to read the moov segment. After that, it would ask for the rest of the file in another range request (skipping ftyp). One "optimization" I thought about doing (you can tell me if it make sense) -- is that if we get a request for the whole MP4, just send (or plan to send) the first megabyte or so. Because (from our observations) the only non-range request is in order to retrieve that information -- I thought about implementing something like that. I no longer need to do that because we changed the way we stream videos, etc --- but it's a thought. You can test to confirm, but the roku never really asks for the entire file. Another thing to remember with range requests is that the "ends" are inclusive; that hung us up a bit. We kept sending one too few bytes.

--RT

[renojim]

retrotom,

I just went through a tcpdump I captured that used an Apache server to serve the file (so any issues the Python server I've been using had with range requests were irrelevant). This was from a file that had the moov data at the end, which also demonstrates why you should put it at the beginning, although I'd have to analyze the traffic for a file with the moov data at the beginning to see if all the requests still occur.

Request for the whole file - about 70k was returned before the transfer was stopped
Request for the whole file - about 50k was returned before the transfer was stopped
Open-ended range request starting at offset 28 - about 50k was returned before the transfer was stopped
Open-ended range request starting at offset 160 - about 50k was returned before the transfer was stopped
Open-ended range request starting about 20k before the end of the file - although the entire data was sent, Roku still responds with RST
29 more requests near the end of the file for data it should already have!!! - all but the last ended with RST
Open-ended range request starting at offset 595 - returns the rest of the file

This file was only about 2MB, so it would easily fit within the RAM on the box.

Another thing, I have yet to see anything other than open-ended range requests and I have to believe they are the only kind used since the Python server I've been using would have crashed for anything else. I'm curious if you've seen a range request with both first and last bytes specified.

The problem with the Python server turned out to be that it was returning a status of 200 instead of 206 for range requests. It also wasn't setting the headers like Content-Range, but it was fixing the status that made everything work under 2.8.

-JT

[markhood]

Dang, that's a lot of redundant transmissions just to initiate the stream. Seems like it could have something to do with the major pause in the progress bar that a lot of people are seeing before the real buffering starts.

[kbenson]

Yeah, that's exactly what I saw. I'm not sure it's the most efficient, but it may end up that it's the most compatible. I figure there's got to be some reason they did it that way, as it sure doesn't seem like it would be any easier to write. If so, it would be nice to be able to toggle different sets of behavior, so if we know the other end conforms to some specific standard, we can cut out the odd parts and request just what we need.

P.S. In my tests, I believe much less than 50k was served on average per range request that was reset. Closer to 5k, so it's less wasteful in those cases, as long as the network connection isn't latent and the server is responsive.