Closed Skarlett closed 1 year ago
After given some thought, I believe the prime suspect of this problem is the underlying process is being closed before its competition. When I have an opportunity, I'll make sure to add logging capabilities for stderr on ffmpeg & deemix-stream. I'll post my findings shortly after.
will switch to next
branch
Solution was to stick cat
in-between the process chain.
source process was timing out the connection. cat
acts as a container buffer.
Songbird version: 0.3.2
Rust version (
rustc -V
):1.69Serenity/Twilight version: 0.11
Description: https://github.com/Skarlett/coggie-bot/blob/7e36f7accd124a5286f191be8c42b7fda939ca48/crates/mockingbird/src/deemix.rs After producing my own
Restartable
based off ofytdl
, I've been occasionally (~2h intervals) experiencing partial playtime with unexpectedly endings to song. For example, a song may play for 1 minute, while its duration is 3 minutes.Digging through the logs, yields the following.
Some other circumstances to know of is that the process creating the mp3 stream is slightly CPU aggressive due to it decrypting the stream on the fly.
I do not believe this to attributed to your library, but If you have a few moments to look over the following and give advice would be appreciated greatly.
Edit: Deprecated logs.
While experimenting, I was able to isolate a log from songbird. the Logs presented above seem to have no relation as they're not spawned on the event.
New Logs
Transaction between two songs + known bug
full transaction log with known errors https://gist.github.com/Skarlett/c054d949dac152fe82d70cb2386efb96
The bug only seems to appear when multiple items are queued to play.
Prime suspect causes so far.
the bug is reproducible using ytdl, though still unsure of the cause.
some ideas are:
Steps to reproduce: I haven't not yet found a viable method for reproduction.