Sat>IP support

Channels DVR Server Feature Requests
#185

Blockquote You're absolutely right about Sky (and Virgin): they will never allow subscribers to use their own equipment, which is a shame because I would happily pay for a subscription if I wasn't restricted to accessing it through their (horrible) boxes and apps.

Well they at least are not as bad, Virgin has some new Android TV box, SKY Q box are for me masterpiece if you compare this to shit unreliable boxes offered in Poland by Canal+, Cyfrowy Polsat, T-Mobile, or Play. No company in Poland can do this properly and they don't understand customers needs :frowning: at least you in Britain still has decent FTA.

Also Sky lacks of corporate managment due to their takeover by Comcast. Sky customers do not have access to Peacock on their boxes, I assume voice assistant didn't improve with X1 assitant know-how. Also SKY making bunch of weird moves:

  • there is SKY Q app on Apple TV but only in Germany and it's terrible
  • there is fibre-only SKY Q box but only in Italy
    -in Spain they only offer some sort of NOW TV
    -in Austria they offer yet-another-crap box called Sky X
#186

if the card is paired with box good luck with that, a first man who discover how to do this (it probably requires reprogramming of the chip on card) will get Nobel, eternal fame, lot of money and naked ladies :slight_smile:

#187

Short request to @neild7744 - can you record today Muse concert from 3Sat? :slight_smile:

Happy New Year to everyone, let's pray it will be without virus, social distance and instead full of hope, joy. Stay safe folks!

@stoli412 I realise, sky decription card is not needed, because they have subsription no contract service called NOWTV. Not ideal (most streams are only 720p) but in their Entertrainment Pass you got access to on-demand content collections called Boxes.
This is not TVE but maybe @tmm1 would know how to extract stream link (each customers obviously has its own) for the channels using Puppeteer? :slight_smile:

1 Like
#188

I'm very intrigued by this Sat>IP thread. I'm currently using a HDHomeRun in the UK but find there is only limited HD Free to Air channels available. I am hoping this Sat>IP solution might make more HD channels available to me.

I've just purchased a Kathrein EXIP 418 server from Germany (£235 including delivery) and have this working now in VLC. The next step is to try and get this working in Channels but I am struggling to set it up.

I have the latest AppleTV testflight app installed but can't see any options in the settings to add an MTU source, only the HDHomeRun tuners. I think I need to upgrade my Channels DVR server as well but I can't find anywhere where I can download the latest BETA version, it doesn't seem to be mentioned on the https://getchannels.com/beta/ link.

If anyone can help me I would be very grateful, I am a Channels Plus subscriber.

Thanks in advance

#189

Upgrading to the latest prerelease and adding m3u sources is done via the DVR web UI. Do you know how to access that?

#190

Ah that's how its done, thanks your help. It's easy when you know how :wink:

it case others need it
http://xxx.xxx.xxx.xxx:8089
where the xxx are your Channels DVR server IP

I can't believe the great job the channels team has done on this. With just a few clicks it pulls in all the Freeview channel data and I now have loads of new free HD free channels (over and above the handful of terrestrial ones I had before) - kudos to the Channels team

2 Likes
#191

Just started to get something similar, I suspect it is/was a kernel update or bug at some point. The cause, in my case, was CPU frequency scaling - mainly with the intel_pstate driver.

Since forcing ACPI scaling and disabling intel_pstate at boot/grub, so the OS decides rather than the chip, and setting 'performance' governor the problem has not reoccured. An old post on the tvheadend bug tracker showed someone else managed to resolve it by setting the minimum frequency scaling for all cores to somewhere between 1.3 and 1.95Ghz (they noticed the sub 1Ghz caused problems).

I suspect UDP packets go walkies during the scaling or at lower frequencies. Changing to HTTP, TCP by nature, packets that are lost will be resent by the network stack.

Assuming this does continue to resolve the problem in the coming days, I may experiment with some of the other governors, perhaps 'conservative' or 'powersave' with a minimum CPU frequency - so that the CPU will at least reduce power when not needed.

1 Like
#192

