Opened 12 years ago

Closed 12 years ago

#4931 closed defect (invalid)

When avoiding conflicts with LiveTV, HandleGetNextFreeRecorder iterates through encoders in wrong order

Reported by: Nick Morrott <knowledgejunkie(at)gmail(dot)com> Owned by: danielk
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords: avoid conflicts live tv
Cc: Ticket locked: no

Description

When "Avoid conflicts between live TV and scheduled shows" is enabled, MainServer::HandleGetNextFreeRecorder? seemingly iterates through the available encoders in the wrong order.

If the iterator reaches the end of the encoder list, the function resets the iterator to the beginning of the list (mythtv/programs/mythbackend/mainserver.cpp, lines 2755-8), which surely results in returning the *best* encoder available (and therefore most likely to be used for recordings), rather than the next least-worst encoder (which is the next least likely to conflict with scheduled recordings).

Because the behaviour does not change whether "Avoid conflicts between live TV and scheduled shows" is enabled or not, the only benefit currently seems to be that the *first* card chosen for LiveTV is unlikely to conflict with LiveTV, as MainServer::HandleGetFreeRecorder? takes LastFreeCard? into account, whereas MainServer::HandleGetNextFreeRecorder? does not.

As an example, on my system I have 4 currently configured cards. I have 'avoid conflicts' enabled, and if I fire up Live TV I get the last encoder (#4) as expected. If I then choose the next tuner, I would expect to get the next least-worse (#3) but it cycles back to #1 (the best encoder, if available), and then iterates forwards until the end of the list is reached again.

Change History (2)

comment:1 Changed 12 years ago by danielk

Owner: changed from Isaac Richards to danielk
Status: newassigned

comment:2 Changed 12 years ago by danielk

Resolution: invalid
Status: assignedclosed

After looking over the code it appears this is working as designed and simply reversing the iterator will not produce the desired result. But a patch implementing a better avoidance algorithm would be desirable.

I'm marking this invalid as a feature request without patch.

Note: See TracTickets for help on using tickets.