[mythtv] [mythtv-commits] mythtv commit: r24724 by mdean

[Michael T. Dean]

On 05/18/2010 03:56 AM, Simon Kenyon wrote:
> On 17/05/2010 22:34, mythtv at cvs wrote:
>>        Author: mdean
>>          Date: 2010-05-17 21:34:21 +0000 (Mon, 17 May 2010)
>> New Revision: 24724
>>     Changeset: http://svn.mythtv.org/trac/changeset/24724
>>
>> Modified:
>>
>>     trunk/mythtv/programs/mythfilldatabase/xmltvparser.cpp
>>
>> Log:
>>
>> Ensure unique programid generation for XMLTV-based grabbers that 
>> provide episode and season numbers.
>>
>> The historical encoding of episode and season numbers into programids 
>> (since [5248])--appending unpadded episode and season numbers to the 
>> end of the seriesid--could cause non-unique programid's (for example, 
>> episode 11 of season 2 and episode 1 of season 12 were both 
>> represented with the same "112").  Since changing the programid would 
>> cause duplicate matching to fail against previously-recorded 
>> episodes, we have to maintain the approach of appending unpadded 
>> episode and season numbers to the seriesid.
>>
>> To ensure uniqueness of generated programids, this change requires 
>> that season always be represented as a single character.  To increase 
>> the number of seasons for which we can generate a programid, the 
>> season is represented in base 36.  If the season can not be 
>> represented as a single character, a programid is not generated, so 
>> the scheduler will fall back to using normal duplicate-matching 
>> methods (title/subtitle/description).
>>
>> This change will cause duplicate matching to fail for any episodes in 
>> seasons 10 or above for users whose XMLTV grabbers provide episode 
>> and season numbers--meaning that episodes of high-numbered seasons 
>> will be re-recorded.  All episodes in low-numbered seasons will be 
>> unaffected by the change.  However, after this change, users will no 
>> longer have the problem that episode 1 of seasons 11 through 19 are 
>> not recorded because the user previously recorded episode 11 of 
>> seasons 1 through 9, etc.  A false negative on duplicate matching is 
>> better than a false positive, and we have to change some programids 
>> to fix the bug.
>>
>> This change does not attempt to make the episode and season 
>> information in the programid parseable values.  Parsing of episode 
>> and season information from programid is discouraged as there are 
>> probably more users for which the episode and season information does 
>> not appear in the programid than users for which it does.
>
> would it not be "better" to "fix" the data
> this would appear to be a bit of a hack

Feel free to come up with an algorithm that goes through all historical 
recordings of EP12345678<episode_num><season_num> (with absolutely no 
padding in the episode and season numbers) and determine which one is 
episode 11 in season 2 (program ID EP12345678112 )and which is episode 1 
in season 12 (program ID EP12345678112 ).  And hitting thetvdb.com for 
every recording a user has ever made is not a valid solution--and 
wouldn't work, anyway, as the data there is sure to differ from the data 
in the database so matching would be difficult, and we're likely to do 
far more damage trying to automatically do any kind of fuzzy matching 
than we're doing by simply making it so that users have to either set 
the episode to "Never Record" if they realize that they've seen it or 
simply delete the episode after it records.

We just plain don't have the information to "fix" the data.  It's too 
late, so there's no other way to fix the issue.  Besides, the number of 
people affected by this change is rather small (only people in areas 
where XMLTV-based providers never specify programids and always specify 
episode and season numbers).  And, the number of shows having 10 or more 
seasons is likely much smaller than the number of shows having less than 
10 seasons.

There is one other potential workaround that could have been used, but 
it would have put additional strain on the scheduler--already one of the 
slower parts of MythTV--so the scheduler experts asked me to implement 
this solution.

Mike