feat(Player): automatically select best buffer duration #7358
Conversation
| ) | ||
| .build() | ||
| } | ||
| fun getLoadControl(): LoadControl = DefaultLoadControl.Builder() |
There was a problem hiding this comment.
I think this method is only called when the player is created for the first time, so it stays the same during autoplay or starting other videos (except if the current player is getting closed by the user).
But isn't it very likely that the available RAM is going to change when playing the next video, e.g. via autoplay?
There was a problem hiding this comment.
The method also isn't very accurate, since it doesn't include memory used by the kernel :)
Changed it to be based on the total memory that the device has.
Alternatively we could also just choose a value, but in either case I would like to remove this setting, as it's not really user-friendly or helpful.
There was a problem hiding this comment.
Sorry for comments here but as a user I feel there should be two options in setting " auto" and "custom" . You can set "auto" by default but if some users want to change it they will. For me this setting save a lots of data uses
There was a problem hiding this comment.
The PR actually tries to simplify the preferences and remove "unnecessary"/"unintuitive" preferences that are not really easy to understand or useful.
So adding a new option to toggle between auto and custom would be like the opposite of what this PR is trying to achieve imho.
There was a problem hiding this comment.
Sorry for comments here but as a user I feel there should be two options in setting " auto" and "custom" . You can set "auto" by default but if some users want to change it they will.
What's the issue with the (current) default, that requires you changing it?
For me this setting save a lots of data uses
The (network) data that is consumed is the same, it's just distributed differently.
There was a problem hiding this comment.
I want to share my experience with adjusting the buffer size for video streaming. By default, the app has buffer size of 50 seconds, but due to limited data from my provider, I reduced it to 10 seconds.How does this save data? A smaller buffer size reduces data usage when I skip videos. For example, if I'm watching a video and decide I don’t like it after a few seconds, THEN I only consume 10 seconds of buffered data instead of 50 seconds. This prevents wasting data on content I don’t watch.
By the way I tested this PR with a 3-minute video, the app cached nearly the entire video in just a few seconds. If I stopped watching and switched to another video, the cached data for the first video was wasted. A larger buffer size means more data is downloaded upfront, which is inefficient if I frequently skip videos.This is why I recommend keeping a buffer size setting but allowing users to adjust it. A smaller buffer, like 10 seconds, balances smooth playback with minimal data waste, especially for users with limited data plans.
Automatically selects the 'best' max buffer duration based on the amount of available memory. This improves the users experience as the player is less likely to constantly load, whilst avoid having user to configure the technical setting themselves (without any help/guidelines).
As the max preload (buffer duration) setting is now set automatically, there is no longer the need to keep the setting around. Ref: 405a916
FineFindus
force-pushed
the
feat/auto-buffer-selection
branch
from
b9c2e87 to
e90f2ce
Compare
| @@ -158,8 +158,6 @@ | |||
| <string name="show_updates">Check updates automatically</string> | |||
| <string name="related_streams">Related content</string> | |||
| <string name="related_streams_summary">Show similar streams alongside what you watch</string> | |||
| <string name="buffering_goal">Preloading</string> | |||
| <string name="buffering_goal_summary">Max. amount of seconds of video to buffer</string> | |||
There was a problem hiding this comment.
In any case we will also need to remove all translations of this because otherwise there are likely going to be issues with Weblate
There was a problem hiding this comment.
I assumed Weblate would manage that itself when someone updates the translations for that language? It's not that much work, but it seems something that should be done automatically (e.g. it is for .po files).
There was a problem hiding this comment.
Not 100% sure. In the past, I already had build issues due to some string resources messed up by Weblate, but I'm not 100% what used to cause it back then.
There was a problem hiding this comment.
Here's what happens if you only remove the source string: https://github.com/you-apps/WallYou/actions/runs/14822641921/job/41611687792#step:4:300. So no, Weblate doesn't seem to handle it.
|
Thinking about it a bit more, maybe we should also take into account the playback speed (as that is one of the major factors of what the 'best' buffer duration is). But I'm not sure how to best deal with changing speeds. |
Automatically selects the 'best' max buffer duration based on the amount of available memory. This improves the users experience as the player is less likely to constantly load, whilst avoid having user to configure the technical setting themselves (without any help/guidelines).
The exact values may need to be adjusted, based on user feedback.