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