Set the progressive_load_interval_default_value to 64 KiB

[litetex]

What is it?

• Workaround (user facing)

Description of the changes in your PR

Set the progressive_load_interval_default_value to 64 KiB

This should workaround the problems from #8238.
#8238 (comment)

As a theoretical drawback stuttering may occur on very low bandwith connections, but I think this is negligible (also users can change it in the settings).

Fixes the following issue(s)

• Works around [YT] Throttling of (60fps) streams #8238

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR.

Due diligence

• I read the contribution guidelines.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[Stypox]

I don't think this PR solves anything, see how progressive_load_interval_default_value is used here. You are basically using a different name for the default value, without changing its effect, that is, setting the default loading check interval to DEFAULT_LOADING_CHECK_INTERVAL_BYTES = 1MiB. I am opening a PR myself in a few minutes.

NewPipe/app/src/main/java/org/schabi/newpipe/player/helper/PlayerHelper.java

Lines 424 to 435 in 9b3e43f

	public static int getProgressiveLoadIntervalBytes(@NonNull final Context context) {
	final String preferredIntervalBytes = getPreferences(context).getString(
	context.getString(R.string.progressive_load_interval_key),
	context.getString(R.string.progressive_load_interval_default_value));
	if (context.getString(R.string.progressive_load_interval_default_value)
	.equals(preferredIntervalBytes)) {
	return ProgressiveMediaSource.DEFAULT_LOADING_CHECK_INTERVAL_BYTES;
	}
	// Keeping the same KiB unit used by ProgressiveMediaSource
	return Integer.parseInt(preferredIntervalBytes) * 1024;
	}