Preview Thumbnail regenerated unnecessarily

[stutty@…]

On finishing watching a recording (after setting a bookmark, or hitting the delete recording key), the frontend hangs for over 2 seconds. This is due to the frontend requesting the regeneration of the Preview Thumbnail (on my EPIA 8000 Backend - v slow) even though the the option PreviewFromBookmark? is not selected -> the regenerated preview is exactly the same as the original.

[stutty@…]

Possible patch for problem, works okay for me.

[cpinkham]

Can you see if you can accomplish the same thing by editting PlaybackBox::play() and moving the following line down from the middle of the method to the end right before the return line?

state = kStarting; restart playback preview

Put that line right before this line at the end:

return playCompleted;

I think that will cause the preview to not be updated until we've refreshed the recordings list which till take into account the fact that we just deleted the recording we were watching. The frontend is hanging because the preview generation is consuming the backend CPU at the same time we're trying to refill the recordings list. This will delay any preview generation or playback until after we've refilled the list. PreviewFromBookmark? isn't the only reason we might be updating the pixmap here, it could be that the recording length has changed or the cutlist was changed, etc.. so I think it might be better to use this delayed start rather than not updating the pixmap at all.

[stutty@…]

Alas I am very unfamiliar with the workings of the code, so my solution is only a proposal. I did try your suggestion, but I still get pauses on exiting the recording.

My only comment would be that:

In general for my system the only time I would want the frontend to cause thumbnail generation is in the case where no thumbnail currently exists (Although I would probably be happy with a blank in this case!). A responsive GUI is more important than frame exact thumbnails to me.

Ideally thumbnail generation would be a background backend task such that the frontend is never stalled waiting for the pixmap to be generated, as seems to be the case at the moment.

[cpinkham]

I missed one thing in the change I asked you to try. Can you also move down the "playingSomething = false;" line to the end along with the "state = kStarting;"? The playing something is the important one that would prevent the preview image from refreshing until the frontend had redownloaded the recordings list. state = kStarting is what lets the preview video restart, but if playingSomething is false, the preview pixmap can still be refreshed.

[stutty@…]

Sorry this did not appear to make any difference, I'm making the changes against SVN 8482

[danielk]

(In [8722]) Fixes #935.

• Avoids generating a preview while waiting for the user to confirm a delete of the recording.
• Avoids generating a preview for programinfo's with an availableStatus of asPendingDelete.

Generating these previews is a waste of time the 90% of the time when the user condfirms the delete, and generating previews can take a long time on embedded processors such as the EPIA Via processors often used to run MythTV.

[phoner]

I still have previews being displayed/played while the pending delete. Is this what's intended to be avoided? If so this doesn't seem to be working.

[phoner]

actually what I want is the preview to not be played during the pending delete time, guess that's not the same as regenerating it.