…ingBuffer thread running.
…nt to QString, although QT4 would also complain about it.
… two entries off the array when there is now only one.
This now utilizes the dbus screensaver first, and then the previously existing screensaver methods. This should resolve the issues seen by those using only DPMS or xscreensaver. Fixes #12438 Refs #12414
… level #2 Refs #12438 Refs #12414
… level Refs #12438 Refs #12414
This is a preliminary step to allow multiple screen saver control methods to be utilized at the same time. Refs #12438 Refs #12414
If the Screensaver is Asleep() we ignore all keypresses generated via the remote. This is clearly so that a button pressed on the remote while the screen is asleep only wakes up the screen, rather than triggering an action. This swaps the logic around in the dbus screensaver so that it satisfies the Asleep() check. We may need to revist this in the future if we find that when using the dbus screensaver we are not ignoring the remote keypress which is used to bring us out of screensave. Fixes #12435 Refs #12414
JOB_QUEUED is an explicit value, not part of a bitmask. QMultiMap should use values() instead of find() to get the set of values for a particular key.
1. Put in the correct version of PROTO_VERSION. 2. I don't think requests sent to the backend actually need to be utf-8 or otherwise encoded. The encoding operation was causing an error for the latest, non-ASCII, version of PROTO_TOKEN.
The inputname and bookmarkupdate fields from ProgramInfo are added to the network protocol serialization to reduce the number of queries made by the Watch Recordings screen. Previously, inputname was fetched as a separate DB query in the UI thread, every time the selection changed. Also, a separate DB query might be made for bookmarkupdate as part of preview image generation, though this query was in a separate thread, so that change improves preview image load latency rather than UI responsiveness. Bumps the network protocol version from 85 to 86.
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.
… This has no functional effect but makes comparing our version of libbluray with upstream's much easier.
In the way things were set up originally, by default any playback would check for bookmark, progstart mark, or lastplaypos mark, and start playback from there, unless any or all of these had been explicitly disallowed. This was fine for playback from the Watch Recordings screen, which would always explicitly set each permission. It was not so good for other forms of playback, such as from MythVideo, mythavtest, or Gallery, since they would all favor lastplaypos, which is periodically updated for all playback. As a result, lastplaypos is changed to be disallowed by default. This is not really relevant to the progstart mark, since it is only present for recordings (though it could become a minor issue if a recording and its metadata are imported into MythVideo).
26f6437 was too aggressive in assuming that EnableCaptions would actually enable text subtitles, and DisableCaptions would actually disable text subtitles. They only enable/disable a particular type of subtitles (which may have already been enabled/disabled), so we need to check the overall state after the operation is performed.
Refs #11713. By default, MythPlayer::GetBookmark() now consults these marks if the ProgramInfo flags allow. This means that the initial bookmark for a recording would be precisely at the ProgStart mark because GetBookmark() would return ProgStart as the bookmark. The solution is to disallow those flags in ProgramInfo.
This recorder doesn't go through the usual path of the other recorders, where keyframes are identified (and where frames prior to the first keyframe are discarded) and the event is sent after the first keyframe is found. Refs #12328.
In changeset d526385 (refs #9829), code was added such that the first time ATSC caption data is seen, any future SCTE caption data is explicitly ignored. This was to deal with broadcasts containing duplicate caption data. This policy causes problems when the recording switches back and forth between the two sources of caption data, such as when the broadcaster splices in commercials. The updated solution continues to favor ATSC data, but allows a switch back to SCTE after SCTE data is seen 10 times in a row (a somewhat arbitrarily chosen number) without intervening ATSC data. Refs #12054.
Refs 11713. We actually don't want to tidy up the mark when then user saves a bookmark at exit. If the user starts playback only to realize they should have started at the last played position, we want to give them the chance to exit playback - possibly setting a bookmark but not clearing the last played position - and restart at the last played position. On the other hand, it is still OK to tidy it when the bookmark is cleared when playback reaches the end of the recording.
…blems with LIRC but allow events to be processed. This prevents extra key presses being queued and allows them to be ignored until MythFrontend has returned.
…p to date. There may be bits of code still looking there instead. Refs #12290