[mythtv] Ticket #6898: Detect programs whose broadcasters claim are longer than their timeslot

[f-myth-users at media.mit.edu]

    > Date: Sat, 10 Apr 2010 04:05:50 -0000
    > From: "MythTV" <mythtv at cvs.mythtv.org>

    > #6898: Detect programs whose broadcasters claim are longer than their timeslot
    > ----------------------------------------+-----------------------------------
    >  Reporter:  f-myth-users@?              |        Owner:  danielk
    >  Type:  enhancement                     |       Status:  closed 
    >  Priority:  minor                       |    Milestone:  unknown
    >  Component:  MythTV - Mythfilldatabase  |      Version:  unknown
    >  Severity:  low                         |   Resolution:  wontfix
    >  Mlocked:  0                            |  
    > ----------------------------------------+-----------------------------------
    > Changes (by robertm):

    >   * status:  assigned => closed
    >   * resolution:  => wontfix


    > Comment:

    >  http://www.gossamer-threads.com/lists/mythtv/users/379949#379949

    >  In short, per the SD developer in the thread, the runtime information
    >  bears no direct relationship to the scheduling information and as such

The problem is, for -some- channels, it -does-.

    >  should not be used for any scheduling decisionmaking.

This means that we should let -the user- actually decide, but right
now, we hide the relevant information from him!

I understand the issue in that thread about programs with "8-hour"
runtimes being aired in two-hour chunks, and so forth, though I don't
think I've ever seen this in -my- feed.  According to the conversation
about this we had, though, some commercial channels do this---and when
you mix commercial interruptions into it, of -course- runtimes probably
don't match, because of adding commercials, cutting content to fit the
timeslot, etc.

But for some of my channels (TCM and Sundance are prime and frequent
offenders---and they don't air ads per se), they routinely take, say,
a 2 hour 10 minute movie and air it in a 2-hour slot.  The data from SD
clearly specifies the actual and correct runtime.  But their own
provided scheduling data is bogus, since they've claimed that you
can put 130 minutes of uncut, commfree content into a 120-minute slot.

Sometimes it's much worse; I recall a 20-minute overrun once, also
correctly declared via the runtime but incorrectly scheduled, and
there might have been more egregious examples I'd have to find by
going back through my logs.  (Maybe I even pointed them out in that
thread; I haven't reread it since the discussion.)

So what to do?  I'd argue that there should be (if necessary) a
per-channel way of saying, "No, really, this broadcaster lies about
their scheduling in this way."  Years of complaining directly to these
broadcasters has been completely ineffective; they just don't care
about a bunch of PVR users of any stripe.  They'd rather just round
to approximate schedules and screw anyone who actually needs the data
to be correct.  But since the per-channel "tell the scheduler to trust
runtime" approach gets everyone's hackles up, my alternative was "at
least let the user know to pad -this- recording extra" by showing him
what's going wrong.

Similarly, "just pad -everything- hugely" is a nonstarter for all the
reasons in the thread---I already pad quite a bit. But over 20
minutes?  On -every- recording on each of those channels?  That chews
up recorders that might otherwise be used elsewhere, especially given
the rarely-on-the-hour behavior of movie channels.  And with a limited
number of actual hardware tuners and STBs and monthly fees for every
single one of those STBs?  Adding infinite padding when in theory I
already -know- the information that could avoid that, but Myth is
actively throwing it away without showing it to me, leaves a very bad
taste in my mouth.

Meanwhile, I have my own solution to the problem, which is to
carefully preserve the information so it can be passed along to
Mythweb, where I can -see- it, and take appropriate action.  But that
solution will need to be fixed for -every- version of Myth that I
upgrade to, so it's not very scalable, and it doesn't help anyone else
who gets the same channels or who have broadcasters with similar
behaviors.

I'm not arguing for the -scheduler- to be made aware of this, because
it's too complex to specify that (e.g., which broadcasters do you
trust).  All I'm arguing is that -the underlying information we get
from SD not be gratuitously thrown away- and is instead made available
so the various bindings (Mythweb, python, perl, whatever) can -get- it
and use it, if they feel like it, and so I don't have to maintain my
very own set of patches for this in -every- later version of Myth.

Since no behavioral changes are implemented---just not throwing away
information we just got from SD---it seems like this would be a very
safe change.  I'm willing to implement it for trunk, but I'm not going
to go to the effort of doing it across all bindings (or whatever) if
it won't be accepted.

Just because you don't see it on -your- channels doesn't mean it
doesn't happen every week or two on -mine-.