Project

General

Profile

Forums » Tutorial and setups »

[Solved] Mux Scan Fails & Continuity Errors

Added by Martin Walter almost 9 years ago

I'm running TVH 4.1.988 on a Synology NAS. Two quad tuners, one on 19.2E, the other on 28.2E, are connected to my Digibit R1 SAT>IP server via a multiswitch. I have been struggeling with continuity errors from time to time. They are mostly limited when watching Live-TV, but have been affecting recordings heavily sometime. I'm aware of the limitations of the original SAT>IP server firmware, have tried the axe firmware, but that only made it worse. I'm back to the original firmware now. In order to troubleshoot these bigger issues, and to reduce the number of variables, I'd like to first make sure my TVH configuration is ok.

One thing I realized is that I collect most of continuity errors during epg grabbing (I only use OTA grabbers). I have plenty of failed muxes in my configuration, to be precise: 69 failed muxes on Astra 28.2E and 15 on Astra 19.2E. You see examples in the attached snapshot. I cannot see a clear pattern, sometimes muxes on a given frequency "just" fail. A lot of them come with original network ID and TSID = 65535. Another "mini-pattern" I have seen, is with different muxes on the same frequency, where one succeeds, and the others fail. This even happens when the frequency correspond to different networks, i.e. satellite positions (see 12640V example in the snapshot). It looks as if the scans would "interfere" across networks and satellite positions. Might be coincidence, but I have seen that several times.

Does this look "normal" to you, or do you think something's wrong with my configuration?

Bild1.jpg (335 KB) Bild1.jpg Snapshot of mux configuration

Replies (4)

RE: Mux scan fails - Added by Martin Walter almost 9 years ago

I went through all the failed muxes now and compared the settings with those on www.satindex.de.

What I found:
(1) Some muxes corresponded to frequencies that simply don't exist or don't exist anymore. I deleted those.
(2) Some muxes corresponded to frequencies that do exist but were misconfigured. When inserting the settings from satindex.de I had mixed outcomes after scanning that mux (switching scan status to "active" for that mux and saving):
a) Mux scanned correctly and delivered new services
b) Mux scanned and delivered "OK partial". I kept those.
c) Mux still failed. Actually not that many. But I kept those too. Maybe the weather. It is snowing.
(3) Some muxes were duplicates (on the same satellite), where one copy scanned ok and the other one failed. I found that the failed ones were misconfigured. Here I simply deleted the failed one.

I'm down now to 13 failed muxes, only 1 on 19.2E, the remaining 12 on 28.2E. In addition I'm left with 5 partial OKs on 19.2E.

I think some of this is due to my initial install, because I imported the pre-configured network lists, which probably contained outdated "ghost" entries. I think another reason is the network discovery function, which might(!) have added muxes incorrectly or created duplicates. Not sure. I had it activated initially, but already deactivated it some time ago.

Another interesting observation: My wife is watching TV on transponder #1. Whenever I manually triggered a scan of a mux on another transponder, I produced some continuity errors on transponder #1. Not a lot, just a couple, but enough to briefly distort the movie.

RE: Mux scan fails - Added by Mark Clarkstone almost 9 years ago

Martin Walter wrote:

I went through all the failed muxes now and compared the settings with those on www.satindex.de.

What I found:
(1) Some muxes corresponded to frequencies that simply don't exist or don't exist anymore. I deleted those.
(2) Some muxes corresponded to frequencies that do exist but were misconfigured. When inserting the settings from satindex.de I had mixed outcomes after scanning that mux (switching scan status to "active" for that mux and saving):
a) Mux scanned correctly and delivered new services
b) Mux scanned and delivered "OK partial". I kept those.
c) Mux still failed. Actually not that many. But I kept those too. Maybe the weather. It is snowing.
(3) Some muxes were duplicates (on the same satellite), where one copy scanned ok and the other one failed. I found that the failed ones were misconfigured. Here I simply deleted the failed one.

I'm down now to 13 failed muxes, only 1 on 19.2E, the remaining 12 on 28.2E. In addition I'm left with 5 partial OKs on 19.2E.

I think some of this is due to my initial install, because I imported the pre-configured network lists, which probably contained outdated "ghost" entries. I think another reason is the network discovery function, which might(!) have added muxes incorrectly or created duplicates. Not sure. I had it activated initially, but already deactivated it some time ago.

Network discovery and presets is never a good idea, the lists are so out of date, it's always best to use NIT as it usually prevents duplication, even the slightest difference in frequencies between the NIT and the presets and Tvheadend will see it as a new mux (I've ran into this problem on DVB-T).

Look at your muxes list and pick a couple that are "OK" then delete them all and re-add. You will get some muxes that'll FAIL even some in the NIT. I have a total of 4 Failed on 28E.

Another interesting observation: My wife is watching TV on transponder #1. Whenever I manually triggered a scan of a mux on another transponder, I produced some continuity errors on transponder #1. Not a lot, just a couple, but enough to briefly distort the movie.

Cheap cabling? poor insulation? Have you set up the SAT->IP Server to turn off LNBs when idle?

RE: Mux scan fails - Added by Martin Walter almost 9 years ago

Mark Clarkstone wrote:

Network discovery and presets is never a good idea, the lists are so out of date, it's always best to use NIT as it usually prevents duplication, even the slightest difference in frequencies between the NIT and the presets and Tvheadend will see it as a new mux (I've ran into this problem on DVB-T).

Look at your muxes list and pick a couple that are "OK" then delete them all and re-add. You will get some muxes that'll FAIL even some in the NIT. I have a total of 4 Failed on 28E.

Yes, I learned that the hard way too now. Will start all over with a fresh install when 4.2 finally arrives, but will definitely do it your way then. And use bouquets... :-)

Another interesting observation: My wife is watching TV on transponder #1. Whenever I manually triggered a scan of a mux on another transponder, I produced some continuity errors on transponder #1. Not a lot, just a couple, but enough to briefly distort the movie.

Cheap cabling? poor insulation? Have you set up the SAT->IP Server to turn off LNBs when idle?

I don't have idleing options for my LNBs I suppose. And I had a specialist install my system, but I guess I cannot exclude cabling issues at this stage. The original firmware could be an issue, but had even more issues with the AXE firmware. I have also read that switches can cause continuity errors.

In any case, many thanks for your advice, Mark. I feel reasonably comfortable with my base configuration now to explore further. And that is what I wanted to achieve. I think I will replace my switch next. Is is an old 5-port and I will need an 8-port soonish anyways. If that doesn't work, I will try the AXE firmware again and hope to get perexg to help me with the configuration. The advent of new configuration options clearly outruns any kind of documentation... :-)

RE: [Solved] Mux scan fails - Added by Martin Walter almost 9 years ago

Just a follow-up for those who might face similar issues...

I believe the problem was multi-factorial:
1) I replaced the old low-budget switch by a Netgear GS108, which reduced but did not eliminate the cc errors.
2) I figured out that most cc errors were still generated through EIT EPG grabbing. I deleted the epgdb.v2 file, which again reduced the cc errors (stil "orphan" entries?), but did not eliminate them.
3) I replaced the original firmware by perexg's SatIP Axe firmware, changed from a fixed IP configuration to DHCP and added "Skip TS packets" to 30 in the TV adapter configuration of the TVH backend. Restarted the backend, all cc errors gone!

    (1-4/4)