Hey guys, I’ve been trying to stream this for a while but although it plays, it palys for a minute then repeat what has already been played. I have had success using a certificate chain file and as destruk suggested, however, it wont work with the other streams. Can anyone please help, i’ve been trying forever and i’m losing hope.
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-CACHEThe 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: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.
hi, thanks for the reply, i just download the m3u8 changed the allowcache to , added the link before the segments to make it play and then uploaded it to dropbox to point the roku to it. It still repeats :(, could it be because i used dropbox? Damn i tried everything, what makes it worse it that vlc plays it fine so i feel that there must be a way to make it play…
“httpslash” wrote:
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
Dang it, i got myself too involved here. Try something like this and then ask it to play the local m3u3?
xfer = createObject("roURLTransfer")
xfer.setURL("http://stream0.latvdefrance.com/live/tf1.m3u8")
m3u = xfer.getToString()
tmp_m3u = ""
for each line in m3u.tokenize(chr(10)):
if left(line, 1) <> "#":
line = "http://stream0.latvdefrance.com/live/" + line
else if left(lines, 18) = "#EXT-X-ALLOWCACHE:":
line = "#EXT-X-ALLOW-CACHE:NO"
end if
tmp_m3u = tmp_m3u + chr(10) + line
end for
WriteAsciiFile("tmp:/tf1.m3u8", tmp_m3u)
Hi thanks for taking the time to help. I really appreciate it. I am very new to roku, where would I paste your code? I’m using simple video player…?
EDIT: I pasted it in appmain.brs in simplevideoplayer, all i get is a loading… screen. Did i do it worng?
“renojim” wrote:
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.
I’m not sure it’s illegal, although it does seem rather strange to keep repeating the same sequence numbers without removing files that previously used those same sequence numbers. The key point for this to work is that the client would need to read the playlist file starting near the end (not less than 3 target durations from the end of the playlist file I believe the spec says). For a “live” playlist I’d think you’d want to start as close to the end as you can safely do so anyway. I’d be curious to know whether the Roku player agrees, or whether it just starts reading from the start of the file no matter what, no matter how long the playlist file is. If I were a Roku person, it’s something I’d be looking into. I don’t think the spec requires that you have to delete segment Urls from the playlist file at any specific intervals. In the case of this stream, it doesn’t look like the server is deleting anything from the file, just adding to the end, so even if the segment files were uniquely numbered, you wouldn’t really have a “live” stream, rather a “delayed” stream, delayed by the total length of the playlist file. I wouldn’t think that would be desirable behavior. If it were me implementing an HLS client, I’d start reading from closer to the end of the file.
“httpslash” wrote:
Hi thanks for taking the time to help. I really appreciate it. I am very new to roku, where would I paste your code? I’m using simple video player…?EDIT: I pasted it in appmain.brs in simplevideoplayer, all i get is a loading… screen. Did i do it worng?
I wouldn’t bother. It won’t work, due to the way HLS operates. The m3u8 playlist file is updated every few seconds as new media segment files are added. It’s not a “static” playlist file. Even if you could download it from the server every few seconds, create a new version of the file and write it out to a “tmp” file, I don’t know whether the roVideoPlayer would be able to handle a local file as a stream Url, and even if it did, you’d have to do something about the fact that the segment files it references aren’t local, but served from a remote url. I think you’re out of luck, unfortunately.
Thanks for the reply belltown, I have officially given up.
“httpslash” wrote:
hi, thanks for the reply, i just download the m3u8 changed the allowcache to
It could be because they used the wrong header “EXT-X-ALLOWCACHE” instead of “EXT-X-ALLOW-CACHE:NO” - see my P.S. above.
“belltown” wrote:
I wouldn’t bother. It won’t work, due to the way HLS operates. The m3u8 playlist file is updated every few seconds as new media segment files are added. It’s not a “static” playlist file. Even if you could download it from the server every few seconds, create a new version of the file and write it out to a “tmp” file, I don’t know whether the roVideoPlayer would be able to handle a local file as a stream Url, and even if it did, you’d have to do something about the fact that the segment files it references aren’t local, but served from a remote url. I think you’re out of luck, unfortunately.
Hmm. Why are you so sure?
Video segments can be local, relative or full URLs:
“https://en.wikipedia.org/wiki/M3U#File_format” wrote:Each entry … can be any one of the following:
an absolute local pathname; e.g., C:\My Music\Heavysets.mp3
a local pathname relative to the M3U file location; e.g. Heavysets.mp3
a URL.
I have doubts about your previous paragraph too, where you say a player should start at the end of the m3u - rather seem to me that since a sliding window is used for live streaming, it is server’s job to update the m3u promptly so that new clients hopping in are on the current segment. But that doesn’t even matter in this case - as long as player keeps playing the 6 segments (each ~10sec) without caching - even if it started at the wrong # segment, the worst that can happen is delay from live of 5x10 = 50sec
That’s very interesting. I’m gonna try this as soon as I get home. Could it also be that vlc doesn’t allow by default and that’s why it doesn’t repeat?
“EnTerr” wrote:
“belltown” wrote:
I wouldn’t bother. It won’t work, due to the way HLS operates. The m3u8 playlist file is updated every few seconds as new media segment files are added. It’s not a “static” playlist file. Even if you could download it from the server every few seconds, create a new version of the file and write it out to a “tmp” file, I don’t know whether the roVideoPlayer would be able to handle a local file as a stream Url, and even if it did, you’d have to do something about the fact that the segment files it references aren’t local, but served from a remote url. I think you’re out of luck, unfortunately.
Hmm. Why are you so sure?
Video segments can be local, relative or full URLs:
“https://en.wikipedia.org/wiki/M3U#File_format” wrote:Each entry … can be any one of the following:
an absolute local pathname; e.g., C:\My Music\Heavysets.mp3
a local pathname relative to the M3U file location; e.g. Heavysets.mp3
a URL.
Sorry. I missed the part in your code where you were changing the relative urls to absolute urls; I thought you were just changing the cache header.
“EnTerr” wrote:I have doubts about your previous paragraph too, where you say a player should start at the end of the m3u - rather seem to me that since a sliding window is used for live streaming, it is server’s job to update the m3u promptly so that new clients hopping in are on the current segment. But that doesn’t even matter in this case - as long as player keeps playing the 6 segments (each ~10sec) without caching - even if it started at the wrong # segment, the worst that can happen is delay from live of 5x10 = 50sec
No. It just won’t work unless you start reading within 6 segments from the end of the file.
Each segment has a unique integer sequence number, the first segment in the playlist file being EXT-X-MEDIA-SEQUENCE, each succeeding segment incrementing by 1. In this case, EXT-X-MEDIA-SEQUENCE is always zero, and each new segment is added to the end of the file without deleting any of the earlier segments. Furthermore, the same 6 filenames are used over and over again. So if there are 1000 segments in the file, for example, they will be segments number zero through 999. To work properly in this case the client can “hop in” anywhere – but only if it’s hopping in at one of the last 6 segments (but not less than three target durations from the end of the playlist file, which would be 30 seconds in this case, per the spec), so basically it would need to start with a segment that was 30-60 seconds from the end, roughly. If the client were to start reading the file any earlier than 6 segments from the end, an error would most likely result since the segment file corresponding to that sequence number no longer exists, having been over-written by a later segment. The earlier segments having the same names as the later segments also have different EXTINF tag values, so when the player reads an earlier segment with a 4 second duration, for example, but the file that overwrote that segment file has a 9 second duration, it ends up trying to play 9 seconds of video when the file only contains 4 seconds’ worth, which can really mess things up. Another example - let’s say there are 7 segments in the file, sequence numbers 0 to 6, the first six having filenames ending in 0 through 5, the last one having a filename ending in 0. If the client started reading from the start of the file, it could potentially read the first couple of segments (seq. no. 0 and 1), but when it goes to read the next segment, which should be the data from seq. no. 2, the file it reads could by then have been overwritten by the data for seq. no. 7. That could mess things up too.
I don’t believe that the caching you keep referring to has anything to do with anything. It just tells the client it can keep segments that it’s already read in its local memory once it’s read them so it can replay them later giving the client the ability to rewind and fast-forward through the stream, etc
My guess is that the stream plays fine on VLC because VLC is smart enough to start reading from close to the end of the playlist file, but the Roku is perhaps starting from the beginning.
Another problem with the playlist file is that it specifies EXT-X-TARGETDURATION:10, yet the EXTINF tag values vary between 1 and 20 seconds. The spec says, “The EXT-X-TARGETDURATION tag specifies the maximum media segment duration. The EXTINF duration of each media segment in the Playlist file, when rounded to the nearest integer, MUST be less than or equal to the target duration.”
