[mythtv-users] Guidance for phase 9

Tue Aug 13 18:48:14 UTC 2019

On Tue, 13 Aug 2019 at 18:52, Tom Dexter <digitalaudiorock at gmail.com> wrote:
>
> On 8/13/19, Allen Edwards <allen.p.edwards at gmail.com> wrote:
> > On Tue, Aug 13, 2019 at 8:07 AM Tom Dexter <digitalaudiorock at gmail.com>
> > wrote:
> >
> >> On 8/13/19, Tom Dexter <digitalaudiorock at gmail.com> wrote:
> >> > On 8/12/19, Allen Edwards <allen.p.edwards at gmail.com> wrote:
> >> >> On Mon, Aug 12, 2019 at 1:26 PM Tom Dexter
> >> >> <digitalaudiorock at gmail.com>
> >> >> wrote:
> >> >>
> >> >>> On 8/12/19, Allen Edwards <allen.p.edwards at gmail.com> wrote:
> >> >>> > In planning for Phase 9 channel reassignments scheduled for next
> >> >>> > year
> >> >>> > I
> >> >>> > found this quote (paraphrase):
> >> >>> >
> >> >>> > "MythTV rescan is just too difficult so I did it manually and it
> >> >>> > only
> >> >>> took
> >> >>> > 4 hours"
> >> >>> >
> >> >>> > Not what I wanted to find. Can someone point me to how this should
> >> >>> > be
> >> >>> done.
> >> >>> > Specifically, I find four possibilities on how this might be done
> >> >>> > in
> >> >>> > two
> >> >>> > menus:
> >> >>> > In Connect Source to Inputs
> >> >>> > 1) Scan for Channels
> >> >>> > 2) Fetch channels from Listing Source
> >> >>> >
> >> >>> > In Channel Editor
> >> >>> > 1) Channel Scan
> >> >>> > 2) Edit Transports
> >> >>> >
> >> >>> > I have learned the hard way not to just experiment so I am asking
> >> >>> > for
> >> >>> > guidance.
> >> >>> >
> >> >>> > I have two HD Homerun dual tuners (first generation) so I have four
> >> >>> capture
> >> >>> > cards listed and connected to a single Video Source called "Antenna
> >> >>> North"
> >> >>> > which is linked to Schedules Direct. All the capture cards are
> >> >>> > apparently
> >> >>> > set up as MPEG2TS.
> >> >>> >
> >> >>> > My system is Mythbuntu 14.04.1 LTS and MythTV fixes/0.28
> >> >>> >
> >> >>> > Is there some documentation or can someone give me some specific
> >> >>> > guidance
> >> >>> > for doing the required rescan or other channel reassignment
> >> >>> > process.
> >> >>> >
> >> >>> > Allen
> >> >>> >
> >> >>>
> >> >>> I just replied to a thread from James Abernathy with the subject "USA
> >> >>> OTA FCC frequency rescan?" that you may want to check out. As far as
> >> >>> I
> >> >>> know, the biggest pitfall of the channel rescan in mythtv-setup is
> >> >>> the
> >> >>> possibility of new channels getting created when you really want to
> >> >>> just change the frequency of existing channels. This (also as far as
> >> >>> I
> >> >>> know) is caused by the station changing the callsign that gets
> >> >>> reported from the signal itself.
> >> >>>
> >> >>> Assuming you have something that can be used to just scan channels to
> >> >>> a file as I describe in that reply, you should be able to use the
> >> >>> channel editor to change and callsigns to the new ones before doing
> >> >>> the rescan to prevent that.
> >> >>>
> >> >>> I'm actually one of those who's written utilities of my own to
> >> >>> manually change frequencies surgically, but again, I believe those
> >> >>> callsign changes are the main source of unwanted results.
> >> >>>
> >> >>> Tom
> >> >>>
> >> >>>
> >> >> I am not sure I understand the call signs of these stations. Let me
> >> >> give
> >> >> an
> >> >> example.  Channel 7_3 in MythTV Channel infor is LAFFTV.  In HDHomeRun
> >> >> (under windows) it is also LAFFTV. In Schedules Direct it is KGODT3
> >> >> and
> >> >> the channel that overwrites it is KGOLD3. I think I should ignore the
> >> >> SD
> >> >> name.
> >> >>
> >> >> I did hdhomerun_config 10126134 scan /tuner1 filescan and for the
> >> >> above
> >> >> channel I get two listings
> >> >> Channel 35 Program 5 7.3 LAFFTV
> >> >> Channel 7 Program 5 7.3 LAFFTV
> >> >>
> >> >> That is the problem I always have with scan. I end up with channel 35
> >> and
> >> >> I
> >> >> want channel 7. According the the repack guidance I am seeing, 7 will
> >> >> move
> >> >> to 12 and 35 stays put. This will still give ma a problem when I scan.
> >> >> I
> >> >> think I just rescanned and interrupted it before the overwrite but I
> >> >> am
> >> >> not
> >> >> sure.
> >> >>
> >> >> So just to clarify, you are suggesting checking that LAFFTV and all
> >> >> the
> >> >> other channels to check for name changes then just do a rescan and
> >> figure
> >> >> out how to deal with channel 7.
> >> >>
> >> >> It looks like the repack will move 4 stations we watch.
> >> >>
> >> >> Channel 35 comes to the back of my antenna and is weak. It has the
> >> >> same
> >> >> program information as channel 7.
> >> >>
> >> >> Allen
> >> >>
> >> >
> >> > Wow...I'm a bit confused as to what you're saying. Here's an example
> >> > what my output from the scan looks like:
> >> >
> >> > SCANNING: 599000000 (us-bcast:35)
> >> > LOCK: 8vsb (ss=92 snq=98 seq=100)
> >> > TSID: 0x07D5
> >> > PROGRAM 1: 4.1 WNBC
> >> > PROGRAM 2: 4.2 COZI-TV
> >> > PROGRAM 3: 47.1 WNJU-HD
> >> > PROGRAM 4: 47.2 TeleX
> >> >
> >> > That PROGRAM reported there (stored as the serviceid on the channels
> >> > table) is always unique for the specific frequency and defines the
> >> > specific channel on the multiplex. What's the exact output you're
> >> > getting? It sounds like you're saying you get the same channel and
> >> > callsign (7.3  LAFFTV) on two completely different frequencies. If so
> >> > that's pretty ugly and I have no clue how or if the channel scan would
> >> > deal with that.
> >> >
> >> > As to the callsign reported by SD that should have no affect on
> >> > anything related to the scan. As mentioned above, the only connection
> >> > between the MythTV channels and XMLTV is the xmltvid on the channel.
> >> >
> >> > Tom
> >> >
> >>
> >> Sorry...clearly didn't read you're reply carefully enough. It sounds
> >> like that's exactly what you're saying. I assume  that when you refer
> >> to channel 7 and 35 you mean the VHF channel 7 and UHF channel 35.
> >>
> >> Wow, yea that's a tough one, and I've never encountered that. Maybe
> >> someone else here knows what might happen in that case.
> >>
> >> Tom
> >> _______________________________________________
> >>
> >
> > Yes, I am referring to transmitter channel 7 and 35.  After the repack they
> > will be transmitter channel 12 from San Francisco and transmitter channel
> > 35 from San Jose. I live between the two.  They both carry the same
> > programming and both are virtual channel 7. What happens is that you end up
> > with transmitter channel 35 and nothing for channel 7.
> >
> > What I remember for sure is that it was a problem because I want
> > transmitter 7 and after the scan I got transmitte 35, which is weak.  I
> > think I repeated the scan to clear it.  I don't recall if the scan started
> > at the high end, got 35 and then ignored 7 or if it started at the low end
> > and when it got to 35 it overwrote 7. My forensics indicate that I started
> > the final scan on 7.1 so once I know which way the scan works, I will know
> > what I did.
> >
> > Perhaps I could have renamed the channels from transmitter 35 to something
> > other than 7 and then deleted them after the second scan. But I dealt with
> > it before so I guess I can deal with it again. It is just too bad I can't
> > just edit something or fetch channels from listing source and have that
> > work and avoid the scan.
> >
> > Two questions remain unanswered (or perhaps unasked):
> > 1) Does "Fetch channels from listing source" work? If so, what does it do?
> > 2) Is there documentation on "Edit Transport" beyond don't use it unless
> > you know what you are doing?
> >
> > I only need to change 4 channels although that represents a larger number
> > of sub channels.
> >
> > Allen
> >
>
> First of all, you probably want to read the list thread with the
> subject "USA OTA FCC frequency rescan?", as it seems I was wildly
> wrong about the importance of the callsign in the scan. Based on
> replies there, new frequencies apparently WILL cause a new channel to
> get created. That was news to me for sure. I was probably confusing
> that with the roll of callsigns with recording rules, which is where
> they become important.
>
> To be honest I can't answer either of those questions. If I ever used
> that "fetch channels" it would have been 12 years ago when I first
> built my system. I've never used the edit transport either and am not
> even clear what it attempts to do.
>

