Mailing List Archive

rOn Fri, 28 Apr 2023 17:27:37 +0100, you wrote:

>Hi,
>
>I have a MythTV setup that has been working very well for a few years.
>Highlights:
>- Proxmox, container with Ubuntu 20.04.
>- Hauppauge dualHD USB stick (passed through), DVB/DVB-T2
>
>Suddenly in the last few days it has stopped being able to tune into
>HD channels, but it can still tune to SD. When trying to tune to any
>HD channel, I get a timeout error:
>TuningSignalCheck: taking more than 5000 ms to get a lock. marking
>this recording as 'Failing'.
>
>The timeout was 3000ms, and I tried increasing it to 5000 but it has not helped.
>
>When tuning in MythTV Frontend, it shows:
>Signal 73%
>S/N 4.7dB
>(TLMs) Partial Lock
>
>Clearly, my hardware is still working. I appear to have decent signal
>quality. I have completely restarted all hardware to eliminate any odd
>issues there.
>
>I am not sure on where my line of enquiry should be to investigate
>further? Does anyone have any suggestions?
>
>Thanks!
>
>Karl

Here in New Zealand we have one channel ("Three") where the channel
timeout has to be at least 7000 ms for it to tune. I have all my
capturecard.channel_timeout values set to 10000. Originally,
mythbackend used to do multiple attempts at channel tuning, and with
this channel the first attempt would fail and then a later attempt
would succeed. When the tuning code was fixed to just do one tuning
attempt and obey the channel_timeout properly, Three stopped tuning
and I had to increase the channel_timeout values. With 10,000 ms, it
always tunes. I think that if you create a new database these days,
the default channel_timeout will be 10,000 ms, but if your capturecard
table was created earlier and continuously upgraded, it will have the
older default channel_timeout (3000 ms ???).

Three was not originally different from the other channels, but at
some point in its history some setting was changed in its transmitter
setup that has caused this problem. So it may be that the transmitter
setup for your HD channels has been changed similarly recently. It is
certainly worth trying very large channel_timeout values to see if it
helps.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Fri, 28 Apr 2023 at 18:30, Karl Buckland <buckland.karl@gmail.com> wrote:

> Hi,
>
> I have a MythTV setup that has been working very well for a few years.
> Highlights:
> - Proxmox, container with Ubuntu 20.04.
> - Hauppauge dualHD USB stick (passed through), DVB/DVB-T2
>
> Suddenly in the last few days it has stopped being able to tune into
> HD channels, but it can still tune to SD. When trying to tune to any
> HD channel, I get a timeout error:
> TuningSignalCheck: taking more than 5000 ms to get a lock. marking
> this recording as 'Failing'.
>
> The timeout was 3000ms, and I tried increasing it to 5000 but it has not
> helped.
>
> When tuning in MythTV Frontend, it shows:
> Signal 73%
> S/N 4.7dB
> (TLMs) Partial Lock
>
> Clearly, my hardware is still working. I appear to have decent signal
> quality. I have completely restarted all hardware to eliminate any odd
> issues there.
>
> I am not sure on where my line of enquiry should be to investigate
> further? Does anyone have any suggestions?
>
> Thanks!
>
> Karl
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


It could be that your provider has changed the signal. I suggest doing a
new channel scan.

Klaas.

On 28/04/2023 17:27, Karl Buckland wrote:
> Hi,
>
> I have a MythTV setup that has been working very well for a few years.
> Highlights:
> - Proxmox, container with Ubuntu 20.04.
> - Hauppauge dualHD USB stick (passed through), DVB/DVB-T2
>
> Suddenly in the last few days it has stopped being able to tune into
> HD channels, but it can still tune to SD. When trying to tune to any
> HD channel, I get a timeout error:
> TuningSignalCheck: taking more than 5000 ms to get a lock. marking
> this recording as 'Failing'.
>
> The timeout was 3000ms, and I tried increasing it to 5000 but it has not helped.
>
> When tuning in MythTV Frontend, it shows:
> Signal 73%
> S/N 4.7dB
> (TLMs) Partial Lock
>
> Clearly, my hardware is still working. I appear to have decent signal
> quality. I have completely restarted all hardware to eliminate any odd
> issues there.
>
> I am not sure on where my line of enquiry should be to investigate
> further? Does anyone have any suggestions?
>
> Thanks!
>
> Karl
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

