[PATCH] Encode season & episode systematically on 2 char in programid

[Chris Browet <cbro@…>]

This patch encodes the season and episode (when available) on 2 char in programid when parsing xmltv.

This allows clients only using the mythtv protocol to retrieve the season & episode from the programid for further processing. Nowadays, S1E11 and S11E1 both produces "EP<seriesid>111".

To be put immediately in use in XBMC, to allow scrapping based on title and season/episode.

[Chris Browet <cbro@…>]

Sorry, forgot to say that the patch is vs. 0.22-fixes

[sphery]

David, thoughts on this patch/proposal? TTBOMK, it would have the effect of breaking duplicate matching for all previously-recorded episodes (except episodes 10-99 in seasons 10-99) for all XMLTV users whose grabbers report season and episode information. And, I can't think of any way to retroactively fix programid's for old episodes. So including this change would likely require deleting the programid from oldrecorded and hoping that the title/subtitle/description info of future episodes matches the previously reported info (and we should only clear the programid for users who will be affected by the change--where identifying who's affected would be challenging in and of itself).

I'm nearly convinced that this causes more problems than it solves. I will admit that the current implementation is broken--but I'd guess that it's a small number of shows (let alone episodes) for which it breaks dup matching. (There aren't that many shows with more than 9 seasons and within those shows, it's only certain episodes that are affected.)

For safety and to maintain most functionality, I'd recommend we just suppress programid creation for an episode when season > 9. That will allow falling back to title/subtitle/description dup matching for seasons 10+. (BTW, I'm assigning this to you for your input, but I'm happy to create the patch, myself.)

[stuartm]

The long term plan is to gradually harmonize the information stored for recordings and video, which will mean the addition of series and episode columns in the recording tables. Using the proposed patch would be a very short term measure, I'd say we're more likely to accept a patch which adds series/episode numbers to those tables and ProgramInfo?.

[gigem]

Stuart is right -- the season and episode numbers should come from the database when and if they are available. The use of those values in the programid is purely to generate a unique value.

Mike, the only change I would make to your suggestion is to still encode seasons >= 10, but do it differently. For example, use 'A' - 'Z' for seasons 10 - 35. That should be enough for almost everyone. I'm assigning this back to you so please go ahead and create a patch.

[Chris Browet <cbro@…>]

@Stuart: Please take into account that the goal of the patch is to be able to get Season/Episode? information thru the API.

If I'm not mistaken, the info is already availabla in the "recordedprogram" table "syndicate..." column (although I don't know what this table is used for; seems very similar to "recorded").

The main problem is that there is no way to access this information thru the api at the moment, only by sql. As the programid is sent, it is a quick win to get Season/Episode? info for xmltv users.

The proper way would be to return this info in a "QUERY RECORDING" (if I'm not mistaken), but that is out of my league...

[sphery]

Fixes programid generation to create unique IDs

[sphery]

Replying to gigem:

Mike, the only change I would make to your suggestion is to still encode seasons >= 10, but do it differently. For example, use 'A' - 'Z' for seasons 10 - 35. That should be enough for almost everyone. I'm assigning this back to you so please go ahead and create a patch.

Attached a patch that implements the solution recommended by David. I'm holding this patch until after the 0.23 release since it will cause re-recording of all episodes from seasons 10+ for all XMLTV (not Schedules Direct) users whose grabbers report season and episode numbers, so I'd rather it get some testing in trunk for a while before it's pushed to stable.

[sphery]

Changing summary back and closing so that the 2 separate issues aren't confused.

programid should not be used by any applications to determine season and episode numbers, as we don't guaranteed the existence of programid and in many areas there is absolutely no season and episode information in programids. Use of programid for anything other than duplicate matching makes invalid assumptions.