Does this software require redis dependency to function? about radio-api HOT 26 CLOSED

from radio-api.

Hi,

the Docker container of Radio-API requires to run another container with redis.

I seems that CONF_REDIS_HOST is empty or 127.0.0.1 in your config, what will be the Docker container running Radio-API itself, but not redis. The value of CONF_REDIS_HOST should be a (possibly local) host name of the redis container.

If you use this Docker compose file, redis will get the hostname redis. Otherwise you may create a network using Docker for both containers and use the hostname/ ip of redis in this network.

from radio-api.

from radio-api.

Hi,

yes, you need two containers and set CONF_REDIS_HOST to the redis hostname.
The example docker-compose.yml will automatically start both required containers. It then should work with the default hostname redis.

Yes, an IP address may be also used, but make sure, that the IP address is reachable by the Radio-API container. (And Docker IP addresses may not be stable after restarts.)

from radio-api.

from radio-api.

Hi,

it now looks better, but still seems a bit fiddly with Redis. I have release a new version v2.8.3 which allows to run Radio-API via Docker but without requiring Redis (falling back to a JSON-based cache, just like the manual install). For huge installations the JSON-based cache may be a bit slow, but with one or two radios, it should work well.

Thus, you now can set CONF_USE_JSON_CACHE=true in the environment-section of docker-compose.yml.
Afterwards, no Redis container is needed any more and Radio-API should run.
And make sure to pull the latest version of kimbtechnologies/radio_api:latest, e.g., by running docker-compose pull.

Yes, the first letter of all tokens (called GUI-Codes is Z). This GUI-codes are shown on the radio's display and are used to identify which radio belongs to a user of the WebGUI.
Thus, when connecting your radio to Radio-API for the first time, you will get a GUI-Code starting with Z to log into the WebGUI.

from radio-api.

from radio-api.

I just tested v2.8.3 enabling CONF_USE_JSON_CACHE=true and removing the REDIS-related env vars (I also stopped my redis instance), but then the radio didn't work.

I didn't debug anything so far, but I stopped the container, added the REDIS-related variables again (but left the CONF_USE_JSON_CACHE=true), started the redis server, and everything works again.

Hopefully I'll have time to play with it tomorrow!
Thanks in any case, I would be happy to stop/remove redis from my server.

from radio-api.

I moved the problem when switching from Redis mode to non-Redis mode to a new issue #51.

from radio-api.

Regarding the token:

The token 3a3f5ac48a1dab4e is a static one and used by the radio to somewhat validate if the server provides the correct API.

You will need to connect your radio to Radio-API once and see a GUI-Code: Z**** on the radio's display. This GUI-Code can than be used to access the webinterface. (In other words, the radio registers on first connect with the server and then one can use the webinterface to manage stations etc. for this radio.)

from radio-api.

Ok good news- finally got this up and going on my synology docker with redis. The issue with the docker-compose.yml file always giving errors turned out to be that I had to declare the data paths. - ./data/:/php-code/data/ will not work and always gives errors, but - /volume1/docker/sangean/data/:/php-code/data/ installs just fine. The synlogy pro that helped me said to change - "8080:80" to this - 8080:80 as well but regardless it is up now with zero errors!

Now I could use some help getting the radio connected. I gave it a static IP changed the dns to my docker server 192.168.11.49 but left the gateway at 192.168.11.1.

I then installed radio.dns and set radio_ip to 192.168.11.49 and set upstream like this : - SERVER_UPSTREAM=192.168.11.1

I then ran it and tried connecting the radio but noticed it connects to wifi fine but can't see the internet nor does it offer me the code/token.

I noticed you did not expose port 53 and figured that needed to be done but no change. Do my settings look ok?

Thank you.

results if I querry radio.dns:

wifiradiofrontier.com
Server: UnKnown
Address: 192.168.11.49

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for wifiradiofrontier.com

from radio-api.

Is 192.168.11.49 (also) a DNS server?
From your description, that IP is your Synology/Docker server, but you didn't say if it also runs DNS.
Whatever/however you do it, you need your radio to use a DNS server which can provide a "fake" record for "*.wifiradiofrontier.com" so that it returns the address of your Docker server (192.168.11.49).

from radio-api.

Hi,
if I understand it correctly, you use my Radio-DNS Docker container (https://github.com/KIMB-technologies/Radio-DNS-Server/blob/master/docker-compose.yml).

This Docker container uses network_mode: host and thus you do not need to expose a port, as the network of the container is shared with the network of the Synology host itself.

However, you may not set SERVER_UPSTREAM to a local IP. This IP needs to be the IP of an DNS resolver, the default uses Google DNS at 8.8.8.8, which should work well.

Thus, the full configuration should look for example like this:

- SERVER_BIND=0.0.0.0
- SERVER_PORT=53
- SERVER_UPSTREAM=8.8.8.8
- RADIO_IP=192.168.11.49
- ALLOWED_DOMAIN=all
- TIME_SERVER=ntp0.fau.de

Afterwards, your radio should be able to connect.

If not, please send the response from Radio-DNS for „hama.wifiradiofrontier.com“, e.g., this response may be generated by dig hama.wifiradiofrontier.com @192.168.11.49.

from radio-api.

from radio-api.

from radio-api.

Hi,
the DNS responses look good and the requests in the log also.

Thus, I assume Radio-DNS works well and the problem is something between the radio and Radio-API.
Do you see requests of the radio in the logs of Radio-API? If yes, we are sure that the radio requests the right server.

Does the radio show some type of error message?

What is the response of curl "http://192.168.11.49/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: sangean.wifiradiofrontier.com", it should be <EncryptedToken>3a3f5ac48a1dab4e</EncryptedToken>.

Does curl "http://192.168.11.49/setupapp/iden/asp/BrowseXML/loginXML.asp?gofile=&mac=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&dlang=eng&fver=4&ven=iden00" -H "Host: sangean.wifiradiofrontier.com" show something like <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ListOfItems> ... </ListOfItems>, including <Title>GUI-Code: ...</Title>?

from radio-api.

from radio-api.

Hi,
the logs are very helpful and Radio-API seems to run fine.
However, the radio always requests port 80 to access the API. Thus, you should change the port in the docker-compose.yml (or some reverse proxy). (This port configuration in the example was a bit inaccurate, but I just updated it.)

You do not need to do a hard reset.

from radio-api.

from radio-api.

Hi,

this should get Radio-API running, maybe this issue (and the discussion there) might help you: #34 (comment)
It is also about using a Synology NAS and its Reverse Proxy.)

from radio-api.

from radio-api.

Hi,
it seems as you did an huge step towards getting it working.
The Web GUI should look like https://github.com/KIMB-technologies/Radio-API/blob/master/screenshots/Readme.md.

If the streams play in the browser and not in the radio, I would assume some problems with https streams (enable the proxy via Web GUI) or issues with CONF_DOMAIN and CONF_RADIO_DOMAIN.

from radio-api.

from radio-api.

Hi,

the Web GUI just provides a preview of radio stations, podcast, ... – you can test it there in the browser/ on the computer, but it will not start the radio nor select a station in the radio.

If BBC plays, then the tricky part is done :)

from radio-api.

from radio-api.

Hi,
I am happy that it works now!
Yes, Synology seems to be a bit fiddly, I always use a Linux VM/ Server.

Radio-API was started as project for my personal radio. First it was not planned to publish it, but now I am happy that it is used by others!

from radio-api.