INTERACT FORUM
Windows => Third Party Plug-ins, Programs, and Skins => Topic started by: TheShoe on February 19, 2020, 02:00:58 pm
-
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.... ?
-
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.
-
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.