Why have the Stream settings been disabled from the web panel

Dev Talk
1

Hi every one! we are enjoying the stable 3.0.0 so much over here in south America. Thanks a lot for the job done! My respects.
I’m just curious about the reasons that moved the stream settings to the config.yml file only and disabled them from the web panel.

I coudn´t find much info n the web. So I’d be greatful for any comments.
Thanks!

2

Hi,
The main reason is simplicity and scalability.

The complexity of a “database based” configuration is too high for the stream settings use case and would have introduced a lot of dirty hacks to move the project forward.

It didn’t bring much benefit, apart from being editable from the UI. In addition those things shouldn’t change once they are configured.

As a general rule, we strive to keep “services settings” (understand database or rabbitmq settings) in files. I consider stream settings to be “services settings”, as the app cannot run without them.

Some specific reasons why we used the file based stream config:

  • Making it less “dynamic” allow us to support docker based setup.
  • The stream credentials are less prone to be hacked via the old UI.
  • Adding new formats (e.g. HLS) and settings (SSL icecast) will be much simpler.
  • Easier to use the config data across all the different services.
  • Easier to deploy and configure libretime on multiple systems without having to tweak the DB or the UI (e.g. deploying a dev/staging/production environment you only have to change the config file)

I think I missed a lot of benefits from using a simpler setup, but hope this gives you already a good idea why I pushed towards this.

EDIT: And I want to push LibreTime to be more powerful. I pefer to provide good documentation to inexperienced users, instead of making it “easier to install”, and therefor not being able to enhance LibreTime because of the added complexity.

Cheers.
Jo

3

Hi, thanks for the info, and by the way, top-notch job guys! really impressive!

The complexity of a “database based” configuration is too high for the stream settings use case and would have introduced a lot of dirty hacks to move the project forward.
It didn’t bring much benefit, apart from being editable from the UI.

by “database based” you mean inside a real database server and not in a file?

Just to understand, the stream settings used to be saved in the /etc/airtime/liquidsoap.cfg file, and the file was generated by Libretime, right? and now you want to avoid this part.

In addition those things shouldn’t change once they are configured.

Yeah, usually yes, but I also work with radios that like to do some testing with different bit rates and Icecast servers from time to time, and they usually do it by themselves. But sure, is not a big deal.

Some specific reasons why we used the file based stream config:

  • Making it less “dynamic” allow us to support docker based setup.

  • The stream credentials are less prone to be hacked via the old UI.

  • Adding new formats (e.g. HLS) and settings (SSL icecast) will be much simpler.

  • Easier to use the config data across all the different services.

  • Easier to deploy and configure libretime on multiple systems without having to tweak the DB or the UI (e.g. deploying a dev/staging/production environment you only have to change the config file)

Superb! 8)

I think I missed a lot of benefits from using a simpler setup, but hope this gives you already a good idea why I pushed towards this.
EDIT: And I want to push LibreTime to be more powerful. I pefer to provide good documentation to inexperienced users, instead of making it “easier to install”, and therefor not being able to enhance LibreTime because of the added complexity.

sweet, I totally agree, thanks a lot for the clarification!

4

Yes.

Yes, instead of having legacy (php) > rabbitmq > playout > generate a liquidsoap config in /etc > liquidsoap. We simply do config.yml > playout > generate config in a runtime dir > liquisoap. The generated config file that was previously in /etc wasn’t supposed to be edited anyway. (Note that /etc/{air,libre}time previously had to be writable by the libretime user, this isn’t the case anymore)

1 Like