Simplifying/consolidating the Instant Recording menu

[prl]

In the discussion about implementing single-press recording, peteru raised the possibility of simplifying the instant recording menu (and indirectly simplifying the choices available in configuring single-press recording).

The available options for single-press REC would be:

• Instant record menu...
• Record the rest of the current event
• Record indefinitely
• Record for given duration
• Record until given time
• Record current timeshift event
• Record selected timeshift event
• Change instant recording duration
• Change instant recording end time
• Stop instant recording
• Stop timer recording
• Do nothing

I'm thinking that presenting the user with so many options will lead to less than ideal user experience. Simplifying the list should not be too hard, but it will require a bit more work on other parts of the user interface. In particular, the options for duration and end time can be merged if the editor has two linked fields. Similarly, stop recording can just have a list of recordings, irrespective of whether they are "instant" or timer. Record indefinitely can be removed since it actually creates a recording 1440 minutes long, which can be done via other means.
...

It would make sense for me to implement changes like this together with the single-press recording changes (because changes in the instant recording menu are reflected in the choices available for the single-press record button).

[jpp]

I don't know about the majority of users, but I'm ALWAYS in time shift mode simply because inevitably someone will hit the PAUSE button during a program. So, I would like the bias towards simplicity, in case a choice has to be made, to be for time-shift recording. And yes, always to the end of the current program + post padding.

I know that this will inevitably lead to recording not just the currently watched program, but also whatever was in the time shift buffer before the start of the currently watched program. Not sure if you want to have an option here to just record the currently/now watched program + pre padding and cut off the stuff from the previous program. Maybe this option has already been canvassed?

Any other machinations are really recordings using the timer setting menu IMO.

[prl]

I'm quoting simoncasey's post in Single-press recording here because I think most of it pertains more to this topic than to where it was originally posted.

There's a couple of issues I'd like to raise that this change may solve or worsen.

In general I like peterus suggestion to simplify the list as there are currently a lot of options that read as quite similar. Particularly the stop recordings etc and record duration.

I question whether both short and long press of the rec button should be configurable for recording functions. It would be more consistent that the short press does the default action and the long press does the menu. I realise that currently the red button short press also brings up the record menu but I don't think that is intuitive, especially since red button has lots of different functions in other places (exit, delete, hbbtv).

I also think timeshift mode complicates things. For example, my preference for default would be:
When in timeshift: Timeshift save recording (stop after current event)
When not in timeshift: Add recording (stop after current event)
To me, they are both the same instant record function but are timeshift aware.
In the current plan, I would have to choose one or the other as default and either lose the timeshift buffer if I used add recording or receive an error saying save timeshift wasn't available.

[simoncasey]

I'm quoting simoncasey's post in Single-press recording here because I think most of it pertains more to this topic than to where it was originally posted.

There's a couple of issues I'd like to raise that this change may solve or worsen.

In general I like peterus suggestion to simplify the list as there are currently a lot of options that read as quite similar. Particularly the stop recordings etc and record duration.

I question whether both short and long press of the rec button should be configurable for recording functions. It would be more consistent that the short press does the default action and the long press does the menu. I realise that currently the red button short press also brings up the record menu but I don't think that is intuitive, especially since red button has lots of different functions in other places (exit, delete, hbbtv).

I also think timeshift mode complicates things. For example, my preference for default would be:
When in timeshift: Timeshift save recording (stop after current event)
When not in timeshift: Add recording (stop after current event)
To me, they are both the same instant record function but are timeshift aware.
In the current plan, I would have to choose one or the other as default and either lose the timeshift buffer if I used add recording or receive an error saying save timeshift wasn't available.

I think the timeshift bits belongs where I posted it originally. It really relates to which option you configure to the red button. I'm not proposing merging the record timeshift and add recording functions in the menu. It's just that if I choose save timeshift (stop after current recording) as the default for the red button then if I'm not in timeshift I'll get an error where really I want it to do Add recording instead.
In that case I wouldn't end up using one press recording as it would just annoy me to get an error message and have to go into the menu anyway.

[prl]

I'm not planning on changing the function of the RED button. Only REC.

[peteru]

