Opened 6 years ago
Closed 4 years ago
#13257 closed Bug Report - General (Fixed)
Auto-tune of HD channels fails but works when transponders manually added
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | 31.0 |
Component: | MythTV - Channel Scanner | Version: | v29.0 |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
Internet searches reveal that a failure to tune HD channels is not uncommon. Having identified the following workaround for PCTV 290e HD auto-tuning fail works for me (this is post Crystal Palace (UK) Mar 18 changes that also required a new wide-band aerial), sharing this may help others resolve their own difficulties and perhaps even help developers reduce the likelihood of HD channel scan failure.
Symptoms: Post Crystal Palace changes need to retune my MythTV to locate changed HD channels. However, MythTV auto-tune fails to pick them up. Neither does TVheadend nor w_scan. w-scan does find the MUX/transponder but not the channels within. When I insert the 290e into my Windows laptop (running PCTV's TVCenter 6.4.9.1033) it finds the new HD channels automatically with a reported signal strength of > 80%. The issue is therefore not my aerial, too high or too low a signal but something software related on my arch linux arm box (4.4.47-1-ARCH armv5tel) common to the autoscan detection process in MythTV, TVheadend and w_scan.
Workaround: Autodetect of the HD channels is no longer working (it did before the recent Crystal Palace changes). However, manually adding the MUXs/transports to MythTV/TVheadend etc and specifying that they are QAM256 modulation and 8Mhz bandwidth (rather than leaving them both at Auto) does enable both MythTV and TVheadend to discover the channels on the HD MUXes/transportes.
I don't know why auto-detect does not work nor why specifying the modulation and bandwidth manually solves my problem, but am happy to offer my setup as a reproducible testbed for any expert willing to investigate the matter further.
Change History (4)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
Channel number assignation worked perfectly for me once MythTV and TVheadend processed the new transports.
comment:3 Changed 6 years ago by
Just to add to this - I had the same problem in Malvern when the frequencies changed recently. The problem was that all the frequencies were detected, but the scanner seemed to randomly assign the MUX as DVBT or DVBT2. So the process I ended up using was:
- delete all the existing channels
- do a full scan - this found all 6 MUXs but about 4 were incorrectly assigned as DVBT2 rather than DVBT (or vice versa)
- edit the transports to set the correct DVBT/DVBT2 assignments
- do a scan of existing transports
- watch TV!
comment:4 Changed 4 years ago by
Milestone: | needs_triage → 31.0 |
---|---|
Resolution: | → Fixed |
Status: | new → closed |
Channel scanning is improved in the development of mythtv v31 and the problem reported here should be fixed now. Therefore this ticket is now closed. If the problem appears again with mythtv v31 or later then please re-open this ticket or create a new one.
I have the same PCTV 290e and have 'always' used it this way, usually retuning with the 'all known transports,' 'ignore timeouts' and 'follow links to other transports' settings. But this doesn't work well when mux characteristics change or new QAM256 muxes are added, as happened recently (700 MHz clearance) or for the Olympics. IIUC inter-channel signalling doesn't find DVB-T2 muxes, so good up-to-date internet info is perhaps best.
Currently my scans with this device (master, F26) do not correctly assign Freeview channel numbers - but did so the last time I tried it under (master, kubuntu). I get good SD channel numbers from my PCI SD-only tuner, and 'O' from the programme guide now shows 2*SD and 1*HD option.... Ticket #13222