MyWebRadios truncating titles … so for example ‘BBC Radio 4’ appears the same as ‘BBC Radio 4 Extra’ etc.
IP connect not connecting to the IP address added correctly. So on ‘Looking for Volumio’s’ screen, if I enter the IP address of a device not shown, I get nothing, or 'can’t find IP address, or it goes to Volumio device it has already found. (Also as a typo, 'Volumio’s" should be “Volumios”)
could do with an easy way of seeing what device you are connected to.
some text on ‘Settings’ screen still in black on the brown/grey (whatever colour it is ;)) background.
persistent devices not so persisted … better than it was, but I still have one that very occasionally shows up (and is not remembered)
Well done Joni for developing so much in a short time,and it’s looking like this might be becoming my go-to app for controlling my several devices.
Need to look at that, thought sadly some limits have to be applied on how long text it can show, or it will show odd when one item haves 6 rows of text, rest have 1 row and there is “alot” of space not used. perhaps i could able scrolling text on some places.
Hmmn, do you add the address in form of “111.111.111.111” or with some extra’s? i believe currently its expecting only the IP without “http” or so.
But there is still the same catch as in the automatic finder, if the device refuses to answer to the rest api call i make for system information, it wont connect to it, because that rest api call is to identify the device as volumio. For a test, can you reboot the offending device if you did not allready. The “persisting” works sameway aswell, it first tests if the device at the saved address answer, only then adds it to the list.
i do have occasions when my lonely volumio wont answer to the rest api call for uknown reason, im still trying to find the cause.
I will add this info on the Work in progress “settings screen” for next playstore release.
As mentioned in the earlier wall of text, it will only persist devices it can get the rest api answer from, and on the next launch it first launches task to go throught the list of persisted IP addresses and makes rest api call’s on those, while simultaneously it will start scanning LAN for new devices.
There might very well be an race condition somewhere, because of multiple workers accessing same internal data structures, in same time even thought i have taken precautions for that.
IP address entered as bare 4 block IP numbers. I’m thinking these problems are arising as a consequence of using the rest api to identify devices. Even if I have two devices shown as detected, and enter an IP address of one of them, then I am not guaranteed to go to that device.
How do these network scanners work that show you everything on your network?
No idea of the internal workings, this scanner is from Google itself. I guess at the lowest level it must ping every ip address in certain subnet? I don’t think there is any other way to identify network devices which are “alive”, the proplem is that google have not implemented mDNS, so the scanner finds all devices, which is why I need to verify with the rest API that the device which was found is volumio.
Okay, that’s really odd that it connects to wrong device if you manually enter the IP address, i assume you verified it by trying playback and it started on wrong device? Somewhat this is a “good news” as it points me looking code somewhere else what i have looked now.
I’m sorry for the proplem, i try to address it as quickly as possible, this might need an debug version on your device thought, so i can write an log to file or so, to really see what’s happening in here.
Perhaps we could try that i lift out the check for device, when IP is manually entered? This way you can try if it does still connect to it?
Unable to run tests today, will do it tomorow.
As Volumio V2.8 decided to mess-up everything and decided to no longer accept the Hifiberry Dac2 Pro after a reboot.
No it does not, device can be configured as such that it won’t response to pings, this is very common option in firewall software, sometimes referred as “stealth mode” since it basically makes that device invisible in the network for other devices.
But even if it did not response to a ping, it should response to the rest API command when IP is manually entered.
I will compile you an version which does not check the device with rest API, when IP is manually entered, and tries to connect to the socket directly with the address, perhaps it’s not an issue to leave it like that for the app, just for the cases like this, it saves the IP address in the text field for future launches aswell, it only did persist it when the device did response to the rest API before, but for now on it will peraist it always.
Sorry to hear that.
Usually it helps to change output to USB and save changes, then reboot and reselect the digiberry, happened to me couple of times.
Okay heres next test release, there is also the speed optimisations for the “Genres” now.
So in total Albums/Artist and Genres does have the better performance now.
The “Settings” view should show the IP address of connected device now
V3. 079, I have 2 pi, installed latest versions, when open the app 2 volumio instances are found but when trying to connect to one of them it crashes, one volumio instances it connects, works ok. When connect from switch page is ok. Only when trying at the beginning… All te time to same vol instances it crashes
Interesting, i believe this might very well be the same underlying issue @chsims1 is having, i really need to get another volumio instance to figure this out, perhaps i can install it on my old laptop tomorrow, there was X86 version of volumio i believe.
Are you on the latest version of the app from playstore? i think it is 0.71 if you look at the app info, or some test version i put here?
Managed to get my lonely pi in state that the app fails to find it after installing V3, now if all stars align and it won’t recover i have good change of debugging the proplem with device not getting picked up by the scanner.
Early debugging shows that it’s in my case Json data expection, this is kind of proplems are expected since kotlin is strongly typed, and does not implement nullable type if i am not explicit about wanting a nullable type. So most likely there is something that volumio device might but null in the answer for the rest API, where my code expects that value not being a null resulting in the device not find.
Soon installing in two spare PC’s to get more insight.
Okay, so i dont think this is completely my apps fault in here, for the part of finding the device. This is very much not the rest api response one would expect.
@volumio@ashthespy is there some known proplem with the restapi getSystemInfo api?
Edit: official volumio android app fails to find the device in this state aswell, i guess you use the same rest API call to identify? And so does sound@home aswell, perhaps it does the very same rest API call at beginning.
E2: Okay got the PC running volumio now, it seems that regardless of empty response for “getSystemInfo” endpoint, if i run “getZones” on the PC volumio, it can identify my pi which fails to respond on the “getSystemInfo”
