Rewind - how does it work?

[ploughguy]

The remote has << and >> buttons underneath the red and blue buttons.
In the universe that I grew up in, these would go backwards and forwards, increasing in speed with every click.
Which these do.
But then I would expect to click > (overloaded here with pause) and resume play from the point I have fast fwded or fast rewed to.
However, my V2 resumes play at the point that I started from - i.e. aside form burning some time and annoying the Mrs, they have no effect on replay.

I cannot find anything in the manual about these buttons. How do I tell them to start playing to the point I FFed or FRed to?

Release is 19.3.

Thanks for your help,
Russ.

[MrQuade]

The OK button will resume play no matter what FF/REW/pause state you are in.

You can customise how the play/pause button behaves too. By default, it will resume the last speed, buy you can also get it to play, or step between i-frames. That is set from the system button settings in the main menu.

In general though, I always recommend that you use the skip buttons instead. They're very customisable and much quicker to navigate around a recording as opposed to the FF/REW hangover from tape days.

[ploughguy]

So the correct sequence is << OK, not << >? That is truly odd.

We use the skip buttons for ad jumping, but my bride likes to use << for those “wtf did that mumbling bastard just say?” situations, and if its there, it should work, and if it works, it should work like every other similar device on the planet, i.e. << to rewind then > to play from the point rewound to.

Having the Play button act as “Undo Rewind” is counter-intuitive, undocumented (as far as I can see) and it breaks the tape machine metaphor that all other similar devices use.

I can feel an enhancement request coming on...

But thanks for the help. I’ll slug a few coffees and give it a go. Then I’ll slug a few bourbons and explain it to the bride.

[MrQuade]

I can feel an enhancement request coming on...

As per my previous post, there is already a setting in the setup menu to customise the PLAY button function.

[MrQuade]

Having the Play button act as “Undo Rewind” is counter-intuitive, undocumented (as far as I can see) and it breaks the tape machine metaphor that all other similar devices use.

It's not actually supposed to act as "undo rewind", in the default setting it is supposed to pause at the point showing on screen.

Rewinding is inherently difficult for the Wiz to do and you will end up with strange behaviour of you are just going beck a short distance. It's one unfortunate problem that has plagued the T, U and now V series.


Surely of you want to hear the mumbled line, isn't it easier to tap left arrow button to skip back 10s to hear the line again instead of having to press REW and then press PLAY again? Skips are just generally more convenient.

[Grumpy_Geoff]

We use the skip buttons for ad jumping, but my bride likes to use << for those “wtf did that mumbling bastard just say?” situations,

For those "what was said" moments I use a 5-second skip back which I've assigned to the "1" button via MENU>>Setup>>System>>Button settings, setting Enable skip for number buttons to Yes and setting the skip amount to the buttons (Number skip method set to Relative seconds).

[prl]

We use the skip buttons for ad jumping, but my bride likes to use << for those “wtf did that mumbling bastard just say?” situations, and if its there, it should work, and if it works, it should work like every other similar device on the planet, i.e. << to rewind then > to play from the point rewound to.

Having the Play button act as “Undo Rewind” is counter-intuitive, undocumented (as far as I can see) and it breaks the tape machine metaphor that all other similar devices use.