Are you by any chance located in UK?  I am in the south east using the
Bluebell Hill transmitter.  My setup uses a Hauppauge WinTV-quadHD and
since Thursday have been experiencing the same as you, all previously
stable HD channels fail to tune.  I have rebooted, increased the timeout
and even done a channel rescan for that transport (PSB3/BBSB/C45) which
found all the same channels but still the channels on that transport
fail to tune.  There have been no changes to the platform (Ubuntu 18.04
| mythtv 29.1) and since all the channels on the other transports are
working fine I wasnt sure where to go next.

--

Andy


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 28/04/2023 21:40, Andy Smith wrote:
>
> On 28/04/2023 17:27, Karl Buckland wrote:
>> Hi,
>>
>> I have a MythTV setup that has been working very well for a few years.
>> Highlights:
>> - Proxmox, container with Ubuntu 20.04.
>> - Hauppauge dualHD USB stick (passed through), DVB/DVB-T2
>>
>> Suddenly in the last few days it has stopped being able to tune into
>> HD channels, but it can still tune to SD. When trying to tune to any
>> HD channel, I get a timeout error:
>> TuningSignalCheck: taking more than 5000 ms to get a lock. marking
>> this recording as 'Failing'.
>>
>> The timeout was 3000ms, and I tried increasing it to 5000 but it has
>> not helped.
>>
>> When tuning in MythTV Frontend, it shows:
>> Signal 73%
>> S/N 4.7dB
>> (TLMs) Partial Lock
>>
>> Clearly, my hardware is still working. I appear to have decent signal
>> quality. I have completely restarted all hardware to eliminate any odd
>> issues there.
>>
>> I am not sure on where my line of enquiry should be to investigate
>> further? Does anyone have any suggestions?
>>
>> Thanks!
>>
>> Karl
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>
> Are you by any chance located in UK?  I am in the south east using the
> Bluebell Hill transmitter.  My setup uses a Hauppauge WinTV-quadHD and
> since Thursday have been experiencing the same as you, all previously
> stable HD channels fail to tune.  I have rebooted, increased the timeout
> and even done a channel rescan for that transport (PSB3/BBSB/C45) which
> found all the same channels but still the channels on that transport
> fail to tune.  There have been no changes to the platform (Ubuntu 18.04
> | mythtv 29.1) and since all the channels on the other transports are
> working fine I wasnt sure where to go next.
>
I have rescanned with nothing similar. But

https://www.freeview.co.uk/help/service-updates/channel-changes-26-April-2023

John P
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 28/04/2023 23:03, John Pilkington wrote:
> On 28/04/2023 21:40, Andy Smith wrote:
>>
>> On 28/04/2023 17:27, Karl Buckland wrote:

>>
> I have rescanned with nothing similar.  But
>
> https://www.freeview.co.uk/help/service-updates/channel-changes-26-April-2023

In fact I saw the equivqlent change earlier this month. The HD
Transport ID changed from 16517 to 16518

Waltham, East Midlands

Nov 2022
Transport list before processing (7):
538000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:12294 ss:58
554000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:24640 ss:57
562000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:4166 ss:61
578000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:8200 ss:60
586000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T2 ro:0.35
onid:9018 tsid:16517 ss:62 *******
602000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:20544 ss:58
634000000 qpsk a 0 3/4 1/2 8 8 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:32780 ss:36

Today
Updated old transports (7):
538000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:12294 ss:65
554000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:24640 ss:64
562000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:4166 ss:67
578000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:8200 ss:65
586000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T2 ro:0.35
onid:9018 tsid:16518 ss:67 *******
602000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:20544 ss:62
634000000 qpsk a 0 3/4 1/2 8 8 1/32 n v fec:auto msys:DVB-T ro:0.35
onid:9018 tsid:32780 ss:41

