[mythtv] [mythtv-commits] Ticket #8535: Add ability to filter recording schedules by season

[Jason Musits]

On Mon, Jun 7, 2010 at 4:15 PM, Michael T. Dean <mtdean at thirdcontact.com>wrote:

> On 06/07/2010 03:52 PM, Jason Musits wrote:
>
>> On Mon, Jun 7, 2010 at 9:28 AM, MythTV wrote:
>>
>>
>>> #8535: Add ability to filter recording schedules by season
>>>
>>> Comment:
>>>
>>>  program.syndicatedepisodenumber does not contain any usable information
>>>  for filtering by season (see below).  The syndicatedepisodenumber is a
>>>  string whose format is decided by the producers of a show--there is no
>>>  standard for its construction.  Therefore, parsing the
>>>  syndicatedepisodenumber to determine season or episode information is
>>>  unreliable, at best.  And, the syndicatedepisodenumber may not be
>>> provided
>>>  for a large percentage of users.  The only users for which the
>>>  syndicatedepisodenumber is generally usable are those XMLTV users whose
>>>  listings providers specify an "xmltv_ns" episode-num (versus the
>>>  "onscreen" episode-num values, which is what syndicatedepisodenumber is
>>>  designed to hold--see the documentation for episode-num at
>>>  http://xmltv.cvs.sourceforge.net/*checkout*/xmltv/xmltv/xmltv.dtd ).
>>>
>>>  Anyone wanting to be able to use ordinal season and episode information
>>>  should not attempt to parse such information from any existing fields
>>>  (syndicatedepisodenumber, programid, ...), but should instead add
>>> columns
>>>  to the database for season and episode numbers and modify XMLTV, EIT,
>>> and
>>>  DataDirect (Schedules Direct) grabbers to properly (directly) pull such
>>>  information from listings, when present, and save it directly to the
>>>  database.
>>>
>>>  Furthermore, we're actually in the process of removing extra information
>>>  from ProgramInfo, not adding new information.  Also, when adding
>>>  additional information to ProgramInfo, it should be added to the end,
>>> not
>>>  inserted randomly into the middle--where inserting into the middle
>>>  requires a significant amount of changes so that all users agree on the
>>>  meaning of each field.
>>>
>> ...
>
>>  If you choose to use syndicatedepisodenumber in your recording rules,
>>>  anyway, you should do so using a "Custom Recording Rule"/"Power
>>> Recording
>>>  Rule".
>>>
>>>  Thank you for the patch.  If you have any additional questions about,
>>> for
>>>  example, how to add the season and episode ordinals to program, please
>>>  follow up on the mailing lists.
>>>
>>> --
>>> Ticket URL:<http://svn.mythtv.org/trac/ticket/8535#comment:1
>>>
>> Thanks for reviewing my patch.  I realize that syndicatedepisode number
>>
>> wasn't the perfect solution, but I didn't see any other one.
>>
>
> Exactly.  The current database does not handle this data.  This is mostly
> due to the fact that only a very small percentage of users have providers
> that supply such information.
>
>
>    I would be
>> interested it getting the real season and episode numbers in the
>> grabbers, but according to
>> http://forums.schedulesdirect.org/download/file.php?id=2 (TMS
>> DataDefinition) that information does not seem to be provided.  If
>> anyone knows where this information can be obtained I would gladly
>> update the grabber(s) to pull it and then modify my existing patch to
>> work with the new fields, as suggested.
>>
>>
>
> Even after the new fields go in, I still think the proper solution for the
> actual recording rules is to use Custom/Power Recording Rules, rather than
> have a new field in record that's only useful for limiting generic rules to
> a specific season.  More things to set makes scheduling more complex, and
> less-commonly-useful criteria are better left to custom rules.  (That said,
> I actually use an any/all rule and just Never Record all the episodes in
> seasons I've already seen.)
>
>
That makes sense.  I had the season limit default to 0 if the user didn't go
into the Schedule Options Editor screen, but I completely understand the
wanting to limit preferences/options that are available on the basic
recording rules setup.  I'll open up a thread on the Schedule Direct forums
to see if there is a "secret" way to gather this information, or if it is
something that could possibly be added in the future (although I suspect
not, I imagine getting TMS to add this data would be a major hurdle).  But
then again, it's worth asking about.


>  I could potentially interface with http://thetvdb.com and post-process
>> the grabber data, but that seems a little cumbersome.  Any thoughts on
>> this?
>>
>>
>
> Pulling that data from any provider for each program in each users' program
> listings (even if it's limited to only the programs that match recording
> rules) would be an undue strain on the services--remember these listings are
> updated daily.  The right solution is to get it from the listings provider.
>  If the listings provider doesn't provide the data, there aren't a lot of
> other options--as you realized.  It sounds like only the users whose XMLTV
> providers actually specify an xmltv_ns episode-num and, possibly, users of
> some EIT providers get the data you're looking for.
>
>
I certainly agree, which is why I didn't pursue this avenue further.  Even
only updating newly grabbed listings for shows with record rules would
probably be too much strain on the servers.


> That said, eventually the season and episode numbers will be available in
> the database.  Their use in areas where listings do not provide the data
> will likely be limited only to actual recordings (never programs in
> listings) so we don't abuse the metadata services.
>
> Since TMS doesn't provide season and episode number for us, you'll have to
> use what's available from your listings provider and try to find some
> recognizable pattern in syndicatedepisodenumber or programid and then write
> an appropriate custom recording rule for it.  I would be more accepting of a
> patch that adds an example SQL clause to the Custom Recording Rule editor
> showing how to filter a range of programid's or some substring within a
> syndicatedepisodenumber.  Then again, if you don't think it would be
> generally useful, you can simply save a "user" example clause for yourself
> (using the Custom Recording Rule editor).
>

When syndicatedepisodenumber is set properly the formula seems to be (season
* 100) + (episode).  There were certainly a lot of false negatives (shows
that would be recorded if the information was there), but I did not run into
any false positives.  I can certainly provide example SQL for the Custom
Recording Rule editor, if others would find it useful.  This would actually
be better as you could restrict to a range of seasons or prevent a range of
seasons from recording.

Frankly I have never used the Custom Recording Rule editor and will check it
out when I get home this evening.


>
> Sorry to be the bearer of bad news.
>

Don't be sorry about the reality of the situation :)


>
> Mike
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


Cheers,

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20100607/8f245a3c/attachment.htm>