[mythtv] Any plans
bjm at lvcm.com
Wed Mar 31 16:42:30 EST 2004
Chad Columbus wrote:
> Are there any plans to allow recording of "first run" shows like a tivo can do?
No. As someone else pointed out, that relies on the original
air date which is not available from XMLTV.
> i.e. Set-up separate recordings/priorities for first run shows vs. re-runs.
TiVo has no such feature of treating first run shows as separate
recordings/priorities. You can only have one Season Pass (same
as myth's kChannelRecord) that is ranked in the Season Pass
Manager. There is an option to the Season Pass to record "First
run and repeats", "First run only" or "All". "First run only"
may not necessarily work the way you'd expect. MythTV also has
duplicate matching which may work better for you in many instances.
The way TiVo works is that it only keeps track of previously
recorded shows for about 5 or 6 weeks then clears them out. If
you use "First run and repeats", the same episode will re-record
if it hasn't been recorded in the past several weeks so it will
re-record summer reruns for example.
"First run only" checks the original air date and will only record
if it was within the past 28 days. This means that it doesn't have
to record the very first showing but can record any showing in the
first 4 weeks. Once it records, it is in the old recording table
for 5 or 6 weeks so by the time it expires, it's been more than
28 days and is no longer eligible to record. I assume they do this
so they can limit the size of the old recording list.
Say you discover "Mythbuster". It's been on for two seasons and
they show new and old episodes throughout the week month after
month. By default with TiVo, you would see unique episodes at
first. However, after a couple months, it would re-record any
episode that you recorded more than a month and a half ago.
If you choose "First run only", It would record new episodes
from this season and not record them again but it would never
record last season's episodes that you haven't seen.
MythTV keeps things in the 'oldrecorded" table indefinitely (and
there are ways to add or remove entries). With myth, it would
record each episode, old and new, once and never record it again
unless you asked it to. If you are looking at the Conflict page
or the episode list for Mythbusters and see a description of
an episode that you'd seen before using myth, you can press
Enter and click "Never record this episode". If you see one that
you've recorded before but decide you'd like to see it again you
can click "Record it anyway". If you record an episode but the
recording was bad or part was missing or the station showed a
different show in that timeslot, press "i" and click the button
that says "Allow re-recording" (or what ever it says this week ;-).
> That way you have less conflicts and if you don't want re-runs can avoid them.
This is just as true in myth already as it is in TiVo. I actually
prefer myth's approach because TiVo will create MORE conflicts
because of re-recording re-runs that you have already seen than
However, not only don't we have original air dates but XMLTV doesn't
pass along the unique database episode numbers. These are available
on the pages that they parse but they don't include them in their
output (Doh!). To compensate, myth has to try to match episodes
by doing string matches on the descriptive info. Attached is some
documentation for duplicate matching in 0.15.
Adam Biskobing wrote:
> I think this is a problem not so much with Myth, but with the program
> data received.
> Tivo's program data is marked with first run episodes,
> what we get from XMLTV is not.
There isn't a "mark" but a field that contains the original date.
the system figures out if that is recent enough. If you press
the button in the the bottom right corner marked "enter" while
on any show description page, there is a page listing all the
database fields that have info for that show.
Daniel Walton wrote:
> You sure?
I am =).
> Because ReplayTV does this exact thing but it doesn't get any first
Certainly not "exact" and probably not even very similar ;-).
> run data in the guide. It just looks for the "repeat" keyword at the
> beginning of the episode/description.
I think you're confusing how they present the information to
the user with how they decide if a showing should be given the
"repeat" marking that you see.
> now, previouslyshown is not set for 100% of the shows, but
> it usually is for the primetime stuff on the broadcast
> stations in my area.
It may not be very useful though. Say a show is first run on
Tuesday then repeated on Friday. If there is a conflict for
Tue, I'd certainly want to record the Fri showing if possible.
I think this is why TiVo uses the airdate and a 4 week window
to consider something as new.
Adam Biskobing wrote:
> If I remember correctly that is a little different. Previouslyshown is data
> gathered from Myth, and not from XMLTV. I could be wrong about this, if so,
> someone please correct me.
Correction, you are wrong ;-). Previouslyshown is filled in from
xmltv data. MythTV's info about previously recorded shows is stored
in a table called "oldrecorded".
> even if it wasn't used for the scheduler it would be nice to
> have that info stored in recorded table
Well, that may be possible, however, after you've recorded
something, how valuable is it to know that the listing service
considered to be a repeat at the time you recorded it ;-) ?
-------------- next part --------------
The MythTV scheduler can check the descriptive information for a show
to try to determine if there are duplicates of a previously recorded
or previously scheduled episodes. How to best determine if there are
duplicate episodes depends largely on how the information is presented
in the program listings. Different titles may have different formats
for their information. Therefore, MythTV allows you to choose from
four different methods to determine if showings are duplicate
episodes. The "Duplicate Check" method can be set from the advanced
NOTE: These methods work by comparing subtitle and description
information. If the listings from your provider includes episode
number fields or notation for re-run shows, there are no current
duplicate matching methods that use this information.
This is the safest method. The scheduler will consider all showings to
be unique without checking for duplicate subtitles or descriptions.
For this and all other methods, a showing will only be recorded if it
matches the record type (timeslot, weekslot, channel or all) and if it
'wins' the time slot in conflict resolution when there are other shows
scheduled at the same time.
Sub & Desc
This is the default method. The scheduler will consider two showings
to be duplicate if the subtitles and descriptions are not empty and
they match. If this is true, only one of the matching episodes will be
recorded. It is unlikely that you will miss a unique episode if this
method is used.
The scheduler will consider two showings to be duplicates if both
subtitles match with no consideration of the description. This is
useful for shows that always have subtitles but don't always have
descriptions. This could cause you to miss an episode in a case where
a two part episode has the same subtitle but "Part 1" and "Part 2"
appear in the description.
This is not the best choice for sporting events either. Often games
will list the teams in the subtitle and have no description giving the
appearance that subtitle matching would make sense. However, if you
were to record "MLB Baseball" with the subtitle "Boston Red Sox vs
Chicago Cubs" and use the "Subtitle" method, you would never again see
these teams play in the World Series.
The scheduler will consider two showings to be duplicates if both
descriptions match with no consideration of the subtitle. For many
shows, this is quite likely to cause you to miss episodes that you
would have wanted to record. The reason is that often "generic
episodes" are used as place holders when the station does not declare
which episode will be shown. For example, "Seinfeld" may have no
subtitle and a description like "Jerry and his friends face life in
New York". The episode shown may be "The Soup Nazi" or "The Contest"
but this cannot be determined from the information in the listings. If
you use the "Description" method, a generic episode will only be
recorded once. After that, you would miss all of the unique episodes
that have this generic description.
The scheduler can check for duplicates against it's list of saved
recordings, it's list of all episodes that were previously recorded, or
both. "All Places" is the default and you would rarely need to change
this. "Previous Recs" will always give the same result as "All Places"
unless the list of previous recordings had been manipulated in some
way. "Current Recs" will only check to consider an episode to be a
duplicate if there is a matching episode in your list of saved
recordings. After that episode has been deleted then the scheduler is
free to re-record the same episode again.
Choosing a Method
"None" is the surest way to not miss an episode but in most cases
would record duplicate episodes unnecessarily. "Sub & Desc" is the
most accurate method to skip showings that are truly duplicates. The
other methods make it <EM>more</EM> likely (not less likely) that you
will miss unique episodes. You should use the default "Sub & Desc"
unless there is a clear pattern in the listings that makes it obvious
that one of the other two methods would be a better choice.
Initially you should click the "See a list of all up-coming
episodes/playtimes" button on the advanced options page to see the
current listings for a show. The fact that the current listings match
a certain pattern does not guarantee that future episodes will also
match. Therefore, you should check periodically until you are sure
that the method you've chosen is correct.
On the "Fix Scheduling Conflicts" page, showings that are considered
to be duplicates are marked with a "P" for previously recorded or "O"
if another showing of the episode is scheduled to record. If you have
chosen "Subtitle" or "Description", you should check these to be sure
that they are duplicate showings. If not, you have two choices; if it
is an anomaly that you don't expect to happen again, you can use
overrides to "record it anyway" or you can go to the advanced options
page to chose a safer "Duplicate Check" method.
More information about the mythtv-dev