[mythtv] What is an "episode" ? What is a "part" ?

[Torbjörn Jansson]

> On 11/19/2012 09:47 AM, Stuart Morgan wrote:
> > On Monday 19 Nov 2012 09:36:59 Daniel Thor Kristjansson wrote:
> >> On 11/16/2012 08:01 AM, Håkon Alstadheim wrote:
> >>> I find I confuse myself more on this question the more I think
> about
> >>> this. I get shows with descriptions like "(2:3)" , "(2:3/s4)" or
> >>> "(2/s4)". I've also seen "Sesong 4. (2) ", indicating episode 2,
> total
> >>> number of episodes 3, and season 4 in those examples. Other
> variations
> >>> also exist. This system is fairly new in my part of the world, so I
> have
> >>> never seen how "part 2 of episode2" would be marked.
> >>>
> >>> My question is: should I use the above strings from the description
> to
> >>> fill in "syndicatedepisodenumber" AND also partnumber and parttotal
> ?
> >>> Why is one a string and the others integers ?
> >>> What would it take to change myth into storing episodes, parts,
> seasons
> >>> and total episodes in a consistent way? -- That is, how is this
> >>> information used by myth ?
> >> The partnumber and parttotal are the
> >> episode number and number of episodes in a series and is
> >> intended to inform algorithms needing to know that info.
> > My understanding was that it was specifically for multi-part episodes
> sharing
> > the same episode ID/subtitle, so that the scheduler would record both
> parts
> > instead of treating the second as a duplicate?
> 
> Yes, for example, a mini-series with the same title and subtitle and
> even program ID that's aired in 2 or 3 parts or whatever.  Note,
> though,
> that the same could apply for multi-part episodes of regular series
> that, perhaps, were originally aired as a special one-hour episode and
> are later re-aired as 2 half-hour episodes or whatever.
> 
> > There's unquestionably a lot of confusion around these three columns
> and there
> > always has been. At the very least I'd back dropping
> syndicatedepisodenumber
> > in favour of discrete episode #, series # fields (these already exist
> but are
> > currently reserved for metadata grabber supplied values). Renaming
> the part*
> > columns with more descriptive names would also be good. Either
> episode #,
> > total_episodes OR episode_part, episode_totalparts depending on what
> the
> > intention is here.
> 
> Note that syndicatedepisodenumber is not what most people would
> consider
> an episode number.  It's the production-company-internal value used to
> identify the episode during production.  It's a string because it uses
> whatever format the production company chooses--and very often contains
> non-numeric characters.  For example, these are a few of the ones I
> have
> RS024, SAS108, SW051012.  Grabbers shouldn't fill it out unless they're
> given the actual syndicated or "official" episode number.
> 
> Note, also, that as Daniel mentioned, it's never used internally for
> any
> decision making--it's just "informational".
> 

Well...
If i'm not mistaken xmltv based grabber uses the syndicatedepisode number to
put season and episode info since there is no better location to put it.
And this is then never carried over to the actual recording resulting in
missing episode numbering on all recordings even when the guide data is a
perfectly good source for this info.

I believe this have been discussed before.
Can we have a fix or something for this?

If I remember correctly there is one or more tables that don’t store that
info so it never carries over to the recording.
My hackish workaround is to run a sql script that copies it over manually by
splitting syndicated episode number (if present it is always in the form
SxxEyy due to xmltv)