Metadata on DJ connect is incorrectly cached

[alexhorner]

Using Docker installation method

Yes

Host Operating System

Ubuntu 18.04.4 LTS

Describe the bug

When a DJ connects to the radio after AutoDJ, there appears to be a chance the metadata of the last DJ is displayed for a few seconds, even if that DJ was on several hours ago

To Reproduce

1. Connect, play out a few songs, disconnect
2. Wait for AutoDJ to play a few songs
3. Connect, play out some more songs

Expected behavior

The new metadata should immediately take the place of Now Playing metadata, and if no meta is available yet, Azura should hold the meta of the last played AutoDJ song so that a random song isn't displayed

Relevant Logs

LiquidSoap does not display the random song:

2020/04/24 06:57:13 [stationname_next_song:3] Prepared "/var/azuracast/stations/stationname/media/High Priority/harry_styles_-_watermelon_sugar.mp3" (RID 10).
2020/04/24 06:57:13 [lang:3] AzuraCast Feedback Response: OK
2020/04/24 06:59:27 [lang:3] AzuraCast Raw Response: annotate:title="Circles",artist="Post Malone",duration="215.",song_id="b42b2ed29fd45ad023fc3f0473bfe850",media_id="27":/var/azuracast/stations/stationname/media/High Priority/post_malone_-_circles.mp3
2020/04/24 06:59:27 [decoder:3] Method "MAD" accepted "/var/azuracast/stations/stationname/media/High Priority/post_malone_-_circles.mp3".
2020/04/24 06:59:58 [lang:3] Authenticating DJ: DJNAME
2020/04/24 06:59:58 [lang:3] AzuraCast DJ Auth Response: true
2020/04/24 06:59:58 [decoder:3] Method "MAD" accepted "audio/mpeg".
2020/04/24 06:59:58 [lang:3] DJ Source connected! Last authenticated DJ: DJNAME- [("icy-name", "Station Name"), ("icy-genre", "Various"), ("icy-url", "http://www.stationname.com"), ("icy-irc", "#audiorealm"), ("icy-icq", "NA"), ("icy-aim", "NA"), ("icy-pub", "1"), ("icy-br", "320"), ("content-type", "audio/mpeg")]
2020/04/24 06:59:58 [server:3] New client: 172.19.0.6.
2020/04/24 06:59:58 [server:3] Client 172.19.0.6 disconnected.
2020/04/24 06:59:58 [lang:3] AzuraCast Live Connected Response: recording
2020/04/24 06:59:58 [stationname_input_streamer:3] Decoding...
2020/04/24 07:00:03 [stationname_live_fallback:3] Switch to audio_to_stereo_7752 with transition.
2020/04/24 07:00:07 [lang:3] Authenticating DJ: DJNAME
2020/04/24 07:00:07 [lang:3] AzuraCast DJ Auth Response: true
2020/04/24 07:00:07 [stationname_input_streamer:3] New metadata chunk ? -- Modern Baseball - Your Graduation.
2020/04/24 07:02:48 [lang:3] Authenticating DJ: DJNAME
2020/04/24 07:02:48 [lang:3] AzuraCast DJ Auth Response: true
2020/04/24 07:02:48 [stationname_input_streamer:3] New metadata chunk ? -- Basement - Covet.

Screenshots

This shows an AutoDJ song, a random song, then two songs the DJ actually played which are shown in the LS log

This shows a DJ several hours earlier playing out two songs before dropping to AutoDJ, with their last song being the random song which was displayed

[BusterNeece]

@alexhorner This has actually already been reported here on GitHub, but I don't remember what its description was. I'll have to find it later.

Basically, the proposed solution, disabling replay_metadata on the live-specific fallback, seems to be exactly how to handle this situation. I've applied that change, which should help avoid this issue.

[CodeSteele]

Found it, duplicate of #1968 as per the known fix.

[gammaw]

@SlvrEagle23 not sure if it's an issue for you that reply_metada is now disabled for the entire radio source not only for live. We have a custom LS config (based on yours) and the option fixes our problem for live but introduces a new problem for regular playlists: tracks that are interrupted by a scheduled playlist or by a live DJ will not be displayed correctly when they return. My plan was to disable metadata replay only for the live source but no idea if it's possible (see https://github.com/savonet/liquidsoap/issues/1096).

[BusterNeece]

@gammaw Hmmm...honestly not sure how to just disable it for the live side, since the fallback is the only function that has that parameter as far as I know.

[gammaw]

@SlvrEagle23 input.harbor has it too (the one used to define the live source) but with replay_metadata=false by default. And switch too. So probably if live is used in a subsequent switch or fallback, the replay metadata setting will apply to it too (as an override). That's my guess at least, and this is what I see when we try it.

[ChandigarIT]

Similar problem, during live stream, I have the META for the previous track showing...