>
> John P

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Fri, 28 Apr 2023 at 19:49, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>
>
>
> On Fri, 28 Apr 2023 at 18:30, Karl Buckland <buckland.karl@gmail.com> wrote:
>>
>> Hi,
>>
>> I have a MythTV setup that has been working very well for a few years.
>> Highlights:
>> - Proxmox, container with Ubuntu 20.04.
>> - Hauppauge dualHD USB stick (passed through), DVB/DVB-T2
>>
>> Suddenly in the last few days it has stopped being able to tune into
>> HD channels, but it can still tune to SD. When trying to tune to any
>> HD channel, I get a timeout error:
>> TuningSignalCheck: taking more than 5000 ms to get a lock. marking
>> this recording as 'Failing'.
>>
>> The timeout was 3000ms, and I tried increasing it to 5000 but it has not helped.
>>
>> When tuning in MythTV Frontend, it shows:
>> Signal 73%
>> S/N 4.7dB
>> (TLMs) Partial Lock
>>
>> Clearly, my hardware is still working. I appear to have decent signal
>> quality. I have completely restarted all hardware to eliminate any odd
>> issues there.
>>
>> I am not sure on where my line of enquiry should be to investigate
>> further? Does anyone have any suggestions?
>>
>> Thanks!
>>
>> Karl
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>
>
> It could be that your provider has changed the signal. I suggest doing a new channel scan.
>
> Klaas.
>
>


I've done a full rescan - which definitely worked because it's renamed
some of the channels and changed their IDs. The console output shows
that it detected plenty of channels, including the HD channels I would
expect.

Unfortunately I still can't view the HD channels - but I can still
view the SD channels.

I've stopped mythtv-backend, and used dvbv5-scan and dvbv5-zap to
successfully record a few seconds of an HD channel that I can't view
through MythTV. So this would suggest that my hardware, drivers, etc
are all working fine. Signal must be fine?

Why would this have suddenly stopped working only a few days ago?

Here's the relevant log lines from my mythbackend.log:

Apr 29 15:42:51 bender mythbackend: mythbackend[534]: I TVRecEvent
tv_rec.cpp:1057 (HandleStateChange) TVRec[1]: Changing from None to
WatchingLiveTV
Apr 29 15:42:51 bender mythbackend: mythbackend[534]: I TVRecEvent
tv_rec.cpp:3662 (TuningFrequency) TVRec[1]: TuningFrequency
Apr 29 15:42:52 bender mythbackend: mythbackend[534]: I TVRecEvent
cardutil.cpp:1173 (SetDeliverySystem) CardUtil[1]: Set delivery
system: DVB-T2
Apr 29 15:42:52 bender mythbackend: mythbackend[534]: N CoreContext
autoexpire.cpp:242 (CalcParams) AutoExpire: CalcParams(): Max required
Free Space: 3.0 GB w/freq: 14 min
Apr 29 15:42:52 bender mythbackend: mythbackend[534]: N TVRecEvent
recordinginfo.cpp:678 (ApplyRecordRecGroupChange)
ApplyRecordRecGroupChange: LiveTV to LiveTV (2)
Apr 29 15:42:59 bender mythbackend: mythbackend[534]: E TVRecEvent
tv_rec.cpp:3967 (TuningSignalCheck) TVRec[1]: TuningSignalCheck: Hit
pre-fail timeout
Apr 29 15:43:02 bender mythbackend: mythbackend[534]: W TVRecEvent
tv_rec.cpp:3995 (TuningSignalCheck) TVRec[1]: TuningSignalCheck:
taking more than 10000 ms to get a lock. marking this recording as
'Failing'.
Apr 29 15:43:02 bender mythbackend: mythbackend[534]: W TVRecEvent
tv_rec.cpp:4000 (TuningSignalCheck) TVRec[1]: See 'Tuning timeout' in
mythtv-setup for this input
Apr 29 15:43:04 bender mythbackend: mythbackend[534]: I TVRecEvent
tv_rec.cpp:1057 (HandleStateChange) TVRec[1]: Changing from
WatchingLiveTV to None
Apr 29 15:43:04 bender mythbackend: mythbackend[534]: I
MythSocketThread(84) mainserver.cpp:7858 (connectionClosed) Playback
sock(56445bd4f1a0) 'bender' disconnected