Some answers...
> > Two questions remain unanswered (or perhaps unasked):
> > 1) Does "Fetch channels from listing source" work? If so, what does it do?
This starts mythfilldatabase with the option --only-update-channels
and this should load channels from whatever is the input for
mythfilldatabase. I have not used this for the last 10 years but it
use to work with the files produced by a tv_grab_xxx utility that
scraped the guide information from a website.
I do all the channel scanning from the Channel Editor / Channel Scan pages.
Reference:
sourceutil.cpp:363 function SourceUtil::UpdateChannelsFromListing
videosource.cpp:3256 function CardInput::sourceFetch

> > 2) Is there documentation on "Edit Transport" beyond don't use it unless
> > you know what you are doing?
It is more or less self-documenting. If you know that an existing
transport, identified by either the transport ID or the current
frequency, is going to move to another frequency, you can edit the
frequency right there. You can also change modulation parameters but
you must of course know what you want to achieve.
You can also manually add a transport and then, in the Channel Scan
page, do a scan for channels on that transport. This can be most
useful for satellites in which you might not want to do a scan for all
channels on the satellite.
If you delete a transport then you also delete all channels on that
transport. This is most useful for satellites where you might want to
reduce the number of channels to the ones that you actually want to
watch.

Cheers,
Klaas.