HLS Troubleshooting
This post will attempt to gather the common HLS issues and solutions that people are running into when rolling out solutions. The Encoding guide in the SDK will include much more detail, but this post...
Forum Discussion
I'm having an issue with HLS. There are times when our clients are forced to stop the stream (this would be during playback of an ad which contains video) to play another video.
The issue is that, for some of our clients, the m3u8 file has a TTL (time to live) of five minutes, and the stream URL cannot be re-requested, as it is no longer there.
The .ts files that made up the m3u8 file are still there, but the playlist (m3u8) isn't.
The solution I'm trying is to store the m3u8 file in "tmp:" filesystem, then retrieve it to use to restart the stream where it left of (or just after the ad).
Unfortunately, this doesn't work, as the paths to .ts files are relative to the request URL for the file itself.
I would parse the m3u8 file to add the appropriate base-url to each .ts file, but that doesn't seem to work either (see above).
Do you know of a way to define the base URL for a m3u8 file, either in the file, or by a command to the player itself?
This is causing major headaches for our clients, as they have to deal with TTL on these files (for security reasons) while still allowing for dynamic advertising that contains video.
Since the Roku cannot have two "connected" video objects at any given time, when the stopped video is re-started, another request for the m3u8 file is made, and the process breaks due to TTL.
This is a huge restriction for our clients who wish to use ads with video content while serving their content video with HLS.
Any ideas on how to resolve this issue would be appreciated.
-tutash
The issue is that, for some of our clients, the m3u8 file has a TTL (time to live) of five minutes, and the stream URL cannot be re-requested, as it is no longer there.
The .ts files that made up the m3u8 file are still there, but the playlist (m3u8) isn't.
The solution I'm trying is to store the m3u8 file in "tmp:" filesystem, then retrieve it to use to restart the stream where it left of (or just after the ad).
Unfortunately, this doesn't work, as the paths to .ts files are relative to the request URL for the file itself.
I would parse the m3u8 file to add the appropriate base-url to each .ts file, but that doesn't seem to work either (see above).
Do you know of a way to define the base URL for a m3u8 file, either in the file, or by a command to the player itself?
This is causing major headaches for our clients, as they have to deal with TTL on these files (for security reasons) while still allowing for dynamic advertising that contains video.
Since the Roku cannot have two "connected" video objects at any given time, when the stopped video is re-started, another request for the m3u8 file is made, and the process breaks due to TTL.
This is a huge restriction for our clients who wish to use ads with video content while serving their content video with HLS.
Any ideas on how to resolve this issue would be appreciated.
-tutash
