Skip to content
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

Loops stop working after stopping or playing audio over another #232

Open
AlejandroCabeza opened this issue Mar 4, 2024 · 2 comments
Open
Labels
bug Something isn't working

Comments

@AlejandroCabeza
Copy link

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:

  • ffmpeg version 6.0

Description:
Loops stop working after running stop or playing another audio when one is already being played.
This happens both for LoopState.Infinite, as well as LoopState.Finite(x) for x > 0.

Steps to reproduce:

  1. Instantiate two tracks with LoopState.Infinite. They can be the same file.
  2. Play one of them.
  3. While the previous track is playing, play the other one.
  4. The currently playing track while get overridden by the new one, but the new one will behave as LoopState.Finite(0), not as expected with LoopState.Infinite.
  5. From now on, LoopState.Infinite doesn't work anymore. All tracks played after this will behave as if LoopState.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.

@AlejandroCabeza AlejandroCabeza added the bug Something isn't working label Mar 4, 2024
@FelixMcFelix
Copy link
Member

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.

@AlejandroCabeza
Copy link
Author

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants