Also - I've read that Continuity errors on SAT>IP set-ups can be the result of missed RDP UDP packets (I think RDP packets have an incrementing unique stamp number so a missed packet can be discovered ?).
Discussion that some recent Linux kernel stuff has caused issues with some hardware in that regard - though no idea if the Pi is impacted. One TVHeadend user was seeing continuity errors every minute or more in that situation.
One other thing - do you have any Transport Errors alongside your Continuity Errors?
I fired up my TV Headend Debian server running on a Celeron PC. Currently just doing AutoRecs of the main UK networks (BBC One HD, BBC Two HD, ITV HD, C4 HD, C5 HD plus a cheeky Talking Pictures SD as that unearths some hidden gems!) TV Headend Server and Kathrein are on the same switch.
Here are some screen shots in case they are useful.
(Still no continuity errors after 3 hours)
(After five hours there were a couple of continuity errors on three tuners - fewer than 10 errors though)
Hi, I just tried the last matrix build for my rpi4 4 gb and everything plays fine (even 130 GB mkvs!). Most of my files are in MKV format created with makemkv stored in a NAS, but two of the tvs at home are still 1080p. Files plays fine, but the colors are obviously washed out.
Is it planned to support tone mapping so colors can be "downscaled"?
Thanks.
Yep - tone mapping Rec 2020 HDR to Rec 709 SDR is a requirement for playback of Rec 2020 HDR content nicely on Rec 709 SDR TVs.
(Rec 709 vs Rec 2020 is the colour gamut, SDR vs HDR is the dynamic range - both need to be handled)
However it's important not to assume it's a UHD 2160p vs HD 1080p thing - there are UHD TVs that need tone mapping as they are Rec 709 SDR only (early 4K TVs weren't Wide Colour Gamut or HDR), and there are 1080p HD TVs that don't need tone mapping, just downscaling (as they are Rec 2020 HDR compatible)
Have you enabled Expert / Advanced mode in the menus on TV Headend? What SAT>IP settings in TV Headend do you have?
Could you post grabs of your DVB config settings in TV Headend?
Post Processing is not the route to fix this - those errors just shouldn't be there in the first place.
I'm in the UK and have a small 50cm dish for Astra 28.2 - cost £50... I take it you are not in the target area for the satellite you want to receive?
How long are you leaving TVH to capture EPG data before viewing - epggrab can sometimes swamp underpowered platforms.
Display MoreHello Noogin I'm very happy that you try to help me. And I really would love to get things running.
I am willing to do all kind of troubleshooting.
First of all I am using a Quad LNB (KATHREIN KEL 444 Euroline Universal Quad LNB).
My Antena is rather old, cheap and small.
My Sat>IP is Kathrein 418 which, from my research, got pretty reasonable test results altogether, although not being a cheap device.
But I am using this setup (antenna + LNB) since years and never had issues ever since (using both my HTPC with 2x Hauppauge Nova S2 cards and a Comag SL40HD receiver.)
[The SAT>IP is brand new (2 weeks?).]
For THV forums I have the issue to not receive an confirmation link e-mail. I tried like 5 times the last couple of days.
Therefore I am unable to open threads there sadly.
Poor signal quality would indeed be an issue to troubleshoot, since I can't really test it (withoput buying a new antena // LNB).
I was kind of hoping for a logging possibility in THV to hopefullly get hints.
Regarding settings:
no I didn't do anything in the THV tuner settings yet. To me its 100% confusing. There are like 30 different entries//lines in THV - although i only have 8 tuners.
I would have no clue at all, what to do - even for "trial and error"
Regarding "continuity errors would be caused by dropped network packets": I would kind of cancel this out. Since not only does DVBViewer run fine, but also Simple IPTV (using a m3u) runs on both the LG TV itself (LG OS6 -SIPTV app) and also on Kodi (SIPTV Client Addon). Without any flaws.
Wouldn't those two programs face the same issues with a root cause in my network?
The "platform" I am running THV on is a RasPi 4b 8GB.
And I tried both LibreElec 9.2.7 and Raspbian lite (using the latest 32bit version from "Raspberry Pi Imager"). Both with exactly the same poor results.
I'll see if I can post on your behalf at TV Headend forums - there are posts from other Kathrein users there I think - have you done a search on those and google to see how others have configured their Kathreins?
I don't know what you mean about '30 different entries/lines'?
You do understand how to set-up TV Headend and how to set-up your SAT>IP receiver within it don't you?
As you only have one orbital position - you've done the basic stuff and disabled the other 3 positions for each tuner (configuring each of the 8 tuners for just a single position (rather than the 4 Diseqc options - A, B, C, D etc. )? (That shouldn't be an issue but will get you down from 32 tuner options to 8 )
There are also SAT>IP specific settings that can differ between different SAT>IP tuners in TV Headend - as some tuners have more functionality than others (Some can send an entire transponder, others can just send a couple of services per transponder before running out of processing)
As for network issues- no you can't assume that because other software works fine over the network with your Kathrein and TV Headend doesn't that it isn't the network. If TV Headend is requesting a lot more data (as it could be if it's not been configured not to) you could be running at much higher network loads with TV Headend vs other tuners.
How much research have you done in to how TV Headend works with SAT>IP tuners?
Sadly I am quite blank on how things all work together (especially in regards of the "cont. errors").
(What's the output of the antenna/LNB, what is Kathein doing with it, how is the network/Fritzbox involved, what is TVH doing exactly, how is the TVH output "received", what does the "player" do with it?)
Assuming you have a Wideband/Quad/Quattro LNB connected to your Kathrein (Unicable and Unicable II is a little bit different)
1. Your LNB receives a focused RF beam which the dish has focused, from the orbital position it is pointed towards.
2. Your LNB contains Horizontal and Vertical polarisation functionality that lets it receive one or both horizontal and vertical polarised signals (polarisation allows the RF band to carry more signals without the H and V signals interfering with each other)
3. Your LNB will have a Local Oscillator (for Universal LNBs this will have two different frequencies, for a Wideband just one) which is mixed with the RF signal received and creates a much lower frequency IF band that can be sent down the cable.
3. Your Kathrein will select the right LNB input (and if a Quad LNB is used tell the LNB which of the 4 universal bands to feed down that LNB feed) and Local Oscillator setting (if required)
4. Your Kathrein will then, under IP control from TV Headend, over SAT>IP, select which transponder frequency band in the IF band it receives down the cable to tune to.
5. Your Kathrein will then, under IP control from TV Headend, demodulate that transponder using DVB-S or S2 demodulation, with the correct FEC etc.
6. Your Kathrein will then, optionally, under IP control from TV Headend, select which PIDS (or audio, video, text, data etc. streams) to send to TV Headend over IP, and then will start streaming them. (In some cases it is possible to select every PID on a transponder - but for many SAT>IP tuners this causes them to fail as the network throughput and processing required is too high)
7. Your TV Headend server will receive those IP streams and process them - either recording them to a local or network storage device, or streaming them back out over the network.
(For Unicable / Unicable II LNBs the set-up is a bit different for points 2-4)
It's points 1-7 that will influence continuity errors. These can be caused by poor signal, slightly incorrect IF oscillator setting, poor network handling (or in some cases the SAT>IP tuner being pushed too hard and sending more PIDs than is required). There are a number of SAT>IP settings in TV Headend for optimising different makes of SAT>IP tuner.
Have you checked the accurate SAT>IP setting for your device in TV Headend - and checked whether there is any advice for your tuner on the TV Headend forums?
The fact that you get good results with DVB Viewer and less-good result with TV Headend suggests this is a TV Headend config issue - or a problem with the platform you are running TV Headend on (continuity errors would be caused by dropped network packets - as SAT>IP uses UDP not TCP so no packets are checked and re-requested)
Display MoreYes that's exactly why I am hoping on an evolution for THV.
This "canceling/correcting (of) errors" seems to be not a major issue, if that many (all) other Apps and Tools are capable of.
Can I maybe switch the "MPEG 2 Transport Stream processors and h.264 video decoders" for TVH manually?
DVBViewer seems to use "LAV Filter", which is an extra installation coming with DVBViewer.
How can I configure those settings (transport stream, decoder, etc.) for TVH? (To tinker around with and trying e.g.).
Unless you are transcoding prior to streaming, TV Headend isn't doing any video decoding (so won't be using an h.264 or MPEG2 video decoder), that's purely a function of your client platform that is playing the video (usually Kodi - though there are also TV Headend apps)
TV Headend doesn't do any video or audio processing on the received streams unless you are transcoding (i.e. decoding and recoding the received video and audio bitstreams). By default TV Headend will just 'pass through' the h.264/h.265/MPEG2 and MP2/AAC/AC3/EAC3 audio it receives from the DVB-T/T2/S/S2/C or IP sources it has untouched.
TVH will be simply demuxing the MPEG2 transport stream to split out the service you wish to stream/record (as transponders and multiplexes are usually a single transport stream containing multiple video+audio or audio services on that tp/mux) - so if there are errors at the transport stream level, this could cause errors in TV Headends demuxing.
However the video and audio decoding (i.e. stream playback) isn't functionality that is part of regular use in TV Headend - so TV Headend doesn't need h.264 video decoders - that's all done on the client that connects to TV Headend that actually displays the video and audioo.
If you are watching in Kodi - then it's the h.264 decoder that Kodi is using that is either able to cope with concealing errors or not. If you are using hardware decoding then this may well be a function of the hardware decoding on that platform. If you are using software decoding in Kodi, then it's likely to be the decoder code that Kodi is using (which is based on ffmpeg I think). I know there has been quite a lot of effort to improve ffmpeg's ability to cope with glitchy streams (as it's used in broadcast distribution chains these days) - so software decode may improve things if your Kodi platform has the CPU power to cope with it.
AIUI some TVs will be using the same decode paths for TV Headend streams as for their own DVB-T/T2 tuners, which will be optimised to cope with error-filled streams (as they are TVs and expect errors), whereas media players are expecting clean, error-free streams, so don't have the same level of optimisation. Other TVs will use totally different paths for decode in Kodi compared to DVB streams (they may be decoded on totally different bits of silicon)
However - the core cause of this is that you have continuity errors that you shouldn't have within TV Headend and a decent satellite signal. Fix those and all the platforms will be OK. (I can go days without a single continuity error in my Kathrein SAT>IP / Astra 28.2 set-up )
I've had no major problems with Gemini Lake Celerons for TV Headend server duties. I never run the Media Playback on the same platform as the server though (I try to keep media playing and TV Headend separate). My last TV Headend SAT>IP server was based around a <£200 Chuwi Herobox and a USB 3.0 external hard drive.
No need for anything like an i3/5/7 for TV Headend duties unless you are also going to do transcoding or run other stuff on it (not recommended).
As for why you see artefacts on some platforms or others - it's likely to be that some MPEG 2 Transport Stream processors and h.264 video decoders (assuming you're watching h.264 content) are better at concealing/correcting errors than others. You see very different artefacts when watching the same errors on different playback devices.
For me it helped to deactivate Timeshift in tvheadend. This results on a slow system/server the performance and cause artifacts.
I am running tvheadend and kodi in 3 households with sat to ip with digibits.
On a digibit it helped to install a custom firmware with TCP stream instead UDP. Don't know if there is one for your kathrein
Yes - with timeshift enabled you are constantly recording (and replaying?) as well as streaming. If you are using a Pi 3B+ or earlier and timeshifting on external storage then the disk access and SAT>IP streaming will all be going over the same, single, USB 2.0 connection.
No, I am NOT using it standalone. Instead I also use it as the source/media center for my TV.
And yes, I did only try LibreElec so far. I thought this was especially geared towards the "bare minimum" as you say.
Yes - it's bare minimum for media playback duties. Once you start throwing PVR backends at it - it's not really bare minimum. It's also not optimised for that.
I'd see how you go running just Raspberry Pi OS Lite and TV Headend on a Pi 4B and see if you still get thousands of continuity errors. It's only a MicroSDc card flash away.
I wouldn't be running on a Pi 3B+ or earlier because of the USB LAN implementation that CvH mentioned. (The Pi 4B doesn't use its USB bus for LAN connectivity)
Yes - but accusing someone of unfounded alarm isn't respectfully disagreeing based on experience is it? This is a forum operated by volunteers.
A bit of respect goes a long way - rather than accusations - particularly when someone is trying to help you...
I was also taught at my universit.y that the plural of anecdote isn't anecdata...
Display Moremaybe you enabled some setting that created that problem ? normally you can keep everything at default and it should work okay at least
do you allow "idle scan" at every tuner ?
I have it just at 2/8 and this works okay without keeping all tuners busy.
I guess you overloading the satip device (I have no experience with that particular one), so it is possible that you have corrupted output at a single tuner. Depending at load this could spread to all tuners.
Could, not saying it is
If you had enabled the idle scan this might fix it.
I have the same SAT>IP tuner and ran it for 6 months constantly recording BBC One HD, BBC Two HD, ITV HD, Channel Four HD, Channel Five HD and the part time BBC Four HD channel to a TV Headend system (so I always had the last 10 days or so of those channels archived). I had very few continuity errors (most recordings were 100% error free). This was using a Celeron PC connected to the same unmanaged switch as the SAT>IP tuner.
In short, I think the alarms generated by CvH are excessive and unfounded.
Not sure what you mean by this?
CvH is a well respected contributor on these things and they're trying to help.
Continuity errors are just that - errors. AIUI they are flagged when the MPEG2 Transport Stream headers in a transport stream are discontinuous. (i.e. they indicate corruption in the received stream)
Continuity errors on directly attached tuners (i.e. USB tuners or a Pi DVB-T2 TV Hat) usually indicate poor signal - but on network attached tuners (like SAT>IP) they can also indicate network issues due to packet loss. SAT>IP is UDP-based not TCP-based - so once a packet is lost, it's lost (TCP would allow a re-request, but UDP is 'faster' as it doesn't continuously handshake)
Whatever the cause - you shouldn't be having continuity errors. Whether it's because your TV Headend server running on the Pi can't keep up (I'm assuming you're running on a Pi 4B but you don't say which model?
Also are you running TV Headend on a standalone Pi (i.e. Raspberry Pi OS - formerly Raspbian - Lite + TV Headend either installed via apt or built from source) or are you using LibreElec as your OS for your Pi TV Headend server? I'd recommend the former not the latter - as for a TV Headend server you want the bare minimum. (Media Vault + TV Headend can be a nice lightweight combo though).
Continuity errors in TV Headend mean that the stream from your SAT>IP server is not 100% error free - each one of those continuity errors is an error in the transport stream being received - which could mean corrupt video and/or audio. Different h.264 decoders will behave differently with corrupt video streams - some will mask errors better than others. You need to get rid of those continuity errors whatever you do.
I have a Kathrein EXIP 418 - though because of building work it's not currently running - but I use a Celeron Linux box as my TV Headend server platform and have it next to the Kathrein server connected via a small 8-port Ubiquiti managed switch. I have only very occasional continuity errors with that set-up. (A couple of them a day at most?)
No, Allwinner and Rockchip implements it. Main requirement is v4l2 deinterlacing driver. LE uses out-of-tree ffmpeg v4l2 deinterlace filter implementation, written mostly by me. Kodi then uses standard ffmpeg infrastructure - first it decodes frame in DRMPRIME format and if content needs deinterlacing, it pushes frame through deinterlace filter. If not, it's displayed directly. It's still considered tech demo, since there are known corner cases, which don't work (mostly frame dropping).
Thanks for the clarification, and for taking the time to post.
So the SoC has no hardware deinterlacing filter? Bummer!
Getting out of the hardware chain is probably crap...Is handing over interlaced content to be deinterlaced downstream just as crappy to achieve?
I think it's more complicated than that - which is why it's non-trivial to support it.
AIUI the Pi series are not quite typical ARM SoCs. Effectively they were designed initially as a GPU that happened to have an ARM core on it too. (My understanding is that the Videocore GPU boots first and then boots the ARM CPU - though I may be wrong)
Whatever the complexity - there is a way of running code on the Videocore GPU from the ARM CPU - and one of the routes to doing that is using an API called MMAL. GPU deinterlacing (which some may call 'hardware' deinterlacing - though in reality it's code running on the GPU rather than the CPU - which is how accelerated deinterelacing has improved over the years on the Pi series) still takes the workload away from the CPU (rather than what would be considered 'CPU' or 'software' deinterlacing where the CPU handles the code entirely.
AIUI the issue is that the new video pipeline that Linux and LibreElec are using moving forward, which avoids bespoke workarounds for different GPU/VPU architectures (instead relying on platform developers/maintainers to implement a compliant driver framework?), wouldn't allow them to graft on the old MMAL deinterlacing system?
I don't THINK this means it's the end of accelerated deinterlacing on the Pi - but it will require a Pi dev to implement it somehow?
Or has handling of interlaced content been somewhat abandoned with the new framework (I hope not - it's still used for a large chunk of ATSC and DVB TV, plus DVD and Blu-ray)
*** PEOPLE IN THIS THREAD KNOW A LOT MORE ABOUT THIS THAN ME - PLEASE CORRECT ME! ***
No change in that area. We discussed that a while ago, but adding software deinterlacing to the drmprime render chain in kodi is quite tricky...
so long,
Hias
And I guess the old MMAL stuff can't be repurposed because of the new video pipeline stuff ?
No changes regarding 10/12-bit output yet, but we just merged a huge set of kernel and ffmpeg changes. They improve H265 decoding performance, fix a couple of H264 decoding issues and add 4kp60 output.
so long,
Hias
Great progress if we have 2160p60 output support.
How is h.264 1080i interlaced support now? (I use a lot of my Pi 4Bs as DVB-T2/S2 UK TV Headend clients)
Display MoreWhich LibreELEC version are you using?
On LE10beta 4kp60 output isn't implemented yet (it's currently being worked on).
LE 9.2.6 supports 4kp60 if you add hdmi_enable_4kp60=1 to config.txt and enable "ultra hdmi deep colour" (or some similarly named option) for the HDMI port in you TV's settings.
The GPU in RPi4 is a bit underpowered for 4k rendering therefore GUI resolution is limited to HD. You can disable the limit in settings->system->display (you need to switch level to expert to see it) but then GUI navigation will be quite slow - I wouldn't recommend doing that.
Actually it's best to change the display resolution to HD (in general your TV will do better HD->4k upscaling than kodi/rpi) and enable 4k modes for video playback in the whitelist.
so long,
Hias
The Pi 4B doesn't support 4K60 HDMI output with 4:2:0 subsampling - which is the only format some UHD TVs support at 4K60. If your TV is one of them - you're unfortunately out of luck.
If your TV supports RGB (and I think YCbCr 4:4:4:) 8-bit at 4K60 then it should work OK. Similarly 4K30 and below at RGB 8-bit.
Also - some TVs support different levels of 4K on different HDMI ports. My Sony supports more on HDMI 2 and 3 than it does on HDMI 1 and 4. (Though this is usually related to 4K60 4:2:2 12-bit support - which is higher bandwidth. The Pi 4B doesn't currently support 4K60 4:2:2 output - but there is hope it will.)
