Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: There is no easy way to "customize" the liquidsoap parts of LibreTime #229

Open
hairmare opened this issue Jun 12, 2017 · 11 comments
Open

Comments

@hairmare
Copy link
Member

@hairmare hairmare commented Jun 12, 2017

Stations that use LibreTime may want to customize the liquidsoap layer to fit their exact needs. One example of this is replacing the default "silence" output with a fallback solution that can actually prevent dead air. Other use cases are doing some processing on the signal before it is sent to the encoder or updating stream metadata (artist, title, ...) in station specific ways.

As far as I can tell, we first talked about this in #194. #224 (comment) reminded me that it is still a thing.

Proposed Solution

Make it easy to override the relevant parts of the provided liquidsoap scripts. I'm doing something similar in my badly named dabplus-on-air-processing repo. In that one you get to choose the actual processor implementation in config. In that implementation the possible processors need to be hardcoded in in the liquidsoap script. Since airtime-liquidsoap generates a liquidsoap file anyway, doing something similar is more than trivial.

While this isn't the nicest architecture (it's hard to define a clear api since liquidsoap has no namespaces or anything non functional hacker might be used to) it can cover lot's of use cases. I should probably ask the liquidsoap mailing list for a recommendation on how else to solve this properly.

The downside of user changeable liquidsoap might be that it's hard to support (you never know if the error is in liquidsoap or the overrides). For that reason, I think we should implement this as an airtime.conf feature (like FreeIPA support). Power Users will appreciate it, others don't need to know it's there.

@xabispacebiker

This comment has been minimized.

Copy link

@xabispacebiker xabispacebiker commented Jul 12, 2017

+1

@xabispacebiker

This comment has been minimized.

Copy link

@xabispacebiker xabispacebiker commented Jul 12, 2017

Actually this is not hard to implement. I have it done in a production server with airtime 2.5.2. I will try to find some time to adapt it in the latest Libretime version and send a pull request.

@xabispacebiker

This comment has been minimized.

Copy link

@xabispacebiker xabispacebiker commented Jul 17, 2017

Let's discuss about this feature to make it real and usable for everyone. Let me tell you what we did and how we did it in the airtime installation running at https://97irratia.info

At first, we were filling all spaces as offline shows and using Smart playlists to fill in them. This solution had some inconveniences.

CONS:

  1. In case we need to add a one time show, we had to undo the previous created offline show instance, create the new show instance and finally create the empty offline show again. Sometimes the administrator forgot to put the offline content back so we ended up with a silence stream.
  2. The calendar got full of offline shows that made the schedule a bit difficult to read.
  3. In case of one of the broadcasters not filling up its own show with content, the stream would play silence.

PROS:

  1. Admins could change this configuration from the administration, without any programming knowledge and without having to touch any airtime files.
  2. It was still working in case of an airtime update.

Silence in a FM radio station is bad, so bad, therefor, we needed a clean way to change this behavior. When nothing is scheduled we wanted it to go offline and play some content. Besides of that, we wanted to play that content based on the time of the day (noisy track would play only in the afternoon, etc..) , it should insert 2 jingles every 4 songs and every hour it should play the greenwich time signal.