Any further suggestions or areas to investigate please?
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 28/04/2023 23:37, John Pilkington wrote:
> On 28/04/2023 23:03, John Pilkington wrote:
>> On 28/04/2023 21:40, Andy Smith wrote:
>>>
>>> On 28/04/2023 17:27, Karl Buckland wrote:
>
>>>
>> I have rescanned with nothing similar.  But
>>
>> https://www.freeview.co.uk/help/service-updates/channel-changes-26-April-2023
>>
>
> In fact I saw the equivqlent change earlier this month.  The HD
> Transport ID changed from 16517 to 16518
>
> Waltham, East Midlands
>
> Nov 2022
> Transport list before processing (7):
> 538000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:12294 ss:58
> 554000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:24640 ss:57
> 562000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:4166 ss:61
> 578000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:8200 ss:60
> 586000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T2 ro:0.35
> onid:9018 tsid:16517 ss:62    *******
> 602000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:20544 ss:58
> 634000000 qpsk a 0 3/4 1/2 8 8 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:32780 ss:36
>
> Today
> Updated old transports (7):
> 538000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:12294 ss:65
> 554000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:24640 ss:64
> 562000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:4166 ss:67
> 578000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:8200 ss:65
> 586000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T2 ro:0.35
> onid:9018 tsid:16518 ss:67   *******
> 602000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:20544 ss:62
> 634000000 qpsk a 0 3/4 1/2 8 8 1/32 n v fec:auto msys:DVB-T ro:0.35
> onid:9018 tsid:32780 ss:41
>
>>
>> John P

Hi John,

Thanks for the tip, I assumed that because the scan of that transport
found all the expected channels, the transport itself must have been
correctly configured.  I looked in the channelscan_channel table and
sure enough, the HD Transport ID has changed from 16515 to 16524 but
this has not been updated in the dtv_multiplex table.

mysql> SELECT `scanid`, `mplex_id`, `service_name`, `chan_num`,
`service_id`, `sdt_tsid` FROM `channelscan_channel` WHERE `scanid` =
'34' AND `mplex_id` = '7' AND `sdt_tsid` > '0';

+--------+----------+---------------+----------+------------+----------+
| scanid | mplex_id | service_name  | chan_num | service_id | sdt_tsid |
+--------+----------+---------------+----------+------------+----------+
|     34 |        7 | BBC TWO HD    | 102      |      17472 | 16524 |
|     34 |        7 | BBC ONE SE HD | 101      |      17548 | 16524 |
|     34 |        7 | ITV1 HD       | 103      |      17603 | 16524 |
|     34 |        7 | Channel 4 HD  | 104      |      17664 | 16524 |
|     34 |        7 | Channel 5 HD  | 105      |      17728 | 16524 |
|     34 |        7 | BBC THREE HD  | 109      |      17920 | 16524 |
|     34 |        7 | BBC FOUR HD   | 106      |      18048 | 16524 |
|     34 |        7 | CBBC HD       | 204      |      18112 | 16524 |
|     34 |        7 | CBeebies HD   | 205      |      18176 | 16524 |
|     34 |        7 | TBN UK        | 66       |      20160 | 16524 |
|     34 |        7 | 5SELECT       | 56       |      20256 | 16524 |
+--------+----------+---------------+----------+------------+----------+
11 rows in set (0.00 sec)

mysql>

After updating the transportid for mplexid 7 in the dtv_multiplex table
and restarting the backend, all the HD channels are working once more.

Thanks again.
--
Andy

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sat, 29 Apr 2023 at 18:50, Andy Smith <a.b.smith@shadymint.com> wrote:

