[mythtv] [mythtv-commits] mythtv commit: r10570 by bjm

John P Poet jppoet at gmail.com
Tue Jul 18 01:05:12 UTC 2006


On 7/17/06, Bruce Markey <bjm at lvcm.com> wrote:
> John P Poet wrote:
> ...
> > I know this ticket is not assigned to you, but if you have time...
> >
> > http://svn.mythtv.org/trac/ticket/1879
>
> The programids are unique identifiers managed by TMS and I don't
> like the idea of mucking with them after the fact. These are stored
> in a field of the program table as are the partnumber and parttotal.
> If you want to look at the partnumber then look at the part number.
> There is no reason to mash this into another field of the same table.
>
> If you feel you are going to need to identify the same programid as
> different episodes by partnumbers, than add code to do so without
> slowing things too much. when checking if two showings are the same,
> if the programid matches, look to see if the partnumbers match. This
> would mean adding the partnumbers to oldrecorded. However, I believe
> that this is one of those things that sounds like a good idea in the
> abstract but isn't really useful in practice.
>
> You referred to an example in an earlier thread as a mini-series but
> the programid in the example was a "MV%" movie. If an actual mini-
> series had unique info, it would have different programids. IOW, I've
> yet see a mini-series with generic descriptions but unique partnumbers.
> It may have happened. I haven't seen it.
>
> mysql> select programid,showtype,partnumber from program where showtype="Miniseries" and partnumber > 0 order by programid;
> +--------------+------------+------------+
> | programid    | showtype   | partnumber |
> +--------------+------------+------------+
> | EP0369350001 | Miniseries |          1 |
> | EP0369350002 | Miniseries |          2 |
> | EP0369350003 | Miniseries |          3 |
> | EP5386030004 | Miniseries |          2 |
> | EP5386030004 | Miniseries |          2 |
> | EP5386030005 | Miniseries |          3 |
> | EP5386030005 | Miniseries |          3 |
> | EP5386030006 | Miniseries |          1 |
> | EP5386030006 | Miniseries |          1 |
> | EP8128690001 | Miniseries |          1 |
> | EP8128690002 | Miniseries |          2 |
> +--------------+------------+------------+
>
> I currently have one Special and three movies with more than one part:
>
> mysql> select programid,showtype,partnumber from program where programid like "SH%" and partnumber > 1 order by programid;
> +--------------+----------+------------+
> | programid    | showtype | partnumber |
> +--------------+----------+------------+
> | SH1367680000 | Special  |          2 |
> +--------------+----------+------------+
> 1 row in set (0.00 sec)
>
> mysql> select programid,showtype,partnumber from program where programid like "MV%" and partnumber > 1 order by programid;
> +--------------+----------+------------+
> | programid    | showtype | partnumber |
> +--------------+----------+------------+
> | MV1464360000 |          |          2 |
> | MV1464360000 |          |          2 |
> | MV1587570000 |          |          2 |
> +--------------+----------+------------+
> 3 rows in set (0.05 sec)
>
> Here's the problem. If I record a movie (or a Special), I'm going
> to use Single or FindOne. If I Single record and it is shown in two
> parts, I'm only going to get the first part that I Single record no
> matter how it's marked. This suggests that maybe movies should be
> set with an All or Channel rule just in case it is shown in more than
> one part. However, this means that you need to remove the rule manually
> afterward. If I'm thinking of the possibility of there being multiple
> parts, I'd rather look to see if that's the case and would still rather
> Single record both parts instead of setting a recurring rule that I have
> to remove later.
>
> So while this sounds like something that ought to be done, in several
> years of using DVRs there has never been a situation where identifying
> matched programids by part number would have ever helped me.
>
> --  bjm

I understand, but I sometimes go out-of-town with no internet access,
so am unable to micro-manage Myth.

I asked David if he preferred putting code to solve this at the "Data
Direct" level, or the scheduling level, and he said he preferred the
"Data Direct" level....

I will continue to apply this patch to my own tree, and will not
expect it applied to trunk.

Thanks for looking at it.

John


More information about the mythtv-dev mailing list