[mythtv] [mythtv-commits] Ticket #1203: Fix channels.conf import for ATSC OTA/QAM

[Steven Adeff]

On 2/3/06, Daniel Kristjansson <danielk at cuymedia.net> wrote:
> On Fri, 2006-02-03 at 18:02 -0500, Boleslaw Ciesielski wrote:
> > Daniel Kristjansson wrote:
> > >>> If you can fix the channum column issue (assign consecutive
> > >>> numbers starting at 1 if you must, but don't use any numbers
> > >>> already assigned to a channel from a previous scan),
> > Unfortunately this won't work, because the channel numbers in the guide
> > data can be arbitrary and are not known in advance.
> > Unless we run mythfilldatabase first and then the scan? Hmm...
>
> I just want them to have some channel number, so you can switch to
> the channel and then say, "Ok, 534 is CSPAN, lets fix that in the
> channel editor." I don't want people to have to get mplayer up and
> running to get MythTV up and running.

well, at this point they've got to do a lot of it manually anyway,
since atscscan will give them channels that may be encrypted and the
only way to find out before importing into Myth is to use mplayer.

>
> BTW If you need info from mythfilldatabase, I don't think it
> is a bad idea to run it. There is already a button for doing
> it without getting 14 days of listings in input connections...

When I add the channels manually I run mythfilldatabase first, using a
source that is all the channels I receive, then I manually enter the
mplexid and service id for these channels.

If the channels are already present because mythfilldatabase was run,
and the channels.conf uses the network name that zap2it uses, couldn't
this be used to match the proper channel?

>
> > > * match channels by callsign This will cause too many problems. Can
> > > you write something that tries to fill in the blank XMLTV id's from
> > > the callsigns instead?
> > I am not sure what you mean? This is exactly what it's doing now.
>
> I don't want to run after the user exits mythtv-setup, I'd like it
> to be something the user does by pressing a button in the channel
> editor, so they can easily edit the result and fix the mistakes.
> But, I'd have committed this two weeks ago, as is; it's just too
> late for features now.
>
> > Well, my idea was to use the callsign from channels.conf. Are you saying
> > that this is not unique enough (within a sourceid)? If this is so, then
> > like you said maybe we need to table this issue for now although I will
> > think some more.
>
> It is not unique for me, but it is pretty close; I think it would be a
> great start at filling the data in.
>
> > You can still commit the first part though.
>
> Can you fix the channel numbers being set to zero first?
> Not everyone is going to have a fully fleshed out channels.conf
> at the ready, creating one it is a tedious manual process which
> is greatly simplified by having MythTV up and running with the
> data needed for tuning.

except that Myth can't properly scan for ATSC/QAM channels.


> > > Otherwise work on this for 0.20, though it might be a better use of
> > > your time to figure out why the internal QAM scanner isn't working
> > It's working for me but the problem is that it produces tons of junk
> > channels and there is no easy way to get rid of them. Also, for the
> > desired channels, there is no way to associate the guide data without
> > manually entering xmltvid.
>
> I see, the junk channels is something we will have to fix in 0.20,
> but you do know that you can delete a extra channel by selecting it
> and pressing 'D' ?

I'd still like to see a proper channels.conf import though, theres
already some users creating a script that will run atscscan, verify
and create a proper channels.conf. If the channels.conf import works
properly then at least until the internal scanning is fixed there will
be a way to easily add channels.


> > Also, having an accurate channels.conf has other benefits outside of
> > myth. And once you do the work, why not reuse it?
> Sure. It would be nice to have MythTV be able write out a
> valid channels.conf. My MythTV channels tend to be more up
> to date than my channels.conf.

--
Steve