>
> On 28/04/2023 23:37, John Pilkington wrote:
> > On 28/04/2023 23:03, John Pilkington wrote:
> >> On 28/04/2023 21:40, Andy Smith wrote:
> >>>
> >>> On 28/04/2023 17:27, Karl Buckland wrote:
> >
> >>>
> >> I have rescanned with nothing similar. But
> >>
> >>
> https://www.freeview.co.uk/help/service-updates/channel-changes-26-April-2023
> >>
> >
> > In fact I saw the equivqlent change earlier this month. The HD
> > Transport ID changed from 16517 to 16518
> >
> > Waltham, East Midlands
> >
> > Nov 2022
> > Transport list before processing (7):
> > 538000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:12294 ss:58
> > 554000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:24640 ss:57
> > 562000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:4166 ss:61
> > 578000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:8200 ss:60
> > 586000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T2 ro:0.35
> > onid:9018 tsid:16517 ss:62 *******
> > 602000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:20544 ss:58
> > 634000000 qpsk a 0 3/4 1/2 8 8 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:32780 ss:36
> >
> > Today
> > Updated old transports (7):
> > 538000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:12294 ss:65
> > 554000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:24640 ss:64
> > 562000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:4166 ss:67
> > 578000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:8200 ss:65
> > 586000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T2 ro:0.35
> > onid:9018 tsid:16518 ss:67 *******
> > 602000000 auto 0 0 auto auto 8 a 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:20544 ss:62
> > 634000000 qpsk a 0 3/4 1/2 8 8 1/32 n v fec:auto msys:DVB-T ro:0.35
> > onid:9018 tsid:32780 ss:41
> >
> >>
> >> John P
>
> Hi John,
>
> Thanks for the tip, I assumed that because the scan of that transport
> found all the expected channels, the transport itself must have been
> correctly configured. I looked in the channelscan_channel table and
> sure enough, the HD Transport ID has changed from 16515 to 16524 but
> this has not been updated in the dtv_multiplex table.
>
> mysql> SELECT `scanid`, `mplex_id`, `service_name`, `chan_num`,
> `service_id`, `sdt_tsid` FROM `channelscan_channel` WHERE `scanid` =
> '34' AND `mplex_id` = '7' AND `sdt_tsid` > '0';
>
> +--------+----------+---------------+----------+------------+----------+
> | scanid | mplex_id | service_name | chan_num | service_id | sdt_tsid |
> +--------+----------+---------------+----------+------------+----------+
> | 34 | 7 | BBC TWO HD | 102 | 17472 | 16524 |
> | 34 | 7 | BBC ONE SE HD | 101 | 17548 | 16524 |
> | 34 | 7 | ITV1 HD | 103 | 17603 | 16524 |
> | 34 | 7 | Channel 4 HD | 104 | 17664 | 16524 |
> | 34 | 7 | Channel 5 HD | 105 | 17728 | 16524 |
> | 34 | 7 | BBC THREE HD | 109 | 17920 | 16524 |
> | 34 | 7 | BBC FOUR HD | 106 | 18048 | 16524 |
> | 34 | 7 | CBBC HD | 204 | 18112 | 16524 |
> | 34 | 7 | CBeebies HD | 205 | 18176 | 16524 |
> | 34 | 7 | TBN UK | 66 | 20160 | 16524 |
> | 34 | 7 | 5SELECT | 56 | 20256 | 16524 |
> +--------+----------+---------------+----------+------------+----------+
> 11 rows in set (0.00 sec)
>
> mysql>
>
> After updating the transportid for mplexid 7 in the dtv_multiplex table
> and restarting the backend, all the HD channels are working once more.
>
> Thanks again.
> --
> Andy
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


The best way to scan again, especially with older versions of MythTV, is to
create a new video source, connect the driver(s) to that video source and
then do a full scan. There have been considerable changes in channel
scanning in MythTV since v31 and I think that at least with version 33
scanning should be perfect and also changed transport IDs are correctly
processed. If not, please create a Github issue for this (
https://github.com/MythTV/mythtv/issues) and it will get fixed.

Klaas.