You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I could not understand a dialogue or want to watch a scene again, I don't want to rewind to a fixed interval, but instead replay the last 30 (or 10, 20) seconds again.
As of now, any rewind / seek always jumps to the next full 30 seconds. I.e. I am at 5:10 and rewind. I'd expect the first rewind to jump to 04:40, but it jumps to 05:00.
Rewinding is also usually desired to be fine-grained, i.e. 5 or 10 seconds (option added in #3794), but seeking forward should skip fast (e.g. due to playback not starting at the correct point in time). Hence, going backward and forward should each have their own slider for step size.
This was already requested here (#4257) but I believe it was closed due to misunderstanding - using jellyfin-androidtv 0.18.4 release, the described enhancement is not implemented.
Proposed solution
Rewind and seek don't jump to absolute points in time, but relatively to the current point
Step size of rewind and seek can be configured independently, proposal: [5-30s rewind] [5-60s seek]
Alternatives considered
Setting the seek time to 10s works better, but introduces the problem of seeking forward for very long when needing to manually seek from 0:00 to (e.g.) 42:50.
The text was updated successfully, but these errors were encountered:
Have you confirmed you are using the actual the fast forward/rewind buttons instead of the left and right menu buttons? On my remote, using the left and right menu buttons work as you described the current behavior (5:15, press left, 5:00), however using the rewind button works exactly like the feature you requested (5:15, press rewind, 5:05, only 10 seconds).
I would argue that it is completely unintuitive to not have this behavior for the left/right menu buttons, at least for the TV controls that are common these days with the circular button like on the chromecast or Fire TV Stick. In my experience, the classic rewind button is used (if at all) to rewind over a longer period of time. For example, if a user only wants to rewind 10 seconds, they will always use the left menu button. I have roughly 20 Jellyfin users and at least half of them complained about this before when I asked them if they have any annoyances/problems - and they all used the circular button, because that is how it works in basically all other streaming/movie apps.
edit:
To add to this, a lot of new controls don't even have fast forward/rewind buttons anymore.
Also, there is no automatic playback function after the video has been rewound. Now, after rewinding, you need to turn on video playback and this is not convenient (an unnecessary action).
@The-Randalorian, my remote does not have these buttons unfortunately.
Also I'd agree with the others - it's unintuitive to not have left/right perform the rewind. Up to your response, I wasn't even aware there are separate buttons for that - in theory.
And yeah, this too:
that is how it works in basically all other streaming/movie apps
This request respects the following points:
Problem description
When I could not understand a dialogue or want to watch a scene again, I don't want to rewind to a fixed interval, but instead replay the last 30 (or 10, 20) seconds again.
As of now, any rewind / seek always jumps to the next full 30 seconds. I.e. I am at 5:10 and rewind. I'd expect the first rewind to jump to 04:40, but it jumps to 05:00.
Rewinding is also usually desired to be fine-grained, i.e. 5 or 10 seconds (option added in #3794), but seeking forward should skip fast (e.g. due to playback not starting at the correct point in time). Hence, going backward and forward should each have their own slider for step size.
This was already requested here (#4257) but I believe it was closed due to misunderstanding - using jellyfin-androidtv 0.18.4 release, the described enhancement is not implemented.
Proposed solution
Alternatives considered
Setting the seek time to 10s works better, but introduces the problem of seeking forward for very long when needing to manually seek from 0:00 to (e.g.) 42:50.
The text was updated successfully, but these errors were encountered: