Getting Zattoo channels into ChannelsDVR (likely timeout issue on Ios/firetv apps)

Playground
#1

Hi,

I'm trying to get Zattoo channels integrated into ChannelsDVR but have hit a dead end.

I've been using telerising-api (https://github.com/sunsettrack4/telerising-api) to create a m3u playlist that lets me access my zattoo account.

When I loaded up the m3u from telerising-api directly as a source in ChannelsDVR, I was able to see the video for each channel but was getting no audio.

From what I can ascertain the issue is Zattoo feeding a HLS5 or HLS7 playlist and I'm assuming channels doesn't support these (any chance of supporting these types of playlists?). Connecting direct to telerising-api's m3u file with VLC works perfectly with the newest version of VLC (slightly older older versions get video with no audio)

To solve this, first I tried feeding the m3u from telerising --> hlsproxy to re-encode the streams, but when I tested the output from hlsproxy with VLC it also had no audio (so it doesn't appear that hlsproxy is able to handle these hls 5 or hls 7 playlists either).

Then I tried feeding the m3u from telerising into xteve (using the VLC option to re-encode, without reencoding, no audio comes through). Once I confirmed that both audio and video where coming out of xteve (using VLC)

I then added the xteve instance as a m3u file to ChannelsDVR (setting stream setting as Mpeg-TS instead of HLS).

I am able to view the Zattoo channels (both audio and video) when accessing using a web browser connecting to my.channelsdvr.net (it does take a bit of time to start the stream 15 seconds or so). (I'm setup with telerising & xteve running on a seperate machine from my channelsdvr machine)

The only issue is when I try accessing these channels from either an iphone/ipad/fire tv, after a few seconds I get the "Tuner Not Available" message (once it has worked, when the stream started particularly fast), otherwise I haven't had any success accessing from any of these devices. I have confirmed that if I record once of the zattoo channels, I am able to play back the recording on either the web or ios/fire tv clients.

Given it has worked once, when the stream started particularly fast. I'm pretty confident after trying a range of options to troubleshoot that the issue is that there is a shorter timeout on the client apps (seems to be about 8 seconds) before it sends you to the "Tuner Not Available" message. If I access via a webbrowser, it will just keep trying until the stream finally starts after 10-15 seconds.

Is there any way for the developers to extend the timeout time on the ios/fire tv clients to a longer period before sending you to the "Tuner not available" message (i'm using the betas for both ios and firetv).

Thanks in advance for any help.

#2

Could you email [email protected] with some copies of the hls5/hls7 playlists so we can see what's going on.

#3

Thanks Aman,

I've just sent you an email.

Cheers

#4

I would also be interested in this.

Have tried a similar approach and nothing played in Channels, but I could play the streams in vlc.

#5

I would also be intrested in this. Having BBC News for recording would be nice.

#6

Just for anyone else trying this out.

Going from telerising-api --> ChannelsDVR will result in no audio, because the HLS5 / HLS7 playlists that come from Zattoo send the audio seperate from the video and Channels doesn't support these types of playlists.

I've tried going telerising-api --> hls-proxy --> ChannelsDVR (same issue video with no audio, hlsproxy's re-encoding doesn't appear to support these types of playlist.

So far the only combination that works is telerising-api --> xteve (set to reencode with VLC only, not using their own encoder or ffmpeg both don't seem to support the playlist format).

The issue is that (for me at least) it takes about 10-20 seconds for the stream to build up a buffer before it starts sending the reencoded steam with the audio and video together in a playlist that ChannelsDVR understands.

As a result if you access using your my.channlesdvr.net using a web browser, there is no timeout and you can view with no issues (but it takes that 10-20 seconds before the video starts).

On the channelsdvr firetv and ios clients, there appears to be a timeout (about 8 seconds on my count) where it goes to the "Tuner not available". (If a manual setting is enabled on these clients to set your timeout, that should fix the issue and allow the setup to work)

I've once had the stream start fast enough and have it work on ios. Also if you record and watch a recording it works with no issue (as it's recorded by channelsdvr, which is then feeding a local recording, so it's not dependant on waiting on a stream from xteve being delivered prior to the timeout.

So for it to work reliability either channels needs to support these hls5/7 playlists (and then you could take xteve out of the picture) or allow a longer timeout on ios/firetv clients before they jump to the unavailable message (i'm assuming the second option should be a pretty simple fix).

I haven't yet tried going telerising-api --> telly --> channelsdvr, to see if it supports VLC to re-encode, and if so it it does it faster than xteve to beat the timeout...

Please post you've had any success

#7

Did you try using ffmpeg to combine both streams in one video/audiostream in real time and then send it to player?

#8

Within xteve I’ve tried its own encoder, ffmpeg and vlc to re encode. I only has success with vlc. So I’m guessing ffmpeg has the same issues as channels with dealing with the hls5/7 playlists

#9

Channels use ffmpeg internally with some middleman scripts. You should try using ffmpeg to combine both video and audio stream into one and create playlist that links to your stream

#10

Experimental support for HLS streams with separate audio tracks is available in v2021.04.14.0108.

#11

I was hoping this would allow TWiT to work, but it doesn’t like the structure of the m3u, from what I can tell. Plays fine on my iPhone.

http://iphone-streaming.ustream.tv/uhls/1524/streams/live/iphone/playlist.m3u8

#12

@tlspambait Is it working with the pre-release?

@Macnbaish The TWiT stream is doing something even more complicated so its not going to work without a bunch more effort.

#13

@tmm1 Ok thanks for taking a look.