[mythtv] Any plans

[Adam Biskobing]

Very interesting.  It's good to know how each of the different systems
works.  Gives me a better understanding of my Tivo.  And yes, now that I
look at it, oldrecorded was what I was thinking of, not prevouslyshown.
Thanks for pointing that out.

> -----Original Message-----
> From: mythtv-dev-bounces at mythtv.org 
> [mailto:mythtv-dev-bounces at mythtv.org] On Behalf Of Bruce Markey
> Sent: Wednesday, March 31, 2004 3:43 PM
> To: Development of mythtv
> Subject: Re: [mythtv] Any plans
> 
> 
> 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 myth will(!).
> 
> 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.
> 
> Absolutely correct.
> 
> >   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.
> 
> henri wrote:
> 
> > 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 ;-) ?
> 
> --  bjm
> 
>