Hangs with long YouTube videos with yt-dlp

[fee1-dead]

Songbird version: 0.3.0

Rust version (rustc -V): rustc 1.66.0-nightly (4b8f43199 2022-10-19)

Serenity/Twilight version: serenity 0.11.5

Output of ffmpeg -version, yt-dlp --version (if relevant):

$ ffmpeg -version
ffmpeg version 4.4.2 Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 11.3.0 (GCC)
configuration: --disable-static --prefix=/nix/store/hiw4xv105p2si2pwg58d88lr7invvslf-ffmpeg-4.4.2 --arch=x86_64 --target_os=linux --pkg-config=pkg-config --enable-gpl --enable-version3 --enable-shared --enable-pic --enable-libsrt --enable-runtime-cpudetect --enable-hardcoded-tables --enable-pthreads --disable-w32threads --disable-os2threads --enable-network --enable-pixelutils --enable-ffmpeg --disable-ffplay --enable-ffprobe --enable-avcodec --enable-avdevice --enable-avfilter --enable-avformat --enable-avresample --enable-avutil --enable-postproc --enable-swresample --enable-swscale --disable-doc --enable-libass --enable-bzlib --enable-gnutls --enable-fontconfig --enable-libfreetype --enable-libmp3lame --enable-iconv --enable-libtheora --enable-libssh --enable-vaapi --enable-libdrm --enable-vdpau --enable-libvorbis --enable-libvpx --enable-lzma --disable-opengl --disable-libmfx --disable-libaom --enable-libpulse --enable-sdl2 --enable-libsoxr --enable-libx264 --enable-libxvid --enable-libzimg --enable-zlib --enable-libopus --enable-libspeex --enable-libx265 --enable-libdav1d --disable-debug --enable-optimizations --disable-extra-warnings --disable-stripping
libavutil      56. 70.100 / 56. 70.100
libavcodec     58.134.100 / 58.134.100
libavformat    58. 76.100 / 58. 76.100
libavdevice    58. 13.100 / 58. 13.100
libavfilter     7.110.100 /  7.110.100
libavresample   4.  0.  0 /  4.  0.  0
libswscale      5.  9.100 /  5.  9.100
libswresample   3.  9.100 /  3.  9.100
libpostproc    55.  9.100 / 55.  9.100

$ yt-dlp --version
2022.10.04

Description:
Using the built-in queue and Restartable::ytdl to play from a long YouTube would hang after 20-40 minutes.

Steps to reproduce:

• Run the serenity example, and play a long video, such as this
• Wait for 25-35 minutes
• Notice that sound has stopped.

Inspecting the thread stacktraces using the debugger would show that songbird is stuck on ChildContainer::read, but it is unclear whether the issue is with yt-dlp, ffmpeg, or songbird itself. I am currently trying youtube-dl to see if this problem persists, and I will report back after.

[fee1-dead]

I just tried switching the yt-dlp feature off to use youtube-dl. The music has played for 1 hour, which has never occured when using yt-dlp.

[rurigk]

I have this exact issue, some songs play without problems but some always fails idk why

This song always fails for me at 2:30-3:00 https://www.youtube.com/watch?v=BnnbP7pCIvQ

[Kronicaler]

This seems to be the same issue i had in this issue #149

It seems to have been fixed in the next branch which uses Symphonia instead of FFmpeg.

I've personally been running my music bot on the next branch without issue for about 6 months now due to this exact bug and there have been no problems with the voice functionality, so I'd recommend switching to the next branch if you want this bug fixed as soon as possible and don't mind being on the development branch.

[fee1-dead]

Yep. The next branch works with yt-dlp and long tracks, and I have been using the development branch since I have reported this

[FelixMcFelix]

This is a weird one, and as far as I can tell it's tied to whether you use youtube-dl or yt-dlp. When I was writing the YoutubeDl handler (and HTTP handling) I found that:

• yt-dlp serves links that download faster and have exactly the right audio/video spec (i.e., Opus-only for songbird). However, google/youtube is VERY likely to kill the TCP stream at some point during playback. You must explicitly resume with the correct byte offset).
• youtube-dl downloads mp4 files at a very slow transfer rate, but the session is never dropped.

Near as I can tell, ffmpeg does not try to resume the session (hence, your audio is likely to cut out at... some point with yt-dlp). These observations are a little old, but I did have to explicitly keep them in mind for next.

[FelixMcFelix]

Closing as commenters all reorted the issue is fixed on next/v0.4.x.