JP Vossen on 6 Sep 2011 01:35:39 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] MythTV & HDHomeRun & Comcast Digital for Pottstown/Collegeville

On 09/05/2011 22:10 PM, Matt wrote:
I think you will find that you can use the channel editor in the
frontend to set the metadata for the channels so that they match what
is in Schedules Direct, which should make things start working as you
would expect. Just cycle through all the channels that were found,
hit "e" and enter the channel #, XMLTV ID, and a Callsign that you
like, and you should start getting expected results.

I have MythWeb working and that has a channel editor too. That might be easier to do in 1 shot, if I had a clue what I was doing. The columns are as follows: delete sourceid xmltvid channum callsign name freqid finetune videofilters brightness contrast colour hue recpriority commfree visible useonairguide

SourceID is either 1 or 3, which I see is "video source" which is odd because it has some "3_1" type stuff in source 1 which is my old non-digital source. Whatever, I can clean that up, if I know what goes in which field and where to get it. "useonairguide" and "commfree" sound interesting...

There is also which I got working and which provided a ton of info, including a VCT_ID (3014) that looks pretty much exactly like the "MontcoPLYPOTT-B1-CFRLP2AE" channel brochure I got in snail mail. I used that to create a MySQL update file, but haven't imported it yet. I globally changed "sourceid=1" or "sourceid=3" but it looks like there are 'mplexid' problems as well? (I already have lots of dups on the field in the DB though). The SQL file contains:
  Count Record
     15 mplexid=92
     14 mplexid=91
      6 mplexid=23
      5 mplexid=82
      3 mplexid=110
      3 mplexid=102
      2 mplexid=79
      2 mplexid=109
      2 mplexid=104
      1 mplexid=93
      1 mplexid=81

Yet none of those exist in the dtv_multiplex table (or the SQL file) and all 22 records that do exist were created yesterday. Will trying to use scte65scan help or hurt me?

Meanwhile, I hit the "report" button on my SchedulesDirect lineup and got the nice table, but it only lists, e.g., "12 | 12 | 11537 | WHYY | WHYY" while the Myth channel editor web page (or via Live TV or whatever) has:
	12_1	# Actually, I have "dups" from source 1...
	12_3	# ... and source 3 for these...
	12_7	# ... three.  :-/

So WTH are those? I don't see them listed in scte65scan or SchedulesDirect... (Oh wait, running scte65scan with -p takes much longer but does seem to add that (PSIP?) stuff. Still no dtv_multiplex entries though.)

Also, the Myth channel scan picked up a bunch of channels I don't think I get (>30 N <70), and that result in "error opening jump program file" when I switch to them, and it didn't find a bunch I do (or will) supposedly get (>100). Scte65scan seems a lot more accurate. Maybe I should nuke all those channels (how? Web interface can do it) and use the scte65scan .sql import?,_PA_-_Comcast_Digital looks like a superset of my Scte65scan output.

When I run the SQL query at that URL, I get some "duplicate" records, and channelnum values of <70, while the channel chart I got from Comcast has lots of stuff > 100 that in theory I get. That same chart and Scte65scan have nothing in the >30 and < 90 range, while the Myth channel scan picked up lots > 30 and < 70.

With regards to live TV not working, you might want to ensure that
the default channel for the tuner is set to something that exists.
Having an undefined channel as the default can cause the symptoms you
are describing. The frontend logs can help a log with this too.

Yup, that seems to be it, though I hadn't changed the "default" tuner or default channels for those and I thought I'd set working ones for the new tuners. Regardless, fiddling with that setting fixed it.

Thanks for the help & sorry if I've being extra dense,
JP Vossen, CISSP            |:::======|
My Account, My Opinions     |=========|
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --