Opened 10 years ago

Closed 9 years ago

#8127 closed defect (wontfix)

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

Reported by: Chris Browet <cbro@…> Owned by: sphery
Priority: minor Milestone: unknown
Component: MythTV - Mythfilldatabase Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (2)

mythtv-2char_SE_programid.patch (1.1 KB) - added by Chris Browet <cbro@…> 10 years ago.
mythtv-8127-fix_programid_uniqueness.patch (1.7 KB) - added by sphery 10 years ago.
Fixes programid generation to create unique IDs

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by Chris Browet <cbro@…>

comment:1 Changed 10 years ago by Chris Browet <cbro@…>

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

comment:2 Changed 10 years ago by sphery

Owner: changed from stuartm to gigem
Status: newassigned

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.)

comment:3 Changed 10 years ago by 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?.

comment:4 Changed 10 years ago by gigem

Owner: changed from gigem to sphery

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.

comment:5 Changed 10 years ago by 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...

comment:6 Changed 10 years ago by sphery

Status: assignedaccepted
Summary: [PATCH] Encode season & episode systematically on 2 char in programidGenerated programid is not always unique for XMLTV-provided listings
Type: enhancementdefect
Version: unknownhead

Changed 10 years ago by sphery

Fixes programid generation to create unique IDs

comment:7 in reply to:  4 Changed 10 years ago by 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.

comment:8 Changed 9 years ago by sphery

Resolution: wontfix
Status: acceptedclosed
Summary: Generated programid is not always unique for XMLTV-provided listings[PATCH] Encode season & episode systematically on 2 char in programid

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.

Note: See TracTickets for help on using tickets.