Selection Doesn't "Take" in the Information Center > System Status

[Scott Harris <snharris99@…>]

If you go to Information Center > System Status and make a sub selection, the first one will not apply. For example, scroll down to Job Queue, then jump over to the first job in the queue and the details of that job will not be displayed. If you select another job in the queue, then the selections will start to be made.

Also, after performing an action on a sub item, when focus is returned back to the list, it doesn't apply. For example, scroll to AutoExpire? List and then select a program to delete. Delete it, then try to delete the program that focus lands on. The second program will appear to be removed, however if you exit and come back, it will still be there. Deleting and then scrolling again also will not allow you to delete another program. You have to exit completely, then come back and do them one at a time.

[Kenni Lund [kenni a kelu dot dk]]

I can confirm the first updating issue. I don't get exactly the same behaviour as reporter describes, when deleting items on the autoexpire list, but something is wrong for sure. This second issue might be a dup of #8441. Tested with the Mythbuntu theme.

[Scott Harris <snharris99@…>]

To add, I have tested it across all standard themes. This is not the same as 8441. This is still in the info center, not the recordings screen.

Perhaps they should have been 2 separate tickets? I just logically linked them together in my head. However, in the second one focus does appear to "take" in so much as when focus is returned to the list from the action menu, you can perform another action on the item it lands on, and it will even appear to work (the item will be removed from the list after a delete for example). However, the second action will not actually take place.

[stuartm]

The first issue may be fixed by [5aa72ebc]/[8bf1a3a], but the root cause is that the status screen mis-uses the helptext textarea which is reserved for a special purpose. I can't break themes in 0.24 and backport the correct fix, but I will re-write it for 0.25.

[stuartm]

Please test the following patch for the second issue, I can't test this without deleting recording I'd like to keep. Be warned that there is potential for deleting the wrong recording if the index is wrong!

diff --git a/mythtv/programs/mythfrontend/statusbox.cpp b/mythtv/programs/mythfrontend/statusbox.cpp
index ec23b0a..44182c5 100644
--- a/mythtv/programs/mythfrontend/statusbox.cpp
+++ b/mythtv/programs/mythfrontend/statusbox.cpp
@@ -445,6 +445,7 @@ void StatusBox::customEvent(QEvent *event)
                 RemoteDeleteRecording(
                     rec->GetChanID(), rec->GetRecordingStartTime(),
                     false, false);
+                m_expList.erase(m_expList.begin() + m_logList->GetCurrentPos());
                 m_logList->RemoveItem(m_logList->GetItemCurrent());
             }
             else if (buttonnum == 1)

[Scott Harris <snharris99@…>]

I'm going to be honest with you, I haven't a clue how to apply a patch. An easy test is to watch some LiveTV....3 or 4 programs in case your index warning comes into play, then try to expire the LiveTV entries from the list in the Info Center.

[Github]

Fix deleting expired recordings in the status screen.

There was a bug introduced by ​https://github.com/MythTV/mythtv/commit/48fb2493 which was preventing recordings from being deleted or their recording group being changed.

This changes the expire button list back to reloading after something is changed, each item in the list needs to be updated to reflect the new stats anyway so there is little advantage to not reloading the list completely. To speed things up we only grab the expire list once from the BE. We also restore the position after refreshing the button list which was the original complaint being fixed by 48fb2493.

Refs #9286, #8787.

Branch: master Changeset: 9649c3ca78580a47643ba349b1038d190bedffad