[mythtv-users] UK: Strictly Come Dancing E1S12, looks like a dupe

[Roger Siddons]

On Thu, 18 Sep 2014 15:42:05 +0100, Michael T. Dean  
<mtdean at thirdcontact.com> wrote:

> On 09/18/2014 08:00 AM, Tim wrote:
>>
>> Quoting Roger Siddons:
>>
>>>
>>> Myth constructs it from the title, series id and season/episode.
>>>
>>> https://code.mythtv.org/trac/browser/mythtv/mythtv/programs/mythfilldatabase/xmltvparser.cpp#L541
>>
>> Thanks for the link, It seems the intro show was listed as E1S12 aswell  
>> as the first show in the series proper. This means it's a listings 
>> problem (Atlas). Cue gnashing of teeth as millions of Freeview+ boxes 
>> fail. Not sure how to report it, I'll try XMLTV first.
>
> Yes, it's a listings error, which will affect users of MythTV in such a 
> way that they must work around the bad listings. The Freeview boxes, 
> however, may not be affected (because they almost certainly have 
> different duplicate matching approaches from ours).
>
>>> And won't your recorded Launch Show be s00e00 because Myth doesn't 
>>> store the season/episode (and your not using metadata lookup) ? Atlas 
>>> may well have marked it as e01 when you recorded it.
>>
>> mysql> select title, subtitle, seriesid, syndicatedepisodenumber, 
>> starttime, programid from program where title like 'Strictly%Dancing';
>> +-----------------------+----------+-----------+-------------------------+---------------------+---------------+ 
>> | title | subtitle | seriesid |syndicatedepisodenumber | starttime |  
>> programid |
>> +-----------------------+----------+-----------+-------------------------+---------------------+---------------+ 
>> | Strictly Come Dancing | | 102474247 | E1S12| 2014-09-26 20:00:00 |  
>> EP1024742471c |
>> | Strictly Come Dancing | | 102474247 | E2S12| 2014-09-27 18:00:00 |  
>> EP1024742472c |
>> +-----------------------+----------+-----------+-------------------------+---------------------+---------------+ 
>> 2 rows in set (0.00 sec)
>>
>> mysql> select title, subtitle, season, episode, starttime, programid 
>> from recorded where title like 'Strictly%Dancing';
>> +-----------------------+----------------------------------------+--------+---------+---------------------+---------------+ 
>> | title | subtitle |season | episode | starttime | programid |
>> +-----------------------+----------------------------------------+--------+---------+---------------------+---------------+ 
>> | Strictly Come Dancing | Strictly Come Dancing: The Launch Show |0 | 0  
>> | 2014-09-07 18:58:00 | EP1024742471c |
>> +-----------------------+----------------------------------------+--------+---------+---------------------+---------------+ 
>> 1 row in set (0.00 sec)
>
> MythTV would not have made the shown program ID for that episode. When 
> MythTV auto-generates a program ID, it does so *if and only if* the 
> season /and/ episode are specified, and it does so by concatenating a 
> category identifier (here "EP" for episode of a series) with the series 
> ID (generally the ELF hash of the title--here "102474247") and the 
> episode number (in decimal--here "1") and season number (in base36--here  
> "c"). So, that program ID would never have been generated byMythTV with  
> season and episode numbers of 0 (instead it would havegenerated the  
> value "EP10247424700"). Therefore, I'm assuming thatAtlas may have  
> provided the program ID (likely trying to copy our(broken--see 
> http://www.gossamer-threads.com/lists/mythtv/users/575087#575087 ) 
> auto-generation mechanism) and reported it as a definitive identifier 
> (using the system="dd_progid" attribute value of the XMLTV <episode-num> 
> tag)? You'll have to look at the raw XMLTV data to verify that Atlas is 
> sending made-up program ID's and reporting them as definitive--and ifso,  
> not only did it report a non-definitive program ID as definitive,but it  
> also generated it incorrectly, assuming (as it appears) it triesto  
> duplicate what MythTV would have generated.
>

I'm pretty sure that's not coming from Atlas. Likewise I'm not sure what's  
gone into 0.27/fixes (presumably what Tim is using) but I believe on  
master Myth WILL generate the id because Atlas always supplies  
episode/season numbers (albeit the wrong ones sometimes, and excepting a  
few radio programmes). They should be stored in the corresponding  
recordedprogram table, if Tim cares to check...

However they are not copied to the recorded table as per Karl's  
informative note in https://code.mythtv.org/trac/ticket/12141. So, if the  
metadata lookup fails/isn't used, recordings will always appear to be  
s00e00, as shown. ie. misleadingly different to the program id!

And what will happen if/when the grabber reports a different  
season/episode, ie. if tvdb correctly reported this as s12e0 (a special ?)  
- it doesn't -then Myth will refuse to record the upcoming s12e01 because  
it's a duplicate of the s12e00 it did last week!

Of course this just adds weight to your argument. Atlas does contain  
provider-designated programme ids but the grabber doesn't pass them on yet  
- it's something I was going to look into...

But I'm curious about SD: how is the dd_prog_id generated ? Does it solve  
these issues in the US, even if the same show is aired on different  
stations/service providers ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140918/f433decf/attachment.html>