Invalid notifications screens added to stack prevent exiting playback

[stuartm]

I've been sitting on this issue for a while and haven't yet managed to get to the bottom of it.

If the backend is restarted while in playback, and possibly under other conditions, it appears invalid notification screens are added to the stack. The underlying reason for the screens being invalid might be theme related, but there are no errors in the logs to indicate this is the case. Notifications aren't displayed during playback.

When it comes to processing the ESCAPE action, we won't exit if there are notifications in the stack since they need to be dismissed first. Because they are invalid, they can't be dismissed and the ESCAPE action does nothing at all. The frontend remains unable to exit playback until it does so at the end of the recording. The invalid notifications remain in the stack despite exiting playback and will block playback exit for any subsequent recordings, meaning the only fix is to restart the frontend.

[Roger Siddons <dizygotheca@…>]

Fix

[Roger Siddons <dizygotheca@…>]

This was caused by commits ccde7292, 6350a12a & 3016a7be.

Effects are;

1. Notifications are not displayed on playback window
2. Notifications displayed on main menu are shown once but not re-displayed when they re-occur.

The assignment-operator is invoked in 2 places;

1. When a notification is removed from display (by expiry or acknowledgement) it is copied to the suspended store for re-use if/when the notification re-occurs (I'm not sure why). Theme elements should be cleared as the theme may have have changed the next time it occurs. Setting the created flag prevents the notification from re-loading the theme on subsequent occurrences. As the theme elements remain unintialised, the notification will fail to be re-displayed after its first occurrence. Presumably this caused the ESC key consumption issue (I haven't checked).

2. Notifications on the playback window are stored in the 'converted' member to account for different OSD resolutions. When displayed, they are refreshed on each frame with the latest metadata. Here, the created flag should be reset so that the OSD loads the theme on first display, then left set to prevent repeated re-loading. 6350a12a repeatedly reset the flag, causing playback performance issues due to theme re-loading on every frame. 3016a7be initialises the flag as set so that the notification is never displayed and ESC is consumed, as in (1).

ccde7292 also incorrectly allocated new timers, causing a small memory leak although seemingly no other adverse effects.

The confusion arose because the assignment-operator was intended/used to update selected members only, to which cppcheck (correctly) objected.

This patch;

1. Detaches the copy-constructor from the assignment-operator (where it was initialising twice) so that suspended notifications re-load the theme and are displayed when they re-occur.
2. Changes the assignment-operator to a member function, where its selective update is acceptable and more obvious.

Tested with basic notifications (Backend disconnected, No file found) but not the more exotic ones (progressbar, music etc.)

[Roger Siddons <dizygotheca@…>]

In 652318685fb880997bb9981562c570734e189213/mythtv:

Fix notifications & playback exit. Fixes #12387

Fixes re-display of previous notifications.
Fixes display of notifications on playback window.
Fixes 'ESC key won't exit playback' due to hidden notifications.

Issues were introduced by commits ccde7292, 6350a12a & 3016a7be.

Signed-off-by: Stuart Morgan <smorgan@…>

[JYA]

I'm seeing a different behaviour.

When I have playback going, and I recently started a scan of the video library. Various notifications will be appearing stating that XXX metadata were found.

Those aren't displayed as they are marked to only be displayed outside of playback. But they are there.

I can exit then and I will see the notifications.

I think it would have been much easier to simply never process a notification known to be invalid (not sure what that mean though)