[mythtv-users] USA OTA FCC frequency rescan?
digitalaudiorock at gmail.com
Tue Aug 13 16:43:37 UTC 2019
On 8/13/19, Klaas de Waal <klaas.de.waal at gmail.com> wrote:
> On Tue, 13 Aug 2019 at 16:05, James Abernathy <jfabernathy at gmail.com> wrote:
>> On 8/13/19 9:53 AM, Jay Harbeston wrote:
>> >> On Aug 13, 2019, at 9:12 AM, James Abernathy <jfabernathy at gmail.com>
>> >> wrote:
>> >>> On Aug 13, 2019, at 8:18 AM, Justin Alcorn <justin at jalcorn.net> wrote:
>> >>> Once you create the file with the sql statements, do:
>> >>> mysql -u [mythtvusername] -p mythconverg < [sqlcommandsfilename]
>> >>> it'll prompt for the database password
>> >>> --
>> >>> Justin B. Alcorn
>> >>> The views expressed are not necessarily my own, much less anyone
>> >>> else's
>> >>> PGP Fingerprint CCEB F776 C3FD 1050 C8DB 532E B8B9 BED7 7764 406C
>> >> Thanks,
>> >> I will be out of town on the day the rescan is needed. So this all
>> >> looks simple enough to do via ssh thru my home VPN remotely. If it
>> >> works great, but if it doesn’t then I don’t get some recordings. No
>> >> difference if I just ignored the rescan till I got home.
>> >> It’s worth a shot anyway.
>> > Note that you will have to do the rescan from within the mythtv-setup
>> > Graphical utility. This will be difficult to do over a ssh connection
>> > and ( I assume) a windows PC.
>> > Regards
>> I routinely use my Macbook pro to ssh -Y into my mythtv-backend to run
>> mythtv-setup. So that should work for this.
>> As to Windows? What's that? :-) When I turned in my company Laptop
>> when I retired, that's the last time I used Windows. I can run Windows
>> XP in a Virtual machine on my Ubuntu desktop or Macbook, but why. :-)
> About mythtv-setup creating new channels or updating old channels.
> In a nutshell it works like this (as I understand it).
> A channel found in a scan is considered an old channel if the
> transport/multiplex has the same frequency and if the ATSC major and
> minor channel numbers are the same. In that case the existing
> callsign, channel name etc are replaced by the values from the scan
> but the xmltvid is preserved.
> This means that if channels, even if they keep the major/minor
> numbers, are on another multiplex after the update they will be seen
> as new channels.
> The callsign is relevant for programming/scheduling/recording but it
> is not used by mythtv-setup for identifying a channel so there is no
> need to edit it before doing a scan.
> If this is not the way that it should be then it is always possible to
> create a ticket with a description on how the channel update behavior
> should be. The question of what identifies "the same channel" needs to
> be addressed there.
> Note that I have not tested this because I do not live in ATSC land,
> but with DVB it works along the same lines, with channels identified
> by network ID and service ID.
> - channelinfo.cpp:445 function ChannelInsertInfo::IsSameChannel
> - channelimporter.cpp:968 function ChannelImporter::GetDBTransports
> Success with the update!
Wow...Thanks for replying, as I was wildly mistaken if that's the case.
I actually just hunted down an old list thread on this, and I may have
been confusing this with changing callsigns of newly created channels
to match the callsign on exiting recording rules (in cases where the
callsign changed) in order to get the recording rules working. I also
happen to use a lot of rules with the "this channel" filter, which
complicates things. I use that for cases where I temporarily enable
channels in Philadelphia (which requires turning my antenna almost 180
degrees) to prevent those from getting used in the scheduling.
This all makes me even more glad that I've written my own stuff to
change frequencies and PIDs surgically on existing channels. I got
through the many changes around here on 8/1 really well that way. Even
if recording rules work correctly, unwanted new channel ids become
quite a mess as I recall...for example with the channels etc displayed
for existing recordings.
More information about the mythtv-users