Prefer the lower level socket timeout feature, to the hand made threaded
timeout. The thread timeout does not raise or log the errors that may occur
during the communication with liquidsoap, and we should handle them
instead.
Tracks are not fading with the crossfade function which leads to hard cuts at the end of tracks and shows. Therefore the explicit fade functions are used.
In Liquidsoap version 1.4.3. crossfade is implemented as a cross with a custom transition (fade_in and fade_out).
9f730f2c5f/src/libs/fades.liq (L433-L436)
The "duration" argument is passed through to the cross function.
In the implementation of the cross operator the value duration is used to determine how log the crossfade should take.
It is set to the cross_lenght parameter
f075905715/src/operators/cross.ml (L30-L34)
This can be overwritten with metadata, but the current annotation does not include a "override_duration" field so in our case it is always 0.
f075905715/src/operators/cross.ml (L186-L198)
So I assume the crossfade is starting to fade.out the track but because the duration is set to 0. the "cross" is completed immediately and the next source of the queue is started. Our queues do only ever contain one track at a time so there is no next source to play.
The next queue is activated and the same happens for the fade.in.
Replacing the crossfade with a fade.in/out removes this time boundary as there is no longer a "cross" function involved.
Until the tag 3.0.0-alpha.8 there was a custom crossfade_airtime function.
In tag 3.0.0-alpha.9 it was replaced with the crossfade function but was unable to find why.
ecd302068c/python_apps/pypo/liquidsoap/1.4/ls_script.liq (LL76C9-L76C18)
Co-authored-by: Marvin <Marvin>
jo
renovate[bot]
Jonas L
Marvin