(feature request) Configuring playback speed control
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 2.4k
- Forks
- 110
- PR merge metrics
- No merged PRs in 30d
Description
Hi,
In the lbry client, there are a few predefined playback speeds: 0.25x, 0.5x, 0.75x, 1x, 1.25x, 1.5x, 1.75x, 2x
For listening to podcasts, while sometimes 1x is not fast enough, we may want to increase the speed. The problem is 1.25x is already too fast. The odysee web client is allowing 1x, 1.1x and 1.25x, which is slightly better. With some speaker you can use 1.25x without problem, for some other you can even reach 1.3x.
The problem is 1.5x, 1.75x and 2x doesn't seem very relevant (and even 0.25x doesn't seem so too)
To make the experience better, there are a few solutions:
-
Adding a few more playback speed in the option. Obviously, there is room for this (in the screen). I'd suggest adding more values around 1. For example: 0.80x, 0.90x, 1x, 1.1x, 1.15x...
-
Adding more playback speed like above and removing other ones such as 0.25x and 2x (some people might miss this, but probably not too many)
-
Using a slider or a field for changing playback speed. The slider approach is the one used in NewPipe
-
Adding an option for selecting the default playback speed. You can have this in AntennaPod (https://github.com/antennapod/AntennaPod).
You select the few playback speed you like in the main options. Then only those will be available in the selection on screen. Very convenient.
The best, but most complicated to implement I suppose.
Here is a screenshot
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files, tests, or entry points. Review the existing playback-speed control and compare the four proposed approaches, then define one concrete behavior and its acceptance criteria before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android
- Domain
- mobile
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100