Unresponsiveness with long songs

[danrpinho]

Description

When playing long songs, such as radios or playlists (which usually run about an hour long), the bot suddenly stops playing audio and stops responding to commands.

Expected vs. Observed

-	-
Expected	The song plays until the end, and users can input commands.
Observed	The audio playback stops (around the 30-minute mark) and the bot does not respond to commands.

Repro Steps

1. !play a long video (for example, this one)
2. Listen until the video ends
3. Attempt to add commands later in the video's runtime

Environment

Key	Value
Operating System	Ubuntu 21.10 impish
Kernel	x86_64 Linux 5.13.0-23-generic
CPU	Intel Core i5-6500 @ 4x 3,6GHz [22.0°C]
RAM	7866MiB / 15893MiB

[afonsojramos]

I can confirm that this happens as well. I haven't had many occasions where I listened to long videos, however, everytime that I have, it has stalled at some point.

Ps: I think this is unrelated to the Windows bug that we've discovered the other day @aquelemiguel @joao-conde

[aquelemiguel]

Thank you for the bug report, @danrpinho.

It just might, @afonsojramos, they seem too similar... 99.99% chance it's unrelated to our code however, given v0.2.0 is also failing now. Should most likely be some funky dependency on both issues. I'm still investigating this.

[afonsojramos]

The thing is that your case @aquelemiguel does not fail on Linux, and this one does. If it IS the same problem, it is much worse on Windows vs Linux.

[aquelemiguel]

It's the same issue, no? Only that on Windows it freezes after a minute or so and on Linux it's half an hour.

[rafaeldamasceno]

This issue is, sadly, a regression. 51a9937 is a good commit (and possibly the last, if you say v0.2.0 is now failing).

[joao-conde]

@rafaeldamasceno thanks for testing it <3 So you mean that commit works fine for you? Let us all test and double-check that. If that is confirmed, would that mean 2b7f635 to e1c0249 are the culprit? Let's test that as well.

[aquelemiguel]

This issue is, sadly, a regression. 51a9937 is a good commit (and possibly the last, if you say v0.2.0 is now failing).

God's work, @rafaeldamasceno. 💖

@joao-conde I can also confirm 51a9937 is working on Windows and failing on 2b7f635 meaning that it was the transition from youtube-dl to yt-dlp. In order to get yt-dlp, we're getting the latest version of Songbird from their current branch:

# Cargo.toml
git = "https://github.com/serenity-rs/songbird"
branch = "current"
features = ["builtin-queue", "yt-dlp"]

[rafaeldamasceno]

@rafaeldamasceno thanks for testing it <3 So you mean that commit works fine for you?

Yeah, the commit I mentioned works fine. This is the same machine/environment as reported by @danrpinho. I simply checked out that commit (since it was the last before the youtube-dl change), built parrot, restarted the service and have been listening to long songs for some time with no issue. When the current track is over, I can try e1c0249 again to see if the issue was already present there on Linux.

Also youtube-dl and yt-dlp versions might be relevant.

[joao-conde]

I believe this might be related to songbird and the latest version. To use yt-dlp we need to use songbird's current branch which likely has a bug. But if we revert to youtube-dl we won't be able to use !seek

[aquelemiguel]

Guys over at Serenity's Discord seem to have repro'd it.

[joao-conde]

Seems to be this will be an easy fix 😄 Let us wait for a Serenity patch release and see. Preferably we should stop depending on the current branch, so if they do make a release with the fix, we should swap to the version.

[afonsojramos]

Waiting it out it is then 🤓 Awesome, thanks for contacting them directly @aquelemiguel!

[aquelemiguel]

No fucking way, I think I got it.