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