I'm planning on changing the function of the RED button. Only REC.

You mean NOT planning, right?

[prl]

I'm planning on changing the function of the RED button. Only REC.

You mean NOT planning, right?

Indeed. Changed in the original.

[prl]

There are also some oddities in some of the instant recording menus that should also perhaps be looked at in this attempt at simplification/rationalisation.

• Peteru's post says "Record indefinitely can be removed since it actually creates a recording 1440 minutes long" (1440 min = 24 hours), but that doesn't appear to be correct. "Record indefinitely" initially sets a 60 minute recording, but enables a facility to auto-increase the timer length each time the timer would otherwise come to an end, and then immediately does an auto-increase, which would make it 1500 min initially. The auto-increase is in steps of 1440 minutes. This is not the same as setting a single 1440-min timer. The "indefinite" recording will also stop short just before the start of the first conflicting timer if its next increment would cause a timer conflict. Whether it's a useful function above simply setting a 1440-min timer is a reasonable question.
• Cancelling out (using EXIT) of any of Record for given duration, Record until given time, Change instant recording duration, Change instant recording end time sets the end time to the current time (and so stops the recording). That may be a reasonable choice for Record for/until, though if that is to be retained as the behaviour, it should probably clean up the recording it started. It seems to be simply the wrong action for Change, which I'd expect to be to just keep the old end time. If I'd wanted to stop the recording, I'd have asked to stop the recording.
• In Record until given time and Change instant recording end time, the end time in the TimeDateInput screen is the end time of the recording timer, which is fine, but the end date is today's date, even if the end time is tomorrow. I.e. if I start a 120-min timer at 23:00 on 1 Jan, and ask to change the time, the change time screen will pop up showing the end time as 01:00 1 Jan, not 01:00 2 Jan. The problem can also occur in Record until given time if the timer's initial end time (start of current event + 60 min) goes past midnight.
• For Record for given duration and Record until given time, the recording timer is initially set for 60 min. That's reflected in the initial end time shown in Change instant recording end time, but the default duration in the popup is 5 min, which seems too short to be of much use. It should perhaps reflect the initial timer length of 60 min.
• If you skip back to a previous timeshift event and ask to Record current timeshift event, or you use Record selected timeshift event on a prior event, there's no feedback to indicate that it's done anything until some time later, when createapscfiles finishes and you're notified that the work has completed. That can be in the order of 30 sec or more for reasonable-sized recordings. Even longer if the timeshift buffer has to be copied rather than using Unix hard links.

[prl]

I don't know about the majority of users, but I'm ALWAYS in time shift mode simply because inevitably someone will hit the PAUSE button during a program. ...

The current firmware test that determines whether Record current timeshift event and Record selected timeshift event appear in the instant record menu isn't that you are currently timeshifting, its whether timeshifting is enabled; that is that MENU>Setup>TV>Timeshift settings>Automatically start timeshift after isn't set to Disabled, and that the "start timeshift" delay since your last channel change has elapsed. In other words, the test is whether the timeshift files are available, not whether you happen to be using them.

[peteru]

Hmm, last time I used the Record indefinitely option was to try and fill up a HDD. It created a file that was about 24 hours long, then the recording stopped. It's possible it was 1500 minutes, rather than 1440. There may have been a bug in there that is fixed now, or it may still not work as advertised. Testing it will take more than a day...

However, I still don't see any sensible reason for having an option to "record indefinitely" - all you will be doing is setting yourself up for issues once the HDD fills up. For the very rare cases where you want a very, very long recording, allow the user to edit a timer and set any arbitrary end time.

Yes, chickening out of an edit screen should have no side effects. It certainly should not stop a recording / timer.

Yes, default duration of 60 minutes rather than 5 and an editor to go with it.

The editor should be sensible and work on the integer time representation and only use the time formatting functions to actually display the time. That will avoid any issues with time formatting (and hopefully even deal with DST). I suggest that the duration editor should have keys to alter individual seconds, minutes and hours and render it's results as both the duration and effective end time.

