### Description
Not all forward auth solutions use a comma for group seperator.
**This is a new feature**:
Yes
**I have updated the documentation to reflect these changes**:
Yes
### **Links**
[Authentik uses `|` so may as well make the group separator
configurable](https://docs.goauthentik.io/docs/add-secure-apps/providers/proxy/)
Mutagen may fail with:
```
worker-1 | Traceback (most recent call last):
worker-1 | File "/usr/local/lib/python3.10/site-packages/celery/app/trace.py", line 412, in trace_task
worker-1 | R = retval = fun(*args, **kwargs)
worker-1 | File "/usr/local/lib/python3.10/site-packages/celery/app/trace.py", line 704, in __protected_call__
worker-1 | return self.run(*args, **kwargs)
worker-1 | File "/src/libretime_worker/tasks.py", line 114, in podcast_download
worker-1 | metadata["artist"] = podcast_name
worker-1 | File "/usr/local/lib/python3.10/site-packages/mutagen/_file.py", line 74, in __setitem__
worker-1 | self.tags[key] = value
worker-1 | File "/usr/local/lib/python3.10/site-packages/mutagen/id3/_tags.py", line 341, in __setitem__
worker-1 | raise TypeError("%r not a Frame instance" % tag)
worker-1 | TypeError: "Infos du soir" not a Frame instance
```
This TypeError was raised when I trying to write metadata to a wave
file.
This patch ensures that the error is reported back to the frontend. It
also improve the error messages being reported.
### Description
Allow fine grained configuration on which release the test should be
run. This will be useful to start testing liquidsoap >=2.0.0 in our ci.
### Description
The playout exchange was changed to `fanout` without migrating the
previous `direct` exchange. This cause issues during upgrades, such as:
```
amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'type' for exchange 'airtime-pypo' in vhost '/libretime': received 'fanout' but current is 'direct'
```
This is documented upstream in
https://www.rabbitmq.com/docs/queues#property-equivalence
This change provides an upgrade path by renaming the exchange, and leave
the old exchange behind. Loosing messages is not a concern for the
playout queue.
### Testing Notes
- Checkout version `4.4.0`
- Run `make dev`
- Checkout 9e55d3bb6f2fa0f9a4dc858359a99e9d50c826a4
- Run `make dev`
- See the exception in playout: `docker compose logs -f playout`
- Checkout this PR
- Run `make dev`
- See playout fine working.
### **Links**
https://github.com/libretime/libretime/pull/3161
### Description
When liquidsoap starts, it sends an API request to the legacy API which
triggers a rabbitmq message to the playout service to update the
liquidsoap queues and make sure they are correct. The removed line is
not necessary and will cause issues if there is more than one liquidsoap
service. It is not necessary because the playout service automatically
prunes the queue and will add/remove only what is necessary and does not
require the whole queue to be cleared. If the whole queue is cleared and
there are multiple liquid soap services, every LQ service will go silent
and then fade to normal volume in the middle of playout. Removing this
line has no logical effect as all the work it does is immediately redone
and removal fixes the re-cue-in issue when you have multiple liquidsoap
services all running playout.
So, this line in the best of cases is useless and does nothing, and in
the worst of cases causes playout issues, hence its removal.
**This is a new feature**:
No
**I have updated the documentation to reflect these changes**:
Bug fix
### Testing Notes
**What I did:**
I setup multiple playout/liquidsoap service pairs, and heard that when
one is restarted all of them go quiet and fade in from their current
play cursor. I then made the change and verified that only the restarted
service faded in.
**How you can replicate my testing:**
See above section
### **Links**
Related to #3161 and #3162
### Description
Remove the liquidsoap connection lock to remove any chance to run into a
deadlock. With this change, the client is not thread safe anymore.
Also handle connection error exception when talking to liquidsoap, e.g.
when liquidsoap is restarted and closes the telnet connection.
**This is a new feature**:
No
**I have updated the documentation to reflect these changes**:
Not relevant.
### Testing Notes
- Restart liquidsoap while playout is talking to it.
- See the connection being dropped and playout that might run into a
deadlock.
### Description
The `source_disconnect` method in the liquidsoap client was still using
the old names of the 2 harbor input (currently named input_main and
input_show).
Remove the `source_disconnect` method, in favor of the
`source_switch_status` method, to have a single source name mapping
between playout and liquidsoap.
This is a missing update from a refactor made a while ago:
2f9f60e639f13854094abb0f43730aebc9c89cee
### **Links**
Potential fix for https://github.com/libretime/libretime/issues/2796
### Description
If the title or artist metadata in libretime has a newline, that file is
not played as telnet takes the newline as a command enter in the middle
of the command.
**This is a new feature**:
No
**I have updated the documentation to reflect these changes**:
No
### Testing Notes
**What I did:**
I spun up a fresh local LibreTime instance, uploaded a track with a
newline in the creator field. I then created a show and added the track
to the show and verified that the track did not play with error:
```
playout-1 | 2025-06-06 17:41:49,888 | ERROR | libretime_playout.liquidsoap.client._client:_set_var:50 - ERROR: unknown command, type "help" to get a list of commands.
```
I then added my fix and verified that the track did play as it was
supposed to.
**How you can replicate my testing:**
See the above section
---------
Co-authored-by: jo <ljonas@riseup.net>
### Description
Currently, only one service can listen to libretime schedule change
events. This change allows for as many services as desired to listen for
schedule change events.
**This is a new feature**:
Yes
**I have updated the documentation to reflect these changes**:
No, as this seems like the obvious default
### Testing Notes
**What I did:**
I created 2 playout blocks, connected them both to the fanout queue and
saw that they could all connect and receive schedule change events at
the same time.
**How you can replicate my testing:**
See testing notes
### Description
- Removes the need to download the nginx config file during the install,
- Can be overridden by mounting your own config file.
**This is a new feature**:
Reduce the amount of steps and files to install LibreTime using
docker-compose.
**I have updated the documentation to reflect these changes**:
Yes
### Testing Notes
**What I did:**
Do not mount the `./docker/nginx.conf` file in
`docker-compose.override.yml` and run:
```
make dev
```
### **Links**
Related to #3155
### Description
This replaces the volume mount that shared PHP code between the nginx
and legacy containers with a custom nginx image that has the code baked
in from build. I would have preferred to find a solution that did not
require this, but it looks like docker volumes do not support temporary
volumes that only last the lifetime of the container.
**This is a new feature**:
No
**I have updated the documentation to reflect these changes**:
N/A
### Testing Notes
**What I did:**
Tested with docker-compose
**How you can replicate my testing:**
Run the docker-compose setup
### **Links**
Closes: #3150
---------
Co-authored-by: jo <ljonas@riseup.net>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [asottile/pyupgrade](https://redirect.github.com/asottile/pyupgrade) |
repository | patch | `v3.19.0` -> `v3.19.1` |
Note: The `pre-commit` manager in Renovate is not supported by the
`pre-commit` maintainers or community. Please do not report any problems
there, instead [create a Discussion in the Renovate
repository](https://redirect.github.com/renovatebot/renovate/discussions/new)
if you have any questions.
---
### Release Notes
<details>
<summary>asottile/pyupgrade (asottile/pyupgrade)</summary>
###
[`v3.19.1`](https://redirect.github.com/asottile/pyupgrade/compare/v3.19.0...v3.19.1)
[Compare
Source](https://redirect.github.com/asottile/pyupgrade/compare/v3.19.0...v3.19.1)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/libretime/libretime).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yMzguMCIsInVwZGF0ZWRJblZlciI6IjM5LjIzOC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
### Description
When generating a show that contains a playlist with dynamic blocks, the
show will be incorrectly under scheduled because the fade time was added
onto the total track length. Fade should not add time to an overall
track length as then it wouldn't be a fade.
**This is a new feature**:
No
**I have updated the documentation to reflect these changes**:
No, none needed.
### Testing Notes
**What I did:**
I created a playlist with 3 dynamic blocks:
1. 10 minute length dynamic block
2. 1 item dynamic block
3. fill rest of show dynamic block
I then created a show with the defined auto loading playlist. I then saw
that on auto-load the show was not under scheduled.
**How you can replicate my testing:**
See testing notes
Co-authored-by: Kyle Robbertze <paddatrapper@users.noreply.github.com>
### Description
The `now{}` macro for criteria filtering used UTC rather than station
timezone leading to confusing results.
**This is a new feature**:
No
**I have updated the documentation to reflect these changes**:
Yes
### Testing Notes
**What I did:**
I named a track the current date and hour, and used the date macro to
try to select it. It failed, I then implemented this fix and saw that
the track was selected.
**How you can replicate my testing:**
See what I did.
### **Links**
None
### Description
V3 has several breaking changes that need to be addressed
### Testing Notes
**What I did:**
Tested using docusaurus:
```shell
make docs-dev
```
### Description
add Liquidsoap2.0 files
(port syntax 1.4 to 2.0)
### Testing Notes
I ran libretime on ubuntu 22.04 and liquidsoap2.0
this pr is just the beginning, just 2 files added it's a clean one...
in order to work under 22.04,it requires changes in
1. this pr
1. (https://github.com/libretime/libretime/pull/2789)
1. libretime/propel (https://github.com/libretime/propel1/pull/1) or
change legacy /composer.json
``` "type": "vcs",
- "url": "https://github.com/libretime/propel1"
+ "url": "https://github.com/mp3butcher/propel1"
},
{
"type": "vcs",
@@ -30,7 +30,7 @@
"james-heinrich/getid3": "^1.9",
"league/uri": "^6.7",
"libretime/celery-php": "dev-main",
- "libretime/propel1": "dev-main",
+ "mp3butcher/propel1": "main",
"php-amqplib/php-amqplib": "^3.0",
```
4. and few mods in install
``` case "$ID-$VERSION_ID" in
ubuntu-20.04) is_ubuntu=true && distro="focal" ;;
+ ubuntu-22.04) is_ubuntu=true && distro="jammy" ;;
debian-11) is_debian=true && distro="bullseye" ;;
*)
error "could not determine supported distribution '$ID-$VERSION_ID'
@@ -375,8 +376,12 @@ prepare_packages_install() {
if $is_ubuntu; then
install_packages software-properties-common
- add-apt-repository -y ppa:libretime/libretime
+ +if echo $distro | grep -q 'focal'; then
+ add-apt-repository -y ppa:libretime/libretime
+ fi
+ if echo $distro | grep -q 'jammy'; then
+ apt-get install php-cli php-dev php php-fpm php-pear php-yaml php-gd php-bcmath php-curl
+ fi
DEBIAN_FRONTEND=noninteractive apt-get -q update
fi
}
```
It will require testing changes against ubuntu 20.4 and debian,that's
why i think a testing branch can be wise
---------
Co-authored-by: mp3butcher <mp3butcher@gmail.com>
### Description
Improves the way hashlib is called in libretime_playout/player so that
is isn't broken on systems with python < 3.9
The way it is currently called in
site-packages/libretime_playout/player/file.py, in the section where
scheduled files are copied to the cache dir for playout, specifies the
usedforsecurity=False flag as follows:
`hasher = hashlib.md5(usedforsecurity=False)`
hashlib.md5 did not support this flag until Python 3.9. Attempting to
specify the flag directly as an argument to hashlib.md5(), in an older
python environment (such as that in Ubuntu Focal 20.04), is unsafe, and
can cause hashlib.md5() to balk/throw an exception, which results in
file copy operations failing. This then precipitates into playout
problems, as scheduled media is missing from the cache folder.
This PR instead calls using hashlib.new(), and passes the argument to
that, as follows:
`hasher = hashlib.new('md5', usedforsecurity=False)`
This method of calling with the flag argument is safer, because the
constructor will take it or leave it gracefully, regardless of whether
the system has a version of hashlib that supports the `usedforsecurity`
flag. AFAICT, it improves (fixes) function on older systems without
negatively impacting others.
### Testing Notes
**What I did:**
Before applying this patch, we were experiencing occasional but fairly
regular periods of silence when the system was supposed to be playing a
song or track. This behavior was consistent with errors such as the
following being present in the playout log:
```
2025-01-15 14:01:28,331 | INFO | libretime_playout.player.file:copy_file:47 - copying file 19834 to cache /var/lib/libretime/playout/scheduler/19834.mp3
2025-01-15 14:01:28,466 | ERROR | libretime_playout.player.file:copy_file:77 - could not copy file 19834 to /var/lib/libretime/playout/scheduler/19834.mp3: 'usedforsecurity' is an invalid keyword argument for openssl_md5()
Traceback (most recent call last):
File "/opt/libretime/lib/python3.8/site-packages/libretime_playout/player/file.py", line 70, in copy_file
file_event.filesize = self.report_file_size_and_md5_to_api(
File "/opt/libretime/lib/python3.8/site-packages/libretime_playout/player/file.py", line 89, in report_file_size_and_md5_to_api
hasher = hashlib.md5(usedforsecurity=False)
TypeError: 'usedforsecurity' is an invalid keyword argument for openssl_md5()
```
_For more information about the characterization and results of this
problem, see issue #3134_
**Testing on running systems**
After the patch was applied, these errors were no longer seen. I first
tested this on a dev server, and then on a live server, with
approximately 100 distinct tracks of playout occurring over about 24
hours. There were no file copy failures, and no related playout
problems, which was a major and immediate improvement.
**Testing installer, fresh installs**
***Ubuntu 20.04***
I deployed a patch to the installer and installed it on a blank system
running Ubuntu 20.04 and tested it to make sure the fix was applied and
worked.
***Debian 11***
I deployed patch to the installer and installed it on a blank system
running Debian Bullseye (which runs python = 3.9) , and tested it there
to make sure it did not break anything or introduce a regression.
### **Links**
Closes: #3134
### Description
PRs are intended to be squashed to a single commit. Only checking the
last commit gives us the intended state of the repo and ensures that if
the author commits the schema fixes later, the CI passes as expected.
Currently, the CI will fail because the earlier commits still have an
out of date schema.
### Description
Added support for previewing FLAC files in the web interface, provided
in #509 by marmotte32 on Github in the comments for this issue.
I have tested this against a script-installed copy of 4.2.0, and FLAC
preview is working, although auto-play isn't. I haven't tested to
confirm if this behavior matches MP3 and OGG uploads.
**This is a new feature**:
_Do the changes in this PR implement a new feature?_
**I have updated the documentation to reflect these changes**:
No changes needed; this bug is a missing file format in preview, and it
requires no updates to the documentation.
### Testing Notes
**What I did:**
I installed a LibreTime 4.2.0 system using the default installation
script against a fully-updated, brand new Debian 11 system. I logged
into the web interface, uploaded some FLAC files, and attempted to
preview them. They failed to preview.
I then replaced the preview_jplayer.js file with the contents in this PR
and then refreshed the page. I was able to preview the FLAC files and
hear the results in my local browser audio output.
**How you can replicate my testing:**
Perform the same steps above, or replace the same file in the
libretime_legacy_1 docker image to see the same results.
### **Links**
Closes: #509
---------
Co-authored-by: Kyle Robbertze <kyle@paddatrapper.com>
### Description
Upstream has renamed docker-compose to docker compose for all commands
**This is a new feature**:
_Do the changes in this PR implement a new feature?_
**I have updated the documentation to reflect these changes**:
Yes
### Description
The existing implementation for exporting playout logs to a CSV file
incorporates a very simplified CSV format. Some aspects of the complete
[RFC](https://www.rfc-editor.org/rfc/rfc4180) are missing, such as
escaping of quotes, and quoting of fields that contain certain
characters. This is problematic for common office spreadsheet tools, and
practically, anything else. Many radio stations rely on this
functionality to work well for exporting playout data, for example, in
order to compile data for reporting requirements.
**This is a new feature**:
The changes in this PR add quoting of fields containing a comma, as well
as those containing a CR/LF. It also escapes quotes by doubling them.
I'm not sure it makes CSVexport.js completely RFC 4180 compliant, but it
is much closer than it was.
**I have updated the documentation to reflect these changes**:
I don't think there are any documentation changes necessary; this is
probably expected behavior for anyone trying to use the CSV exporter.
### Testing Notes
**What I did:**
To validate this, I did a clean install of Debian, cloned from the
official libretime repo, and applied the code as a patch to the
installer. I then proceeded with the install and then loaded a database
from a running system (so that I had some playout data to test with). I
then performed the playout history export and examined the resulting CSV
file and after seeing previously problematic fields properly quoted, was
convinced it looked the way I expected. I loaded the csv file into
Libreoffice Calc and did not see any errors.
**How you can replicate my testing:**
See "What I did" above, basically run the patch after cloning the
installer from the repo. You could also apply the changes to a running
system by applying the patch to the file:
/usr/share/libretime/legacy/public/js/libs/CSVexport.js
Be sure to clear your browser cache and do a hard reload of the web
interface, before re-testing.
### **Links**
Closes: #2477
### Description
This is a way of ensuring the schema is up to date with every change.
This should be extended by fixing the PR api schema pipeline to squash
down all PR commits into a single change and checking the API schema for
that. Otherwise people will fix the schema after a failed pipeline and
the pipeline will continue to fail
### Description
Added filters for genre and md5 to the files API, e.g.
`/api/v2/files?genre=soul`
**This is a new feature**: Yes
**I have updated the documentation to reflect these changes**: No
There should be a schema and docs that are generated automatically. I
don't know where that is.
### Testing Notes
**What I did:**
- Used docker to deploy locally
- Confirmed filters work at
http://localhost:8080/api/v2/files?genre=Soul
**How you can replicate my testing:**
- `make clean dev`
- Upload some files!
- Visit http://localhost:8080/api/v2/files
- You can use the filters
<img width="658" alt="Screenshot 2024-12-23 at 01 36 01"
src="https://github.com/user-attachments/assets/ba19f7f3-fb3e-495d-8937-d451c70d326c"
/>
<img width="652" alt="Screenshot 2024-12-23 at 01 35 56"
src="https://github.com/user-attachments/assets/c7191131-a963-463a-b52f-9d0952192555"
/>
_How can the reviewer validate this PR?_
- See above
- wrote tests to confirm filters work
### Description
This fixes various problems in legacy migrations that were preventing a
successful database migration from Airtime 2.5.1. Previously, following
[the
procedure](https://libretime.org/docs/admin-manual/install/migrate-from-airtime/)
using the migrations provided in the Libretime 4.2.0 installer, without
the fixes in this PR, would either fail completely, or cause all of the
imported data to be completely deleted.
_migrations.py
If schema_version is not found in the table cc_prefs, it then checks for
system_version to have a value of '2.5.1' (in case this is an airtime
2.5.1 migration which will not have any schema_version in cc_pref). If
found, it prevents loading of the schema file, which is critical to
preserving the imported Airtime data.
0006_2_5_5
Removed a redundant addition of the image_path and description columns
to cc_show (done in earlier migration 003_2_5_2)
0015_2_5_17
Fixed a syntax error with adding the artwork column to cc_files
0023_3_0_0_alpha_9_1
Removed a redundant addition of the artwork column to cc_files (done in
earlier migration 0015_2_5_7)
### Documentation Changes
The [airtime migration
documentation](https://libretime.org/docs/admin-manual/install/migrate-from-airtime/)
already suggests a procedure to be followed, it just didn't work because
of problems within these migrations. The procedure as documented should
now work for those coming from Airtime 2.5.1.
### Testing Notes
**What I did:**
I attempted to migrate an actual airtime 2.5.1 database from a
production system containing a large amount of shows, tracks, and users.
I observed that the migration completed without errors, and that the
expected system state was achieved within Libretime. Specifically, the
calendar, library, authentication, and other aspects are populated with
the data that was present in the migrated Airtime database, and
Libretime is able to function using this data.
**How you can replicate my testing:**
Install Libretime 4.2.0. Restore a sample postrgresql database backup
from an Airtime 2.5.1 server. Apply the database migration. Restart the
services. Login and view the library, calender, etc.
### **Links**
Closes: #3121
May also be related to, or even close (as a duplicate): #2563
