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

[FEAT] WebradioDB compatibility as another open alternative server like Radio-Browser.info #261

Open
goliv04053 opened this issue Nov 26, 2024 · 1 comment
Labels
postponed A feature request that will be implementd in the future

Comments

@goliv04053
Copy link

Is your feature request related to a problem? Please describe.
This feature request is made because Radio Browser doesn't allow user editing radios information much easy to fix when it's wrong or without complete informations.

Describe the solution you'd like
Adding WedradioDB as another option to Radio Browser.

Describe alternatives you've considered
I considered using closed-source radio directory services apps, which limit flexibility and there is ads and those standard problems related to closed-source apps.

I also considered manually compiling radio links and using a media player like VLC, which is very time-consuming.

Additional context
His project and repo
https://github.com/jcorporation/webradiodb
https://jcorporation.github.io/webradiodb/

@s-n-g
Copy link
Collaborator

s-n-g commented Nov 26, 2024

Hi @goliv04053

This is very interesting!

I did have a look at the project, but...

  1. It does not have an API: "At the moment there is no api endpoint to query the database. An application should fetch the metadata json file and use it locally."

    Assuming that the "metadata json file" is docs/db/index/webradios.min.json, I have loaded it using python and it contains 661 entries. RadioBrowser provides a list of more than 52 thousand stations.
  2. All images are of webp format, which cannot be used by the notification system (as far as I know).

    I know this is not a deal breaker, but it is a disadvantage.

The fact that there is no API, and the limited number of stations provided, makes me be reluctant to even consider adopting the project.

I will leave the issue open and keep an eye on the project, see how it evolves and we'll see

@s-n-g s-n-g added the postponed A feature request that will be implementd in the future label Nov 26, 2024
@s-n-g s-n-g pinned this issue Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
postponed A feature request that will be implementd in the future
Projects
None yet
Development

No branches or pull requests

2 participants