You were correct.
there are some circular references within the data which are bit frustrating, but other than that i think the data is pretty good for building the UI blocks dynamically, which propably have been one key point when designing the data structure that the endpoint returns.
Indeed, Volumioās API is just a bit moreā¦ letās say involved if you are trying to work with it with a strongly typed languageā¦ 
I guess you are in a similar boat if you are using Kotlin?
Yup, i have had basically write custom āmapperā for every single response, to get it look like something that UI can consume, without huge if else clauses or null checkās, oh and to get rid off String references.
[Hotfix needed]
I just realised that i made terrible mistake when taking advantage of new SplashScreen api google provides, when compiling against SDK31, so most likely All users with Android 7.1 or earlier did suffer from startup crash.(Yup, should have tested with emulators on earlier Android versionsā¦will make a memo for myself)
I will provide an Update to address this later today, it will also include.
For now i propably have to back off from releasing the Qobuz/Tidal Go to artist/Album from queue, since i have had no time to implement it in such way i think its good.
[hotfix needed]
It seems that, i have used an attribute for drawables which is not available on earlier android versions, and this was not spotted by static lint tools, neither did my Huawei test device crash for this, but just silently handled it.
Will try to fix this later today, when get from my day job.
Edit: Published an update, should be up soon, hopefully its working for Android 6 now.
Also includes an fix for loading favourite tracks.
Iāve sent in an problem report from my old Sony tablet running Android 6, I updated to 0.85.1 - but it still crashes on fetching music sources.
Iām also testing the app on my Galaxy Tab A7, I have noticed that sometimes the now playing tab stops responding so I canāt pause without restarting the app - but I have now tried to exclude the app from all Samsungās batterysaving functions that can couse some strange behaviour and will keep on using it to see what happens.
I might have found the proplem, i still had an reference for resource which Android 6 for some reason dont want to load, Just wondering why my huawei test device does not seem to care about it, but i can clearly see your device affected from developer console(sadly the crash does not contain stacktrace :/, so i really had no clue where to begin with the fix)
This at first sounds like if there is connection drop out of some sort, it would explain the behaviour. (im still working on reliable reconnection schema). i need to leave my test devices on that screen for night, perhaps i can reproduce it that way.
Either way, i have had it happened myself aswell couple of times, that im unable to control the volumio, and restart was necessary, ill move that issue higher on my todo list.
When the app crashes on Android 6 it is like it crashes twice since the error message pops up twice, would there be any difference if in the information you need if I report from both messages?
It probably wonāt help if you report both, i found couple of soul mates from stackoverflow, who also can see the very same crash on console, and no matter what there is no stacktrace available.(And itās always android 6 device in question)
I think if the version i put as zip on my last post wonāt work, it would be needed that you capture the stacktrace locally with your PC.
I can assist with that of course, but first i need to compile an debug version, so it spills out all the information on the captured log.
Success 
, version 0.85.2-debug works on the Android 6.0.1 version on my Sony Xperia Z3 Tablet Compact (just wished that Sony could release a new modern version of that tablet)
[Update(0.85.2)]
Fixes crash if you have zero Favourite tracks, from local library and or spotify(Had null check, but forgot to check the lenght of list before accessing by indexā¦)
Fixes Drawable recource loading error on Android 6 for real this time.(Thx Wolfman74, for confirming it)
Validates manually inputted IP address before trying to connect, button is disabled until correctly formed IP address is entered.(Fixes a crash if there was whitespace in the address field)
Show number keypad for manually input.(Please report if some Android version does not show DOT as character to input)
Fix for a crash which happened when connecting to an IP address which canāt be reached.
Status update.
Have fixed Bugs on Artist, Albums & Genres, if the random button is clicked without having any items in there, it would lead to an crash. Same for favourites āplay allā action"
For now i will implement Album/Genre/Artist browsing with rest api, because it does allow me to query X amount of content and implement paging, this should allow the app to run on devices with less memory and cpu power smootly even with huge local libraries, and this will benefit everyone at the end.
Initial testing showās good results since Querying with rest api for whole library seems to be up to 70% faster than with websocket. it seems that slower device benefits more from this.
some test runs
22422 Albums ā
Ok, some things Iāve noticed.
The Add to queue function behaves differently to Volumios own webinterface/app. In the app it adds the song to the queue and starts playing the song direct - in the Volumio interface it does not interrupt the current song or starts playing if the queue is empty.
(Above noticed with Qobuz and Spotify, donāt have Tidal any longer)
Another thing is that I have set Playback Mode in Volumio to Single, but the app seems to ignore that setting and adds a whole album/playlist to the queue even if I have only selected one song.
If I do the same thing via the Volumio interface it will only play that song and donāt add the rest of the album/playlist to the queue.
(Qobuz and Spotify)
Good observation, yes currently the app behaves differently to the web UI on some parts and does not follow the āplayback modeā, i am still working on retrieving the actual device settings, so that i could respect those better.
perhaps for now i could āhard codeā the parts of retrieving playback mode and volume control options, to make the app respect those settings, since i believe those are the ones that most want would want to change?
Iāve just tested what you said, and yes there are some obvious bugs/annoyances in the current system, there was supposed to be an option to add single track to queue(long press the track and select add to queue), but it seems that while it adds to queue only the single song, it does also start playing it, which is not intended behaviour by me, it should only add to queue, not play the song.
Thank you very much, for the feedback!
Edit:
Here is version which should correct behaviour for āadd to queueā, when you long press track or anything, and select āAdd to queueā, it only adds that item to queue and playback does not jump in there.
Also fixes the bugs mentioned earlier by me, and implements some parts of navigation with rest api, instead of websocket, which gives HUGE performance improvements on those areas(Albums, Genres and Artists, No paging yet thought)
I dont want to upload this to playstore yet, since i have not tested it too much, and do not know about my spare time this weekend.
Done some quick testing with 0.85.5. Add to queue now behaves as expected, at least in Qobuz - Edit and Spotify.
But the Go to artist function now seems to be broken, it crashes the app.
Edit: On the now playing screen it seems the app has some problem with the scaling on mid size screens like the 8.9 inch screen on my Sony tablet (this is for both 0.85.2 and 0.85.5)
Edit 2: Go to album also crashes the app in Qobuz, did also try that and Go to artist in Spotify - but it does not work there at all.
I would guess that thoose options is the ones that it is important that the app follows, I donāt myself use the volume in the app since Iāve have the mixer type set to none and use an external DAC/Amplifier - but for those with active speakers etc it would be important.
Can it be implemented like itās done in BubbleUPnP where it actually shows the details, and not like Qobuz do in their own app (and also mConnect Player) that only shows an HiRes Audio icon?
Sure, i think i think i actually find it better way myself aswell.
Iāll need to take a look if the bitdepth and samplerate was available everywhere, if i remember correctly that information is not returned by all the API calls to volumio.
After using the app (in this case the 0.85.5 testversion) Iāve started to see some consistency in the behaviour when the app loses connection. If I start playing a couple of songs and the app is on the homepage or queue-page and I leave the device alone so the screen goes to sleep, when I then a while later come back the app will itself reconnect and everything is fine. If I leave the app on the Now Playing page, then when I return it will still show the Now Playing page -but the time played will be out of sync or if it has switched to new song it will still show the previous/first song, and you will then have to back out of the app and restart it. (Also affects the shortcut in the notification menu)
Also noticed that the now playing shortcut on the lockscreen/notification menu sometimes will remain even if you have closed down the app.
Edit: Found another bug in 0.85.5 (works in 0.85.2) - In Qobuz if you go to the discover section and choose playlists by Qobuz it will chrash the app.
Thx for the reports, sorry for radio silence i have been very busy with my day work after the vacation, but i will try to start address the issues asap, aswell as implementing the missing features.
I know how it is - sometimes you could have the need for a clone!
I thought of a small thing (i hope) - since I have the app installed on three devices and sometimes then they are different versions, could the version number be displayed on the system page if you forget what version is installed?
