Skip to content

YTuner only fetches 1000 stations from self-hosted radiobrowser-api-rust mirror (server's api-default-limit is silently applied) #187

Description

@TheBossME

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! 🙏

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions