Support multiple streams per radio #227
Replies: 1 comment 3 replies
-
At first: thanks! I started this project because of the bad data quality of radio-browser.info and to provide a community curated database for myMPD. Changing the data model to provide a 1:n relationship between radio stations and streams could really improve this project, but we need a backward compatible way to not break the myMPD usage of this project. To not break this, we must keep the naming of the m3u files and provide one m3u file per stream. First idea is to add codec and bitrate to the current metadata and use the current stream url as the default stream and naming source. We can now add additional streams with codec and bitrate as metadata to the sources directory. Naming convention could be the default stream name appended by codec and bitrate. To create a compatible index, we add an alternativeStreams key to the json structure and create for each stream a separate m3u file in the publish folder.
|
Beta Was this translation helpful? Give feedback.
-
Hi. First of all, great project/initiative. I am/was a user of radio-browser.info, however due to the impossibility of submitting fixes to the data there the quality is slowly deteriorating. I hope yours will end up being a worthy successor, if not for quantity, then for quality.
I believe that it would benefit if your data model did not consider a stream and a radio to be one and the same. It's quite common for the same radio to have more than one stream, with different codecs and/or bitrate. A 1:N relationship between a radio and its streams would model reality better and also be more convenient in many ways:
Considering the above, I feel that using the (slightly transformed) stream URL as the de-facto radio ID / primary key as it is done now is clever but will lead to some difficulties. For example, "DR P8 Jazz" is originally imported from Moode Audio, but then a better stream is found, and you include that better stream in the database, and now currently this results in a "new" radio and two duplicated entries (in reality different streams to the same radio) when searching. It would be nice if those two were exposed as two different streams for the same radio station. Similarly, if a radio changes its stream URL, from the perspective of the consumer of the data that radio "died" and a new radio exists, instead of the same radio just changing streams.
At the very least, given the current data model, it would be accurate to use the term "radio stream" everywhere and not "radio" or "radio station" in order to prevent any confusion.
I am not claiming that implementing this is trivial (figuring out what the radio identifier should be, detecting duplicate streams of the same radio for the ingestion scripts, coming up with an improved API, etc.). I am just curious to read what are your thoughts about the above. If you believe that a better data model could be a good idea, then I could help with brainstorming/design/implementation (I am a developer myself).
Anyway, keep up the good work!
Beta Was this translation helpful? Give feedback.
All reactions