Question and not issue
stoneubi opened this issue · 7 comments
After a while I was able to get this wonderful setup to fly. My issue was a wrong setting in pihole to reroute the needed website. Solved it with this link:
https://medium.com/@containeroo/using-pi-hole-to-route-your-services-internally-2ff495093718
I do have a Hama IR 100 and the radio connected to my local provided server.
Question: the radio takes long to operate. This means that resolving the tuner list or loading a radio station takes long (about 30 second).
Does any one else realize this issue? Are there any tipps to speed up the system. Are there any puffer setting are something similar?
My setting is: proxmox server with Ubuntu lxc container, docker and portainer. The service is not published to the internet. The gui address is a local address.
Thank you
stoneubi
Hi,
the Radio-API does not have any buffers. And I do not know any settings of the radio regarding this.
- Did you set
ALLOWED_DOMAIN=all, otherwise the DNS queries might slow down the system a bit (but not 30 secs). - How fast is the web gui and the preview there? Does it show similar issues? (And if yes, are there any insights given when looking into the developer tools of the browser?)
- I do not have experience with pi hole.
- Loading an external stream through the proxy or end url normally takes some more seconds, as multiple requests are done by Radio-API, but less than 30 sec.
Thank you for your quick response. Yes, I allowed all domains and the gui is very fast as expected. There are no issues with the gui. Loading the external stream also takes some time via the original frontier service. The loading time once the radio station is selected takes same time as with your radio api.
Anyhow, I will try to find out whats going on here.
Can I please ask one more question reading nextcloud. At the gui during the process of adding radio station there is a tick box called nextcloud. I do have my own nextcloud. What is this tick box good for at radio stations? How can I integrate nextcloud in this setup? I saw the hint for nextcloud at your documentation for podcasts,
Thank you very much for your effort of creating this api as frontier is changing the service and I'm a friend of open source and hosting my own services :-)
One more thing I realized. If you turn on the radio and select one radio station the radio will not be able to re-connect after a start from standby again. Having the original frontier service enabled, the radio will connect to the last selected station automatically after a start from standby.
The interesting thing is that press the button preset on my Hama IR 100 and select exactly the same radio station the radio back can connect without any problems.
Is there any setting for timeout? I saw one at the docker yml.
Thank you.
If the web gui runs fast I assume that the loading times are not directly caused by Radio-API.
The preview in the gui does the same requests as the radio.
However it might/ will be something which occurs using Radio-API along with the radio.
It would be interesting to know what causes this long loading times.
The idea of nextcloud is similar for podcasts and radio stations.
A podcast assumes that the shared folder in the nextcloud contains audio files where each file is one episode.
Thus, it is possible to choose and play each file on its own.
A radio station assumes that the shared folder in the nextcloud contains audio files, too.
However, it is assumed that the files are shorter and shall be played one after another.
Thus, one might place a bunch of music files in a folder and add this folder to Radio-API as radio station.
When playing this radio station all files are played one after another.
The audio files are shuffled randomly if CONF_SHUFFLE_MUSIC=true.
When I start my radio it sometimes directly starts the last running audio stream and sometimes it has the same problems you describe.
However, in all cases the station starts normally after I select it again. (Also if I use the favorites stored in the radio itself.)
Thus, I do not know what happens there, but I thought the same would happen with the Silicone Frontier API, too.
The setting CONF_CACHE_EXPIRE is only used with the Redis cache.
The episodes of podcasts, items in a nexcloud share, etc. are stored for this amount of time. After this timeout, Radio-API fetches the values from the nextcloud or RSS url again. (This should not affect the overall list of station and podcasts and has the same effect to the web gui.)
Yesterday I re-created both docker containers and the docker image was re-pulled and now the speed is perfect. There are no more connection lags to the server.
One thing was interesting. After the re-creation I switched on the radio and the gui code changed and I had to create all radio station by scratch.
Anyhow, this project is super great. Thank you so much. Please consider a donation possibility.
Happy to hear that it became fast now.
It sounds a bit like a filesystem issue. The radio stations, podcasts, and gui codes are stored in json files in the folder ./data/. Is there a file table.json, radio_1.json and podcast_1.json in your ./data/ folder?
I just released version 2.4 which improves the json handling a bit, but if your setup works, version 2.4 will not make any difference.
I will close this issue as the question seem resolved.
Yes, the files are available. I just re-pulled the latest version 2.4 and after the update all stations are available. Really good project. Thank you. Everything works perfect not 👍😃