As far as visible feedback for saving the timeshift buffer, I'd like to see something like the toast messages we've seen in the DP-A1 beta. Basically a very small unobtrusive text box that briefly appears near the edge of the screen and goes away, without ever interfering with the remote control functionality. I'd also like to see such a UI element used for the subtitle notifications, rather than the intrusive message box we get in the middle of the screen now. And yes, I know that there really isn't an easy to use tool for this. I think the GMail plugin notification has something that may be usable.

[prl]

... I suggest that the duration editor should have keys to alter individual seconds, minutes and hours and render it's results as both the duration and effective end time. ...

I thought that you were suggesting a single editor for setting the end time, where changing the end time made corresponding changes in the duration and vice versa. That's not incompatible with what you said, but I just wanted to be sure.

[peteru]

... I suggest that the duration editor should have keys to alter individual seconds, minutes and hours and render it's results as both the duration and effective end time. ...

I thought that you were suggesting a single editor for setting the end time, where changing the end time made corresponding changes in the duration and vice versa. That's not incompatible with what you said, but I just wanted to be sure.

What I mean is a single editor where the user changes the duration of the recording and the results are displayed as two fields. One field being the duration itself and the other field being the resulting end time based on the start time and duration.

You could try to go into the trouble of making both fields directly editable, but that hardly seem like it would be worth the effort. It seems it would be easier to just have buttons to increase / decrease the individual time units. On re-reading the above, I realise that it's pretty pointless to have seconds, so you really just need four buttons to increase/decrease minutes and hours.

Most logical assignment seems left to decrease minutes, right to increase minutes, CH+ to increase hours, CH- to decrease hours. An alternative method could be to use up/down and left/right for minutes and hours and OK/EXIT with coloured buttons to confirm changes, exit without making changes or completely cancel the timer.

If you do want to go down the path of two fields that can both function as editors, have a look at the code that handles the manual tuning and the conversion between channel numbers and frequencies in Screens/ScanSetup.

[prl]

... As far as visible feedback for saving the timeshift buffer, I'd like to see something like the toast messages we've seen in the DP-A1 beta. Basically a very small unobtrusive text box that briefly appears near the edge of the screen and goes away, without ever interfering with the remote control functionality. I'd also like to see such a UI element used for the subtitle notifications, rather than the intrusive message box we get in the middle of the screen now. And yes, I know that there really isn't an easy to use tool for this. I think the GMail plugin notification has something that may be usable.

I don't recall the "toast messages" on the DP-A1.

I like the idea of the "lightweight messagebox". I think the size and location of the gmailnotifier is sort-of OK for it, but I think it needs to use instantiateDialog()/show() when it's called up rather than open() to avoid interfering with the remote control, and perhaps also have setSubScreen() called on it so that it doesn't hide the old screen when it's called up.

I have to admit that the obtrusiveness of the subtitle popup is really rather irritating.

[prl]

...
Most logical assignment seems left to decrease minutes, right to increase minutes, CH+ to increase hours, CH- to decrease hours. An alternative method could be to use up/down and left/right for minutes and hours and OK/EXIT with coloured buttons to confirm changes, exit without making changes or completely cancel the timer.
...

I think that would need a new (or modified) config element. It's probably do-able by modifying ConfigDateTime to have two increments, one on LEFT/RIGHT and another on CH+/-.

[prl]

is there any reason why:

• "Instant" recordings shouldn't be saved like normal recordings are (e.g. that would mean that they would resume if the box was restarted, rather than being stopped).
• "Change instant recording duration" shouldn't be "Change recording duration"? There is a question there, though, about repeated recordings, because changing their duration would affect all future recordings for that timer.

I'm seeing the list of possible menu entries now as:

• Start instant recording (not sure about the right name for that)
• Record current timeshift event
• Record selected timeshift event
• Change instant recording duration (or Change recording duration)
• Stop recording (instant or timer)
• Do nothing (possibly eliminate this, too)

The notes in parentheses aren't part of the menu entry.

It brings all the "Record" entries together. The current list has the "instant recording" entries at the start, and the "record timeshift" entries at the end of the list.