The PLAY/PAUSE button action (it's not, strictly speaking, a PLAY button) can be configured in MENU>Setup>System>Button settings>Behaviour of PLAY/PAUSE when paused. The title of the setting and the text are somewhat misleading, because the setting also affects the behaviour of PLAY/PAUSE when in other modes, like REW and FF.

The problem is that the action of the button depends on the current play mode and that setting, and there simply isn't enough space available to properly explain it in the setting description box. I and other developers improved a lot of this sort of description and help information some time ago, but it still leaves something to be desired in this case. The title of the setting is particularly misleading here.

However, the default value for this setting is "Play", and in that mode, pressing PLAY/PAUSE while in FF or REW (at any FF or REW rate) will go straight back to playing at a normal speed (which I think is what you want).

I can feel an enhancement request coming on...

As I said, I and some other developers put quite a bit of work into improving the help functionality (pressing HELP in most screens will give you a list of the actions of the buttons in that screen) and the wording of setting names and their descriptions, but some things have complicated descriptions and interactions that make that difficult to get right.

Better wording for this setting's title and description would be appreciated, but to do it, you'd need to do a lot of experimentation with the interaction between play mode and the setting, and possibly look at the code that implements it (which is itself a bit convoluted), and take into account the limited space available for displaying the description of the setting's effects..

In all screens that have a HELP button hint at the bottom right, pressing HELP will give you a screen that shows what the current button actions are for the screen. Help is also available in other screens where showing the button hint would be inappropriate, like when watching live TV, when timeshifting and when playing media and recordings. The Help screen tries to show the actions of the buttons taking into account the settings that affect them. Pressing HELP in the Help screen gives you a screen that describes how to use the Help screen.

[greentea]

The PLAY/PAUSE button action (it's not, strictly speaking, a PLAY button) can be configured in MENU...

Yes, I agree.
I prefer to think of it as a PAUSE/UNPAUSE button.

And that 's how I describe it to those people that I have recommended buying a Beyonwiz to (and for whom I provide support).

[ploughguy]

prl wrote:

Better wording for this setting's title and description would be appreciated, but to do it, you'd need to do a lot of experimentation with the interaction between play mode and the setting, and possibly look at the code that implements it (which is itself a bit convoluted), and take into account the limited space available for displaying the description of the setting's effects..

Hmmm... Perhaps this is a sign that you are aiming for too much flexibility? FF/REW is a fundamental function of devices such as this. It is something primal that everyone expects to function in a well-defined and reliable way. My wife’s annoyance (at the device, (and at me for buying it) is completely reasonable. I did some science experiments with this last night. FF always behaved as I expected (but we rarely use it) but for REW, pressing >|| seems to randomly either work as expected or jump back to the start point.

If >|| is indeed meant to be pause/unpause, then what is the correct way to resume after a rewind? Someone above suggested OK, but it always brings up the information box.

Saying “Don’t use it” is not a good answer. People will try to use it because it has obvious, well-labeled, visually bold, world-wide industry standard buttons with symbols that they have been recognising since they were six years old. In fact, when you look at the remote the power button, the info button and the “tape movement” buttons are the ones that speak to you first. The jump buttons are unlabelled and non-intuitive, plus they don’t provide the visual positional feedback that rewind does. I think that of all the functions on the remote, these are the ones that should be functionally immutable and 100% predictable.

[MrQuade]

FF/REW is a fundamental function of devices such as this. It is something primal that everyone expects to function in a well-defined and reliable way.

It's really a hangover from obsolete tape-based linear recording technology. The feature is included because people expect it to be there, but there are just better ways of navigating files now. REW has always been a bit iffy, and to make it work like an old VCR would take a lot of finessing (as I understand it), so noone has been particularly motivated to get it working 100%.

If >|| is indeed meant to be pause/unpause, then what is the correct way to resume after a rewind? Someone above suggested OK, but it always brings up the information box.

If you are in any mode except PLAY, then the OK button will put you into play mode. If you press OK while in play mode, then you get the Infobar as you have observed.

Saying “Don’t use it” is not a good answer.

I respectfully beg to differ.

[Grumpy_Geoff]

I did some science experiments with this last night. FF always behaved as I expected (but we rarely use it) but for REW, pressing >|| seems to randomly either work as expected or jump back to the start point.

What are you playing when it jumps back to the start? An unedited recording, a downloaded media file, or an edited recording?

[prl]

prl wrote:

Better wording for this setting's title and description would be appreciated, but to do it, you'd need to do a lot of experimentation with the interaction between play mode and the setting, and possibly look at the code that implements it (which is itself a bit convoluted), and take into account the limited space available for displaying the description of the setting's effects..

Hmmm... Perhaps this is a sign that you are aiming for too much flexibility? FF/REW is a fundamental function of devices such as this. It is something primal that everyone expects to function in a well-defined and reliable way. My wife’s annoyance (at the device, (and at me for buying it) is completely reasonable. I did some science experiments with this last night. FF always behaved as I expected (but we rarely use it) but for REW, pressing >|| seems to randomly either work as expected or jump back to the start point.

I'm not sure who the "you" refers to here. I didn't write the code that implements the rather over-loaded functionality of PLAY/PAUSE. I just tried to make the setting description and the help information for it better.

The enigma2 code is open source. It would probably be possible to trace exactly who wrote the code that implements the interaction of PLAY/PAUSE with playback modes other than play, but you can be pretty sure it wasn't any of the developers who regularly post on the Beyonwiz forum.

If >|| is indeed meant to be pause/unpause, then what is the correct way to resume after a rewind? Someone above suggested OK, but it always brings up the information box.

As I said in the post you're replying to:

However, the default value for this setting [MENU>Setup>System>Button settings>Behaviour of PLAY/PAUSE when paused] is "Play", and in that mode, pressing PLAY/PAUSE while in FF or REW (at any FF or REW rate) will go straight back to playing at a normal speed (which I think is what you want).

FF always behaved as I expected (but we rarely use it) but for REW, pressing >|| seems to randomly either work as expected or jump back to the start point.

As Grumpy_Geoff asked, we'll need more information about what you were doing to be able to assist. Is this rewinding live TV back into timeshift, playing Beyonwiz recordings or playing media files?

How often does it drop back to the start point (of what?) compared to how often does it work correctly? That's needed so someone who's trying to replicate the problem has some idea of how many times they'll need to try it to see the problem.

I just tried PLAY/PAUSE a few times while rewinding from live TV into timeshift, and PLAY/PAUSE returned to normal playback each time.

Saying “Don’t use it” is not a good answer.

I didn't say that, though I don't in fact use it myself. I use a short skip back for "what did they just say?" moments.

By the way, the cleanest way to quote someone on the forum is to use the "quote post" function: the double quotes icon at the top of the post you want to reply to. That fills in the name of the person you're replying to, and a link back to the post being quoted.

You can edit the quote to remove bits that aren't relevant, so long as you don't break up the quote markup. With a little copy/paste, you can also split parts of the quote up to reply to separately, as I've done in this post.

The Preview button (beside the Submit button) is you're friend while you're getting used to how it works.

[ploughguy]

I did some science experiments with this last night. FF always behaved as I expected (but we rarely use it) but for REW, pressing >|| seems to randomly either work as expected or jump back to the start point.

What are you playing when it jumps back to the start? An unedited recording, a downloaded media file, or an edited recording?

I was replaying an unedited recording. The errant behaviour is that under seemingly random circumstances, it jumps back to the point where the rewind operation started, so the effect of the rewind operation is that I get to see some action in reverse, then when I tap >||, it returns to the start point of the rewind action and resumes playing forward from where the rewind interrupted it.

Please understand my motives. I love this device. I want it to be the best it can. I bought it despite some reviews saying it has bugs, and aside from this particular problem, I think it is perfect. The point I am trying to make is that there is a minimum level of user interface expectation for a device like this. If you drew a Venn diagram of expected functionality, the rewind/play/pause/ff operations would be pretty much the only thing in the overlap other than On/Off.

I disagree that the rewind operation is obsolete and old school. Rewind lets you (and your companion viewers) see what you are doing and where you are up to. It is way more natural to rewind, watch the screen to see the point you want to re-play from, then resume than to pause, think “How far back was that?”, work out which of the four or five unlabelled step-back buttons is appropriate (back 30, then another 15, then forward 5. That should do it... ... Damn...) then annoy everyone else watching while you execute a sequence of jumps to get to the bit you wanted to see again. It is not a tape metaphor, really, it is a view of the media as a continuum, and very convenient way for going back to a given point in time.

[ploughguy]

Hmmm... Perhaps this is a sign that you are aiming for too much flexibility?

I'm not sure who the "you" refers to here. I didn't write the code that implements the rather over-loaded functionality of PLAY/PAUSE. I just tried to make the setting description and the help information for it better.

My apologies for the lack of clarity - and please attempt to interpret everything I have said as my trying to contribute rather than as grumpy criticism. The “you” I was mentally referring above to is the Beyonwiz product design team. When I wrote it I was clearly in a fugue state that was totally divorced from reality. This is not uncommon. The point I was clunkily trying to make is that the average consumer would be quite disappointed to find out that this basic function does not work.

I did not dig into the background of this device so I was unaware of how dependent it is on open source software. It makes a bit more sense now - as an open source application, users of the raw software will be inevitably technical and rather forgiving. However, when such a project is packaged up into a consumer product, it starts to reach an audience with different expectations.

I gotta say, this whole discussion is way livelier than I expected. I hope my comments have not been taken as anything other than a constructive if ill-conceived attempt to help make the product the best it can be.

I will try to develop a repeatable scenario that will allow it to be trouble-shot and maybe even fixed.

Meanwhile, consider this real world scenario (The first three lines triggered this discussion):

Bride: “Hang on - go back a bit.”
Me: “How far?”
Bride: “Back to a bit before the start of the opening credits.”
— IRL, I discover that REW is not as intuitive as one might expect.
— But lets update the dialog in the light of the discourse above.
Me: “How many seconds do you think that is?”
Bride: “ @$#&! You *{^%$! Just go back and I’ll tell you when to stop.”. ***

At this point, I would rather not say “Now dear, this is (not really) the start of the 2020‘s. Old-school tape metaphors are no longer considered relevant. We gave evolved beyond them. You must tell me how many seconds you want to go back, give or take five...”

It would not have made any difference. At this point she timed out and went to bed.

*** My wife does not actually address me with punctuation symbols. Her explanations are more colourful than symbolic. Her creative expletives and resolute right jab are what endears her to me.

[Grumpy_Geoff]

I did some science experiments with this last night. FF always behaved as I expected (but we rarely use it) but for REW, pressing >|| seems to randomly either work as expected or jump back to the start point.

What are you playing when it jumps back to the start? An unedited recording, a downloaded media file, or an edited recording?

I was replaying an unedited recording. The errant behaviour is that under seemingly random circumstances, it jumps back to the point where the rewind operation started, so the effect of the rewind operation is that I get to see some action in reverse, then when I tap >||, it returns to the start point of the rewind action and resumes playing forward from where the rewind interrupted it.

Was that a completed recording, or were you chase playing the not yet finished recording?
I've tried and failed on a number of occasions to have REW->PLAY/PAUSE jump back to the time point from where the REW operation commenced when playing completed recordings. It just worked every time.
I know you said it was random, for you.
I don't use REW (nor FF), as I previously posted, I use a small skip back (I have 5 and 10 secs configured on the 1 and 4 buttons).

[prl]

Meanwhile, consider this real world scenario (The first three lines triggered this discussion):

Bride: “Hang on - go back a bit.”
Me: “How far?”
Bride: “Back to a bit before the start of the opening credits.”
— IRL, I discover that REW is not as intuitive as one might expect.
— But lets update the dialog in the light of the discourse above.
Me: “How many seconds do you think that is?”
Bride: “ @$#&! You *{^%$! Just go back and I’ll tell you when to stop.”. ***

At this point, I would rather not say “Now dear, this is (not really) the start of the 2020‘s. Old-school tape metaphors are no longer considered relevant. We gave evolved beyond them. You must tell me how many seconds you want to go back, give or take five...”

How about [skip] this far back? No? [skip] here? No? [skip]...

You don't actually need to know how many seconds back to skip. If you do, there's actually a skip function for that, but it probably takes too long to use in this context

I just use my normal short backward skip of 15 sec for "oops, missed that bit of dialog". It's rarely not enough, and it's not so much that it's too annoying.

[prl]

The “you” I was mentally referring above to is the Beyonwiz product design team.

There really isn't such a thing for the new T/U/V series Beyonwizes. All the developers who post on the forum are users who contribute their spare time to improve the firmware.

I was unaware of how dependent it is on open source software.

It's probably >90% open source software. Most of what isn't is proprietary SDK code from the SoC manufacturer. That is completely "black box".

I gotta say, this whole discussion is way livelier than I expected. I hope my comments have not been taken as anything other than a constructive if ill-conceived attempt to help make the product the best it can be.

I think that everyone involved in the discussion is coming from that perspective.

[IanB]

I think what ploughguy is experiencing here is more of the original bugs with the V2 drivers not correctly reporting playback position, this time during some trick play modes.

[prl]

That sounds possible.

I've done a bit more testing (this time with audio on to make it clearer what's happening in "talking heads" recordings) of REW followed by PLAY/PAUSE on recordings, and I've been able to replicate the problem on a recording from 9HD (MPEG4), but not on a recording of ABC (MPEG2 SD). So perhaps it's something to do with the handling of MPEG4 in the V2 drivers.

I've seen PLAY/PAUSE take the play position back to the point where REW started, and I've also seen PLAY/PAUSE take the play position to slightly after the point where REW started.

Ploughguy, do you find any differences on whether this problem occurs between recordings from different channels, and especially between recordings in MPEG2 and MPEG4?

Unfortunately, there's no simple way to check whether a recording is MPEG2 or MEG4 from recording playback. To find out whether a channel is MPEG2 or MPEG4 you need to go to live TV, change to the channel, and then do MENU>Information>Service. The video coding is indicated in the Videocodec field, MPEG2 for MPEG2, and AVC for MPEG4. The broadcast resolution is in the Videosize field (Videomode is the display resolution).

For example, SBS ONE is MPEG2 SD, SBS HD is MPEG4 HD and SBS Food is MPEG4 SD.

[ploughguy]

I think that everyone involved in the discussion is coming from that perspective.

Excellent. I bought the right product then.

Lemme point out that the sometimes irascible Mrs is a real sweetie with a strong technical computing background and high standards. She understands the difficulties of making this stuff work, which is why she goes a bit glass-half-empty when it doesn’t. If it’s not working by the time you buy it, it will probably never work.

However, this product is a different story, I think.

She is very impressed by the V2 box, but somewhat surprised that this basic function has issues.
However (spoiler alert) she will be heartened to hear that the problem is data-dependent (see below). i.e. someone ~did~ successfully test it, but there are scenarios that were not covered by the test. She would say “Well fix it then and add it to the regression tests.”. Which is what I am sure will eventually happen.
R

[prl]

However (spoiler alert) she will be heartened to hear that the problem is data-dependent (see below). i.e. someone ~did~ successfully test it, but there are scenarios that were not covered by the test.

There may be, but a lot of the code is common between different ways of playing recordings. MPEG2 and MPEG4 are quite different in the ways that the frames between full broadcast frames are represented, and that could be a significant difference in the ways that REW and the return to normal playback from REW are handled.

One of the reasons I asked about differences between channels was to get more information about the contexts in which the problem occurs. Saying "there are scenarios not covered by the test" is accurate, but less useful than "I also see the problem in these scenarios that weren't covered by the test". Grumpy_Geoff has also asked for information about the context where you see the problem.

She would say “Well fix it then and add it to the regression tests.”. Which is what I am sure will eventually happen.

If IanB is correct and the problem is in the drivers, then that's likely to be in the < 10% pf the code that's not open source: in the SDK provided by the SoC manufacturer. AFAIK, the developers posting here do not have access to that, so any fix will be up to the chip manufacturer's software engineers, and it would be useful to have the circumstances that cause the problem defined as well as possible to have the best chance of them fixing the problem and ensuring that it does nor reoccur.

Fixes for the V2's SDK have definitely been achieved, mostly, I think, through peteru's efforts, but he hasn't posted on the forum for a while and may be on summer holidays at the moment (as has been suggested in the topics about the current problems with downloading plugins)..

[ploughguy]

sounds possible.
I've been able to replicate the problem on a recording from 9HD (MPEG4), but not on a recording of ABC (MPEG2 SD). So perhaps it's something to do with the handling of MPEG4 in the V2 drivers.

I've seen PLAY/PAUSE take the play position back to the point where REW started, and I've also seen PLAY/PAUSE take the play position to slightly after the point where REW started.

Whew! Not crazy after all!

Ploughguy, do you find any differences on whether this problem occurs between recordings from different channels, and especially between recordings in MPEG2 and MPEG4?
Unfortunately, there's no simple way to check whether a recording is MPEG2 or MEG4 from recording playback. To find out whether a channel is MPEG2 or MPEG4 you need to go to live TV, change to the channel, and then do MENU>Information>Service. The video coding is indicated in the Videocodec field, MPEG2 for MPEG2, and AVC for MPEG4. The broadcast resolution is in the Videosize field (Videomode is the display resolution).

For example, SBS ONE is MPEG2 SD, SBS HD is MPEG4 HD and SBS Food is MPEG4 SD.

The recording that kicked off this first world problem was made from SBS HD which the above menu path tells me also uses the AVC codec. The problem is not displayed in ABC SD (MPEG2) live or a recording from ABC Comedy./Kids (also MPEG2), so I am seeing the same behaviour that you are seeing.

So we have a repeatable test! Fixing it should be a walk in the park then, no?

Thanks for the excellent work, PRL. Nicely done.

[ploughguy]

]
If IanB is correct and the problem is in the drivers, then that's likely to be in the < 10% pf the code that's not open source: in the SDK provided by the SoC manufacturer. AFAIK, the developers posting here do not have access to that, so any fix will be up to the chip manufacturer's software engineers, and it would be useful to have the circumstances that cause the problem defined as well as possible to have the best chance of them fixing the problem and ensuring that it does nor reoccur.

Fixes for the V2's SDK have definitely been achieved, mostly, I think, through peteru's efforts, but he hasn't posted on the forum for a while and may be on summer holidays at the moment (as has been suggested in the topics about the current problems with downloading plugins)..

Right-oh then. Let’s start the analysis:

• It happens during rewind

• It happens during fast forward

• It does not happen every time

<Time passes. Much clicking and FF/REW later...>
I have a repeatable case.

• Open a file from SBS One HD then FF at 64x to around 25 mins in. It does not seem to matter if the file has been played before or not

• Go back at 2x for a count of five, which my watch’s stopwatch says is about 6 seconds

• Click >|| and it goes back to the starting point of the rewind

• Click the stop button, then reopen the file from the file list

• Accept the resume option, which starts play from around 25 minutes in where Stop was clicked

• Repeat the 5-count rewind, same result

I have tried this multiple times on each of four files recorded from SBS-One-HD and they all behave the same way, first try.

Peer review time! Can anyone else replicate this result?

[prl]

I'll do some more testing, but when I first found the problem, whether it did the jump back to near the start of rewind seemed to depend on where I was in the one recording I tried. Some places it worked "as advertised", other places it jumped back to at or after the start of the rewind. If I started rewind from about the same place again, I got the same result.

I didn't really notice how far in I was.

I didn't use the "replay from old position" to get the effect, though that seems to be a convenient way of going back to about the same place to retry the problem.

[ploughguy]

Prl,

I think the “Jump to previous position” component is not relevant from the point of view of the test case, but not being near the start of the file seems to be. I mentioned the jump in the interests of rigour and repeatability.

My observation is that the problem is less predictable near the start of the file. My selected point of 25 minutes in is arbitrary, but clearly sufficiently far from the start to make the problem reliably repeatable.

Please follow my steps to determine if the problem is portably repeatable. If you get the same result, we have what we need to demonstrate the problem to the software developers.

If would be nice to get more than one or two demonstrations of the problem, so if you have read this far, please follow the steps in my post above to see if you get the same result.
Ploughguy

[peteru]

This is just another manifestation of the driver bugs that were reported way back during closed beta testing. Github issue #5. Last update on that was that it needed SDK fixes from Hi-Silicon, before the Chinese driver developers could look into it.

I don't know if anything happened after that update. I know that a few HiSi boxes sold in Europe have received more recent driver updates than what Beyonwiz have been given, but the problem is that the Chinese ODM added code to prevent the drivers from one brand working on other brands of boxes, even when the hardware is identical.

The more recent drivers for other boxes may not fix these problems anyway.

Basically it boils down to two problems.
1. The drivers often misidentify the payload content at the start of playback (which includes resuming from pause)
2. The drivers are really, really rubbish at reporting the current PTS, which, given the nature of an asynchronous playback engine, needs to be accurate and prompt.

I fixed a lot of these problems for the T-series, because I had access to the source code. I can't do anything about the V2 - no source.

[ploughguy]

Basically it boils down to two problems.
1. The drivers often misidentify the payload content at the start of playback (which includes resuming from pause)
2. The drivers are really, really rubbish at reporting the current PTS, which, given the nature of an asynchronous playback engine, needs to be accurate and prompt.

I fixed a lot of these problems for the T-series, because I had access to the source code. I can't do anything about the V2 - no source.

Right. I see. So basically, it is unfixable until BeyonWiz sells enough boxes that its threats to take its business elsewhere have an impact and the two-degrees-of-separation software providers decide to take notice...

Skip buttons it is, then.

Thank you all for taking an interest. We shall wait and see.

...

...

... Unless ... a bunch of us get together and form an Oceans Eleven squad to go over there, lock the developers in a room and threaten to feed them health food and water until they fix it...