[mythtv-users] [mythtv-commits] Ticket #3295: Scheduler schedules recordings on channels it doesn't receive
Michael T. Dean
mtdean at thirdcontact.com
Wed Apr 18 21:22:25 UTC 2007
On 04/18/2007 01:25 PM, Adam Brewster wrote:
>> On 04/11/2007 05:56 PM, MythTV wrote:
>>
>>> #3295: Scheduler schedules recordings on channels it doesn't receive
>>>
>>> I've found a little problem with the way mythtv schedules programs.
>> .
>>
>>> If more than one capturecard is connected to a single inputsource, mythtv
>>> assumes that it can receive every channel associated with the inputsource
>>> on either capturecard. Normally this is probably true, but I've found at
>>> least one case where it isn't.
>>>
>>> I've got a cable box connected by firewire (dct-6200) and a DVB card
>>> (pchdtv-5500) both connected to the same feed. The cable box can get any
>>> channel, but the DVB card can only get a subset of the channels. I can't
>>> set up two different input sources because mythfilldatabase changes the
>>> datadirect lineups, and I end up with no data for a bunch of channels.
>>> The result is that mythtv schedules recordings on channels it doesn't know
>>> how to tune, and these recordings fail, so I miss a bunch of shows.
>> Adam, the right way to configure your system is to use two different
>> video sources /and/ two different DataDirect lineups. If you can't
>> create 2 lineups (i.e. DataDirect prevents you from creating multiple
>> lineups using the same "source"--i.e. your local cable company's digital
>> package), you have two choices:
>> a) use a different nearby zip code where the provider has the same
>> channels
>> b) create and use a second DataDirect account.
> Thanks for your help. I didn't see your first message, as you may
> have guessed I'm not on the mailing list.
Yeah, normally I BCC the reporter of the ticket just in case, but I
couldn't find your e-mail. I got part of your e-mail from the Trac
page, but couldn't get the domain, so I searched to see if you had ever
posted to the list using that e-mail or if your full name had come
across on the list, but found nothing, so I crossed my fingers and hoped
that you were subscribed or that you would check the archives for
replies to your ticket (i.e. searching on "#3295" (no quotes)).
> I apologize for misusing
> the trac system, from the page http://svn.mythtv.org/trac/wiki it
> looked like that was the preferred way to submit things like this.
>
Basically, Trac is the preferred way to submit /confirmed/ bug reports.
:) The mailing list is the preferred way to confirm that a behavior is,
in fact, a bug and not simply a misunderstanding. The vast majority of
things that users see as bugs are often misunderstandings of proper
configuration. (I would guess that more than 50% of the tickets
submitted so far have been invalid tickets.)
And, the mailing list is the place where discussion of why tickets were
closed should take place.
> As I said before, I can't use a nearby zip code. I don't know why, I
> assume it's because the neighborhoods around here all have the exact
> same lineup. When I try to add another lineup from a nearby zip code,
> it says that "This provider has already been selected."
>
> As for using a different account, that's a good idea that I haven't
> heard before. It means I have to take the survey twice every time I
> renew my account(s), but that's a minor inconvenience. They may also
> not appreciate a project like mythtv recommending that many people
> sign up for multiple accounts.
Well, we just need to ensure we fix it in a way that does not break any
of the assumptions on which Myth is designed.
> Either way, I don't see how sanity checking in in the scheduler is a
> bad thing. If the scheduler knows that a recording will fail (even if
> it's because the user is/am an idiot), shouldn't it refuse to schedule
> it?
Sanity checking isn't a bad thing. The reason it's not required here is
due to an invalid assumption. From your original ticket description:
> If more than one capturecard is connected to a single inputsource,
> mythtv assumes that it can receive every channel associated with the
> inputsource on either capturecard. Normally this is probably true, but
> I've found at least one case where it isn't.
>
By definition, a MythTV video source is a unique identifier for a source
of programming. The video source must be "connected" to one or more
card inputs (on one or more capture cards) to allow capturing
programming from that source. A video source must also have one or more
channels that are used to specify what programming is available through
that source.
Since the channels on a video source specify the programming available
through that source, /all/ channels associated with a video source must
be accessible through all inputs that are "connected" (i.e.
mythtv-setup's input connections) to that video source.
Or, a little more concisely (and not quite so precisely) said, the video
source is used to specify a unique collection of channels available to
an input.
So, if different channels are available through 2 different inputs,
MythTV requires 2 separate video sources (to provide the bounds within
which the inputs can record).
This is by design.
The reason why ticket #3295 is invalid is because it attempts to reuse
one video source for multiple, er, video sources. :) Since the
available channels are different for the two different inputs, we /need/
two different video sources.
I think the issue you really want to fix is MythTV's current 1:1 mapping
between video sources and DataDirect lineups. Currently, Myth requires
that each video source use a different DataDirect lineup. But, to allow
the reuse of DataDirect lineups, the video source must be decoupled from
the lineup, which ticket #3299 ( http://svn.mythtv.org/trac/ticket/3299
) does (and, as I read the code, seems to do so correctly--even without
breaking "--remove-new-channels" or mythfilldatabase's not adding new
channels to digital sources).
> P.S. I'm still not subscribed to the list, so I'd appreciate a cc/bcc
> to me if you reply. I'll check the archives, but if it's in my inbox
> I can give you proper reply (with an "In-Reply-To:" and everything)
> instead of creating a new thread with a subject of "Re:...
Hmmm. I'm wondering how you got this post to the list... I thought
only subscribers could post.
Mike
More information about the mythtv-users
mailing list