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

Mike


More information about the mythtv-users mailing list