Sat>IP support

Finally migrated over from a DVBViewer generated m3u playlist, direct to SATIP - So now my m3u playlist tunes directly to either my Kathrien or triax SATIP servers.

So far I have loaded & re-mapped channels for Astra 28.2 - Manually... that took some time!

As i write this post im now scanning channels on Astra 19.2 & will hopefully have a custom M3u playlist loaded into channels DVR & EPG mapped by tomorrow morning :slight_smile:

The final satellite to add to my setup (but will require re-alignment of my satellite dish & a 3rd lnb fitting) will be for scanning of Hotbird 13e. I currently have my dish offset for 28.2 & 19,2 & TBH couldn't be bothered last week messing about with the amount of work involved to offset my dish for a '3 satellites on 1 dish' setup as the problem has always been lack of EPG for Hotbird 13e... however as channels DVR seems to have updated its EPG support and now shows listings for channels on Hotbird, im tempted to get it setup over the next few days!

So far so good. It will be nice to remove DVB Viewer & have direct tuning to my SATIP servers! Nice work.

For me, an m3u playlist as HTTP seems better - Channel loads are quicker. One thing i have noticed is loading a channel within the Channel DVR web browser does take longer than my Apple TV box. Also, having my Apple TV box with a wired connection onto my LAN also improves channel loading times. Most channels load within 1 second. I also did a bit of testing earlier today to see what channel scan / load times are on Astra 19.2 - As this satellite is wired into a unicable multiswitch and uses my triax SATIP server - Channel loads are 1 - 2 seconds, so no real differences.

All my channels seem to have options for subtitles, ability to change audio streams etc... basically whatever is provided by the m3u list Channels DVR seems to recognise and handle without issue.

Everything seems to be working well. I've had no real issues with failed connections etc since creating new m3u playlists. My series passes all seem to be working ok & plenty of live tv has been successfully recording this afternoon.

The only improvement of SATIP / m3u which would be good, is the ability to have channels correctly filtered (i.e. HD, SD...etc). All channels within my m3u lists show up in Channels DVR as HD.

Thanks again for the support.

1 Like

I'm in Poland so not afraid of EU duties. GB will have bigger problems from 1 January, unfortunately.
I stopped learning German after leaving High School 25 years go, so the dictionary may be helfpfull :smiley:
Still this is sooo pricey especially for salaries in Poland. The way to go is to find a friends to participate, one pay for server another gives space with symmetric fibre 1000/1000 and we are ready to go :slight_smile:

Speaking about providers - I always Thought Virgin is satellite not a cable. And yes, they are overly paranoid, Sky could offer only decryption card for using with E2 tuners but no:( That Sat>IP tuners has no place for inserting such cards anyway :frowning: If Channels could utilitze that to get access for SKY On-demand boxes that would be huge, but probably this never gonna happen in this world. Sky uses the same approach in Germany, Italy, Austria and probably Spain.
They are not intrested in entering Polish market unfortunately. In Poland most of the channels on satellite are encrypted even the terrestrial ones which is a shame but our government similar to US government doesn't do a shit about this. The channels that are FTA in UK or Germany like HGTV,CBS Reality are paid and encrypted in polish version :expressionless:

Maybe some other specialist here know (@racameron ?) is there anything that can convert Enigma2 tuner eg. VU+ Duo from being sat>ip receiver only into server? after all they are linux-powered.

I don't know why, but it seems like the prices have gone up and the choice has gone down since I bought my sat>ip server around this time last year.

Virgin Media in the UK and Ireland is a cable provider, not sure about elsewhere. 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.

Whilst I never looked into it too much, I thought TVheadend supported card readers etc?

I'm not sure if it supports CI+, but it does support CI.

TVheadend does support card readers, but good luck getting one to read a UK Sky card reliably, consistently and legally. :grinning:

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

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:

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

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

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

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

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

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.

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

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

1 Like

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

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

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

@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