Question Global conspiracy against "rewind" and "fast forward"

[stereator]

Hi all! It's so sadly to realize but I figured out that Android platform and every its app aren't skip-friendly on viewing or listening media (video or music). I mean that many Bluetooth gadgets, widgets etc, have skipping track only but don't have skipping back (aka rewind) and skipping forward (fast-forward) option within the playing track at all.

For instance, if you start playing video on YouTube and lock the screen (assume you have premium subscription), you'll see the widget with "previous", "stop/play", "next" buttons and there are absent "rew" and "ff" here. The same with widget in the notification area. The same thing with many Bluetooth headphones. The same even with many music players.

I wanted to assign double pressing the volume hardware buttons on my Samsung S24 Ultra for skipping YouTube video by 5 secs. The only option I found out is Button Mapper app where I made such assignment. But it doesn't work. When I started to figure out, I realized that this is almost impossible feature. Really? But why? Seems it's a fundamental issue. And why all vendors ignore need to "rew" and "ff"? It looks like a global conspiracy, ahahaha. I don't have any another explanation of why these useful basic controls are missing. If I would be a vendor I'd make smartphones with all 5 hardware buttons to control the playback...

 

[Mooncatt]

It's less a conspiracy and more of a no longer needed function. Gone are the days where all you had are control buttons, which necessitated a fast forward and rewind option to navigate within a given track. Now you simply go to the player and use the timeline to scrub to exactly where you want to be in almost no time flat. There are a few exceptions to this, like with Pandora that limit your ability to rewind and replay a track, but that's due to their licensing agreements with the music industry. If there is a song you want to listen to again, then you can usually head to YouTube and find it.

 

[stereator]

It's less a conspiracy and more of a no longer needed function. Gone are the days where all you had are control buttons, which necessitated a fast forward and rewind option to navigate within a given track. Now you simply go to the player and use the timeline to scrub to exactly where you want to be in almost no time flat. There are a few exceptions to this, like with Pandora that limit your ability to rewind and replay a track, but that's due to their licensing agreements with the music industry. If there is a song you want to listen to again, then you can usually head to YouTube and find it.

Obviously, you don't understand the problem. Let me explain it to you.

Seeking and skipping are the different controls, though seem similar. Assume we have very long video, say 1 hour length or more. If you hasn't heard some words of speech and need just to rewind it by 5-10 secs your sliding always will be as more than 5-10 secs as longer video is, due to scaling. Timeline not allows to move precisely but very roughly. Moreover timeline is often a big problem when you tap on it suddenly and did not memorize the previous position. So, no wonder that YouTube app still has an 'rew' and 'ff' functionality by double-tapping the video area.

Another reason to have such controls is an accessibility. It's so hard to operate the touch sensor based device for people with various vision disabilities. Much more convenient would be to press the physical button that such people may find by groping. Even if the person doesn't have vision disability, for example I often listen to the long videos with speech when I walk or before sleep with closed eyes, so when I need to rewind it, I am forced to look at the screen and be focused to not to set wrong position. It is very annoying. Much more convenient would be just to press one button which the person could find groping. I hope I explained clear enough?

 

[B. Diddy]

Welcome to Android Central! You can adjust the Double-Tap To Seek option in YouTube to as short as 5 seconds, so at least it's not skipping ahead or back by 10 seconds or more.

I suggest you send feedback to YouTube from within the app settings about your concerns.

 

[stereator]

Welcome to Android Central! You can adjust the Double-Tap To Seek option in YouTube to as short as 5 seconds, so at least it's not skipping ahead or back by 10 seconds or more.

I suggest you send feedback to YouTube from within the app settings about your concerns.

Well, I mentioned YouTube app just as an example. The core problem is Android apps don't support 'rew' and 'ff' features on the OS level, whereas skip track support.

 

[B. Diddy]

In that case, send feedback to Google in general from the system settings menu. If enough people give the same feedback, that may prompt Google to consider bringing back FF/REW controls.

 

[mustang7757]

In my s24u YouTube on the lock screen you can use the slider bar to forward or rewind

 

[SeeBeeEss]

Michigan football is taking a turn for the...

Don't leave us in suspense. "Michigan football is taking a turn for the..." what?

 

[Mooncatt]

Well, I mentioned YouTube app just as an example. The core problem is Android apps don't support 'rew' and 'ff' features on the OS level, whereas skip track support.

That's more a result of how developers program their apps than core OS support. I still stand by my earlier comments that the seek buttons are not really necessary anymore. I understand that some people may want or need them, but app developers make programs for the masses, and rarely for the more niche users like you. You have to understand it from their business perspective, where they are unlikely to add features, which adds complexity and difficulty to the programming side of things, just to appease a small number of users. This is especially true for free apps where there is no real incentive to do something like that.

 

[joeldf]

In my s24u YouTube on the lock screen you can use the slider bar to forward or rewind

The OP did account for that. The problem is described as one of scale. And I can understand the point being made.

If the video or audio is only a few minutes long, a slight bump on that bar may go back only a few seconds.

But, if it's an hour or two hours long, then a tap back on that bar may go back 10 or 20 minutes when the OP only wants to jump back 5 to 10 seconds to re-hear something that might not have been clear. The longer the media being played, the less time control you have with the progress bar being the same physical length on the screen.

 

[mustang7757]

The OP did account for that. The problem is described as one of scale. And I can understand the point being made.

If the video or audio is only a few minutes long, a slight bump on that bar may go back only a few seconds.

But, if it's an hour or two hours long, then a tap back on that bar may go back 10 or 20 minutes when the OP only wants to jump back 5 to 10 seconds to re-hear something that might not have been clear. The longer the media being played, the less time control you have with the progress bar being the same physical length on the screen.

Ahh..I see

 

[stereator]

That's more a result of how developers program their apps than core OS support. I still stand by my earlier comments that the seek buttons are not really necessary anymore. I understand that some people may want or need them, but app developers make programs for the masses, and rarely for the more niche users like you. You have to understand it from their business perspective, where they are unlikely to add features, which adds complexity and difficulty to the programming side of things, just to appease a small number of users. This is especially true for free apps where there is no real incentive to do something like that.

Nope, that is exactly the limitation of the Android OS. It doesn't allow apps developers to use this necessary functionality, just look at the docs. There aren't any reference to the REW/FF at all. This way, Google intentionally limits the technology development. If we say about market, well, I'd prefer to buy that apps which support this features rather than those that doesn't. People don't chose between the slider and REW/FF options just because they do not have last one. I will not wonder if tomorrow, say Chinese HyperOS implement this feature and it will be its advantage on the market.

 

[gomezz]

Gone are the days where all you had are control buttons, which necessitated a fast forward and rewind option to navigate within a given track. Now you simply go to the player and use the timeline to scrub to exactly where you want to be in almost no time flat.

Apart from the time and faff needed to hoik your phone out of your pocket or bag to access the playbar. For shortish skips backward and forward controls on the earbuds or speakers are much more convenient - Where the app allows I have mine set to -20/+60 seconds.

Mind, my use case if mostly for podcasts and ripped radio programmes. But even when I *do* scrub the playbar to get to a particular play point that can only be done very approximately on a multi-hour recording so the skip controls can then be used to zone in on exactly where you want to be.

 

[stereator]

In that case, send feedback to Google in general from the system settings menu. If enough people give the same feedback, that may prompt Google to consider bringing back FF/REW controls.

I see that this is the only option we have. But how to reach them out? Google support service ignores every claim and feature requests from users.

 

[B. Diddy]

You may feel that they ignore feedback, but I know from my experience as a Product Expert (in the Chromebook community) that they do pay attention to feedback. But they can't accommodate every single request for feature changes. I don't know their exact protocols, but there has to be a certain critical mass of similar feedback (or the feedback has to be of a major flaw/glitch) for them to act. I can say from experience that there have been several times where something I gave feedback about was fixed some time later -- was it my feedback that was responsible? Probably not by itself, but I'm sure it was one of many bits of similar feedback that prompted them.