Openopened 4 months ago by Manketnas · 23 comments
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Deleting a branch is permanent. It CANNOT be undone. Continue?
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
I will look into this.
Maybe you can help testing a solution?
Thank you much, yes I make myself available for testing.
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:
I compiled a test version of Transistor, that includes the new setting. It is based on the code up to this commit:
You can download a signed test APK here:
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.
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.
5000 are milliseconds?
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.
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.
I believe 60-90 seconds could be enough. Just an opinion.
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.
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..
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.
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)
Thank you for the new build may this site could help you
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...
20 sec cache is cool. I also would like an automatic wifi reconnecting as it comes back.
Is it possible add this?
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.
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
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).
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.
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?
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.
the stream stops automaticly after some minutes, mabye android power Optimization
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.
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.
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.