Opened 13 years ago

Closed 8 years ago

#724 closed defect (fixed)

Inconsistent OSD timeout values

Reported by: bmayland@… Owned by: markk
Priority: minor Milestone: 0.24
Component: MythTV - User Interface Library Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

There are 3 configurable settings for OSD timeouts: OSDProgramInfoTimeout, OSDGeneralTimeout and OSDNotifyTimeout. However, many OSD activators do not use these timeout values.

TV::HandleStateChange() - settings OSD, 3 second timeout
TV::DoInfo() - program_info / status OSD, proginfo timeout
TV::DoQueueTranscode() - settings OSD, 3 second timeout
TV::UpdateOSDTextEntry() - channel_number OSD, 2 second timeout
TV::PreviousChannel() - channel_number OSD, 1 second timeout
TV::UpdateOSD() - program_info / channel_number OSD, proginfo timeout
TV::UpdateOSDInput() - settings OSD, 3 second timeout
TV::UpdateOSDSignal() - program_info / channel_number OSD, proginfo timeout
TV::ToggleMute() - settings OSD, 5 second timeout
TV::ToggleSleepTimer() - settings OSD, 3 second timeout
TV::ToggleLetterbox() - settings OSD, 3 second timeout
TV::ToggleRecord() - settings OSD, 3 second timeout (twice)
TV::ChangeAudioTrack - settings OSD, 3 second timeout
TV::SetAudioTrack - settings OSD, 3 second timeout
TV::ChangeSubtitleTrack - settings OSD, 3 second timeout
TV::SetSubtitleTrack - settings OSD, 3 second timeout
TV::ToggleSleepTimer(string) - settings OSD, 3 second timeout
TV::DoSkipCommercials() - status OSD, 6 second timeout
TV::UpdateOSDSeekMessage() - status OSD, passsed second timeout (always general)
TV::ChangeBrightness() - status OSD, 5 second timeout (twice)
TV::ChangeContrast() - status OSD, 5 second timeout (twice)
TV::ChangeColour() - status OSD, 5 second timeout (twice)
TV::ChangeHue() - status OSD, 5 second timeout (twice)
TV::ChangeVolume() - status OSD, 5 second timeout
TV::ChangeTimeStretch() - status OSD, 10 second timeout
TV::ChangeAudioSync() - status OSD, 10 second timeout
TV::DoTogglePictureAttribute - status OSD, 5 second timeout
TV::DoToggleRecPictureAttribute - status OSD, 5 second timeout
TV::ToggleAutoExpire() - status OSD, 1 second timeout (shouldn't this use settings?)
TV::SetAutoCommercialSkip() - status OSD, 1 second timeout (shouldn't this use settings?)
TV::SetManualZoom() - status OSD, 1 second timeout (shouldn't this use settings?)
UDPNotify::incomingData() - notify OSD, notify timeout
NuppelVideoPlayer:: - all over the place.  Do we still use this?

I think there are actually 3 timeouts needed in the TV class:
ProgramInfo? - self-explanitory
Status - displaying something non-interactive such as "Recording" or "Position Saved". Mainly things that use the "settings" OSD.
Interactive - changing picture adustments, time-scale, etc. Anything that is presenting information that may be changed by the user multiple times before going away.

At the very least, the hard coded timeout should be changed to use the user settings.

Change History (16)

comment:1 Changed 13 years ago by danielk

Milestone: 0.20
Resolution: invalid
Status: newclosed
Version: head

Please bring discuss you OSD timeout proposal in the mythtv-dev, that seems like too many timeout settings to me. I think two should be enough; but I don't have strong feelings about this. Try to obtain a consesus and then make a patch and reopen this ticket with the patch.

comment:2 Changed 11 years ago by judaz

Resolution: invalid
Status: closedreopened

I have the same problem as described in ticket #3023: After fiddling around with the playback options (from standard, to XvMC, and back I think) the given timeout for osd is not used it seems.

I run Fedora Core 6 with the packages from ATrpms: mythtv-0.20.1-157.fc6

I don't know what has been discussed on the myth-dev list, though...

I'll reopen the ticket as suggested in #3023

comment:3 Changed 11 years ago by Janne Grunau

Milestone: 0.20unknown
Version: head0.20-fixes

comment:4 Changed 11 years ago by stuartm

Milestone: unknown0.21
Owner: changed from Isaac Richards to stuartm
Status: reopenednew
Version: 0.20-fixeshead

comment:5 Changed 11 years ago by greg

Owner: changed from stuartm to greg

comment:6 Changed 10 years ago by greg

Milestone: 0.210.22

comment:7 Changed 10 years ago by Dibblah

Status: newassigned

comment:8 Changed 9 years ago by stuartm

Milestone: 0.22unknown

comment:9 Changed 9 years ago by stuartm

Component: mythtvMythTV - User Interface Library
Milestone: unknown0.23
Owner: changed from greg to stuartm

comment:10 Changed 8 years ago by stuartm

Owner: changed from stuartm to markk

comment:11 Changed 8 years ago by markk

Milestone: 0.230.24

This will be addressed in the libmythui-osd branch which should be merged in for 0.24

comment:12 Changed 8 years ago by markk

Status: assignedaccepted

comment:13 Changed 8 years ago by beirdo

Can this be closed?

comment:14 in reply to:  13 Changed 8 years ago by gigem

Replying to beirdo:

Can this be closed?

At the risk of re-igniting a firestorm, no. Most OSD displays would probably be OK with a standard timeout or even require user action to clear them, but IMO, there is a small subset which I still feel the timeout should have some reasonable configurability.

comment:15 Changed 8 years ago by beirdo

Hmmm, OK. Maybe close this ticket, open a new one for the small subset? The issue this ticket is reporting is no longer the case, is that not correct?

comment:16 Changed 8 years ago by beirdo

Resolution: fixed
Status: acceptedclosed

Closed. I added #8701 as a tracking replacement for ongoing work with OSD timeouts.

This ticket is no longer valid as the OSD timeouts are now consistent, as there is only one timeout.

Note: See TracTickets for help on using tickets.