New Issue

Cache Setting #447

Open

opened by Manketnas · 23 comments

Manketnas commented

Often streams are stopping when the connection isnt perfect.

I'd like to have a constantly audio experience.

A larger cache which could be configured over settings page, could solve this problem.

Settings Page with description of pro an cons.
Slider or manual value field with a great cache range

Often streams are stopping when the connection isnt perfect. I'd like to have a constantly audio experience. A larger cache which could be configured over settings page, could solve this problem. Settings Page with description of pro an cons. Slider or manual value field with a great cache range

Manketnas added the

enhancement

label

y20k self-assigned this

y20k commented

Owner

I will look into this.

Maybe you can help testing a solution?

I will look into this. Maybe you can help testing a solution?

Manketnas commented

Poster

Thank you much, yes I make myself available for testing.

y20k referenced this issue from a commit

Added a "Use Larger Buffer" setting (see #447)

y20k commented

Owner

I implemented a simple toggle "Use Larger Buffer = ON/OFF" (see screenshot).

When activated the default values for the DefaultLoadControl are simply doubled. The default values are:

DEFAULT_MIN_BUFFER_MS = 50000
DEFAULT_MAX_BUFFER_MS = 50000
DEFAULT_BUFFER_FOR_PLAYBACK_MS = 2500
DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS = 5000

I compiled a test version of Transistor, that includes the new setting. It is based on the code up to this commit: 2c3cb206a0

You can download a signed test APK here:

transistor-app-testing-4.1.4-001.apk

Note: Currently the test version will only apply a change in buffer size if the playback has been stopped before the change has been made. I would suggest to always stop playback before changing this setting.

This test version is signed with my key and not with F-Droid's. An install has the side effect that all app data is deleted. YOU NEED TO BACK UP YOUR RADIO STATIONS before installing the test version.

Lastly. If this is too much of a hassle for you, don't worry. I will test the new setting myself during my next train commute on Monday, where I have stream interruptions from time to time.

I implemented a simple toggle "Use Larger Buffer = ON/OFF" (see screenshot). When activated the default values for the [DefaultLoadControl](https://developer.android.com/reference/androidx/media3/exoplayer/DefaultLoadControl) are simply doubled. The default values are: - [DEFAULT_MIN_BUFFER_MS](https://developer.android.com/reference/androidx/media3/exoplayer/DefaultLoadControl#DEFAULT_MIN_BUFFER_MS()) = 50000 - [DEFAULT_MAX_BUFFER_MS](https://developer.android.com/reference/androidx/media3/exoplayer/DefaultLoadControl#DEFAULT_MAX_BUFFER_MS()) = 50000 - [DEFAULT_BUFFER_FOR_PLAYBACK_MS](https://developer.android.com/reference/androidx/media3/exoplayer/DefaultLoadControl#DEFAULT_BUFFER_FOR_PLAYBACK_MS()) = 2500 - [DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS](https://developer.android.com/reference/androidx/media3/exoplayer/DefaultLoadControl#DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS()) = 5000 I compiled a test version of Transistor, that includes the new setting. It is based on the code up to this commit: https://codeberg.org/y20k/transistor/commit/2c3cb206a02eff165b720bcb6f460546f0368f06 You can download a signed test APK here: - [transistor-app-testing-4.1.4-001.apk](https://drive.google.com/file/d/1TALWzMp8DR9giIoOfB2ukXtL_MUYxDZf/view?usp=sharing) Note: Currently the test version will only apply a change in buffer size if the playback has been stopped before the change has been made. I would suggest to always stop playback before changing this setting. This test version is signed with my key and not with F-Droid's. An install has the side effect that all app data is deleted. YOU NEED TO BACK UP YOUR RADIO STATIONS before installing the test version. Lastly. If this is too much of a hassle for you, don't worry. I will test the new setting myself during my next train commute on Monday, where I have stream interruptions from time to time.

use-large-buffer-setting.png

92 KiB

Manketnas commented

Poster

May some additional tweaks are needed, i'm not an expert.
I dont know the method how gaps of the missing stream are getting corrected. Buffer is perhaps just one part, a smooth stream maybe more complex.

But I like your design of the toggle setting etc.

Wow thanks for the quick implementation, yes I need to test it a for while to reach a conclusion. I think a train is also a good place for testing, in my case rather my car. At home location the house connection over LTE and wifi can be also very moody. May some additional tweaks are needed, i'm not an expert. I dont know the method how gaps of the missing stream are getting corrected. Buffer is perhaps just one part, a smooth stream maybe more complex. But I like your design of the toggle setting etc.

serrq commented

5000 are milliseconds?

y20k commented

Owner

Yes, the default values above are milliseconds. With the Large Buffer toggle they get duplicated.

For more info about the specific values you can follow the respective links to the developer documentation.

Yes, the default values above are milliseconds. With the Large Buffer toggle they get duplicated. For more info about the specific values you can follow the respective links to the developer documentation.

Manketnas commented

Poster

Hello, till now the setting did not really help me.
Seems like some streams are more problematic also.

Is is it possible to add 2-3 Minute Cache, yes I know thats crazy but i dont care when I have to wait on first start ?

I have some nasty radio holes in the black forest here also, which needed to be brigded.

Hello, till now the setting did not really help me. Seems like some streams are more problematic also. Is is it possible to add 2-3 Minute Cache, yes I know thats crazy but i dont care when I have to wait on first start ? I have some nasty radio holes in the black forest here also, which needed to be brigded.

serrq commented

I believe 60-90 seconds could be enough. Just an opinion.

y20k commented

Owner

I could provide a test version where the cache setting multiplier is higher. In the last test version the cache settings were doubled. Just for testing we could increase it to 8-times for example.

Manketnas commented

Poster

ok why not. Seems like there are also some other issues, the stream stucks sometimes even with good connection. I dont know if its a device specific problem, but i need to press play to start it again..

y20k commented

Owner

Hi there,

the whole caching/buffering mechanism is a black box for me. I don't know what the media3 playback library does under the hood, and that's probably for the better :-)

But I can try to adjust the caching via the LoadControl API.

private fun createDefaultLoadControl(factor: Int): DefaultLoadControl {
    val builder = DefaultLoadControl.Builder()
    builder.setAllocator(DefaultAllocator(true, C.DEFAULT_BUFFER_SEGMENT_SIZE))
    builder.setBufferDurationsMs(DefaultLoadControl.DEFAULT_MIN_BUFFER_MS * factor,
        DefaultLoadControl.DEFAULT_MAX_BUFFER_MS * factor,
        DefaultLoadControl.DEFAULT_BUFFER_FOR_PLAYBACK_MS * factor,
        DefaultLoadControl.DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS * factor)
    return builder.build()
}

You can download a new signed test APK here:

10x Buffer: transistor-app-testing-4.1.4-002.apk
2x Buffer: transistor-app-testing-4.1.4-001.apk (same as in an earlier post)

Hi there, the whole caching/buffering mechanism is a black box for me. I don't know what the media3 playback library does under the hood, and that's probably for the better :-) But I can try to adjust the caching via the LoadControl API. ```Java private fun createDefaultLoadControl(factor: Int): DefaultLoadControl { val builder = DefaultLoadControl.Builder() builder.setAllocator(DefaultAllocator(true, C.DEFAULT_BUFFER_SEGMENT_SIZE)) builder.setBufferDurationsMs(DefaultLoadControl.DEFAULT_MIN_BUFFER_MS * factor, DefaultLoadControl.DEFAULT_MAX_BUFFER_MS * factor, DefaultLoadControl.DEFAULT_BUFFER_FOR_PLAYBACK_MS * factor, DefaultLoadControl.DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS * factor) return builder.build() } ``` You can download a new signed test APK here: - 10x Buffer: [transistor-app-testing-4.1.4-002.apk](https://drive.google.com/file/d/13rt_MgClhmfhGJTVhHEIXwMxdGReqVKT/view?usp=sharing) - 2x Buffer: [transistor-app-testing-4.1.4-001.apk](https://drive.google.com/file/d/1TALWzMp8DR9giIoOfB2ukXtL_MUYxDZf/view?usp=sharing) (same as in an earlier post)

Manketnas commented

Poster

Thank you for the new build may this site could help you
https://exoplayer.dev/customization.html

Didnt expect that a radio player could be this complicated...

10x Buffer seems to work, caches more than 20Seconds ! But its not reconnecting after closing wifi connection and its not possible to start the stream again when wifi is back.
Couldnt test mobile network so far...

Thank you for the new build may this site could help you https://exoplayer.dev/customization.html Didnt expect that a radio player could be this complicated... 10x Buffer seems to work, caches more than 20Seconds ! But its not reconnecting after closing wifi connection and its not possible to start the stream again when wifi is back. Couldnt test mobile network so far...

serrq commented

20 sec cache is cool. I also would like an automatic wifi reconnecting as it comes back.
Is it possible add this?

20 sec cache is cool. I also would like an automatic wifi reconnecting as it comes back. Is it possible add this?

y20k commented

Owner

Hi there,

let's discuss the automatic re-connection in #446. It seems like a desirable feature. 👍

For this ticket here I would like to know, if the new Large Cache Option does help anyone in real life usage scenarios. If so I will include it in the next release. If not - the fewer settings the better -, I will probably not include it.

Hi there, let's discuss the automatic re-connection in #446. It seems like a desirable feature. 👍 For this ticket here I would like to know, if the new **Large Cache Option** does help anyone in real life usage scenarios. If so I will include it in the next release. If not - the fewer settings the better -, I will probably not include it.

y20k commented

Owner

Today I published v4.1.4, which does not yet include the Large Cache Option - but a new re-connection method (see #446).

To be able to continue testing the caching I created a new test APK - current cache multiplier, when activated is: 8x
*

transistor-app-testing-4.1.5-001.apk

Cheers

Today I published v4.1.4, which does not yet include the Large Cache Option - but a new re-connection method (see #446). To be able to continue testing the caching I created a new test APK - current cache multiplier, when activated is: 8x * * [transistor-app-testing-4.1.5-001.apk](https://drive.google.com/file/d/1xip-uAW3fr8wRfpOLs7hTBn19PYPIFd9/view?usp=share_link) Cheers

serrq commented

Testing app: when I choose "Tap anywhere to start radio" might you hyde the play button?

About the playing station just replace the play button with dynamic vertical bars icon (only for currently playing station).

Testing app: when I choose "Tap anywhere to start radio" might you hyde the play button? About the playing station just replace the play button with dynamic vertical bars icon (only for currently playing station).

serrq commented

I would like the large cache option. 💪

It runs properly.

About autoreconnect feature (on lost connection) I am not to able to reproduce the proper case, but I definitely wish it.

I would like the large cache option. 💪 It runs properly. About autoreconnect feature (on lost connection) I am not to able to reproduce the proper case, but I definitely wish it.

y20k commented

Owner

@serrq

It runs properly.

So you experience a real difference between setting on / off with regards to the stability of playback... meaning less / un-interupted playback, when large buffer is selected?

@serrq > It runs properly. So you experience a real difference between setting on / off with regards to the stability of playback... meaning less / un-interupted playback, when large buffer is selected?

serrq commented

Yes, less interruptions, but not always when I change server on my VPN provider Transistor is able to reconnect to station playing automatically. Sometimes it doesn't.

Manketnas commented

Poster

the stream stops automaticly after some minutes, mabye android power Optimization

Manketnas commented

Poster

seems like it still stucks after loosing good connection during driving with car. Also it did not reconnect or was able to play again. Another problem is that during the caching other applications can start a stream, but transistor isnt able to start its own stream when cache has been puffered.

Glacierguy commented

10x cache takes way too long to start the stream.

2x cache seems fine to me for people who need it.

I think most people are losing connection mostly because of Android Power Optimization, which they should disable for Transistor and the app itself should recommend that.

10x cache takes way too long to start the stream. 2x cache seems fine to me for people who need it. I think most people are losing connection mostly because of Android Power Optimization, which they should disable for Transistor and the app itself should recommend that.

logc2073485 commented

The 4.1.5-001 seems like a good buffer size for me. The other buffer iterations are too small for my stream and it restarts a lot w/ the same startup ad over and over, ugh. Yes it takes longer to start the stream but that is an expected trade off.
This version is stable enough for my needs but sometimes a force stop is required when the stream stops and struggles with reconnecting.
Thanks for your time and efforts! Please let me know if I can help test more in the future.

The 4.1.5-001 seems like a good buffer size for me. The other buffer iterations are too small for my stream and it restarts a lot w/ the same startup ad over and over, ugh. Yes it takes longer to start the stream but that is an expected trade off. This version is stable enough for my needs but sometimes a force stop is required when the stream stops and struggles with reconnecting. Thanks for your time and efforts! Please let me know if I can help test more in the future.