Skip to content

New data endpoint for dynamic liquidsoap config creation - #232

Merged
tuz666 merged 10 commits into
masterfrom
dev/new-schedule-endpoints
Sep 8, 2026
Merged

tuz666 merged 10 commits into
masterfrom
dev/new-schedule-endpoints

Conversation

@tuz666

@tuz666 tuz666 commented Jul 27, 2026 •

Copy link
Copy Markdown
Member

/## Why make changes? State your reason

From programming point of view we're planning to extend our schedule for quite a long time, although the current design is not capable to return different weekly schedules.

As part of this PR my aim is to introduce week parameters for the schedule endpoints with a default value of 1, in order to remain compatible with the current frontend / mobile application implementation.

The schedule change will let us handle biweekly and monthly shows properly, and give us a bunch of time slots for possible new show ideas, but it will impact the usage of our Liquidsoap custom configuration as well, that will be handled in a much more flexible way.

What has changed? Describe your work

The following endpoints were extended with an additional week parameter:

  • /show/all_schedule: used by the frontend
  • /show/schedule: used by the mobile application
  • /show/schedule_by: not used by anyone, just aligned with the other changes

A new data endpoint (/data/weekly_schedule) is also created, it generates the custom Liquidsoap configuration script. The script has two dynamic parts: the playlists' initialization and their scheduling.
The new endpoint is generating this file from the current state of the Arcsi DB. There are 3 template files, one for the initialization, one for the scheduling and another with the static part of the script. The shows are used for templating the first two code snippets and they are inserted into the boilerplate file at the following lines: (initialization and scheduling).
It also has a week parameter but by default it returns the actual week's data.

Added LIQUIDSOAP_VERSION variable into config.template.py, with the help of this the possible future Liquidsoap syntax changes can be tracked.

How to review? Add scenarios or information on the output

The PR is deployed to the dev server, the new and modified endpoints can be easily reviewed there.

Notes. Share the github issue link, source link, or anything else

Another PR is expected to kick-off the multi week migration, there are two possible solution for this:

  1. change Show.week Int field into an array or
  2. combine the Show.week and Show.frequency

Extending schedule endpoints to support week query param
@tuz666 tuz666 added enhancement New feature or request back-end configuration This issue includes settings of the environment labels Aug 3, 2026
@tuz666
tuz666 marked this pull request as ready for review August 3, 2026 15:05
@tuz666
tuz666 requested a review from pvj August 25, 2026 21:03

@pvj pvj left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two questions quickly that I have about the overall picture.

  • What's the reason to have 2 separate tpl's and functions (one for init, and one for the schedule)? Is it because of schedule changes without show addition/removal are lightweight this way?
  • Did you think about creating a Schedule class for the Liquidsoap things? Those global environment.filters are a bit weird. And also I would say, I think the file name should reflect something ore generic like schedule.py and then we can create the LiquidsoapSchedule class or whatever.

@tuz666

tuz666 commented Aug 31, 2026

Copy link
Copy Markdown
Member Author

Thanks for the comments @pvj !

  • What's the reason to have 2 separate tpl's and functions (one for init, and one for the schedule)? Is it because of schedule changes without show addition/removal are lightweight this way?

I thought it would be better to handle them separately, because they have a different purpose.
Although they can be queried via the same API call, but they are separated in the response as well.

  • Did you think about creating a Schedule class for the Liquidsoap things? Those global environment.filters are a bit weird. And also I would say, I think the file name should reflect something ore generic like schedule.py and then we can create the LiquidsoapSchedule class or whatever.

A really good idea, generalization is always welcome!
I haven't used that much OOP in python, so let me know, if anything could be written nicer.

pvj
pvj previously approved these changes Sep 7, 2026

@pvj pvj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API calls look good, code is good too so I think we can move forward with this. Thanks!!

Comment thread arcsi/api/tag.py
Comment thread arcsi/handler/schedule.py
Comment thread arcsi/handler/schedule.py
Comment thread arcsi/api/data.py Outdated
" pm.expect(shows).to.be.an(\"array\")\r",
" shows.forEach(function(show) {\r",
" pm.expect(show).to.be.an(\"object\")\r",
" pm.expect(show.items).to.be.an(\"array\")\r",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for keeping this updated!

Comment on lines +5 to +20
init.daemon.pidfile.path.set("/var/azuracast/stations/lahmacun_radio/config/liquidsoap.pid")

log.stdout.set(true)
log.file.set(false)

settings.server.log.level.set(10)

settings.server.socket.set(true)
settings.server.socket.permissions.set(0o660)
settings.server.socket.path.set("/var/azuracast/stations/lahmacun_radio/config/liquidsoap.sock")

settings.harbor.bind_addrs.set(["0.0.0.0"])

settings.tag.encodings.set(["UTF-8","ISO-8859-1"])
settings.encoder.metadata.export.set(["artist","title","album","song"])

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just thinking out loud, maybe some of these variables could be stored in config so it is easier to change settings.

It is a very minor case nothing serious as we don't really touch them

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would leave this as it is now, but I agree that this should be configurable in the future.

@pvj pvj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job, good addition!

@tuz666
tuz666 merged commit dcc2119 into master Sep 8, 2026
1 check passed

This branch was successfully deployed

1 active deployment
dev — 32ee9790 Deployed Sep 7, 2026 by tuz666 via build (12, 3.14, 24) #615
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

back-end configuration This issue includes settings of the environment enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants