-
-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repeat Metadata Entry when Smart Crossfade uses Default Action #2153
Comments
Hi! Thanks for reporting. I have made some correction on the Also worth noting that the current |
Sorry for the delay, been off on vacation with limited connectivity. Besides, should one really be working on GitHub projects on vacation? Depends on the vacation, I suppose. I think i saw you mention to someone else that main is too volatile for debugging purposes. With that in mind I went back to 2.0.0 a few weeks ago. Now I've gone to the 2.0.3-preview for troubleshooting this problem. The problem is now... different. It looks like when the smart crossfade does a default transition, the metadata list gets a double-entry of the song that's finishing and the song that's starting never makes the list at all.
The actual list of songs was The Rock (crossed) Self Destruction (default) Speedster (crossed) Smash. Self Destruction made the list twice, Speedster doesn't appear at all.
Hope this helps provide new clues. |
Looking things over later, I have more information. Before a default transition, the currently playing song shows up in the metadata list when it plays (as it should). Then after the transition it shows up again, rather than the next (now current) song. I think before in 2.0.0 this same thing was happening only the current song was then being immediately put into the list after the second entry of the previous song. Also, this affects the metadata push (ICY-INFO?) so that the player shows the wrong (previous) song information after a default transition. This may have always been the case but because the current song was pushed to the list after the re-push of the previous song, it was pushed out over the stream as well and the player did show the currently playing song. Therefore it wasn't immediately apparent that something weird was going on. |
Well, hopefully I'm not wearing out my welcome on this thread but I keep finding more little things that may or may not help with finding the fix... figure it can't hurt to write it up. I've noticed that the smart crossfade default action (that's causing this metadata mishap) is cutting off the start of the "next" song. Almost as if it was trying to overlap/crossfade them but the audio isn't switching over to the next song until the previous one is finished. Basically the ending song plays to completion and the next song stars a few seconds into the song already. What I noticed tonight is that while the current song is not getting added to the metadata list or being pushed out on the stream, the "request.on_air" socket command returns the proper RID which can then be used in "request.metadata" to get the current song's metadata. So the system is aware of what song is playing and the metadata for it can be fetched. There's just a fumble going on in the metadata push to the stream and it being added to the "<stream>.metadata" listing. |
You're never wearing out a welcome when adding relevant feedback! Testing this rn. |
… sure crossfade transition sources do no re-send old source metadata. Fixes: #2153
I just had a review of the code. We do re-insert the ending track's metadata when computing the crossfade transition. This is because the fade operators rely on metadata to adjust their duration and etc. This, indeed, leads to metadata appearing twice in the same track and I can understand how this can create confusion. I've just pushed some changes that de-duplicate metadata coming out of the crossfade. This could generate change in existing behavior but I'm suspecting the de-duplicated source is the expected behavior for most people. I added an option to disable it in the crossfade, if needed. |
Finally got around to loading up 2.0.4-preview and checking this out. I don't know if you get notifications on closed issues, but I'll put this here anyway. Also I have a possible clue or lead at the very end, feel free to skip there directly. So the duplicate metadata is gone now, but the "slot" that the repeat metadata was in is blanked out, which leaves a hole in the list. I.E.:
The output from radio.metadata is:
So slot 5 was the repeated metadata and is now empty. But my parsing code uses that number header to create the array index. It creates index 5 but then has nothing to put in it. I could skip it, but then the usual list of the last 10 songs would only have 9 songs in it. Maybe this is taking up way too much time for a cosmetic/accounting item. I kinda feel like it is, or that I'm being picky. Maybe I'll just never be happy. :P There is one thing I thought of though: this only happens with the default transition and not any of the crossfades. And all the crossfades use add(), but the default is sequence(). So is there something in sequence() that would repeat metadata that isn't in add()? |
Found a workaround that works pretty well, it's outlined in Discussion #2339. |
Describe the bug
I recently started tinkering with .php scripting to pull information from LiquidSoap and display it on a page. My first page is using the "<stream>.metadata" command to get metadata from the previous 10 songs. This has led me to notice that when using the smart crossfade function, if the smart crossfade falls through all its decisions and uses the "default" behavior, a song's metadata will be repeated in the "<stream>.metadata" listing.
The metadata shows up as expected when the song begins playback, but will added to the list again when the "default" transition is made, just before the metadata for the next song is added:
In this case, the transition from "Escape from Na Pali" to "Night Mover" was the smart crossfade default:
Any other transition in the smart crossfade does not cause this behavior, nor does it appear if the crossfader is not used. I played a 2+ hour list of songs with no crossfades and the recent metadata list behaved exactly as expected.
To the best of my knowledge this bug is strictly cosmetic, so doesn't have to be a high priority if there are bigger bugs to squash.
To Reproduce
Something super-simple that involves the smart crossfade would probably be adequate for testing:
Then keep an eye on the "stream.metadata" listing in the telnet/Unix socket interface and look for repeats when the crossfade uses the "default" transition.
Expected behavior
When the smart crossfade punts and falls through to the default behavior, song metadata should not be added again to the list of recent metadata for a stream.
Version details
Debian Linux - Buster
Liquidsoap 2.1.0 (but originally seen in 2.0.0)
Install method
Downloaded Debian Package directly from GitHub Actions and installed manually
The text was updated successfully, but these errors were encountered: