FEATURE: Ability to select and play a timeshifted event

[MrQuade]

As-per discussions that began in the thread Not getting reliable recording of events in the buffer, this thread has been created to discuss a potential new feature.

If a user is in timeshift mode, and wishes to view another event in the timeshift buffer, they are required to use the PREV and NEXT buttons to navigate between events in the timeshift buffer.

The issue with this is that the user has little idea of where they are in terms of the sequence of events in the timeshift buffer, and cannot immediately tell which events are contained within the buffer. There is also no immediate indication of the actual time at which the event was originally broadcast.

The user does have the option of opening the recording menu and choosing the "select an event to save" option. This will list the events in the buffer, but offers no way to immediately skip to an event, may result in accidental saving of the event, and requires many keypresses to achieve.

A new feature is proposed such that the user should be able to press a single button, and then be presented with a list of events that are currently in the timeshift buffer with event description and time stamps. The user may then select an item from the list and press OK which would then immediately begin playback of that event's timeshift buffer.

Some factors to consider:
Should this feature be available in both Live-TV mode and in timeshift mode?
What button should be used to open the timeshifted events popup list?
What information should be displayed on the timesfhited events list?
Can this feature be extended to cover recordings and other media files to quickly skip between bookmarks/chapters?

Suggestions:
I would propose that the feature only be made available when in timeshift mode, and that a long-PREV or long-NEXT should open the timeshifted event list. The reason being, that the PREV and NEXT buttons are already assigned to skip between events, and it is a natural extension of their function for them to bring up a list of events which may be skipped to.

I'd suggest that the popup list should list each event's name, and a timestamp consisting of a start time, end time and duration. (Highlighting an event may also display the event description somewhere in the popup?)

[telesynth]

These are great ideas. I suggest that Prev and Next isn't intuitive because you end up in the History Zap screen when you step past the first/last event. A list shows you exactly where you are and I especially like timestamps on the events. You could have the option to Play Event from its start or Save Event to disk.

[MrQuade]

These are great ideas. I suggest that Prev and Next isn't intuitive because you end up in the History Zap screen when you step past the first/last event.

The proposal is that the short-PREV and short-NEXT would still function as it normally does, just that a long-press of either will bring up the list of events. Alternate suggestions for the UI are of course welcomed.

A list shows you exactly where you are and I especially like timestamps on the events. You could have the option to Play Event from its start or Save Event to disk.

That's an interesting idea, but I am not sure that user should be allowed to save an event from this list though. That feature already exists on the REC button. It just means more places to maintain functionality, but others can chime in on that idea too.

[telesynth]

I don't mean to derail the feature request. Going into record menu is fine for saving the event.

[MrQuade]

I don't mean to derail the feature request.

Not at all. You were the originator of the concept after all

[prl]

... Can this feature be extended to cover recordings and other media files to quickly skip between bookmarks/chapters?

That may be a reasonable idea in itsself, but it's really unrelated to this, in use context, popup contents, function and implementation. If it were implemented, though, long-PREV/long-NEXT would be a reasonable button choice since in the use context PREV/NEXT are for skipping between bookmarks.

I'd suggest that the popup list should list each event's name, and a timestamp consisting of a start time, end time and duration. (Highlighting an event may also display the event description somewhere in the popup?)

The meta files in the timeshift buffer do not contain duration or end time, so it's not easy to add that to the popup (and I can't, for the moment, even work out where the timeshift .meta files are written!).

They do, however, contain the program description. But remember that the program description in the FTA EPG will most often be the text description of the episode, and not a nice short episode name as it will most often be with the IceTV EPG.

So, for example, Charlie and Lola is currently playing on ABC2.

In the FTA guide, its description in the .meta file in the timeshift buffer is:

Charlie wants Lola to hurry or they will be late for school. But Lola keeps getting distracted. He comes up with a cunning ruse to get his little sister to hurry up. You wouldn't want to miss Dragon Day at school, would you?

but with the IceTV guide, the description is:

I Am Hurrying I'm Almost Nearly Ready!

[prl]

The fact that currently only prev/next event operations on the timeshift playback (via PREV/NEXT, REW, FF and playing past the end of a timeshift event) are available is embedded in the code in a rather ugly and asynchronous manner.

Have a look at the use of self.pts_skipBack in InfoBarTimeshift (Components/Timeshift.py). If only they'd used something like self.pts_skipAmount set to +1/-1 instead of using self.pts_skipBack where True => skip -1 and False => skip +1.

It's doable, of course, but more incompatibilities with upstream code at a fairly fundamental level.

[MrQuade]

