Resolving a Recording Conflict

Discussion in 'Improvement Suggestions' started by CyberSimian, May 15, 2017.

  1. CyberSimian
    • Team MediaPortal

    CyberSimian Test Group

    June 10, 2013
    Likes Received:
    +1,004 / 3
    Home Country:
    United Kingdom United Kingdom
    Show System Specs
    Started on: 2017-05-15
    last update: 2017-05-15

    The algorithm for resolving a recording conflict does not act sensibly when there is more than one tuner available.

    MP Client, TV Server.

    When the user attempts to schedule a recording that would fail because of too few tuners, the MP Client displays this panel (skin shown is "DefaultWideHD"):

    one_tuner_one_mux_one_recording.jpg one_tuner_one_mux_six_recordings.jpg

    The first screenshot shows the case of one tuner with one recording already scheduled. The second screenshot shows the case of one tuner with six recordings on the same MUX already scheduled. The list shows only four recordings, but the list is scrollable, so it is possible to see the other two recordings. The problem with the current support is what the action does:

    Skip new recording This works fine, and simply rejects the attempt to schedule the recording that is causing the conflict.

    Keep conflict This also works fine, and simply accepts the recording that is causing the conflict. The user needs to resolve the conflict at a later time, in order to prevent recordings failing.

    Skip conflicting recording(s) This is the action that is deficient. This action discards all existing scheduled recordings that clash with the new recording.

    In the case of one tuner, this is the correct action to take, because the existing recordings that clash must all be for the same MUX (since the user has only one tuner). Therefore if the user wishes to retain the new recording, all of these existing clashing recordings must be discarded.

    However, if the user has two or more tuners, discarding all of the clashing recordings is unnecessary. Suppose that the user has n tuners, and has scheduled n recordings, each for a different MUX. In order to schedule the new recording, it is necessary to discard only one of the existing recordings, not all of them.

    The general case is more complex, for example n recordings spread over m MUXes (where m is less than n). Some tuners may perform only one recording, but other tuners will perform two or more recordings. In order for the user to be able to make a sensible choice of which recordings to discard, the MP Client needs to identify in some way which recordings are on the same MUX, and which therefore have to be discarded as a group if the user picks that set. Something like an arbitrary "MUX number" displayed adjacent to the programme name would do this, especially if the recordings were sorted by MUX number, rather than by name or starting time. Displaying a MUX number would need TV Server to send this information (or something equivalent) to the MP Client.


Users Viewing Thread (Users: 0, Guests: 0)

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice
  • About The Project

    The vision of the MediaPortal project is to create a free open source media centre application, which supports all advanced media centre functions, and is accessible to all Windows users.

    In reaching this goal we are working every day to make sure our software is one of the best.


  • Support MediaPortal!

    The team works very hard to make sure the community is running the best HTPC-software. We give away MediaPortal for free but hosting and software is not for us.

    Care to support our work with a few bucks? We'd really appreciate it!