[Feature Request] - Rename 'Buffering strategy' options

[Forage]

Summary

The options too choose from in the 'Buffering strategy' list are all but self-explanatory. It would be good to rename them instead of even trying to explain them.

Description

I had to go to the initial ticket to understand what the 'Buffering strategy' options actually do.
Its description only talks about the need to restart the app.
The names giving now are subjective and can be interpreted in different and even opposite ways. There is no way of knowing what they actually do (a multiplier) without knowing its internal implementation (default duration of 50 seconds).

Current options apparently mean:

• Minimum, 5 seconds
• Moderate, 50 seconds
• Aggressive, 3 minutes and 20 seconds
• Extreme, 6 minutes and 40 seconds

I'd say changing the durations a bit, no longer working with a multiplication factor, and calling them by its duration makes a lot more sense:

• 5 seconds
• 30 seconds
• 1 minute (default)
• 3 minutes
• 5 minutes

The description in the main settings list should also be changed to display the current applied/selected value. A message to restart could be displayed after changing its value.

Alternatively you could also choose to no longer work with a specific duration but with number of songs, providing options like:

• 1 song (default)
• 2 songs
• 3 songs
• Album

The latter only making sense when implementing #471 ;)

Use Case

Understand what an option does right away, without the need to look for an explanation elsewhere.

[tvillega]

Title: Read-ahead time cache.

Summary: How many seconds of the song to fetch from the server. Choose a high value if your internet connection is unstable to ensure a smooth playback. Current value is X seconds.

Options:

• 10 seconds
• 30 seconds
• 60 seconds
• 120 seconds
• 200 seconds
• 300 seconds

I used as reference the flag --demuxer-hysteresis-secs= from MPV. I didn't use minutes for the last 3 options because wording becomes complicated in the explanation (I could be biased on that for reading so much technical documentation).

To solve this issue we should agree what values are reasonable. I used as max value 5 minutes because in an hypothetical scenario of bad connectivity the phone would fetch the entire song as soon as it has the chance.

If I'm not mistaken, DSub offers the alternative of choosing how many songs to fetch ahead, which is tightly linked to the download of songs on the phone (not cache). If we implement that, a user that tries to have a smoother streaming will end up eating their storage the more songs they listen to. Feats should be kept separated to avoid that.

[Forage]

If changing the name for the settings itself is on the table as well, I'd opt for something a bit less technical even more: "Preload buffer", or even "Song preload buffer" to make it clear outside of context too.

If your intent is to use that summary in the main settings list, I'd say it's rather a lot of text.
It would be the first settings which has an explanation and its current value displayed in the settings list. I did not find a similar pattern in the Android guidelines. To be most consistent with the rest of the apps settings maybe only stick to the current selected value only.
Unfortunately, I did not find a setting with a list of options that has an additional explanation above the options. So it might not be something you'd like to introduce now. At the same time, does it really need that much explanation?
A good label and self-explanatory options should suffice.

I would still go for 2/3/5 minutes instead of talking about seconds. It prevents high numbers and having to calculate.
At the same time, 5 options max. I don't quite see people really having a need to be more accurate, and it starts to feel like an overload of options.
Changing the first option of my initial list from 5 to 10 seconds is something I'm neutral about. I only took 5 to match the current implementation.
I'm at "Aggressive" at the moment. Going below 3 minutes is not really an option for me.

[tvillega]

I agree with you.

I found CappielloAntonio/tempo@0a5983e, where the feat was implemented.

We could go even further with this enhancement and provide a stepped-slider, this way we leave the choice to the user:

* 5 sec
* 10 sec
* 30 sec
* 1 min
* 2 min
* 3 min
.
.
.
* 30 min

A bigger buffer consumes more memory, but it may be desirable for podcast users (voices use little space in compressed audio files) while commuting.

[Forage]

It feels to me that going beyond just 5 quick and simple options to choose from is making things more fancy than currently really needed. It might be handy, hypothetically. But without anyone actually stepping forward and presenting their requirement, you only risk introducing more problems for users who go nuts with the setting just because they can, without them really needing it.

[tvillega]

@Forage the PR above implements the feature.

[peddarson]

Actually I'd be a friend of buffering a whole song / or/and the next songs in advance instead of seconds, minutes, etc....

This would work much better if you have a unstable internet connection. Also slightly less battery consumption(?).