The meta files in the timeshift buffer do not contain duration or end time, so it's not easy to add that to the popup (and I can't, for the moment, even work out where the timeshift .meta files are written!).

That could be derived from the start time though?
Failing that, just including the start time, as-per the "save recording" popup would probably be sufficient.

[MrQuade]

The fact that currently only prev/next event operations on the timeshift playback (via PREV/NEXT, REW, FF and playing past the end of a timeshift event) are available is embedded in the code in a rather ugly and asynchronous manner.

Bummer. That bodes poorly for those other timeshift enhancement requests too.

I often wonder if the poor state of timeshifting is another artifact of it being an infrequently used feature in the original Enigma2 overseas markets.

[prl]

The meta files in the timeshift buffer do not contain duration or end time, so it's not easy to add that to the popup (and I can't, for the moment, even work out where the timeshift .meta files are written!).

That could be derived from the start time though?
Failing that, just including the start time, as-per the "save recording" popup would probably be sufficient.

The problem with using the previous start time for end/duration calculation is that it can't be derived for the oldest entry.

I'm not sure that adding the end time or duration really adds much anyway. Showing the end time seems especially pointless.

One think I did notice, though, is that the start time format in the "Select an event to save..." popup wasn't changed in IanSav's time format choice effort.

[MrQuade]

The problem with using the previous start time for end/duration calculation is that it can't be derived for the oldest entry.

I'm not sure that adding the end time or duration really adds much anyway. Showing the end time seems especially pointless.

Why not for the first entry?
You could fudge that with the file creation date I guess.

[IanSav]

Hi Prl,

One think I did notice, though, is that the start time format in the "Select an event to save..." popup wasn't changed in IanSav's time format choice effort.

I will look into this when I return to Enigma2 programming.

Regards,
Ian.

[prl]

... file creation date ...

One of which we do not have. Linux has access time, modification time and inode change time. No creation time. It's even arguable just what such a thing might be.

And in any case, it's not the time we want. We already have the start time for the timeshift buffer recording.

The recording file modification time, though, will give us what we want.

[IanSav]

Hi Prl,

I had a quick look for why the time string was not updated. It appears that a number of times have either not been updated or have been reverted. I will look more closely at this issue as soon as time permits.

Regards,
Ian.

[prl]

OK. Thanks.

[peteru]

I'd suggest keeping this is as simple as possible. IMNSHO a GUI that requires a long press and brings up a list from which you select is overkill. Jumping between timeshift buffers is reasonably quick and is already hooked up to the PREV/NEXT buttons.

My suggested improvement would be just a bit more feedback for the user so that they can get better oriented as to where they are. One way of doing that is to show the user the timeshift buffer "neighbours" so that the user can see what's before/after the event that is currently playing. Something like:

Name of previous event < Name of this event > Name of next event

Display that with the same timeout as the infobar and it should do the trick. Make the three fields skinnable so that a skin author can stylise the presentation as required. My suggestion would be slightly bigger and darker text in the centre of the screen near the top, for the current event. Position the prev and next events to the left and right and make them lighter and slightly smaller. Make use of the entire width of the screen. Show the < and > as button icons to make it clear that pressing those buttons will step to the indicated buffer. This could replace the existing timeshift mini progress bar, which could be then co-sited with the current event display field.

[MrQuade]

That would certainly streamline the whole process and make it quick to access.
Would it be worth including the start time for each event as well, or do you think that is information overload?

Also, at the risk of dusting off old controversies, perhaps modifying the mini skipbar it is an opportunity to address the placement along the lines of the discussions and suggestions here and here.

[telesynth]

However you do the visual feedback, please show the start time. I think you can just show the HH:MM as the date will be the last few hours. The recording menu "select an event to save" list of events should have the start time in it too.

If you want a scrolling list:-

show the user the timeshift buffer "neighbours" so that the user can see what's before/after the event that is currently playing. Something like:

Name of previous event < Name of this event > Name of next event

then I suggest you clearly show when Next/Prev will jump into the History Zap screen. Not just blank but maybe the word ZAP. A bit of warning you will go to an entirely different screen.

[MrQuade]

then I suggest you clearly show when Next/Prev will jump into the History Zap screen. Not just blank but maybe the word ZAP. A bit of warning you will go to an entirely different screen.

Those buttons will only activate history zap when you are not in timeshift mode, and this display will only work when you are in timeshift mode, so what you are asking is not really compatible.

[telesynth]

then I suggest you clearly show when Next/Prev will jump into the History Zap screen. Not just blank but maybe the word ZAP. A bit of warning you will go to an entirely different screen.