Interesting. I always assumed the issue was something with my network topology and/or the Megasat just being flaky over UDP. Since I'm using the Channels M3U direct setup now I'll just stick with HTTP because tuning is so much faster vs RTSP.

#193

Did you have any more luck with this? I just did a few tests on my Digibit R1. I am getting video and audio after 10 seconds of buffering in the browser but just a still on both stable and beta apps on tvOS and iOS. This is with the satip.info m3u. Still having no luck with my custom m3u that are currently working with telly.

2 Likes
#194

Same, messed around with every setting I could find but no improvement. Gave up in the end and went back to tvheadend.

1 Like
#195

Geez that's the price of decent set-top-box from Vu+, world went crazy or maybe it's a niche market so the prices went up to cope with pandemic economy. But back to the point, you experiencing problem with the stream server is sending to you, I never seen admin panel of such sat>ip server is there any possibility you can set reencode (possibly with ffmpeg) stream to different format?

Also what is about radio? I think there is lot of radio stations broadcasting from Astra 28, is server able to create stream from them too?

1 Like
#196

My example m3us are below, I'm using a Megasat 3:

Running: 2021.01.09.2109

I've been testing this morning and saw:

  • RTSP (UDP) via TVHeadend, tuning was fast
  • RTSP (UDP) direct to Channels, tuning was slow
  • HTTP direct to Channels, tuning was as fast as RTSP via TVHeadend
  • satip:// (UDP, calls RTSP to the Sat>IP server) direct to Channels, as fast (if not slightly faster) than RTSP via TVHeadend

@tmm1 what's the main difference/advantage from a Channels perspective of using satip:// URLs?

P.S. I did note, that when using the scraped m3u from kingofsat, the pids weren't the same as TVheadend was using.... so I manually edited these, similar to @stoli412, using tvheadend status as a guide. This cured a lot of the random problems I was having with tuning.... but the above bullet points still apply after doing this.

satip:// URLs seems to be the way forward for me

#197

^^ Oh, I see it's already answered... seems to speed up channel tuning for me, whilst still using UDP for the stream.

#198

@tmm1, I am seeing a LOT of the below in the Channels logs, it doesn't seem to impact streaming (as far as i've seen) - would be good to be able to silence this, assuming it's not critical:

2021/01/11 14:51:48.676173 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28975983
2021/01/11 14:51:48.676492 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28976095
2021/01/11 14:51:48.676947 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28976239
2021/01/11 14:51:48.677471 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28976349
2021/01/11 14:51:48.678012 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28976493
2021/01/11 14:51:48.678382 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28976596
2021/01/11 14:51:48.678831 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28976704
2021/01/11 14:51:48.691069 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28976846
2021/01/11 14:51:48.691468 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28976954
2021/01/11 14:51:48.691690 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28977059
2021/01/11 14:51:48.692258 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28977210
2021/01/11 14:51:48.692652 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28977313
2021/01/11 14:51:48.693082 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28977413
2021/01/11 14:51:48.693426 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28977566
2021/01/11 14:51:48.693829 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28977677
2021/01/11 14:51:48.694404 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28977817
2021/01/11 14:51:48.694993 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28977919
2021/01/11 14:51:48.695369 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28978025
2021/01/11 14:51:48.695915 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28978173
2021/01/11 14:51:48.696300 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28978286
2021/01/11 14:51:48.696787 [HLS] ffmpeg: rtsp-604:  [data @ 0x7182580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28978474 >= 28978384
  • Version: 2021.01.09.2109
  • satip:// URLs
  • Megasat 3 server

UPDATE: After a few hours, the log file gets rather large as well! :slight_smile:

-rw-r--r-- 1 channels channels 180M Jan 11 16:30 channels-dvr.log

#199

I just did a bit more playing around with the Digitbit R1 links and found luck with replacing http:// with rtsp://

Some channels loaded very quickly 1-2 seconds, others 3-4 seconds and some 7-8 seconds and some had the freezing issue. The 1-2 second one was SD and others were HD. I'll keep testing.

#200

Bloomberg HD, BBC News HD are/were always fast for me - BBC 1HD is a little slow, but isn't slow using the same M3u with VLC (even over wifi on my laptop) and via TVHeadend first.

1 Like
#201

Blockquote

That’s where I left it - only RTSP would work (with playback via Android TV), but it was slow with too slow channel changes to be useful - tvheahend with android tv live channels changes in less than 2s. It was up to 10s in channels.

2 Likes
#202

I mainly tested 4 channels
Sky News SD 1-2 seconds
BBC News HD 2-3 seconds
BBC One HD 7-8 seconds
CNN HD freezing issue

Just tested on Apple TV 4K stable. Will keep trying.

#203

At least with rtsp:// and satip:// Channels spawns an ffmpeg instance, I was going to have a play with the various options there to see if it sees the same latency/delay.

UPDATE:
I think the delay is coming from ffmpeg - if I run a basic test using the channels ffmpeg binary, it's around 7-8 seconds with BBC One HD before I see the "frame" in the log, i.e it's playing.

Testing with the same link in VLC, it starts playing within around 3-4 seconds - which is more or less the same as what I see when using TVHeadend -> Channels.

There are a variety of warnings/errors spat out from ffmpeg, although this was just a basic test (I'm not yet using the exact arguments that channels launches ffmpeg with, so it's not a like for like).

I need to do some research to see what these mean. Perhaps TVHeadend/VLC is more tolerant, or simply ignores, the errors or perceived 'dirty' stream?

[h264 @ 0x69b2f40] co located POCs unavailable
[h264 @ 0x7025fc0] reference picture missing during reorder
[h264 @ 0x7025fc0] Missing reference picture, default is 65724
[h264 @ 0x69b2f40] reference picture missing during reorder
    Last message repeated 1 times
[h264 @ 0x69b2f40] Missing reference picture, default is 65740
    Last message repeated 1 times
[h264 @ 0x695ad40] Missing reference picture, default is 65743
[h264 @ 0x7025fc0] mmco: unref short failure
[h264 @ 0x69b2f40] Reference 2 >= 2
[h264 @ 0x69b2f40] error while decoding MB 76 18, bytestream 4749
[h264 @ 0x69b2f40] concealing 5973 DC, 5973 AC, 5973 MV errors in B frame
[h264 @ 0x695ad40] co located POCs unavailable
[h264 @ 0x695ad40] concealing 7909 DC, 7909 AC, 7909 MV errors in B frame
[h264 @ 0x7028cc0] co located POCs unavailable
[h264 @ 0x7028cc0] concealing 7112 DC, 7112 AC, 7112 MV errors in B frame
[h264 @ 0x6a15cc0] co located POCs unavailable
[ac3 @ 0x6977800] exponent -2 is out-of-range
[ac3 @ 0x6977800] error decoding the audio block
Error while decoding stream #0:0: Error number -16976906 occurred
[h264 @ 0x7025fc0] error while decoding MB 36 16, bytestream -16
[h264 @ 0x7025fc0] concealing 6253 DC, 6253 AC, 6253 MV errors in B frame
[h264 @ 0x69b2f40] Reference 3 >= 2
[h264 @ 0x69b2f40] error while decoding MB 118 6, bytestream 1549
[h264 @ 0x69b2f40] concealing 7371 DC, 7371 AC, 7371 MV errors in B frame
[h264 @ 0x695ad40] concealing 7676 DC, 7676 AC, 7676 MV errors in B frame
[h264 @ 0x7025fc0] reference picture missing during reorder
    Last message repeated 1 times
[h264 @ 0x7025fc0] Missing reference picture, default is 66028
    Last message repeated 1 times
[h264 @ 0x7025fc0] Reference 2 >= 2
[h264 @ 0x7025fc0] error while decoding MB 49 0, bytestream 21350
[h264 @ 0x7025fc0] Cannot use next picture in error concealment
[h264 @ 0x7025fc0] concealing 8160 DC, 8160 AC, 8160 MV errors in P frame
1 Like
#204

Seems similar to telly. Loads 1-2 seconds in VLC, avg 5-6 seconds on telly through ffmpeg