How to stream http stream?

Um... there's only 6 segments in that file that just repeat over and over again. It's no wonder it repeats after a minute. I'm not sure it's even "legal" to repeat segments within the m3u8 playlist file.

-JT

Hey, thanks for the reply. I thought too, but why does it play if I paste the link in vlc? Does it perhaps redirect to another link?

They aren't always the same 6 segments. If you watch the file names, as one falls off the top another is added to the bottom. That's normal for a live stream.

could you please guide me in making it play on the roku? It works on the computer and on VLC without repeating, however, on the roku, it keeps repeating.

Hi, thanks for taking the time to help me. I'm gonna read the link right now. However, I am able to play the link in your code fine. Its the second non https stream that I am unable to stream. Could you please try to stream that one? I am very inexperienced and would really appreciate it.

Oh, my mistake. Wrong stream.

renojim is right that it's the same 6 segments over and over. So it seems to me that it's playing exactly what the manifest is telling it to. If the idea is that the content of those segments is changing periodically, that could be a caching issue. It could also be that the encoder isn't updating them before the player makes the next request. I don't know for sure if repeating segment URIs is a violation of the HLS spec, but it's definitely unusual. And the timing of a scheme like that seems dangerous. Best practice would be for each segment to have a unique URI.

so am i out of luck...? The stream isn't mine so i cant change anything? Is there any way to make it play?

It looks like they're reusing file names in that playlist. The content of the files changes every minute. I don't know if that meets the HLS spec, but somehow I doubt it. I'm surprised VLC plays it. If you really, really wanted to play it on a Roku, I suppose you could process the playlist and download the segments to tmp: while renumbering the segments and recreating the playlist on tmp:, but it would be a lot of work fraught with potential problems. Is it really worth it? You'd probably have better luck trying to get the producer of the stream to fix his encoding.

On the other hand, if the playlist really is valid under the HLS spec, then I guess you've uncovered a bug on the Roku. Something tells me it wouldn't be a high priority to fix. 😄

-JT

Thanks so much for the help, I would be willing to try the tmp thing however it seems far too difficult for me to do. How would you go about doing it? Does it take a lot of steps? Thanks

"renojim" wrote:
It looks like they're reusing file names in that playlist. The content of the files changes every minute. I don't know if that meets the HLS spec, but somehow I doubt it. I'm surprised VLC plays it. If you really, really wanted to play it on a Roku, I suppose you could process the playlist and download the segments to tmp: while renumbering the segments and recreating the playlist on tmp:, but it would be a lot of work fraught with potential problems. Is it really worth it? You'd probably have better luck trying to get the producer of the stream to fix his encoding.

On the other hand, if the playlist really is valid under the HLS spec, then I guess you've uncovered a bug on the Roku. Something tells me it wouldn't be a high priority to fix. 😄

First, let me disclaim i am talking out of my mule here, since i haven't used HLS before - all i did was open teh spec and searched for "cache" in it. Using said ninja skill, here is what i found:

"http://tools.ietf.org/html/draft-pantos-http-live-streaming-13" wrote:
3.4.6. EXT-X-ALLOW-CACHE

The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST NOT cache downloaded media segments for later replay. It MAY occur anywhere in a Media Playlist file; it MUST NOT occur more than once. The EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. Its format is:

#EXT-X-ALLOW-CACHE:<YES|NO>

See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag.
...
6.3.3. Playing the Playlist file
...
If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value is NO, the client MUST NOT cache downloaded media segments after they have been played. Otherwise the client MAY cache downloaded media segments indefinitely for later replay.

So if there is "#EXT-X-ALLOW-CACHE: NO" in the M3U, client is required NOT to cache segments, even if they repeat. If there is no such line or it has different value but "NO" (that is any other string, including "YES", "NOPE", "NEVER", "3.141592"!), the client is free to do whatever the heck they see fit - cache them or not cache them - and they will be spec compliant.

Now looking at our m3u,

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOWCACHE:1
#EXT-X-TARGETDURATION:10

it says "#EXT-X-ALLOWCACHE:1", which means exactly nothing. It should be saying NO there.

PS. even the name is misspelled there, EXT-X-ALLOWCACHE instead of EXT-X-ALLOW-CACHE ! That file is chock-full of errors. Can't blame RokuCo for the behavior, it would be bending over backwards.