Those buttons will only activate history zap when you are not in timeshift mode, and this display will only work when you are in timeshift mode, so what you are asking is not really compatible.

Great because it doesn't make sense to be surfing the events one second and then looking at a list of channles the next. That is how is works now though, isn't it? That is what it did on the pre 16.0 T4 yesterday.

[MrQuade]

Great because it doesn't make sense to be surfing the events one second and then looking at a list of channles the next. That is how is works now though, isn't it? That is what it did on the pre 16.0 T4 yesterday.

The way I described the button behaviour is the the way that it currently operates. If you are at Live-TV and press NEXT or PREV, it activates a history zap action (either they immediately zap or else bring up the history zap menu, depending on your settings). If you are in timeshift mode, then NEXT and PREV will zap between events.

If you were to press NEXT until you reach Live TV, then you will drop out of timeshift mode and drop back to Live TV, after which any subsequent presses of NEXT will activate history zap mode.

I think that if we had the timeshift next/previous event display appear as PeterU describes, then you will be less likely to accidently zap to Live TV.

[telesynth]

OK, got it. Two different modes. You have to know when you have changed modes.

[prl]

However you do the visual feedback, please show the start time. I think you can just show the HH:MM as the date will be the last few hours. The recording menu "select an event to save" list of events should have the start time in it too.

The "Select an event to save" popup already has the start time for each event, apart from the current event, in it. I was intending to do at least the same in any jump menu, and to add any new time fields from the jump menu to the save menu. Perhaps even use common code

Here's what the current "Select an event to save" popup looks like:

The start time of the oldest event is the time that timeshift (re)started on the channel, not the start time of the program.

[IanSav]

Hi,

Perhaps we should explore moving the ZAP History back to the BACK button where it used to live. (More exactly it was on the LAST button that was changed to BACK in a firmware update long ago.) That would free up the PREV and NEXT buttons to only deal with time shifting. Thus pressing PREV could immediately jump the user to the beginning of the current event in time shift mode. Another press and you jump to the start of the previous event, etc.

This may simplify things for Telesynth and any others who find the unexpected context switch confusing.

Regards,
Ian.

[prl]

I'd suggest keeping this is as simple as possible. IMNSHO a GUI that requires a long press and brings up a list from which you select is overkill. Jumping between timeshift buffers is reasonably quick and is already hooked up to the PREV/NEXT buttons.

My suggested improvement would be just a bit more feedback for the user so that they can get better oriented as to where they are. One way of doing that is to show the user the timeshift buffer "neighbours" so that the user can see what's before/after the event that is currently playing. Something like:

Name of previous event < Name of this event > Name of next event

Display that with the same timeout as the infobar and it should do the trick. Make the three fields skinnable so that a skin author can stylise the presentation as required. My suggestion would be slightly bigger and darker text in the centre of the screen near the top, for the current event. Position the prev and next events to the left and right and make them lighter and slightly smaller. Make use of the entire width of the screen. Show the < and > as button icons to make it clear that pressing those buttons will step to the indicated buffer. This could replace the existing timeshift mini progress bar, which could be then co-sited with the current event display field.

That would mean making the timeshift progress bar considerably wider than it is now.

[MrQuade]

Perhaps we should explore moving the ZAP History back to the BACK button where it used to live. (More exactly it was on the LAST button that was changed to BACK in a firmware update long ago.) That would free up the PREV and NEXT buttons to only deal with time shifting. Thus pressing PREV could immediately jump the user to the beginning of the current event in time shift mode. Another press and you jump to the start of the previous event, etc.

That seems like a good idea to me.

[MrQuade]

That would mean making the timeshift progress bar considerably wider than it is now.

I think that was exactly PeterU's intent. A completely new timeshift mini skipbar interface. Hence my following comment and links to the thread about revisiting the skipbar appearance and placement.

[prl]

I'm in no way convinced that anything needs to be changed in navigation in the timeshift buffer, other than making normal skips skip through the start/end of timeshift events and to allow REW to rewind smoothly across event boundaries in the timeshift buffer, as in enhancement request #393: Allow forward/back skip buttons and trickplay to navigate between timeshift events.

[peteru]

Baby steps. As you increase the complexity, the likelihood of getting it done diminishes. Keep this enhancement simple (either two extra skin elements and a tweak to the skins, or enable automatic switching between timeshift buffers when skipping) and it may make it. If you throw it to a committee it will be decided that it absolutely requires a kitchen sink, a bath tub and a swimming pool with a spa ... and will never get built.

[Grumpy_Geoff]

What about having the timeshift progress bar also show a buffer sequence number in addition to its current event name. For example, "3/5 Pointless", which indicates there are 5 events in the timeshift buffer and we are currently in the 3rd youngest.

[prl]

Baby steps. As you increase the complexity, the likelihood of getting it done diminishes. Keep this enhancement simple (either two extra skin elements and a tweak to the skins, or enable automatic switching between timeshift buffers when skipping) and it may make it. If you throw it to a committee it will be decided that it absolutely requires a kitchen sink, a bath tub and a swimming pool with a spa ... and will never get built.

Actually, I think the simplest implementation path is via a ChoiceBox popup. Most of the UI part of the popup code is already written.

However, any implementation will need to change the way that timeshift file changes are handled.

[prl]

What about having the timeshift progress bar also show a buffer sequence number in addition to its current event name. For example, "3/5 Pointless", which indicates there are 5 events in the timeshift buffer and we are currently in the 3rd youngest.

I'm not sure that adds much.

[IanSav]

Hi PeterU,

Baby steps. As you increase the complexity, the likelihood of getting it done diminishes. Keep this enhancement simple (either two extra skin elements and a tweak to the skins, or enable automatic switching between timeshift buffers when skipping) and it may make it. If you throw it to a committee it will be decided that it absolutely requires a kitchen sink, a bath tub and a swimming pool with a spa ... and will never get built.

My suggestion is to go back to the original system where PREV and NEXT deal with time shift and BACK (LAST) deals with the ZAP History. That is, I propose removing the complexity that has been added and returning to the original and more logical arrangement. This reversion also gives the mostly unused BACK button some appropriate and mnemonic purpose.

Regards,
Ian.

[MrQuade]

My suggestion is to go back to the original system where PREV and NEXT deal with time shift and BACK (LAST) deals with the ZAP History. That is, I propose removing the complexity that has been added and returning to the original and more logical arrangement. This reversion also gives the mostly unused BACK button some appropriate and mnemonic purpose.

I am very much in favour of this approach. Did you have in mind to have short-BACK for instant zap to last service, and long-BACK for zap history?
(This is of course in addition to having PREV act to activate timeshift and skip to the start of the current event as well, as you mentioned earlier).

That would address a good deal of confusion of the feature, and serve to make timeshift and live TV transitions more seamless.


I am of course biased and also VERY keen to see request #393 implemented as well. But that is already logged as an issue and can be addressed separately. Implementing that would almost completely address all the clunkiness between liveTV and timeshift mode.

Changes to the skipbar and GUI could also be split off into its own topic (I would suggest the existing topic that I linked to). That could serve to unify the skip interface across the whole interface for both media playback and timeshifting. I reckon that could be treated separately.

[prl]

... My suggestion is to go back to the original system where PREV and NEXT deal with time shift and BACK (LAST) deals with the ZAP History. ...

That's deep history. It looks to me like the use of PREV/NEXT for history zapping was introduced in commit d8db49b in Feb 2006.

[IanSav]

Hi Prl,

That's deep history. It looks to me like the use of PREV/NEXT for history zapping was introduced in commit d8db49b in Feb 2006.

When did we lose the ZAP History on the LAST button (when LAST become BACK)?

This is the change I think I am remembering. It should be far more recent than 2006.

Regards,
Ian.

[IanSav]

Hi MrQuade,

I am very much in favour of this approach. Did you have in mind to have short-BACK for instant zap to last service, and long-BACK for zap history?
(This is of course in addition to having PREV act to activate timeshift and skip to the start of the current event as well, as you mentioned earlier).

That would address a good deal of confusion of the feature, and serve to make timeshift and live TV transitions more seamless.

I don't fully remember how the feature used to work but what you describe sounds familiar. It doesn't really matter because what you describe is a logical way to proceed.

Regards,
Ian.

[peteru]

That's deep history. It looks to me like the use of PREV/NEXT for history zapping was introduced in commit d8db49b in Feb 2006.

When did we lose the ZAP History on the LAST button (when LAST become BACK)?

This is the change I think I am remembering. It should be far more recent than 2006.

I think you may be getting confused. There was a bug early on in the life of the T3 where the "BACK" button was erroneously generating the same event as "NEXT" button.

[IanSav]

Hi PeterU,

I think you may be getting confused. There was a bug early on in the life of the T3 where the "BACK" button was erroneously generating the same event as "NEXT" button.

This is quite possible. This all happened a very long time ago. I suspect I may have been mostly involved with XML skins and not the Python code in those days.

Regards,
Ian.

[peteru]

It's been a long journey to get where we are now. Now, consider that we are relative newcomers to the enigma2 world. The legacy goes back a long way, so it's no surprise that some of the user interface design choices are a bit odd.