"Do nothing" currently has a use as a placeholder in contexts where there are no valid actions (yes, such contexts exist ). Alternatives if there are no "instant recording" actions possible are to remove the "Do nothing" entry and either show the UnhandledKey popup, or show the menu ChoiceBox with no entries and a title/subtitle of something like:
No instant recording actions available.
Press OK or EXIT to close the popup

Start instant recording and Change (instant) recording duration would both allow the duration of the recording to be set as an end time or as a duration (and they would be kept consistent with each other in the setting screen). The default end time for Start instant recording would be the end time of the current event, eliminating the need for Record the rest of the current event (but it would require an additional button press).

[IanSav]

Hi Prl,

is there any reason why:

• "Instant" recordings shouldn't be saved like normal recordings are (e.g. that would mean that they would resume if the box was restarted, rather than being stopped).

Nothing of which I can think. Is there anything "special" about instant recordings that might need to be preserved?

[*]"Change instant recording duration" shouldn't be "Change recording duration"? There is a question there, though, about repeated recordings, because changing their duration would affect all future recordings for that timer.[/list]

Changing the duration of future recordings is a definite no-no. Is there any way to treat all active recordings as "instant" recordings once they start? With the resume of these recordings being achieved by the previous point this would seem like a desirable option. I believe that editing a timer to affect an active recording is a problematic UI paradigm.

I'm seeing the list of possible menu entries now as:

• Start instant recording (not sure about the right name for that)

"Start recording" should be accurate enough while not not being confusing for users. If more detail is required try "Start non timer recording"

[*]Record current timeshift event

Is there a follow up ChoiceBox question asking to start from the beginning of the event or now?

[*]Record selected timeshift event
[*]Change instant recording duration (or Change recording duration)

Latter preferred but must only affect the current instance of the recording and not future events.

[*]Stop recording (instant or timer)
[*]Do nothing (possibly eliminate this, too)[/list]The notes in parentheses aren't part of the menu entry.

The "Do nothing" option should go.

It brings all the "Record" entries together. The current list has the "instant recording" entries at the start, and the "record timeshift" entries at the end of the list.

"Do nothing" currently has a use as a placeholder in contexts where there are no valid actions (yes, such contexts exist ). Alternatives if there are no "instant recording" actions possible are to remove the "Do nothing" entry and either show the UnhandledKey popup, or show the menu ChoiceBox with no entries and a title/subtitle of something like:
No instant recording actions available.
Press OK or EXIT to close the popup

Definitely UnhandledKey if the above is the only alternative.

Start instant recording and Change (instant) recording duration would both allow the duration of the recording to be set as an end time or as a duration (and they would be kept consistent with each other in the setting screen). The default end time for Start instant recording would be the end time of the current event, eliminating the need for Record the rest of the current event (but it would require an additional button press).

Do you want to add the end padding to the duration? Alternatively set the duration to recognise that *actual* start of the program and the actual duration of that program. That is, try to ensure that EPG errors in start time and duration are allowed for or corrected. (Mind you we often see issues with Now/Next data as well.)

Regards,
Ian.

[prl]

Hi Prl,

is there any reason why:

• "Instant" recordings shouldn't be saved like normal recordings are (e.g. that would mean that they would resume if the box was restarted, rather than being stopped).

Nothing of which I can think. Is there anything "special" about instant recordings that might need to be preserved?

Not that I can think of.

[*]"Change instant recording duration" shouldn't be "Change recording duration"? There is a question there, though, about repeated recordings, because changing their duration would affect all future recordings for that timer.[/list]

Changing the duration of future recordings is a definite no-no. Is there any way to treat all active recordings as "instant" recordings once they start? With the resume of these recordings being achieved by the previous point this would seem like a desirable option. I believe that editing a timer to affect an active recording is a problematic UI paradigm.

All recordings use the same representation, whether they're "timer" or "instant" recordings. They're really all timer recordings deep down. The firmware just keeps a list of the ones it thinks are "instant", and instant recordings are always created as once-off and (currently) as "don't save".

Repeating timers don't generate timers in the way that AutoTimers do. A repeating timer just has single start and end times, which get updated when the timer completes, so there's nothing to treat as a separate "instant" timer.

I'm seeing the list of possible menu entries now as:

