Roku Developer Program

[destruk]

I still don't understand the recommendation. Is there some enormous speed increase in accessing a file by removing the leading host url name? It's less typing and makes it easier for you to zip the entire server contents and stick it somewhere else (like that happens every day), but other than that I don't see the benefit. And if your playlist file is on one server and your content is spread across multiple servers, I guess they just write that off as 'not possible, so don't'.
What real difference does it make in performance? 😉

[TheEndless]

"destruk" wrote:
I still don't understand the recommendation. Is there some enormous speed increase in accessing a file by removing the leading host url name? It's less typing and makes it easier for you to zip the entire server contents and stick it somewhere else (like that happens every day), but other than that I don't see the benefit. And if your playlist file is on one server and your content is spread across multiple servers, I guess they just write that off as 'not possible, so don't'.
What real difference does it make in performance? 😉

It sounds like you're confusing HLS playlist files with standard static playlist files. M3U8 files are generated on the fly during a live stream, and are constantly requested by the client during playback. I imagine shorter URLs reduce the amount of wasted bandwidth during requests. I'm also pretty sure, by design, the contents of an M3U8 should never exist across different servers (except maybe in the case of an inserted ad).

[destruk]

Thanks for that.

[jbrave]

one could, perhaps distribute across multiple servers if the servers are aliased to the same domain, on an HA cluster or nfs mounted? I can imagine if you are a company like Netflix, you would probably want the next chunk to come from the nearest server with the lowest load...

[msauer]

I've discovered a setup that worked on Roku 1 (2.9) but not Roku 2 (4.1) with HLS.

Our setup uses a variant playlist (requested by https) with different bitrate streams, to then request the actual playlist (by https).

The actual playlist lists the .ts files, which are AES encrypted, and the key files are requested via https, but the media files are handled with straight http.

Our server is setup to perform mutual authentication, and our https server is set to trust the roku certificate authority.

The problem we are seeing is that the first variant playlist loads correctly, and gets past the mutual authentication phase. However on roku 2, the main playlist load will fail to get past the mutual authentication, and our server refuses to deliver the playlist to roku 2 (returns on error 403 - access forbidden). This worked fine on roku 1.

If I set the roku to play the second playlist via https directly, it authenticates fine, and plays the stream perfectly.

Here is the variant playlist (with only one stream to choose) - i've changed the ip of the server
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=1740800
https://8.8.8.8/hls/playlist/stream1.m3u8

Here is the contents of stream1.m3u8
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:398

#EXT-X-KEY:METHOD=AES-128,URI="https://8.8.8.8/hls/keys/stream1_132.key"

#EXTINF:10,
http://8.8.8.8/hls/stream1_398.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_399.ts

#EXT-X-KEY:METHOD=AES-128,URI="https://8.8.8.8/hls/keys/stream1_133.key"

#EXTINF:10,
http://8.8.8.8/hls/stream1_400.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_401.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_402.ts

#EXT-X-KEY:METHOD=AES-128,URI="https://8.8.8.8/hls/keys/stream1_134.key"

#EXTINF:10,
http://8.8.8.8/hls/stream1_403.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_404.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_405.ts

#EXT-X-KEY:METHOD=AES-128,URI="https://8.8.8.8/hls/keys/stream1_135.key"

#EXTINF:10,
http://8.8.8.8/hls/stream1_406.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_407.ts

[bmckim]

Be cool if this was fixed sometime soon. We are really looking forward to sending Roku 2s out to our clients since it is a really cool little box.

[galexe]

Yeah, we have to remove adaptive feeds until this is fixed or we have to steer people away from Roku2. Right now we're pulling the adaptive feeds and hoping this gets fixed quickly.

[sberner]

Hi Guys,

Just curious if there are any updates on a fix for HLS on Roku 2? We are starting to get emails from people having problems with our channels and we aren't sure what to tell them. Is this an issue Roku is going to fix or do we need to change something on our end? We are using Wowza to deliver live HLS streams and they were working fine with 3.0 on the old boxes.

Sean

[TheEndless]

"sberner" wrote:
Hi Guys,

Just curious if there are any updates on a fix for HLS on Roku 2? We are starting to get emails from people having problems with our channels and we aren't sure what to tell them. Is this an issue Roku is going to fix or do we need to change something on our end? We are using Wowza to deliver live HLS streams and they were working fine with 3.0 on the old boxes.

Sean

According to the release notes for the latest firmware 4.1b1265 (viewtopic.php?f=28&t=42571😞

Improved playback compatibility with HLS streams provided by Wowza servers

That was just released on Friday, so it may not have rolled out to all players, yet.

[unDEFER]

We also has this problems with the last build 1265