most of the times is breaking in 2 lines a option or scrolling.
clriis
IMO the Android app should only be responsible for the frontend aspect (view / UI) of Volumio. The code for sorting should be done within the music service (backend) itself. Volumio does not have a dedicated Sort button and the workaround is to implement sorting in the form of âfoldersâ.
I appreciate your opinion and agree totally. But what u are suggesting does not work for ALBUM ARTIST/ALBUM/YEAR.
Guess have to wait for Volumio.
MusicBee does it perfectly so sometimes Windows is better
Claus
Has been a while since my last update. Sofar I am pretty impressed with the application.
This app is now my preferred way of interacting with Volumio 2.
I did a quick test with Volumio 3. It sees the device when I tap âswitchâ but tapping on the Volumio 3 device does not seem to connect.
Could you try after you start playback via web UI?
This might be due to some rest API endpoint timing out(= never give any response back), i have had it happened some times aswell, starting playback via web UI did seem to fix it for me in these cases, Iâm investigating whatâs the root cause for it, but since my setup is in car i barely never have laptop with me when it happens so i havenât had a change to debug the app whatâs happening.
Starting playback doesnât make a difference. However if I set the IP and tap connect to IP it works fine.
This is what the system reports for Volumio 3
This is volumio 2
Connecting with IP skips the rest API call(it was actually designed to be like that for similar issue someone had on volumio 2 before), i never got to reproduce it myself.
But Iâm 100% positive itâs issue with volumio OS not responding to rest API call(probably the one which gives system info, need to verify tomorrow), since that is the only possible situation the app wonât proceed to open socket connection, even with empty response the app would proceed, if it was malformed it would just crash at the moment you choose the device from the list.
Iâve used the volumio 3 for sometime now, it should work as good as volumio 2 with the app.(there have been no breaking changes to the API)
Iâm take a look at it tomorrow morning if there is something i can do for it.
E: i donât know, but it might be possible that volumio logs that it gets the rest API call, but then forgets to answer, can you take a log from when it happens?
1 Like
My memory served correct its the system info call that never responds, or not in 10s timeframe anyway.
D/FragmentInitConnection: Known device count -> [KnownVolumio(name=, address=192.168.1.103, id=), KnownVolumio(name=PassatMediaCenterV3, address=http://192.168.1.103, id=7bf0b63e-24a0-4bad-9237-6e0af6db0ef8)......
Address to test for -> 192.168.1.103
Expection in RestCall java.net.SocketTimeoutException: failed to connect to 192.168.1.103 (port 80) from 10.182.69.52 (port 45694) after 10000ms
Ill see if this call can be omitted completely, without much of refactoring since it have been issue before aswell, this seems to be different than the playerstatus end point dying, because of slow or unstable network.
E: this wasnt an issue for me until the latest OTA, well easier to debug now since my PI is acting the same
And the issue it self is here â Volumio2/system.js at master ¡ volumio/Volumio2 ¡ GitHub
Starting from line 35, the method has no fallback, it just assumes it gets the data and if not its like âwell whatever i dont bother to do anythingâ, so yeah ill find a way to get what i need without this rest call, since its doomed to fail occasionally.
E: i think i will start using the zone apis for device verification, this will also help deal with the not so good mDNS on android, since if one volumio is found by scanning the network, it should let me know IPâs of the other devices aswell.
Ill try to get this done today, with various other stability fixes.
1 Like
Update: Today the system switch started working for Volumio 3 (3.192)
Could it be the release on Fri 29th resolved the issue?
Propably it was the system reboot during update which solved it.
Iâve noticed that the âgetsysteminfoâ rest endpoint randomly breaks itself, this have been like this in volumio2 aswell havenât found a reliable way to reproduce it so i havenât reported it anywhere.
And the âgetStateâ(or whatever it was)endpoint breaks itself if the system boots without active internet connection, or if there is network drop.
My app is on some parts relying both of these, so itâs not always so easy to tell wether itâs the app going nuts or if volumio reboot is needed to get the rest endpoints working again.
I still didnât finish the update, but Iâm working on changing parts of the code that does find the device, which should make it faster in some edge cases, and hopefully fix the issue of not being able to connect to a device seen in the list if it does not answer for the rest API call.
Also have been doing some refactoring to better networking error management, as that seems to be #1 cause of all the crashes registering on developer console.
1 Like
Okay small update of the progress.
iâve re-written the part of code which manages allready known volumio devices.(i persist all devices which have been connected to, so full network discovery is not needed on later launches of the app to discover those again)
- should be threadsafe now, and fix âconcurrent modification expectionâ crashes at launch on some lower end devices, which seemed to suffer from this.
Automatic device finder now fallbacks to using the multiroom rest endpoints, if the ones i would prefer are timing out for reason or another, timeout is lowered to 1s(was 10s) which should be more than enought, this should make the discovery process way faster in case one volumio in the network is not answering if it happens to be the first one discovered.
- this should provide faster and better discovery and device verification on app launches, in all cases.
Iâm still going to implement proper error handling for timeouts, in rest of the app before update.
- this should fix 99% of the crashes occuring currently if the tracker provided by play console is not lying about the crash causes.
2 Likes
Great work you are doing here @Joni_Salminen 
Out of curiosity - would you be considering releasing the source of this? If so what license would you use?
Once i have time to clean the underlying library ive written which implements the websocket/rest api interfaces, ill release atleast that portition under MIT license.
Iâve got an pretty clear idea now how i want to implement the network/JSON etc error handling, it just takes some time as i need to do quite huge changes within the codebase to push all the possible exceptions to UI layer in a meaningful way, so that the user can know what went wrong, IE. If itâs bad JSON response or networking timeout.
Iâm hoping this solves most of the crashes with the app in its current state, but since this will affect the codebase on all levels i want to take the time and try to do it in such way i would not be injecting more crash bugs in the app.
Since we have programmers here, i might aswell share how i think its good to do it, anyways this kind of an gives some insight how the upcoming library for the apis, can be consumed.
First thing was obviously to get the data format, this is what all the rest api calls, or websocket datastreams now return, this lets my wrap the exception or parsed data to the same response object, with easy way to consume it.
sealed class ApiResult<out T> {
data class Success<T>(val data : T) : ApiResult<T>()
data class Failure(val exception : Exception) : ApiResult<Nothing>()
}
and to make the data ready for view in viewmodel one could do like below.
volumio.getBrowseSources().collect {
when(it){
is Success -> {
services.value = it.data
}
is Failure -> {
/* TODO, Forward to UI */
Log.d(TAG, it.exception.toString())
}
}
}
So basically here we just collect the âflowâ which the getBrowseSources start emitting once we call it for first time, now if one decides to attach an USB stick or de-attach one, the flow emits new values to subscriper(s) as soon as volumio pushes new event.
I do insert the new data on livedata object âservicesâ which is then databound to the UI/View so its always kept up-to-date without any additional code.(expect for the actual databind code of course, but thatâs 2 lines of xml code, if you were using databinding allready)
So thats basically how the library released later on will work, all the calls will be asynchronous in nature and all results are wrapped in same ApiResult body, only the type of data changing within the âsuccessâ response.
E: besideâs creating new UI state for the error, with possible retry i think it should catch most errors now and allready forward everything to viewmodel state.
Must say now that i use volumio 3 beta, its quite alot faster with the local stuff atleast on my pi4, compared to what volumio 2 was. Only a little over second to open my album collection completely is nice.
2 Likes
Hi,
I received an update today and was hoping to connect to my single Volumio Pi box directly without having to click âConnect to IPâ.
It seems that the app recognises two instances from the same box.
It is a small issue but never the less a bit annoying.
Otherwise Iâm really happy with the excellent work. The app is soooo very fast and stable 
1 Like
thx for reporting, im suffering the same myself currently. I sadly did not notice this before pushing the update 
(Im working on a fix for it)
-
there is also fix for the favourite handling, now it should properly sync with the favourites, after deletions and additions via the app. (before it did not load the new additions before app restart, which then further confused the main UI showing something is not favourite when it indeed was)
-
Memory leak fix and some more fixes not so notable to the user.
-
Also added SVG image support, should now properly load icons which are in svg format.(Youtube plugin main icon was SVG, and i think some radio plugin only used SVG images, and there was something else aswell)
i do also have couple of features/feature remakes coming, but i think ill fix the issues and push update, and those have to wait for the next update then.
Something i have wanted for good while now is going to be fully centralised Favourite handling, So that all favourites would be under the âFavouriteâ section, currently its only tracks from qobuz/tidal/volumio, but i do want to add artistâs, albums and playlistâs in there aswell.(most likely splitted with tabs, to keep it organised).
E: Update to fix mainly the duplicate device discovery is published. should be live shortly.
2 Likes
[Update]
Some more fixes coming soonish.
It seems i have broke the playlist management at some point, will fix that.
Also a QoL change for portrait users incoming, i was supposed to do this months ago, but im using tablet on my daily usage so i kind of forgot about it.
- Same gestures still, Swipe for next/prev and by tapping you open the now playing screen
E: is there some other broken features currently than the playlist management? Crash reports looks promising as there are very few with the 2 latest versions, and none of those are network error related.
5 Likes
Now i have some time for the app again, i have been wondering something and want to ask you guys would you see this beneficial.
Currently the automatic reconnection to volumio helps only cases where the connection is lost for couple seconds etc.(socket tries to reconnect 5 times, 5s between attempts) then you will see the searching screen again and have to manually select a device.
Should there be an option to try reconnect for longer periods of time? IE. When you join the WLAN again which was used to control the volumio device last time.
There are some issues with this thought.
First issue is kind of out of control for me, and it is the manufactor specific power saving options, if tuned too aggressive my backround service is getting killed, and then the feature would obviously not work, this is actually a proplem allready and ive got some feedback about losing ability to control volumio as soon as the app is put on backroundâŚ(https://dontkillmyapp.com/ there is some info on the settings per manufactor)
Second issue is Battery consumption, monitoring the network and maintaining connection is not free, in terms of battery consumption.
1 Like
I only use the app and volumio in the home, so in practice this isnât really an issue for me. Does the widget maintain connection? This seems to lose the ability to show the latest track after a while. Is that part of the same issue? If so, then periodically reconnecting would perhaps help.
I like to use the widget to see what is the currently playing track, as I listen to Radio Paradise most of the day
Yes itâs part of the same issue(+ the widget
Still needs some love), i have a background service running, which is responsible of updating notification, widget, lockscreen etc stuff which needs to happen when the app is not in foreground, if the service gets killed by system or it kills itself because socket have disconnected then no further updates will be processed.
I donât close the option of an bug in the service which might cause this under some condition, but the device/manufactor and android version specific power saving features are all something that will eventually kill the backround service if not properly tweaked by end user.