No retry if the randomly picked server all.api.radio-browser.info fails.

[rorso]

Response to "radio-browser.info" query contains "no entries", if the server picked by the round-robin query (all.api.radio-browser.info) fails.
The recommended procedure noted by "radio-browser.info" is "if one server fails, try the next one".

However the error is translated into a "no entries" reply without retry.

This is especially bad, if the device caches the result and simply does not requery as it already knows that there are "no entries" as my Grundig SonoClock 890A-Web does.

"vtuner" is once again down and the replacement is broken too :-(

Manually setting a specific server might help out but asks for troubles if THAT one fails tomorrow.

[coffeegreg]

You can change to a specific radio-browser.info server using the YTuner project.
The case you describe is interesting. I need to implement the ability to dynamically change radio-browser.info server in YTuner because it is true as you write "if one server fails, try the next one". 🤔

[TheBossME]

a few days ago i also notice issues with the all... api
I do switch to the at1 server.

Issue looked like on de1 server, my feeling is overload. We should inform the servers owner for checking. I dropped an email to Alex Segler.

Regards
Beatrice

[rorso]

It was the nl1 server yesterday. I did call the service provider and it was fixed shortly thereafter. The service seems to be essentially the work of a single person. Dedicated, friendly, but as a service prone to hiccups any now and then if it does not get broader coverage.

Let's see, if I can help the project gaining momentum.

[coffeegreg]

YTuner will soon have the functionality of full caching of radio-browser resources, so problems with temporary unavailability of radio-browser.info servers will be irrelevant.

[TheBossME]

was issue analyzed deeper ?.

[rorso]

@coffeegreg Are you sure? The project seems not to be quite active. The last change was 4 years ago.
I'm not convinced that my tries to get the "Grundig Sonoclock" supported will somehow end up here.

That's what forks are meant for, but I lack the capabilities to verify my changes against other devices.

[coffeegreg]

@rorso I mentioned the YTuner project. YTuner is NOT a YCast fork.
Your observations and comments in this issue, but also in this one #137 , seem very helpful and I will take them into account in the further development of YTuner. In the meantime, I work on full resource caching of the radio-browser.info in addition to YTuner's current caching capabilities.
Projects such as YCast and YTuner are quite unusual because I will never test some of the implemented solutions at home because I do not own all possible devices that have built-in vtuner support. Only thanks to the community and posts with problem descriptions can such projects continue to develop. That's why I'm looking for additional information wherever I can. Also here...