Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TheShoe]

I've noticed that the resulting response to GetFile.m3u8 results in a response such as this in my case:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:EVENT
#EXTINF:6.000000,
/MCWS/v1/File/GetFile.ts?File=757250&Conversion=WebPanel&Quality=Very%20High&Start=0.0&Playback=2&HLS=1&Context=seg0.ts
#EXTINF:6.000000,
/MCWS/v1/File/GetFile.ts?File=757250&Conversion=WebPanel&Quality=Very%20High&Start=0.0&Playback=2&HLS=1&Context=seg1.ts
#EXTINF:6.000000,

...and so on.

Missing is the absolute URL to the request for the segments.  Why is it relative and can an absolute path be provided?

e.g. instead of "/MCWS/v1/file/GetFile.ts", can it be: "http://[my media server:port]/MCWS/v1/file.... ?

[Hendrik]

Its relative to the same server you got the m3u8 playlist from, which avoids a load of issues with proxys and whatnot. Any HLS client i've ever seen handles that just fine.

[TheShoe]

Thanks.  Could be the Emby mobile client then is at issue.

I'm adding the GetFile request into a stream (.strm) file.  Emby indexes this file on its server, and in its webclient has no issue playing back the stream from Media Center.  The Shield TV app also works; the iOS mobile apps from Emby however do not.

I can see 404 errors in the Emby server logs to the .ts files via the GetFile API because they are likely using relative URLs.  But only for the mobile clients.

I have an interesting use case for why I use Emby this way where Media Center is my primary server...  I'm going to run the request through a proxy in node.js and change the response from Media Center to add the domain to each URI for the .ts file and see if that makes any difference.