[mythtv] conflict resolution
Bruce Markey
bjm at lvcm.com
Sat Nov 8 22:15:21 EST 2003
David Engel wrote:
> On Sat, Nov 08, 2003 at 12:09:54PM -0500, Chris Pinkham wrote:
>
>>If recorddups is not set, the source code will not mark an item as
>>duplicate provided it is not still in the recorded table, so it
>>should show up to record.
>
>
> Yes, I know that. But there is code in Scheduler::PruneList that
> scans for and removes multiple showings from recordingList. This is
> exactly where my unpatched version is dropping the extra showings. I
> just re-re-verified it. The issue I've been trying to address is why
> Bruce's version is not doing this also.
Ya, I think the pruning may be the source of the ambiguity.
Please try this:
mysql> select starttime,title from program where subtitle='2000'
and description='From Sun City, South Africa.';
+----------------+-----------------------------------+
| starttime | title |
+----------------+-----------------------------------+
| 20031110140000 | World's Strongest Man Competition |
| 20031110143000 | World's Strongest Man Competition |
| 20031110150000 | World's Strongest Man Competition |
| 20031110153000 | World's Strongest Man Competition |
| 20031111080000 | World's Strongest Man Competition |
| 20031111083000 | World's Strongest Man Competition |
| 20031111090000 | World's Strongest Man Competition |
| 20031111093000 | World's Strongest Man Competition |
| 20031111140000 | World's Strongest Man Competition |
| 20031111143000 | World's Strongest Man Competition |
| 20031111150000 | World's Strongest Man Competition |
| 20031111153000 | World's Strongest Man Competition |
| 20031112080000 | World's Strongest Man Competition |
| 20031112083000 | World's Strongest Man Competition |
| 20031112090000 | World's Strongest Man Competition |
| 20031112093000 | World's Strongest Man Competition |
+----------------+-----------------------------------+
16 rows in set (0.07 sec)
My DB has 16 showings of this episode in the program table.
If you don't have ESPN2, look for another title that has
many showing of the same episode.
With an unpatched backend, I choose "World's Strongest Man"
as a channel record:
--- print list start ---
Title Chan ChID StartTime S I C -- C R D S Rank Total
World's Strongest Man 31 1031 Nov 10 02:00pm 1 1 1 -- 0 1 0 0 0 0
World's Strongest Man 31 1031 Nov 10 03:00pm 1 1 1 -- 0 1 0 0 0 0
World's Strongest Man 31 1031 Nov 11 08:00am 1 1 1 -- 0 1 0 0 0 0
World's Strongest Man 31 1031 Nov 11 09:00am 1 1 1 -- 0 1 0 0 0 0
World's Strongest Man 31 1031 Nov 11 02:00pm 1 1 1 -- 0 1 0 0 0 0
World's Strongest Man 31 1031 Nov 11 03:00pm 1 1 1 -- 0 1 0 0 0 0
World's Strongest Man 31 1031 Nov 12 08:00am 1 1 1 -- 0 1 0 0 0 0
World's Strongest Man 31 1031 Nov 12 09:00am 1 1 1 -- 0 1 0 0 0 0
--- print list end ---
There are only 8 showings that matched!
Now I switch to a patched backend:
--- print list start ---
Title Chan ChID StartTime S I C -- C R O N Rank Total
World's Strongest Man 31 1031 Nov 10 02:00pm 1 1 1 -- 0 1 0 0 0 0
World's Strongest Man 31 1031 Nov 10 02:30pm 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 10 03:00pm 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 10 03:30pm 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 11 08:00am 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 11 08:30am 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 11 09:00am 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 11 09:30am 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 11 02:00pm 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 11 02:30pm 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 11 03:00pm 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 11 03:30pm 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 12 08:00am 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 12 08:30am 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 12 09:00am 1 1 1 -- 0 0 0 4 0 0
World's Strongest Man 31 1031 Nov 12 09:30am 1 1 1 -- 0 0 0 4 0 0
--- print list end ---
One to record and 15 nrOtherShowing. Perfect. Not only does
it show every showing, but it correctly depicts that only
the first will be recorded. Clearly this is much better.
I picked this show because there are several showings of one
episode and there is one this one episode so the output isn't
a mixture of different episodes. However, the odd thing about
this particular case is that current CVS picked all the shows
that start on the hour and dropped the ones on the half-hour
which would be every other showing. This may be a clue but
in all other cases I've seen it hasn't appeared to be such a
regular pattern.
I suspect the pruning may be affected by the order items
are returned from the database. Therefore, I deleted from
program and re-ran mythfilldatabase. Now I get very different
results for Nova.
There are 10 showings in program. None in oldrecorded. "Nova"
is a channel record with recorddups turned off.
In 'program':
mysql> select starttime,title,subtitle from program where title='Nova';
+----------------+-------+---------------------------------------------+
| starttime | title | subtitle |
+----------------+-------+---------------------------------------------+
| 20031109020000 | Nova | The Elegant Universe: Welcome to the 11... |
| 20031109100000 | Nova | The Elegant Universe: Welcome to the 11... |
| 20031111200000 | Nova | Wright Brothers' Flying Machine |
| 20031112010000 | Nova | Wright Brothers' Flying Machine |
| 20031112030000 | Nova | Wright Brothers' Flying Machine |
| 20031113210000 | Nova | Cancer Warrior |
| 20031116020000 | Nova | Wright Brothers' Flying Machine |
| 20031116100000 | Nova | Wright Brothers' Flying Machine |
| 20031118200000 | Nova | Magnetic Storm |
| 20031119030000 | Nova | Magnetic Storm |
+----------------+-------+---------------------------------------------+
10 rows in set (0.00 sec)
Unpatched backend:
--- print list start ---
Title Chan ChID StartTime S I C -- C R D S Rank Total
Nova 10 1010 Nov 09 02:00am 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 11 08:00pm 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 12 01:00am 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 13 09:00pm 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 16 02:00am 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 18 08:00pm 1 1 1 -- 0 1 0 0 0 0
--- print list end ---
There are 10 showing but only 6 appear. The Wright Brothers is
scheduled of the 11th at 8, 12th at 1 and the 16th at 2. There are
3 scheduled. Not 1, not 5, but 3. This is just unintended behavior.
Override patch:
--- print list start ---
Title Chan ChID StartTime S I C -- C R O N Rank Total
Nova 10 1010 Nov 09 02:00am 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 09 10:00am 1 1 1 -- 0 0 0 4 0 0
Nova 10 1010 Nov 11 08:00pm 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 12 01:00am 1 1 1 -- 0 0 0 4 0 0
Nova 10 1010 Nov 12 03:00am 1 1 1 -- 0 0 0 4 0 0
Nova 10 1010 Nov 13 09:00pm 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 16 02:00am 1 1 1 -- 0 0 0 4 0 0
Nova 10 1010 Nov 16 10:00am 1 1 1 -- 0 0 0 4 0 0
Nova 10 1010 Nov 18 08:00pm 1 1 1 -- 0 1 0 0 0 0
Nova 10 1010 Nov 19 03:00am 1 1 1 -- 0 0 0 4 0 0
--- print list end ---
Rocks again! All showings are listed. The first showing of
each episode is marked to record. All others are marked as
other showing.
> This is why I claimed my changes faithfully reproduced the old
> behavior.
Well, not exactly. The old behavior is that it may have been
losing track of showings and wouldn't indicate if the intention
was to record or not record. Clearly the intended behavior should
have been to record every showing. What happens currently in
the override patch that it incorrectly specifies that it intends
to not record some things (even though it eventually will, but
I'm getting ahead of myself).
> Since it's impossible to predict when the user will watch
> or delete any recordings, I try to present what will happen if nothing
> else changes.
But it turns out that they will get recorded and it isn't
presenting what will happen. Let's say there is an episode
in the oldrecorded table and three upcoming showings that
I'll call A, B, and C. Record dups is turned on.
At first A is marked to record with B and C other showings.
"A" is recorded (and deleted) then B is marked to record with
C as other showing. "B" is recorded (and deleted) then C is
marked to record and eventually does get recorded.
Each of the showing did record even though they had been
mis-represented earlier. What should be presented is that the
scheduler intends to honor the users request that all showings
are to be recorded.
All that really needs to happen is that the recorddups status
known in findAllProgramsToRecord needs to be preserved so that
it can be checked in PruneList before marking an item as
nrOtherShowing.
Anyway, I don't think there is any point to debugging the
current pruning problems. The norecord status stuff does
keep all showings and clearly can do a much better job of
depicting what will and won't be recorded. I'm all for
checking this in as soon as the recorddups issue is resolved.
-- bjm
More information about the mythtv-dev
mailing list