• Start instant recording (not sure about the right name for that)

"Start recording" should be accurate enough while not not being confusing for users. If more detail is required try "Start non timer recording"

Part of what I'm trying to do is to make less distinction between "instant" and "timer" recordings. All recordings are timer recordings, so I thnk that talking about "non-timer" recordings would itself be a bit confusing. Especially as the "non-timer" recordings would show up in the TIMER list.

• Record current timeshift event

Is there a follow up ChoiceBox question asking to start from the beginning of the event or now?

No, because it does what it says on the label. It records the whole event. To get a recording starting now, you use "Start recording". This is pretty much unchanged from the menu as it is now.

...

Start instant recording and Change (instant) recording duration would both allow the duration of the recording to be set as an end time or as a duration (and they would be kept consistent with each other in the setting screen). The default end time for Start instant recording would be the end time of the current event, eliminating the need for Record the rest of the current event (but it would require an additional button press).

Do you want to add the end padding to the duration? Alternatively set the duration to recognise that *actual* start of the program and the actual duration of that program. That is, try to ensure that EPG errors in start time and duration are allowed for or corrected. (Mind you we often see issues with Now/Next data as well.)
...

My initial intention was that it will work the same way that the current "Record the rest of the current event" works: get the event's end time from the EPG. It's either that or Now/Next, but the current code uses the EPG. I don't have strong feelings either way (I haven't looked at how to extract the time for Next, but I assume it's not hard). Perhaps use Next with the EPG end time as a fallback if Next is unavailable or looks absurd.

I'm not sure about adding end padding. The user can add padding easily just by bumping up the duration. Otherwise it'd be the standard sized end padding. I wouldn't want to add yet another different sized padding to make the padding stripping situation even more complicated.

[IanSav]

Hi Prl,

The whole concept of adding end padding is an absurdity forced upon us by TV stations that usually refuse to run programs on time for the stated duration.

When you look at this aspect of the code hopefully you can find a way to try and ensure that the duration suggested provides the best chance of capturing the whole program without needing further user intervention.

Regards,
Ian.

[prl]

...
When you look at this aspect of the code hopefully you can find a way to try and ensure that the duration suggested provides the best chance of capturing the whole program without needing further user intervention.
...

I think that might require a trip down Diagon Alley, to Ollivanders.

[MrQuade]

What's the problem here guys?

The existing "record the rest of the event" option as it is now already creates the padding automatically.
Why would the new instant recording option not work exactly the same way and default to the end of the current event plus default padding?

[prl]

What's the problem here guys?

The existing "record the rest of the event" option as it is now already creates the padding automatically.
Why would the new instant recording option not work exactly the same way and default to the end of the current event plus default padding?

I hadn't looked deep enough into the code. The padding to the "Record the rest of the current event" was added elsewhere. That behavior will be retained.

[prl]

This is how my current implementation for setting the end time or duration of a timer looks. The input fields are linked.

Only LEFT/RIGHT are acive on the Date field (and the description text changes correspondingly).

The screen that this replaces for setting the instant recording end time is also used for time entry on the EPG (from live TV, EPG, TEXT). Should that be replaced with something similar to this (but without the duration field, obviously)?

[MrQuade]

Looks great! It would seem to do the job required.

I assume that the recording will have the same name as the currently viewed event? (since the initial end time will be the event end time...)


Would it be at all possible to have a field that allowed you to advance the endtime/duration by event end times (taken from the EPG?). ie. Initial record time is the end of the current event, press right, and the timer increments to the end of the next event, right again, and it advances to the event after the next etc.... Is the EPG data even available to that poup to be able to do that?

[peteru]

Can I suggest that for the duration, only HH:MM is shown? If the total duration exceeds 24 hours, then by all means prepend "1 day" or "2 days", but having "0 days" prepended just looks odd.

Is the date field also editable? If so, what is the user interface for it?

[prl]

Can I suggest that for the duration, only HH:MM is shown? If the total duration exceeds 24 hours, then by all means prepend "1 day" or "2 days", but having "0 days" prepended just looks odd.

