1 | WHY
|
---|
2 |
|
---|
3 | These patches implement detection of programs whose broadcaster claims
|
---|
4 | will overflow their listed timeslot. This can only work if you're
|
---|
5 | using Schedules Direct. They make no actual change to the way
|
---|
6 | scheduling works at all---they only give information to the user.
|
---|
7 |
|
---|
8 | Note that, since this just affects the DB and UI (and, in fact, only
|
---|
9 | MythWeb---there's no implementation for mythfrontend since I never use
|
---|
10 | that to do scheduling) its impact should be zero if only the DB half
|
---|
11 | is installed, except for a trivial (~30K in my listings) increase in
|
---|
12 | the size of the DB. The UI half only affects the display of the
|
---|
13 | detailed recording info for a particular recording, whether or not
|
---|
14 | it's been scheduled to record, and only changes that behavior if it
|
---|
15 | looks like the recording is going to overflow its timeslot. This
|
---|
16 | means, alas, that it won't help you if some recording that will
|
---|
17 | overflow was found automatically via a Power Search or a normal
|
---|
18 | scheduling rule, unless for some reason you happen to be looking at
|
---|
19 | its detailed info anyway. But it -will- help you if you're scheduling
|
---|
20 | it by hand, as is likely on a movie channel.
|
---|
21 |
|
---|
22 | The most important part of the patch is to preserve the incoming data
|
---|
23 | from SD, so that Myth can use it later in its UI. Since the data is
|
---|
24 | preserved in the DB, MySQL queries can also pull it out, independent
|
---|
25 | of Myth itself.
|
---|
26 |
|
---|
27 | This ideas was controversial when suggested on the myth lists, but I'm
|
---|
28 | including this proof-of-concept here so people know what I'm talking
|
---|
29 | about, in the hopes that at least the code that sticks stuff into the
|
---|
30 | DB will make it into a release. These patches certainly won't work
|
---|
31 | for everyone---I've been told (but have not seen personally) that some
|
---|
32 | broadcasters sometimes claim outrageously long runtimes (many hours
|
---|
33 | too long)--but these patches have been saving my bacon for months now
|
---|
34 | with Sundance, IFC, and TCM, to name a few, all of which tend to very
|
---|
35 | occasionally air things that are from several minutes to half an hour
|
---|
36 | (!) longer than their listed timeslot. Having to add up to half an
|
---|
37 | hour of postroll just to catch these is ridiculous---it eats up
|
---|
38 | storage for the 99% of the time when this isn't necessary, and---much
|
---|
39 | worse---eats up tuners, too, since most movie channels have rather
|
---|
40 | random start/end times, and excessive padding eats into tuners that
|
---|
41 | might otherwise be needed to record things from other channels that
|
---|
42 | tend to start on the hour or half-hour. And when one's tuners are
|
---|
43 | actual physical cable boxes feeding analog capture cards---hence
|
---|
44 | multirec is unavailable---this starts to generate conflicts pretty
|
---|
45 | fast. So even though I routinely pad things on movie channels by 5-10
|
---|
46 | minutes at the end, I've often been screwed by this -still- not being
|
---|
47 | enough---even though it's usually way too much. Hence, these patches.
|
---|
48 |
|
---|
49 | INSTALLATION
|
---|
50 |
|
---|
51 | This patch does NOT include the necessary modifications to dbcheck.cpp
|
---|
52 | to change the relevant table schemas! This is, in part, because any
|
---|
53 | such stanza would just have to be changed to match the schema current
|
---|
54 | when the patch is actually applied, if ever. It must contain the
|
---|
55 | following MySQL:
|
---|
56 |
|
---|
57 | ALTER TABLE program ADD COLUMN sd_runtime SMALLINT UNSIGNED DEFAULT '0' NOT NULL;
|
---|
58 | ALTER TABLE recordedprogram ADD COLUMN sd_runtime SMALLINT UNSIGNED DEFAULT '0' NOT NULL;
|
---|
59 |
|
---|
60 | WHAT
|
---|
61 |
|
---|
62 | Four files are attached:
|
---|
63 |
|
---|
64 | (a) Example data from SD that shows the problem, and some simple shell
|
---|
65 | scripting to show how, once the data's in the Myth DB, it can be
|
---|
66 | manipulated.
|
---|
67 | (b) An UNTESTED patch against current SVN (revision 21445). It's
|
---|
68 | untested because I'm not currently running trunk, and didn't
|
---|
69 | expect only 72 hours of notice on the feature freeze. Oh well.
|
---|
70 | If this patch isn't immediately closed as a bad idea, I will work
|
---|
71 | up a tested and working version for trunk, but I won't waste my
|
---|
72 | tiem if somebody closes the ticket and says this will never go in.
|
---|
73 | [But if someone does this, I will pout and be quietly sad. :( ]
|
---|
74 | I'll probably need some hints for the Ajaxified current MythWeb,
|
---|
75 | and perhaps a volunteer for the mythfrontend piece of the UI,
|
---|
76 | which I haven't examined at all yet.
|
---|
77 | (c) A TESTED AND WORKING proof of concept, both for the DB side and
|
---|
78 | the UI side, in a very old version of Myth. I've been using this
|
---|
79 | version of the patch for months and it's worked excellently.
|
---|
80 | (d) A quick explanation of why I'm running an old version. For people
|
---|
81 | who want to make an issue of it (you know who you are), read it.
|
---|
82 | For people who don't care, skip it. It's here to keep people from
|
---|
83 | flaming on the mailing list about it and wasting everyone's time.
|
---|
84 |
|
---|
85 | OTHER NOTES
|
---|
86 |
|
---|
87 | Note that the MythWeb example I've supplied doesn't add sd_runtime to
|
---|
88 | the Myth protocol; it just makes direct calls to the DB to get the
|
---|
89 | info it needs. I did this to minimize the invasiveness, and because
|
---|
90 | plenty of other parts of MythWeb in that version do the same thing.
|
---|
91 | If this actually goes into trunk, and if it's deemed important, it's
|
---|
92 | straightforward to add sd_runtime to the protocol and have MythWeb get
|
---|
93 | it that way---but it requires a protocol bump as well, of course.
|
---|
94 | (I assume that making the frontend know about this requires such an
|
---|
95 | addition anyway.)
|
---|