I'm trying to import a few OTA stations from a remote DVR but keep getting "Can't detect playlist type" when I attempt playback.
The custom channels are being imported as HLS with a URL...
https://channelsdns:8089/devices/HDHR#/channels.m3u?session=xxxx&codec=copy
I can open the playlist and play individual channels using chrome with an HLS player extension.
If you are sure you have the bandwidth, instead of codec=copy use format=ts which will send the actual MPEG transport stream that Channels receives from the HDHR without remuxing to HLS. Then in your custom channel configuration, identify it as MPEG-TS.
Using HLS is always going to be more reliable over WAN connections and is worth the transcoding overhead.
I haven’t had a chance to look into why this situation is failing to load yet…
@JMcGuire could you submit diagnostics from both the DVRs and let us know when you have so we can check out what’s going on?
Submitted from Channels_DVR and NKellett.
Also, I was mistaken earlier when I said I had tried as a URL. I had pleviously uploaded as a text source with only 2 of the channels in the M3U (Downloaded the M3U direct from the server and deleted the unwanted channels).
I just tried with the URL option and it failed to load with "malformed" error.
Yep. I've been traveling so didn't have a chance to check it out until now.
I see these in the logs of the DVR that is serving the m3u:
2022/06/06 16:34:26.905260 [sessions] ERROR! securecookie: base64 decode failed - caused by: illegal base64 data at input byte 244
My best guess is that you have a typo or have truncated the session= parameter. Can you double-check that the parameter is correct?
Seems to be an issue with the "==" at the end of the session cookie, I have tried with and without and neither works.
I tried with another DVR which doesn't have "==" at the end of the cookie and it worked fine. I also deleted the session cookie from chrome but the new cookie also ends with the same characters.
Been awhile, but IIRC the = sign is just used for padding
IIRC correctly (from my 90s AOL hacking days), in base64 = is used for padding. However, its presence is still required to properly decode the input.
See Base64 - Wikipedia and scroll down to the Output Padding section.
@eric Updated to the latest beta DVR and it works, not sure exactly what the issue was because the other M3U from the other DVR worked on the current stable release.
On a side note, there are definitely some things being left over from deleted M3U sources. One I deleted then recreated with the same name but different content and it brought back old channels. Another time I edited the M3U text without deleting the source and it changed the channel number as expected but also left the old channel active.
This still doesn't work with the latest stable release but does on the beta 9/21 release. Any reason for it to only work on the beta builds now and a few months ago but not on 9/14 stable?
#EXTM3U
#EXTINF:-1 channel-id="TEST" tvg-id="2" tvg-chno="2" tvg-logo="" tvc-guide-stationid="XXX" tvg-name="XXX" group-title="HD",TEST
https://XXX.u.channelsdvr.net:8089/devices/ANY/channels/2/hls/master.m3u8?session=XXX&codec=copy
M3U: Could not parse playlist: XXX.u.channelsdvr.net:8089: Can't detect playlist type
If you take the URL and fetch it with curl on the command line, does it appear like a playlist or does it give an error?
@eric I think I've found the issue, but I'm not sure what is causing it. At first I didn't have the full session cookie, I caught that mistake before ever making the post here.
Even after editing the custom channel and deleting and re-adding the custom channel to correct the session cookie (using the M3U text option) it was still trying to use the invalid session cookie.
The Beta release has nothing to do with it working, but the upgrade process is somehow deleting whatever is being "held on to" for lack of better words. Basically, from what I can tell, something is being left behind when a custom channel is edited or deleted.