The underlying object is a ConfigDateTime, whose display can only be controlled by a strftime() format string. The duration display is already a hack because %j returns 001:366, while I need it to be 0-365 (or similar). The "days" is just part of the format string it's passed, _("%j days %H:%M"). I'm not happy about the display format anyway, because I can't control "day" or "days". I could extend the hack on %j do that it adds the "day/days" as appropriate, and it could omit it if the number of days was 0. But that's seriously hackish. The duration is displaying the strftime(format, gmtime(end_time - base_time)).

Is the date field also editable? If so, what is the user interface for it?

Yes: "Only LEFT/RIGHT are active on the Date field (and the description text changes correspondingly)." This is the same as the Date field in the current implementation of the recording duration setting screen.

[prl]

... I assume that the recording will have the same name as the currently viewed event? (since the initial end time will be the event end time...)

Yes, that will remain unchanged (it happens elsewhere from the code I'm intending to change, and I have no reason to change it).

Would it be at all possible to have a field that allowed you to advance the endtime/duration by event end times (taken from the EPG?). ie. Initial record time is the end of the current event, press right, and the timer increments to the end of the next event, right again, and it advances to the event after the next etc.... Is the EPG data even available to that poup to be able to do that?

The current object family that handles the time updating in the end time/duration knows nothing about the start time of the event and knows nothing about the EPG. It's just passed the base time (current time) and an end time (end time of the current event + padding when creating a timer, and end time of the timer when modifying it).

There are functions in the EPG that already do exactly what you're asking for. It's also petty hackinsh getting the keypress actions down into the time control objects. It currently "steals" CH+/CH- from the underlying ConfigListScreen, which are otherwise used for paging UP/DOWN.

I thought this was about simplifying the instant recording menu.

[MrQuade]

I thought this was about simplifying the instant recording menu.

It was just a thought. It would be simple from an end-user perspective, but understandably complex on the implementation side.

Fair call, just thought I would throw it out there. You can happily ignore the suggestion

[IanSav]

Hi Prl,

Will this screen be skinable? (If not can this please be added.)

Regards,
Ian.

[peteru]

Can I suggest that for the duration, only HH:MM is shown? If the total duration exceeds 24 hours, then by all means prepend "1 day" or "2 days", but having "0 days" prepended just looks odd.

The underlying object is a ConfigDateTime

Would it make sense to create a ConfigDuration object that handles the formatting in a sensible way?

[prl]

Can I suggest that for the duration, only HH:MM is shown? If the total duration exceeds 24 hours, then by all means prepend "1 day" or "2 days", but having "0 days" prepended just looks odd.

The underlying object is a ConfigDateTime

Would it make sense to create a ConfigDuration object that handles the formatting in a sensible way?

I already have, but it derives from the ConfigDateTime objects with that behaviour. If you mean, create it from scratch, then yes, that would also be possible, but less flexible in other ways.

[dRdoS7]

Hi,

Does it really need to be more than 24 hours? It's a Instant Recording, and 24 hours gives the user plenty of time to add more permanent, recurring timer, if it's required.

Only time I could see it needing more than 24 hours is if: I was walking out the door, saw something interesting, that was going to be on for 2 days while I was away, or if I was Rip van WInkle.

dRdoS7

[prl]

... Will this screen be skinable? (If not can this please be added.) ...

The screen is skinnable. Currently its skin is TimeDateDurationInput, but it also falls back to the old TimeDateInput if TimeDateDurationInput is not available in the skin files.

I'm not sure why you'd have thought it otherwise.

Skin and class names may change before this all gets wrapped up.

[prl]

... Does it really need to be more than 24 hours? It's a Instant Recording, and 24 hours gives the user plenty of time to add more permanent, recurring timer, if it's required.

The "days" field is there because otherwise in the current implementation you can only have 23:59 hours, which is a bit ugly, and it would either have to stay limited to that or wrap around in an ugly manner. If the whole display for the duration gets re-written, it may end up as just hours:minutes.

Only time I could see it needing more than 24 hours is if: I was walking out the door, saw something interesting, that was going to be on for 2 days while I was away, or if I was Rip van WInkle.

Recordings seem to be limited to 1440 minutes (1 day) anyway.

[IanSav]

The screen is skinnable. Currently its skin is TimeDateDurationInput, but it also falls back to the old TimeDateInput if TimeDateDurationInput is not available in the skin files.

Thanks for the heads up.

I'm not sure why you'd have thought it otherwise.

I have a simple skin_name improvement pull request that PeterU has rejected once (comment issue) been reworked to his specifications and resubmitted but is *still* sitting awaiting acceptance for over 3 weeks now. If he is rejecting my simple requests for such a change then one would assume he will reject your submission as well.

Skin and class names may change before this all gets wrapped up.

I await your final naming and I will then add the appropriate definitions to OverlayHD.

Regards,
Ian.

[prl]

Can I suggest that for the duration, only HH:MM is shown? If the total duration exceeds 24 hours, then by all means prepend "1 day" or "2 days", but having "0 days" prepended just looks odd.

The underlying object is a ConfigDateTime

Would it make sense to create a ConfigDuration object that handles the formatting in a sensible way?

I already have, but it derives from the ConfigDateTime objects with that behaviour. If you mean, create it from scratch, then yes, that would also be possible, but less flexible in other ways.

I've worked out how I want to handle this.

[prl]

New "Duration" format in the Date/Time/Duration popup:

Less than 24 hours:

1 day:

More than 1 day:

The screens also show the two different descriptions for the entries. The description for Duration is the same as that for Time.

[prl]

... The screen that this replaces for setting the instant recording end time is also used for time entry on the EPG (from live TV, EPG, TEXT). Should that be replaced with something similar to this (but without the duration field, obviously)?

I don't think anyone has commented on this suggestion.

[IanSav]

Hi Prl,

... The screen that this replaces for setting the instant recording end time is also used for time entry on the EPG (from live TV, EPG, TEXT). Should that be replaced with something similar to this (but without the duration field, obviously)?

I don't think anyone has commented on this suggestion.

I missed this on the first reading.

I actually prefer the original Date/Time functionality where I can just enter the time I want (via entering the time digits directly). I don't think I would like to go from direct time entry to scrolling digits in the hours and minutes. The odds are that scrolling will require more button presses to get to the desired time.

Is there any chance you can add the direct digit entry model to your new code. Alternatively can you add the duration field (when required) to the original Date/Time screen?

Regards,
Ian.

[prl]

Thr original date-time setup is a bit of a hodgepodge. The interface I've implemented was as suggested by peteru.

[Paul_oz53]

Not a big deal. I looķed but apart from position they are pretty similar. Probably better to also replace the time entry screen to achieve a consistent style but it not a screen I care about.
Paul

[IanSav]

Hi Prl,

Thr original date-time setup is a bit of a hodgepodge. The interface I've implemented was as suggested by peteru.

You asked for opinions on the change,, my opinion was provided. The mess under the covers may not be optimal but the UI provided is better.

By the way, PeterU is not always right. This UI suggestion is another example. Using both direct number entry *and* scrolling numbers would be a good compromise to cover both UI options.

Regards,
Ian.

[peteru]

FWIW: I'm not always right, but currently I do get the final say in what code is merged into the firmware. Working with me is certainly going to get you a lot further than antagonising me.

In this case I never said that direct entry should be prohibited. What I suggested was a user interface where the duration and end time are linked, because those values naturally depend on each other. I also suggested that there should be certain keyboard shortcuts for incrementing the various time units. I wasn't too attached to those particular keys, they just seemed the most logical ones in the context. If there are other suggestions for keyboard shortcuts, then it would be a good idea to present the case, see if there is a consensus that such changes are a good idea and then see if prl can get those changes implemented.

The implementation that prl has showcased is not at all like what I first imagined, but the apparent functionality meets the main criteria. prl has gone to all the trouble of actually implementing something that works and by the looks of it, something that will work a lot better for the average user than what we had until now. Unless the code is a horrible mess, I don't see a problem. Further code improvements can come later down the track, if they are really needed.

@prl, thanks for putting in all the hard work, it is appreciated.

[peteru]

... The screen that this replaces for setting the instant recording end time is also used for time entry on the EPG (from live TV, EPG, TEXT). Should that be replaced with something similar to this (but without the duration field, obviously)?

I don't think anyone has commented on this suggestion.

That time/date input dialog looks pretty sad. Usability is not great either. Some improvement would be welcome. Perhaps abstracting your new implementation, to make the duration field optional, would work. It's hard to tell without being familiar with either code.

One thing that may or may not be worth considering is the underlying "resolution" of the EPG grid. If it works on 15 minute intervals, then perhaps the user interface could support an increment step of 15 minutes rather than 1 minute. Of course, you would also need to ensure that the initial value is aligned to 15 minute intervals.

I suppose both uses of the editor will also need to respect a certain minimum value and not allow the user to "travel back in time".

[prl]

On adding numeric entry to date/time/duration: the problem is that numeric entry uses LEFT/RIGHT for navigation in the field, while in date/time/duration LEFT/RIGHT is increment/decrement. If the actions are combined, both functions are needed. Also, the way date/time/duration is implented, implementing numeric duration is messy. And the way numeric entry is implemented, increment/decrement duration is messy.

Key choice is also limited be the keys used for navigation in ConfigListScreen. Dual increments already steals CH+/- from paging in ConfigListScreen, though using VOL+/- or other buttons with a forwards/back sense (like PREV/NEXT or FF/REW) would also be possible. The advantage of using CH+/- or VOL+/- is that they are already used for increment/decrement start/end in the timer edit screen.

On using date/time/duration with the duratinon not shown: that's already implemented, with the EPG use in mind.

Date/time/duration also implements a lower bound on the time being entered. That was needed anyway to prevent negative durations. The limit is optional and can be made unrestricted by setting the limit to None. The limit applies even if duration os not used.

[prl]

Regridding the EPG and using that to increase the step size on the EPG time jump screen sounds good, but perhaps as a separate set of changes that are more focussed on the EPG.

The new time/date/duration popup could still be used in the EPG in these changes, though. The increments are just seconds and could be charged to the grid size when the EPG in regridded.

Having the possibility of the grid smaller than the EPG time width would also allow for time paging that preserves some context: if the grid size equals the page width, page by the page width; if the grid size is less than the page width, page by pagewidth - gridwidth.

The new simpler offset system for time navigation in the EPG makes implementing all that a lot easier.

[prl]

...
@prl, thanks for putting in all the hard work, it is appreciated.

Thanks.

[prl]

I think I may be able to derive from ConfigClock to make a class that can take part in the mutual updates that are needed to keep date, time and duration consistent in the date/time/duration popup, but keep the numeric key editing of ConfigClock. I'll have a look at implementing it. It may get a bit ugly.

That would mean that for time and duration you'd be able to use the number keys and LEFT/RIGHT as you do now in the time setting of "Record until given time", and perhaps VOL+/- for +/- hours and CH+/- for +/- minutes. That way round, the button positions correspond to the field positions in the time display.

I'm not quite sure what to do with durations >= 24 hours. Perhaps just have a wider range for the hours. That would probably do for timers. An alternative would be ddd:hh:mm. That would fit with the ConfigSequence used by ConfigClock to handle the time editing.

[peteru]

VOL and CH keys for time adjustments sound just fine. Since those keys are usually not used for such purposes in most config screens, it's probably a good idea to have obvious hints on screen, but from the screenshots you already have that covered.

In terms of key choices, the OK + arrow keys are clearly the prime controls, however VOL and CH are also in a prominent position. The colour keys less so and they also get used for other purposes. FFWD and REW keys are less convenient on the standard remotes and may be on secondary screens on some universals. PREV/NEXT are again very likely to be less available on universal remotes.

As far as duration >=24 hours, I would not be too bothered. How often does anyone make a single recording that's longer than a day? If they do, it's perfectly acceptable to measure it in hours. You want a 75 hour recording? You figure out how many days that is! On the other hand, if the implementation that uses days is simpler, then there is no harm, as long as we don't end up with "0 days" being shown in the most common cases.

[simoncasey]

I would strongly request not to use the Vol keys for anything apart from volume. A lot of people who use a sound system may well have the volume key set to control a different device using a universal remote.