Summary
When pointing YTuner at a self-hosted radiobrowser-api-rust mirror (instead of the public all.api.radio-browser.info pool) via the ytuner.ini server setting, YTuner only retrieves 1000 stations, even though the mirror's database contains the full ~60,000 station dataset.
Root cause
radiobrowser-api-rust has a config option api-default-limit (default: 1000) that applies whenever a request is made without an explicit limit query parameter. My self-hosted instance confirmed this:
curl -s "http://<my-server>:8089/json/stations" | grep -o '"stationuuid"' | wc -l
1000
After raising api-default-limit to 100000 in my server's config and restarting, the same query returned the full station count (~59,600).
It looks like YTuner's request(s) to build/refresh its local rb.db don't pass an explicit &limit=... parameter, so they silently fall back to whatever default limit the target server enforces. Against the official public API this apparently isn't noticeable (possibly because the public servers use a much higher default, or a different endpoint/pagination strategy), but against a self-hosted mirror with default settings it caps the import at 1000 entries — with no error or warning in the YTuner log, just an incomplete database.
(I did find a related mention in Discussion #157 — a user noted they "accidentally had the number of radio-browser stations set to 1000," which caused long startup times — so this limit behavior may already be partially known, but I couldn't find it documented as something YTuner itself should account for when talking to a mirror.)
Suggested fix
Would it be feasible for YTuner to always pass an explicit &limit= parameter (matching whatever "number of stations" setting YTuner already has internally, or a suitably high value) when fetching from the configured radio-browser server? That way behavior would be consistent and predictable across both the public pool and self-hosted mirrors, regardless of that server's own api-default-limit setting.
Alternatively/additionally: a note in the README about self-hosting a mirror (there's already good guidance for using rb.db as a fallback when the API is unreachable) mentioning that api-default-limit / api-max-limit should be raised on the server side could save others some debugging time.
Environment
- YTuner version: v1.2.6 (also relevant likely for v2.0.0 dev branch)
- radiobrowser-api-rust:
registry.gitlab.com/radiobrowser/radiobrowser-api-rust:latest, software_version 0.7.44, self-hosted via Docker
- Confirmed working after manually raising
api-default-limit = 100000 on the server side
Happy to provide more logs/details if useful. Thanks for the great project! 🙏
Summary
When pointing YTuner at a self-hosted
radiobrowser-api-rustmirror (instead of the publicall.api.radio-browser.infopool) via theytuner.iniserver setting, YTuner only retrieves 1000 stations, even though the mirror's database contains the full ~60,000 station dataset.Root cause
radiobrowser-api-rusthas a config optionapi-default-limit(default:1000) that applies whenever a request is made without an explicitlimitquery parameter. My self-hosted instance confirmed this:After raising
api-default-limitto100000in my server's config and restarting, the same query returned the full station count (~59,600).It looks like YTuner's request(s) to build/refresh its local
rb.dbdon't pass an explicit&limit=...parameter, so they silently fall back to whatever default limit the target server enforces. Against the official public API this apparently isn't noticeable (possibly because the public servers use a much higher default, or a different endpoint/pagination strategy), but against a self-hosted mirror with default settings it caps the import at 1000 entries — with no error or warning in the YTuner log, just an incomplete database.(I did find a related mention in Discussion #157 — a user noted they "accidentally had the number of radio-browser stations set to 1000," which caused long startup times — so this limit behavior may already be partially known, but I couldn't find it documented as something YTuner itself should account for when talking to a mirror.)
Suggested fix
Would it be feasible for YTuner to always pass an explicit
&limit=parameter (matching whatever "number of stations" setting YTuner already has internally, or a suitably high value) when fetching from the configured radio-browser server? That way behavior would be consistent and predictable across both the public pool and self-hosted mirrors, regardless of that server's ownapi-default-limitsetting.Alternatively/additionally: a note in the README about self-hosting a mirror (there's already good guidance for using
rb.dbas a fallback when the API is unreachable) mentioning thatapi-default-limit/api-max-limitshould be raised on the server side could save others some debugging time.Environment
registry.gitlab.com/radiobrowser/radiobrowser-api-rust:latest, software_version 0.7.44, self-hosted via Dockerapi-default-limit = 100000on the server sideHappy to provide more logs/details if useful. Thanks for the great project! 🙏