Opened 6 years ago
Closed 6 years ago
Last modified 6 years ago
#13269 closed Bug Report - General (fixed)
Active EIT scanning stops after failed tuning
| Reported by: | jmwislez | Owned by: | gigem |
|---|---|---|---|
| Priority: | minor | Milestone: | 29.2 |
| Component: | MythTV - EIT | Version: | v29.1 |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
I have a DVB-S2 adapter connected to a single LNB, pointed to Astra 23.5. I use 10 transponders on that satellite position.
What I observe is that once or twice per day, active EIT is started on that adapter, starting on a random transponder (expected). The crawling process scans successive transponders (always the same sequence), but at a certain moment reaches a transponder which it fails to tune (can happen). Following the failed tuning the crawling process stops (not good), and consequently the transponders that come directly after that one rarely get scanned (problem).
The tuned failing is because the channel data for the channel that is tuned to is outdated, after the channel moved to a different transponder. Of course correcting this channel solves the problem, but outdated channels are a reality on satellite systems with hundreds of channels and daily changes. This should not undermine a feature like EIT scanning.
At least, the crawler should move on to the next transponder after a failed tuning.
Even better, the crawler should first check whether there are other known channels on the same transponder, and try to tune these first. Not all channels on the transponder may have moved or disappeared.
Note that ticket 12106 exposes a similar problem (different cause).
Attachments (6)
Change History (17)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
I'm also seeing this behavior with a USA terrestrial channel on the edge of reception. It's easily reproduced so I spent some time troubleshooting it. It occurs with both version 29 and the git trunk, locally compiled under Debian 9 on an Intel D2700MUD, using the HDHomeRun HDHR4-2US tuner. When the EIT scanner chooses the marginal channel and it fails to obtain a signal lock, that EIT scanner is stopped and will never scan again. Since there are two tuners on the HDHR4-2US, scanning continues with the remaining tuner until it runs into the same problem. Restarting the backend is necessary to resume EIT scanning.
I am attaching a system log showing the messages obtained after running "mythbackend --setverbose all ; mythbackend --setloglevel debug" although I did remove the scheduler messages for the sake of brevity. Channel 54_1 is the marginal channel, resulting in system event TUNING_SIGNAL_TIMEOUT and ultimately the clearing of the flag EITScannerRunning. This log is from the git trunk version, with the mythconverg database cleared and setup from scratch before launching the newly compiled backend for the first time.
I'm happy to repeat this test with additional debugging or patches applied.
Changed 6 years ago by
| Attachment: | mythbackend-log1.txt added |
|---|
Log from EIT scan of channel 54_1 showing effect of TUNING_SIGNAL_TIMEOUT.
Changed 6 years ago by
| Attachment: | 13269-eit-debug1.patch added |
|---|
comment:3 Changed 6 years ago by
| Status: | new → infoneeded_new |
|---|
The attached debug1 patch might help with this problem. It's mainly intended for debugging, though. Please apply it then run the backend with "-v general,channel,eit" and post the log here.
Changed 6 years ago by
| Attachment: | mythbackend-debug1-log.txt added |
|---|
Log from mythbackend with two signal timeouts and loss of scanning, after patch 13269-eit-debug1 applied. Search for "SignalMonitor? timed out" to find failure times.
Changed 6 years ago by
| Attachment: | 13269-eit-debug2.patch added |
|---|
Changed 6 years ago by
| Attachment: | mythbackend-debug2-log.txt added |
|---|
I ran debug2 for three days without loss of EIT scanning. In earlier trials EIT scanning was lost at least daily and usually 2-3 times a day. I then turned down the antenna amplifier until signal timeouts occurred more frequently and ran debug2 in that state overnight, also without loss of EIT scanning. Attached is the log from that overnight run. I'll continue to run debug2 with a non-degraded signal and update here if anything changes, unless there are further patches to evaluate. Thanks for looking into this.
comment:5 Changed 6 years ago by
Thanks for reporting back. I'll check your log and if everything looks good, I'll commit the patch minus the extra logging.
comment:6 Changed 6 years ago by
| Milestone: | unknown → 29.2 |
|---|---|
| Resolution: | → Fixed |
| Status: | infoneeded_new → closed |
Fixed in master with commit [36a1ff5a] and in fixes/29 with commit [57757c1d].
I found this is a duplicate of 11520, which has been closed with recognition that the problem was only partly addressed.