[mythtv-users] Mux-shifting. DVB-T retune

[Klaas de Waal]

On Sat, 14 Mar 2020 at 18:28, John Pilkington <johnpilk222 at gmail.com> wrote:

> On 14/03/2020 15:18, John Pilkington wrote:
> > On 14/03/2020 13:14, John Pilkington wrote:
> >> On 14/03/2020 12:25, Klaas de Waal wrote:
> >>>
> >>>
> >>> On Sat, 14 Mar 2020 at 12:04, John Pilkington <johnpilk222 at gmail.com
> >>> <mailto:johnpilk222 at gmail.com>> wrote:
> >>>
> >>>     On 04/03/2020 14:48, John Pilkington wrote:
> >>>
> >>>       >
> >>>       > The DVB-T/T2 scans did not find the new QAM-256 transports
> >>>       > automatically, and a full scan looked as if it would take a
> long
> >>>     time.
> >>>       > I'm afraid I let the TV tell me the new frequencies.
> >>>       >
> >>>       > "700 Mhz clearance"  ->  DVB-T2 now on 586, 746 and 754 MHz
> >>>       >
> >>>
> >>>     I have a new problem with DVB-T2 and last night's master,
> >>> 2e9f884.  I'm
> >>>     not sure when it started.
> >>>
> >>>     After last week's retune I had 3 DVB-T2 transports, with channels.
> >>>     Their frequencies are quoted above.  In current scans only two are
> >>>     populated.  746 MHz gives no channels. VLC, also using the MyGica
> >>> 230
> >>>     tuner, has the same problem with just that mux.
> >>>
> >>>     My TV finds and plays these channels. One is BBC NEWS HD.
> >>>
> >>>     There's a new commit, 405e049, that may affect this.  I'll start a
> >>>     build.
> >>>
> >>> When VLC also has problems there might have been something changed in
> >>> the multiplex.
> >>> You could try with the "Complete scan data required" option unchecked
> >>> (by default it is checked).
> >>> A complete log of the scan, capturing the terminal output of
> >>> mythtv-setup like this:
> >>>
> >>> mythtv-setup -v chanscan,channel,record --loglevel=debug 2>&1 | tee
> >>> ms-20200314-1321.log
> >>>
> >>> is what I need to figure out what is happening. This will be too big
> >>> for the mailing list but it can be sent to me directly.
> >>>
> >>> BTW the latest commit changes the numbering scheme for duplicate
> >>> channels. It will not influence the scanning itself.
> >>>
> >>> Klaas.
> >>
> >> I have the new build and will experiment soon.  I forgot to say that
> >> the scans reported No Lock, with all the options I tried.
> >>
> >> There are political moves to stop open access in the future.  May be
> >> ominous.
> >>
> > Hope this helps
> >
> > https://drive.google.com/open?id=1SW5c-KbgpghSSvqhs5walkD6-MLJ13Zs
>
> It probably won't, because it didn't get lock on the transport giving
> the problem.
>
> So I tried a frequency offset. and got lock with 746.1 MHz.  It saw
> channels but apparently didn't update the DB (probably because I had
> cheated by editing another transport with the wrong transportid).
>
> Deleted and created a new transport at 746166000 Hz, and one more 'all
> transports' scan looks OK.
>
> I suppose a full scan might have been quicker.  I haven't dared to look
> at the chanids :-)
> >
>
> Yes, a full scan in the UK does try also the offset frequencies..... so
the frequency was the problem. Glad that it is solved.

While at the subject of doing a full scan, would it be possible for you to
do a full scan with again the full debug?
Goal of this is to figure out if and how to automatically remove duplicate
transports received "on the back of the antenna" from other transmitters.
To prevent messing up your working system, you could do the following:
- create a new video source
- connect your MyGIca to the new video source
- do a full scan (-v chanscan,channel,record --loglevel=debug) for the new
video source and capture the output
- then just delete the video source, this also deletes all the new
transports and channels
- reconnect your MyGica to the videos source it was connected to previously
so your system works again.

No hurry on my side, but while we are at it....

Thanks!
Klaas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200314/12ae113e/attachment.htm>