Maintaining the code base is a fairly difficult task of balancing new developments in our fork while also tracking upstream so that we can benefit from new features being developed elsewhere. Sometimes that means coming up with the minimal set of changes to solve an issue, rather than a full rework of a feature.

[IanSav]

Hi PeterU,

An alternative or additional suggestion is to submit our improvements upstream so that Enigma2 users also get to benefit from our improvements. Prl and I have been having success with getting Beyonwiz improvements absorbed into the core Enigma2 code. The benefit to you would be simplified merges with reduced effort to merge with the upstream code.

You could assist with this effort by performing two way merges. Not only take code from OpenViX and Enigma2 but also offer pull requests for Beyonwiz changes and fixes that would make sense upstream.

Regards,
Ian.

[prl]

Hi Prl,

That's deep history. It looks to me like the use of PREV/NEXT for history zapping was introduced in commit d8db49b in Feb 2006.

When did we lose the ZAP History on the LAST button (when LAST become BACK)?

This is the change I think I am remembering. It should be far more recent than 2006.
...

I'm not entirely sure what you mean. In Jul 2014, peteru added a KEY_LAST (BACK button on Beyonwiz remotes) entry mapping to the reCallService action to the keymap.xml InfobarChannelSelection context.

That made the KEY_LAST, which appears to previously have had no function in live TV and timeshift, operate as a button to switch between the two most recently viewed channels.

The reCallService actionmap entry and its corresponding method was added to InfoBarGenerics.InfoBarChannelSelection by Paul (darezik@gmail.com) in Mar 2014.

KEY_BACK and KEY_FORWARD entries in the InfobarChannelSelection context were added to keymap.xml in Dec 2007 Felix Domke. They had parallel action definitions to the actions for KEY_NEXT and KEY_PREVIOUS, and made the definitions as they are now in the current Beyonwiz keymap.xml:

Code: Select all

	<map context="InfobarChannelSelection">
		...
		<key id="KEY_PREVIOUS" mapto="historyBack" flags="mr"/>
		<key id="KEY_NEXT" mapto="historyNext" flags="mr"/>
		<key id="KEY_BACK" mapto="historyBack" flags="mr"/>
		...
		<key id="KEY_FORWARD" mapto="historyNext" flags="mr"/>
		...
	</map>

AFAIK, the Beyonwiz remotes don't generate KEY_BACK and KEY_FORWARD. The BACK button on the Beyonwiz remotes generates KEY_LAST.

KEY_LAST has been defined as 405 (0x195) in driver/input_fake.h since Oct 2003 and it's been defined that way in keyids.py since Feb 2005.

It's possible that at some time, the BACK key generated KEY_BACK in the enigma2 code, which would have made it (redundantly) do the same thing as KEY_PREVIOUS in live TV (that may be the bug peteru was referring to). I can't find any evidence of that in the in the easy-ui-4 repository, though, but it may have happened at a lower level.

[peteru]

The driver code that handles the decoding of IR codes used to have a bug that caused the same key code to be sent for both the NEXT button and the BACK button on the remote. This was fixed in May 2014.

[IanSav]

Hi,

The timing of these changes sounds about right. The effect was that prior to the change the BACK button did generate the ZAP History screen though the reason was probably due to the underlying key duplication issue.

Still, as previously suggested, moving ZAP History to long press of BACK would free up PREV and NEXT for time shift duties at all times.

Regards,
Ian.

[prl]

... Still, as previously suggested, moving ZAP History to long press of BACK would free up PREV and NEXT for time shift duties at all times. ...

But it loses the continuity of the fact that in the HistoryZapSelector screen, PREV and NEXT move you further in the same direction selection list, so you just keep pressing the same button if you want to go further into the list. It also loses the ability to go either direction with the pair of buttons.

[MrQuade]

But it loses the continuity of the fact that in the HistoryZapSelector screen, PREV and NEXT move you further in the same direction selection list, so you just keep pressing the same button if you want to go further into the list. It also loses the ability to go either direction with the pair of buttons.

I had no idea those buttons actually worked like that in that screen. Since it brings up a list the way it does, I have always intuitively used the arrow keys there.
I don't think that any other lists operate like that, so perhaps removing the inconsistency with the rest of the interface is a good thing.

[prl]

I disagree. The way it is now means most of the time you can just keep using the same key.

[IanSav]

Hi Prl,

I agree with MrQuade that the ARROW buttons are far more logical as navigation buttons. The PREV and NEXT buttons should never have been given yet another unexpected function. It is these peculiarities that make the UI hard to predict and use.

Regards,
Ian.