<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 19/05/2016 15:04, Michael T. Dean
      wrote:<br>
    </div>
    <blockquote cite="mid:573DC80B.3000000@thirdcontact.com" type="cite">On
      05/19/2016 09:50 AM, Michael T. Dean wrote:
      <br>
      <blockquote type="cite">It should not be an option as the program
        ID is the definitive identifier of a program.  If it's
        available, it should be used.
        <br>
        <br>
        What you really want is to expand the definition of program ID
        to recognize its source dependence.  So, the most
        straightforward approach would be to include some source
        identifier in the program ID, something like
        <sourceid>-<programid>.  However, the source
        identifier could not be anything like a MythTV Video Source
        sourceid because that can change even when the actual source is
        the same (i.e. after a Delete all Video Sources).  It could be
        the Video Source name, but that would require that the user
        never change that name (and know its additional importance). It
        almost makes sense for it to be the Video Source xmltvgrabber
        (for XMLTV or Schedules Direct), except in some areas the
        grabber name is changed frequently, though it ultimately gets
        its data from the same upstream source.  Ideally, it would be
        some value taken from the data provider itself, though I don't
        know my XMLTV/SD/EIT data well enough to suggest any particular
        value to use for a listings source ID that would be specific to
        a given program ID provider.
        <br>
        <br>
        Any patch making this change would need to appropriately update
        program, record,  recorded, oldrecorded, and recordedprogram
        data.
        <br>
      </blockquote>
      <br>
      Oh, and then the matching should be done using program ID where
      both episode have a program ID and the program ID source is the
      same for both, else it falls back to the user-specified duplicate
      matching algorithm.
      <br>
      <br>
      And, really, the duplicate matching itself would be easier with
      the listings provider ID (program ID source's ID) in a separate
      column, though the patch would be much more difficult (as it would
      require modifying program data in the protocol and such).
      <br>
    </blockquote>
    Thanks Mike. I'm glad you added the paragraph "the matching should
    be done using program ID where both episode have a program ID and
    the program ID source is the same for both, else it falls back to
    the user-specified duplicate matching algorithm" as otherwise, with
    your first response, I didn't see how that would fix the problem
    when one changes listings provider, which at the moment will cause
    all previous episodes to re-record due to all new listings having
    different format IDs.<br>
    <br>
    It would be great if there was a "universal" program ID that would
    give a particular episode of a particular series the same ID among
    all listings providers, but I don't think this will ever happen.<br>
    <br>
    My problem is particularly with the user interface, where it looks
    like we can control how duplicate matching works (and a few years
    ago, indeed we could) with the subtitle, description,
    subtitle+description stuff, but in most cases we cannot. I don't
    like UIs that lie to me! At the very least, some explanatory text
    could be added to say that these options only take effect when
    program IDs are missing. Even better if there was an advanced
    tickbox to ignore program IDs when doing duplicate matching if we
    wish to do so.<br>
    <br>
    It has been suggested that one possible fix of the re-record problem
    when changing listing providers is to blank the program ID from all
    oldrecorded entries, which would force duplicate matching to match
    on subtitle etc. I'm happy to do that, even though I dislike
    throwing away information, but others might not be happy with direct
    database manipulation.<br>
    <br>
    Which is why I suggested that, rather than blanking old program IDs,
    it would be better to add an option to ignore old program IDs when
    duplicate matching, which seems a relatively easy fix. If this
    option was added, I'm not sure if that would be best added to
    individual recording rules, which would mean a lot of editing
    recording rules for people but which would give maximum flexibility,
    or as a global option. Personally, I'm slightly preferring the
    option available in individual recording rules because at the
    moment, even disregarding changing listings providers, I have a
    problem with some series not correctly matching duplicates more than
    others.<br>
    <br>
    John<br>
    <br>
    --
    <pre class="moz-signature" cols="72">John Veness, MythTV user, UK, DVB-T</pre>
  </body>
</html>