After a lot of trial and error we finally ended up with the solution:
1- From one side we have a cron job that runs every night at 4am and recreates the playlists. This script reads the id3tag mood from the postgresql airtime database (we mark the mood tag with "morning, midday, afternoon, night" tags, ie: if one song should be played only in the morning, we tag it as "morning", in case it should be played any time, we tag it as (morning, midday, afternoon, night, etc..) Then, the script writes 4 playlists: morning (6am-12am), midday (12am-6pm), afternoon(6pm-12am) and night(12am-6am).
2- At first we just did a one row modification in liquidsoap.liq to include our own liq file with all the modifications in order to keep it simple in case of an airtime update, but soon we realized that we need more modifications because when swapping from one source to another it was starting the new stream in the middle of a song (liquidsoap keeps playing in the background)

Again we had some cons and pros with this solution:
CONS:

  1. We had to change the airtime core files, (liquidsoap.liq) in case of any update we had to redo all changes again. "Fortunately" there were not many airtime updates so we didn't have to redo this at all.
  2. We could not use the history stats to know what was played.

PROS:

  1. Only real shows were displayed in the calendar, leaving it more clear and maintainable.
  2. Creating a one time show was easier, we just had to create it without modifying the offline slot instances.
  3. In case of any broadcaster forgot to add content to its show, it would jump to the offline content so we never had silence.

Proposal.
Add a screen where offline content can be scheduled, to keep it simple, we will allow only selecting playlists (as you may know, a playlist can contain smart playlists, tracks, streams, etc..) Time ranged, so that we can specify different daytime ranges. Plus a Checkbox to enable/disable the time signal every hour. Something like the following:

captura de pantalla 2017-07-17 a las 11 55 58

@Robbt

This comment has been minimized.

Copy link
Member

@Robbt Robbt commented Oct 16, 2017

I think that the Offline Streaming feature request should be created as a separate issue because it is a feature in and of itself and we can track it easier if it isn't connected directly to the Liquidsoap hacking. I think it could possibly be implemented without a hack to liquidsoap but that might be the easiest way either way if it is implemented as a feature in and of itself it would no longer be a hack.

@frecuencialibre

This comment has been minimized.

Copy link
Contributor

@frecuencialibre frecuencialibre commented Oct 9, 2018

worth noting here another approach taken by the azuracast project to deal with the dead-air fallback issue: different kinds of playlists, only 1 (!!!) of which is actually scheduled.

screenshot from 2018-10-09 14-10-33

see also https://github.com/AzuraCast/AzuraCast/wiki/Using-Advanced-Playlists

We at frecuencia libre actually need the tight integration with a set schedule, with user access by show, that libretime offers, but figured i'd note this here for reference / inspiration.

@frecuencialibre

This comment has been minimized.

Copy link
Contributor

@frecuencialibre frecuencialibre commented Oct 9, 2018

also on the dead-air topic, it appears that automatic playlists, a similar "fall-back" idea aren't working, correct?

@Robbt

This comment has been minimized.

Copy link
Member

@Robbt Robbt commented Oct 9, 2018

There isn't currently a way to have a playlist designated that fills in for dead air specifically. The automatic playlist will schedule "after" any programming that is already scheduled, so it will add itself to the schedule if there is or isn't anything scheduled. It doesn't specifically detect a failure of liquidsoap though and intercede. It can also underschedule if you dont have the repeat until full option. I have some ideas for how it could be improved though.

@xabispacebiker

This comment has been minimized.

Copy link

@xabispacebiker xabispacebiker commented Oct 19, 2018

I got a new job on a Radio station and want to replace their current obsolete system with Libretime but first It'd need to fullfil some requirements.

One of the requirements is the dead-air functionality and what is also important, let the non-techy users to configure it. I thought of re-creating the Airtime autodj feature as described here https://www.airtime.pro/introducing-rotations-and-auto-dj/, more information here https://sourcefabricberlin.zendesk.com/hc/en-us/articles/208261803. I created a free airtime account to see how it looks. Here are some screenshots.

airtime-auto-dj
airtime-rotation

From January I will start the deployment if I finally can convince them that Libretime is the right tool to replace the current outdated system (ZaraRadio + an old Visual Basic app, we also plan to migrate all operating systems to Linux but this is another story..)

I will create separate issues (and pull requests when ready) with the different requirements

@frecuencialibre

This comment has been minimized.

Copy link
Contributor

@frecuencialibre frecuencialibre commented Oct 20, 2018

@Robbt

This comment has been minimized.

Copy link
Member

@Robbt Robbt commented Oct 20, 2018

Ok, yeah so we probably don't want to emulate their autoDJ functionality as they have not released it as open-source. When I was a customer I found their AutoDJ software to mainly be useful as "filler" but not useful for the type of intentional scheduling that is required by broadcast FM. For instance there was no way to designate play a "station ID" at the top of the hour. But for web stations that just wanted to avoid dead air in case someone tuned in it was OK.

But the basic need for something that can detect unscheduled time remaining on the schedule and stick something in is important.

I guess what we really need to do at this point is figure out how we can all connect to brainstorm on this aside from commenting on the issue queue. I think Ryan suggested a voice chat of some sort. That might be a good way of getting us all on the same page but perhaps we could prepare for this ahead of time by laying out the problem space a little more.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Oct 20, 2019

This issue has been automatically marked as stale because it has not had activity in the last 5 months. It will be closed if no activity occurs in the next month.
Please chat to us on discourse or ask for help on our chat if you have any questions or need further support with getting this issue resolved.
You may also label an issue as pinned if you would like to make sure that it does not get closed by this bot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.