[mythtv-users] Why are some seriesid's SHnnnnnnn and some EPnnnnnnn?

Michael T. Dean mtdean at thirdcontact.com
Tue Sep 18 02:51:40 UTC 2007

On 09/17/2007 02:13 AM, f-myth-users at media.mit.edu wrote:
>     > Date: Mon, 17 Sep 2007 00:42:37 -0400
>     > From: "Michael T. Dean"
>     > On 09/16/2007 10:45 PM, f-myth-users at media.mit.edu wrote:
>     > > [I'm not sure if this is going to turn into a -dev issue, so I'll
>     > > start on -users for now.]
>     > >
>     > > Shortly after the DD->SD cutover, I got screwed because one of the
>     > > series I record had its seriesid change from SHnnnnnn format to
>     > > EPnnnnnn format and I didn't catch it in time---because -almost-
>     > > everything else stayed the same.
>     > How do you mean you "got screwed?"  Myth doesn't use the seriesid to
>     > identify shows to record.  It matches on titles.
> Some further exploration (which I only discovered after reading your
> "matches on titles" above and looking specifically at titles in the
> database) yielded -half- of an explanation---as near as I can tell,
> for the seriesid that changed in mid-Aug, the program title acquired
> a "The " at the beginning that it didn't have before.  (I say "as near
> as I can tell" because I can't actually see mid-Aug, but I can
> certainly see that current episodes have a different title than they
> did before mid-Aug.)  That presumably caused matching to fail.

Correct.  It would do so.

>   That
> it also changed seriesid is a clue that perhaps somebody created a
> brand new database record over in TMS-land and changed two things at
> once, halfway through a season.  [Or, perhaps, it's a symptom of the
> DD->SD cutover and the seriesid stayed constant until the end of Aug
> when I started pulling from SD; since I don't have recordings from
> that interval, I can't check anything in my DB.  And see below.]

I really think it's the former (as you agreed in your follow-up
message).  Remember that /both/ seriesid and episodeid are TMS
constructs, which TMS can control as they like.

>     > It is used--in a sense--to detect duplicates.  Therefore, if you mean,
>     > "I got screwed because it recorded a show I had already watched," you
>     > need to rethink your definition of screwed.
> That wasn't my definition of "screwed", so you need to rethink your
> default assumption.  (I think that assuming that anyone would say
> "screwed" when they meant "too much got recorded" is needlessly
> condescending.  I'd like to assume that almost everyone reading this
> would have assumed that "screwed" meant "recording did not happen",
> since that's the outcome that's hard to correct; I'd also like to
> assume that you're not deliberately looking to condescend.)

No.  Not trying to be condescending.  Just didn't like your accusatory
terminology and blaming MythTV for being poorly designed when it's not
designed even close to the way you described, so I used a "curt" way of
saying that the only potential symptom of changing seriesid's is not
that big a deal.  I apologize if I offended you--that wasn't my intention.

The only way you /could/ be screwed (meaning "something didn't occur as
I think it should) by a changing seriesid is the way I described.  So if
the cause of the problem you described was actually the cause of the
problem you experienced, that's the only meaning of "screwed" I could
assume.  You explained the "cause" in detail, but never actually
explained the symptom, so I went with the information you'd given...

Besides, it is possible that a person could lose a show due to
autoexpiration if an unnecessary recording is made.  Though, as I didn't
have any info on what actually happened, I was willing to make  a leap
from explained cause to only potential symptom.  I was unwilling to make
a second leap to potential symptom (autoexpiration of wanted recording
due to lack of space) of the potential symptom (unnecessary recording)
of the explained cause (changing seriesid's) as I figured if this were
the symptom you were concerned about you'd say so in a follow-up.

>     > See:
>     > http://www.gossamer-threads.com/lists/mythtv/users/169129#169129
>     > and
>     > http://www.gossamer-threads.com/lists/mythtv/users/169259#169259
>     > (Heh.  And in the second message, Bruce even mentioned that I'll one day
>     > link to his seriesid messages.)
> Those are useful, and since they date from 2005, they probably
> describe the behavior of thet 0.18.1 that I'm running, too.

Yep.  Myth has worked that way as long as we've been using DD data.

> But then I'm still left wondering why seriesid's are changing at all
> from TMS-land.  It seems all the -recent- stuff (e.g., anything I've
> fetched through SD and not DD) is certainly coming back with SP-format
> seriesid's and not EP-format; if this is an inadvertent change caused
> by some sort of massaging in SD-land, somebody should take a look at
> it, and if it's a deliberate change, somebody should document it---
> especially for those of us who might be using the database in
> nontraditional ways (e.g., for tools outside of Myth).  It's clear
> that -something- has changed there, and I wonder if it's a sentinel
> of other changes that might cause things to break.  And it's for
> -damned- sure I'd have been faster to figure out the -real- cause
> for the failed recordings if there hadn't been a simultaneous change
> in one or both of the seriesid/programid fields; that was quite a
> red herring and wasted a good bit of my time.

As for SD "massaging" data, TTBOMK, they don't even touch the data
(yet--though "soon" may be hosting it themselves).  I will say that I'm
reasonably confident that before they start making changes to the
listings data, though, they (being developers--several of them MythTV
developers) will consider the effect of such changes on software using
the listings data.


More information about the mythtv-users mailing list