LS 2.3.x - Cue/Fade/Amplify values overwritten when Autocue is enabled

[RM-FM]

Installation Method

Docker Installation

AzuraCast Release Channel

Rolling Release Channel

Current AzuraCast Version

dev-ls2.3.x branch #9b14532

What happened?

When Autocue is enabled, the Amplify/Cue/Fade values are automatically saved to the corresponding Azuracast media items, even overwriting existing values partially. Is this automatic saving intentional? If so, could a toggle be added to enable or disable this feature? Obvisouly, existing values should never be overwritten.

Storing the Amplify/Cue/Fade values in Azuracast definitely makes sense for performance reasons, but there should be an option to disable it if desired.

I could imagine that at least part of the issue is related to the changes in the liq_ metadata fields in LS 2.3.x.

Amplify: Amplification is being overwritten on each autocue run Custom Fading: Start Next remains empty

Custom Fading: Fade-In Time populated on 1st autocue run Custom Fading: Fade-Out Time populated on 1st autocue run Custom Cues: Cue-In Point populated on 1st autocue run Custom Cues: Cue-Out Point populated on 1st autocue run

Relevant log output

No response

[RM-FM]

@BusterNeece It appears that liq_ meta tags are already stored in the Azuracast database with the current Rolling Release, not just in the dev-ls2.3.x branch. Is that correct? I noticed this because of brief periods of dead air after some jingles. Upon checking the annotations, I found that the liq_fade_in_delay tag is already present in the annotate response string with a value of e.g. 3.6.

I might be mistaken, and this may not be the cause of the issue, but I'm still surprised that Azuracast stores these values at all. Is that intentional, and is there a way to disable it?

2024/09/03 20:08:12 [lang:3] API nextsong - Response (200): autocue:annotate:title="Dropin 04",artist="RadioMonster.FM",duration="14.76",song_id="a61199df15d23c3f9a2ad1b52491c2af",media_id="13474",liq_amplify="-7 dB",liq_amplify_adjustment="0.00 dB",liq_autocue="cue_file",liq_blank_skipped="false",liq_blankskip="0.00",liq_cross_duration="0.10",liq_cross_start_next="4.20",liq_cue_duration="4.30",liq_cue_in="0.00",liq_cue_out="4.30",liq_fade_in="0.00",liq_fade_in_delay="3.60",liq_fade_out="0.10",liq_fade_out_delay="0.00",liq_longtail="false",liq_loudness="-6.13 LUFS",liq_loudness_range="21.15 LU",liq_reference_loudness="-16.00 LUFS",liq_sustained_ending="true",liq_true_peak="1.11",liq_true_peak_db="0.92 dBFS",replaygain_reference_loudness="-16.00 LUFS",replaygain_track_gain="-9.87 dB",playlist_id="22",jingle_mode="true":media:radiomonster.fm_-_dropin_04.mp3

[BusterNeece]

@RM-FM Yeah...with 2.2.x the AutoCue and Liquidsoap annotations were basically glomped into a single collection all starting with liq_, and so we cache everything prefixed with that so that we can preserve Autocue data between requests to improve performance.

We're working on re-evaluating that in 2.3.x. There are differing takes on how to approach this, but the Liquidsoap team and I are on the same page with intending to no longer store liq_ annotations inside AzuraCast at all (as they're often internal and prone to changing) and exclusively storing AutoCue data in a structured/prefixed manner.

[RM-FM]

I assume that the issues reported with truncated jingles are likely related to a similar problem caused by inconsistent liq_ values after some of the cues/fades were manually changed.

[RM-FM]

@RM-FM Yeah...with 2.2.x the AutoCue and Liquidsoap annotations were basically glomped into a single collection all starting with liq_, and so we cache everything prefixed with that so that we can preserve Autocue data between requests to improve performance.

@BusterNeece is there a way to disable that in the current Rolling Release and remove the already stored liq_ tags? I believe this is negatively affecting some of the transitions.

[RM-FM]

@BusterNeece Thank you for working on that in dev-ls2.3.x branch. It seems that there is still an issue wirh bulk media import. I‘ve tried to remove the cue/fade values with bulk import, but it didn‘t work.

[RM-FM]

@BusterNeece It‘s not possible to remove the cue/fade/amplify values using media meta bulk import - at least not all of them. Would be great if you could have a look at it…

[BusterNeece]

@RM-FM That's more what the "Clear Extra Metadata" bulk action is for in the media editor...the Bulk Media Editor only additively merges with existing records for extra metadata, to avoid people accidentally wiping out all their extra metadata during a bulk import.