I’ve been working on a channel that plays eHLS, both live and complete. Complete streams are fine on all platforms I’ve tested on. Live ones don’t have the ability to seek but do start at the current time in browser (Edge) and Android (ideally I’d like to be able to rewind, which is otherwise possible outside Plex). But the Roku (both Plex and Plex Classic) start live streams at the beginning.
I don’t have any live streams to test at the moment, but I recall the end time being the actual live time at the time the stream is started. I.e. if I fast forward hours to get to the end, it’ll play up to the live point and then just keep on replaying that 10s segment over and over. Using the Roku DLNA player, the stream works as it should.
Is there something I’m overlooking? Again, complete eHLS streams play fine on the Roku. I cannot control the source stream, but it is to specification last I reviewed it, so I’m hoping it’s my end.
Oops, should mention that I’m specifying the requisite protocol/container/codecs in the MediaObject. As well, I’ve used HTTPLiveStreamURL in front of the Callback in the PartObject to achieve the same thing (found that doing so required adding .m3u8 to the end of the route).
Unrelated to the Roku issue, is there a way to disable transcoding for this channel? Because multiple bitrates are provided with HLS, and I’m relying on proper client support, I see no need for the overhead and would prefer direct play only.
edit: didn’t see the original post had a settings button as well. Does the optimized_for_streaming flag do anything for hls? I thought that was an mp4 thing? Either way, I’ve tried that as well.
As far as blocking transcoding, a channel cannot do that. Each player controls whether to direct play or transcode. You can only set Client.Platform restrictions.
Again, I would use the BBC player URL service I linked above for reference on how best to handle eHLS, clients, and resolution. Meriko , who wrote that URL service, is very good at programming HLS/eHLS channels to work with clients best, so I would do it the way he does.
Thanks. Your first link mentions setting the stream as live in the metadata or specifying a high playstart value. Is there a way to do this in the plex channel? I don’t see anything in the documentation (old 2.1.1 pdf :).
I checked out the BBC url service but don’t see anything different that would affect live streams on roku.
I just retested a live stream, and it looks like it’s able to play fine after seeking to the current live point. Again, using DLNA on the roku to access the plex channel works great (starts at live point).
The code in that link is just showing a reference to a known issue. The Plex for Roku app would need to update the way it reads metadata to recognize something like a “live” or “playstart” value before any metadata code that you would put in your channel and/or the URL service for a live feed specification or start time could be recognized. As I said there is an open issue for this for the Roku client.
EDIT
First, the Plex plugin framework would have to add a live attribute for the MediaObject. Then the Plex for Roku app could recognize the “live” attribute value. But adding this to your channel and/or the URL service before these steps are taken, would at the least result in nothing and could return an error, since it it is not currently part of the plugin framework.
Also, I did just confirm, as a result of many mistakes I had made in my code, that if you have one HLS video that has multiple bitrates/resolutions. You do not have to define those bitrates/resolutions in your media object. The client and PMS will decide the best one to use. (Sometimes certain values are necessary to prevent a Plex client from transcoding, so it is always best to confirm what you must define)
Ah thanks, I misread what you wrote the first time.
As for the multiple bitrates, yeah, they don’t need to be defined / should not normally need to be defined to achieve the intended playback. However, being able to manually specify bitrate does still come in handy. A friend who wants to use the channel can pull down 100mbps on his phone, but would blow through his monthly quota in an hour if using the adaptive master list. Fortunately, mediaobjects are selectable on Android. Would still be nice to have on Roku as well.
edit: And I see there’s a new plex pass preview channel. Will have to test that next week.
@ziddey You have peaked my interest Is there an example channel you can supply that exhibits this issue? I’m curious to see how it works (or doesn’t work) on the Roku and how it works correctly on other clients.
That new preview/Plex Pass version of Roku app gives you access to media options(by hitting the * button or you can pause the video and it is the option that looks like 3 cables) and user input/search (InputDirectoryObject) for channels.
The Roku should choose the right bitrate/resolution of the HLS based on your quality settings. As you can see in the Preview channel under Settings > Video, they have now broken up those settings into Local, Remote (remote access of shared libraries), and Online (channel/website content).
Though it used to be that the Roku used the remote quality setting for online content, I think in the current public/free version of the app is using the local quality. So the change you see in the preview/Plex Pass version breaks it up and makes the quality options more clear for users.
@ljunkie said: @ziddey You have peaked my interest Is there an example channel you can supply that exhibits this issue? I’m curious to see how it works (or doesn’t work) on the Roku and how it works correctly on other clients.
Awesome, thank you. You can pretty much use any non-live m3u8 and just strip out the final #EXT-X-ENDLIST to have it be treated as a live stream (except on Plex for Roku).
^ That should now be treated as a live stream, where the player is expected to seek back 3 segments from the end, and keep polling the m3u8 for additional segments.
Because this is a static m3u8 file, it should play the last 3 segments and then stall out. However, feeding this m3u8 to Plex for Roku results in it starting from 0.
@ziddey thanks for the info. That is actually the conclusion we came to while investigating this The issue is that the Roku is not following the HLS spec, and should start the stream at the end of the playlist if #EXT-X-ENDLIST is not included. The Plex channel doesn’t download the HLS manifest itself, it just passes it to the video player which is handled by the firmware. We’ll pass the info on to Roku and investigate a possible workaround in the interim.
It looks like Roku has a “Live” metadata that needs to be set true (default false): Roku
The content-metadata is basically irrelevant now that we have a new video player. It’s use was only to display a “live” icon as a replacement to the time remaining. It’s irrelevant because we have full control now of what we want to display, so setting that key doesn’t actually do anything special.
Live itself would work fine but live+vod would be extra sweet (likely setting PlayStart to a high value as recommended in shopgirl284’s linked thread: HLS Stream Issue in Playback - Roku Community)
The fix is setting playStart to something very large, but the key is knowing the feed is live, otherwise all HLS streams will start at the end and that is obviously worse. This is where the slight complication lies - we don’t have any way to know the feed is live or not without inspecting the HLS manifest, and that is looking like the only foreseeable route to cover both issues. i.e. knowing if the feed is live so we can exclude showing the time remaining/end time in the new player and always start the live feed at the end of the playlist. It’s definitely on our list, but I don’t have any ETA to share.
It looks like Roku has a “Live” metadata that needs to be set true (default false): Roku
Live itself would work fine but live+vod would be extra sweet (likely setting PlayStart to a high value as recommended in shopgirl284’s linked thread: HLS Stream Issue in Playback - Roku Community)
Just an FYI in case you didn’t see the changes to my post, (it says edited, but it doesn’t give you any alert or change the position of the thread) after a conversation and a DUH!! moment on my part, I went back and edited my earlier post on this. We are limited by the existing framework attributes that are available for media objects.
++ has anyone found a workaround for this? I’m currently having to fast forward my custom plugin from the beginning when live streaming (no #EXT-X-ENDLIST)
Is there an example channel you can supply that exhibits this issue? I’m curious to see how it works (or doesn’t work) on the Roku and how it works correctly on other clients.