playbackbox.cpp:extract_job_state() inefficient

[danielk]

Right now it queries the info independently for every recording on screen. But it is much more efficient to get this info in MainServer::HandleQueryRecordings?() where we already do a partial bulk load of this info to set FL_COMMPROCESSING.

[stuartm]

Milestone 0.25 deleted

[Raymond Wagner]

I'm picking this up as part of the rework for #7990.

[Jim Stichnoth]

I agree that in principle it would be nicer to add this directly to ProgramInfo? and ProgramList? and benefit from automatic PBB updates when changes are made.

However, it is complicated by the fact that a given ProgramInfo? can have multiple job queue records associated with it - commflag, transcode, metadata lookup, user jobs - and each can be in a different state, so it's hard to pack that all into a single ProgramInfo? field. Unless we're committed to only transferring a summary of specific state information about commflag and transcode jobs only, and encode that into a single field.

In the meantime, I've attached a simple patch that locally caches the entire job queue and reloads it at most once every 5 seconds. This greatly improves the sluggishness of navigating the Watch Recordings screen.

By the way, at least with my theme, every cursor move in the Watch Recordings screen fires off 4 jobqueue queries for each item displayed (plus a few extra queries). With this patch, changing the selection creates 3 queries total - 2 for card inputname and one for bookmark position (for preview generation) - plus 1 jobqueue query if it's been 5 seconds since the last query. Not perfect, but an order of magnitude better than before.

[Jim Stichnoth <jstichnoth@…>]

In b43b11ca3062086d20ee0072368e9dd3646a5faa/mythtv:

Reduce "Watch Recordings" sluggishness by caching jobqueue state.

Refs #8962, refs #7990.

Currently, when navigating the Watch Recordings screen, every time the
cursor position is moved, 4 jobqueue queries are issued for each item
visible on the screen (the actual number being controlled by the
theme). These queries are done within the UI thread, which makes
navigation noticeably sluggish on most any setup that isn't a
moderately powerful combined frontend/backend.

Ideally, any time a job's status changes (including queue addition and
removal), we would call ProgramInfo::SendUpdateEvent?() to get the
Watch Recordings entry updated, along with any other
ProgramInfoUpdater? subscribers. Also,
ProgramInfo::LoadProgramFromRecorded?() and LoadFromRecorded?() would
set up the necessary commflag and transcode flags in the ProgramInfo?
object.

However, in the current jobqueue implementation, this is not very
practical because of functions like:

JobQueue::DeleteJob?(int jobID)
JobQueue::ChangeJobCmds?(int jobID, int newCmds)
JobQueue::ChangeJobFlags?(int jobID, int newFlags)
JobQueue::ChangeJobStatus?(int jobID, int newStatus, QString comment)
JobQueue::ChangeJobComment?(int jobID, QString comment)
JobQueue::ChangeJobArgs?(int jobID, QString args)
JobQueue::ChangeJobHost?(int jobID, QString newHostname)
JobQueue::CleanupOldJobsInQueue?()

where the ProgramInfo? isn't readily available (though it could be
found given another query on jobID for all but the last function).

Instead, in this approach, the PlaybackBox? locally caches the jobqueue
contents, reloading every 15 seconds as needed. The reload blocks the
UI thread, but only for a small fraction of the time that the current
implementation was blocking it, so it's unlikely a user pay much
attention to this once-in-15-seconds query.

This code should be removed once #7990 makes jobs more autonomous.

[Jim Stichnoth]

Untested backport to fixes/0.27

[Jim Stichnoth]

Add fixes from master

[Jim Stichnoth <jstichnoth@…>]

In 974d1ae9b6fe2f12b8cfc48aafcf10fc730e414e/mythtv:

Reduce "Watch Recordings" sluggishness by caching jobqueue state.

Refs #8962, refs #7990.

This is essentially a cherry-pick of b43b11ca.

[Stuart Auchterlonie]

Milestone renamed

[Stuart Auchterlonie]

Moving remaining open tickets to 0.28.2 milestone

[Stuart Auchterlonie]

Moving remaining open tickets to 29.2 milestone

[Stuart Auchterlonie]

We have moved all bug tracking to github [1]

If you continue to have this issue, please open a new issue at github, referencing this ticket.

[1] - ​https://github.com/MythTV/mythtv/issues