Open AlejandroCabeza opened 7 months ago
It sounds as though there may be an ordering mismatch between tracks in the event context and the audio task itself. I don't know when I'll have the time to dig into this, but if you add an event listener (state change, loop, etc.) you should be able to see what the Event side of the house believes your track state is. You can compare this with the output from TrackHandle::get_info
to see who's wrong.
It sounds as though there may be an ordering mismatch between tracks in the event context and the audio task itself. I don't know when I'll have the time to dig into this, but if you add an event listener (state change, loop, etc.) you should be able to see what the Event side of the house believes your track state is. You can compare this with the output from
TrackHandle::get_info
to see who's wrong.
Thanks for the answer. I'll give it a try in the weekend :)
I've had this problem too. I tried having a look at it myself but I'm definitely too green with Rust to figure out what was going on. Only the first song played would loop: any others would not.
Songbird version: 0.4.1
Rust version (
rustc -V
): rustc 1.75.0 (82e1608df 2023-12-21)Serenity version: 0.12.1
Output of
ffmpeg -version
,yt-dlp --version
(if relevant): Not using either of those, but just in case:Description: Loops stop working after running
stop
or playing another audio when one is already being played. This happens both forLoopState.Infinite
, as well asLoopState.Finite(x)
forx > 0
.Steps to reproduce:
LoopState.Infinite
. They can be the same file.LoopState.Finite(0)
, not as expected withLoopState.Infinite
.LoopState.Infinite
doesn't work anymore. All tracks played after this will behave as ifLoopState.Finite(0)
.Additional Information There are many other combinations that come to my mind, but I haven't tried them all. Let me know if I can help debugging this in any way.