Also fix up attributes and countrycode mapping as outlined in migration suggestions at https://api.radio-browser.info/
Co-authored-by: Thomas Endt <thomas.endt@uipath.com>
Co-authored-by: Jonathan Rawle <git@jonathanrawle.co.uk>
Station tracking depends on redirects which some AVRs don't do in a discernible manner.
We enable this again when we found out what makes redirects work for the affected models.
We now get the playable station URL directly from the Radiobrowser API.
This fixes the issue with playlists in the 'url' attribute.
Does not work if played station tracking would be disabled.
It _could_ work but we would need to create an additional API request for every single listed station, even the ones not enqueued for playing.
This would then be way slower and put extra strain on the Radiobrowser API.
Station icons now get converted to a JPEG with a maxmimum dimension of 290 on icon request.
Although we need to implement caching and aspect ratio keeping, this should fix issues with incompatible station icons and HTTPS icon URLs.
Adds a new package dependency: Pillow
Some AVRs do not allow an ID larger than 15 characters. Thanks to Marc for pointing that out.
Use a MD5 hash (128), XOR fold it (64) and cut it to size (48). This way we _should_ still have enough uniqueness and can generate a checksum which fits the limits.
Some AVRs fetch the station info by calling statxml.asp with the station ID parameter.
It seems like they expect a single station element in a vTuner compatible page.
This should not be confused with the streamurl acquisition proxying implemented in 7c3161aff9.
Generate IDs by hashing the station name and URL.
These IDs should be sufficiently unique.
We _may_ run into performance issues with a very large definition, but it should be fine for a sane amount of custom stations.
Revisit once we implement a custom station database.
Every stream URL is may now be fetched from the YCast server via redirection.
This allows for future integration of a "recently played" functionality and an availability check.
All 'setupapp' calls are handled independently.
Allows for easier distinction between hardcoded vTuner URLs and our
own API calls.
Also may prevent client crashes because of an invalid response with a
landing page.
At least Denon AVRs don't require the API to return a 'Search' element
but use a hardcoded path for the search function.
Also, don't add a distinct menu item. Most AVRs don't display it
correctly either way.
This greatly improves loading times and takes some load off the APIs.
* Add generic directory class to also hold item count
* Radiobrowser: Get station count directly from API
* Optionally show broken stations and their count
* Remove minimum station bitrate to not filter away some listings
* Improve code wording
* Log API requests
To work around the issue that a few AVRs blindly append parameters
with an ampersand.
This also allows us to get rid of the search logic workaround.
Furthermore the vTuner API also hacks around the issue this way.
So this seems like the correct way to handle that even if it looks ugly.