Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rorso opened this issue Dec 28, 2023 · 7 comments
Open

Comments

@rorso
Copy link

rorso commented Dec 28, 2023

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
Copy link

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
Copy link

TheBossME commented Dec 29, 2023

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
Copy link
Author

rorso commented Dec 29, 2023

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
Copy link

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
Copy link

was issue analyzed deeper ?.

@rorso
Copy link
Author

rorso commented Jan 3, 2024

@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
Copy link

@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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants