측정으로 확인한 낭비: YoutubeMusic.getSearchUrl 적중률이 6/10(평균 548ms)이라,
빗나가는 40% 에서는 YTM 을 끝까지 기다린 뒤 다시 ytsearch(~0.5초)를 도는 순차 대기가
통째로 버려지고 있었다.
변경: resolveQuery 기본 경로에서 ytsearch 폴백 검색을 먼저 띄워두고 YTM 결과를 기다린다.
- YTM 적중 -> 폴백 결과는 버리고 기존과 동일하게 동작(Lavalink 검색 1회가 헛돌 뿐)
- YTM 빗나감 -> 이미 진행 중인 폴백 결과를 그대로 사용(추가 대기 0)
- 버려지는 폴백 promise 는 catch 를 달아 unhandledRejection 방지
- " Topic" 중복 부가 방지 조건 추가
실측 A/B(YTM 이 빗나가는 3곡, 검색+해석+리졸브 구간):
기존 1500 / 1688 / 1391ms -> 신규 1224 / 1180 / 1399ms
재생은 3곡 모두 성공, 관찰 중 멈춤 0.
남은 병목: 음성접속 핸드셰이크(0.5~1.3초)는 디스코드 왕복이라 단축 여지가 거의 없다.
운영 리졸버 + 내부API 0순위 조합을 테스트 포트(8780)에 올리고, 운영 Lavalink(.6)로
실제 재생을 검증했다. 프로덕션(8779/Lavalink/master)은 변경하지 않았다.
케이스별 결과(첫 소리 / 관찰 중 멈춤):
짧은영상 7초 성공 888ms (재생 후 정상 종료. 관찰창이 곡보다 길어 판정 오탐 1회 발생)
짧은영상 18초 성공 1437ms 0/2
일반곡(K-pop) 성공 2017ms 0/3
해외곡 성공 4209ms 0/3
스포티파이 URL 성공 2753ms 0/3
플레이리스트120 성공 3147ms 0/3
곡 전환 성공 2982ms 0/2 (Ditto -> HEYA, 6.0s)
긴 곡(1시간) 성공 1430ms 0/3
32분 연속재생 성공 888ms 0/383 <- position 5,180 -> 1,920,180ms 정확히 선형 증가
리졸버 경로 통계: 내부API 11회 / 폴백 0회 / 내부API 실패 0회
참고: SABR 직결은 55초에서 403으로 끊겼던 반면, 이 방식은 32분간 무결. 포맷도 itag 251 동일.
남은 과제(운영 적용 전): visitorData 를 봇이 2시간마다 갱신하는 값과 공유하도록 배선.
현재는 고정 파일(/tmp/vd.txt)을 읽는 프로토타입이라 만료 시 폴백으로 떨어진다.
연령제한곡은 샘플 확보 실패로 미검증(폴백 경로가 쿠키로 처리).
[1] 재생 중 끊김(~55초) 해결 시도 — 전부 실패
- poToken 정상 주입 + 프로덕션 동일 설정 : 55초 끊김 동일
- 클라이언트 WEB 단독(SABR 경로 강제) : 55초 끊김 동일(decode 오류)
- 프록시(.4:3128) 제거 : 55초 끊김 동일
원인: 첫 청크 재생 후 '이어받기' 요청이 실패(정적 경로 403 / SABR 경로 decode).
feat/sabr-support 는 열린 PR #229, 마지막 커밋 2026-07-27 로 미병합 진행 중 기능.
=> 우리 쪽 설정으로 고칠 수 없음. SABR 직결 보류 확정.
[2] 새 방식: yt-dlp 를 '상주 라이브러리'로 호출하는 리졸버(프로토타입 첨부)
- zipapp(/usr/local/bin/yt-dlp) 을 sys.path 에 넣어 import, YoutubeDL 인스턴스 1회 생성
- 매 요청 프로세스 기동(0.40s) 제거 + player_client=default 단독
- 실패 시 기존 subprocess 경로로 자동 폴백(안전)
리졸브 실측: 1.58~2.30s (기존 subprocess 3곡 평균 4.2~4.7s)
재생 검증(프로덕션 Lavalink .6 + 이 리졸버):
일반곡 2656ms / 해외곡 2968ms / 직접URL 1900ms / 곡전환 성공
90초 장시간: 85초 진행, 끊김 0/17 ← SABR(55초 실패) 대비 안정
프로덕션(리졸버 8779, Lavalink, master)은 변경하지 않음. 테스트는 8780 포트로만 수행.
SelfTest 확장: 관찰시간(SELFTEST_WATCH_SEC), 곡전환(SELFTEST_SECOND_QUERY) 지원.
position 샘플링 주기를 Lavalink 보고 주기(5초)에 맞춰 멈춤 오탐 제거.
격리 Lavalink(.9:2334, SABR 빌드) + ytresolver OFF 결과:
일반곡(K-pop) 성공 첫소리 1455ms 20초 관찰 끊김 0
해외곡 성공 첫소리 1696ms 20초 관찰 끊김 0
직접 URL 성공 첫소리 932ms 20초 관찰 끊김 0
긴 곡(1시간) 성공 첫소리 3865ms 20초 관찰 끊김 0
플레이리스트(120곡) 성공 첫소리 5656ms 20초 관찰 끊김 0
곡 전환 성공 (Ditto → HEYA, 6.0s)
라이브 스트림 실패 ※ 현행 방식(1.18.2+ytresolver)도 동일 실패 → 기존 한계
장시간 90초 실패 50초 재생 후 정지, 2곡 재현
장시간 실패 원인: 재생 중 googlevideo 403
(PersistentHttpStream.connect → "Not success status code: 403")
대조군(현행 방식) 동일 90초 테스트: 85초 진행, 끊김 0 → 현행이 안정적.
결론: SABR 빌드는 첫 재생이 약 3초 빠르지만 곡 길이(3~4분)를 못 버티므로 적용 불가.
프로덕션(Lavalink .6, 리졸버, master)은 변경하지 않았다.
이전 결론(직결 불가)은 youtube-source 1.18.2 '릴리스' 기준이었다. upstream 에
feat/sabr-support 브랜치(커밋 02f536d "SABR stream support")가 있고, 스냅샷
저장소에 빌드가 배포돼 있어 격리 Lavalink(.9:2334)에 올려 재검증했다.
빌드 확인: 1.18.2 에 없던 dev/lavalink/youtube/sabr/* 클래스 14개 추가(SabrStream 등).
(참고: main 최신 스냅샷 f45bbb7 에는 SABR 미포함 — 감지 문자열만 존재)
실측(자가 테스트, 동일 3곡 + 1곡, 프로덕션 무영향):
A) 현재 방식(.6 Lavalink 1.18.2 + ytresolver): 4437~4884ms, 성공
B) SABR 빌드 + ytresolver OFF(직결) : 1155~2816ms, 성공
→ 첫 소리까지 약 3초 단축. yt-dlp 단계 자체가 사라져 구조도 단순해진다.
미검증/주의: 연령제한곡·라이브·장시간 재생 안정성, 비공식 브랜치(미병합) 빌드 사용.
프로덕션 Lavalink(.6)·리졸버·master 는 변경하지 않았다.
POTOKEN_INJECT 플래그 추가(기본 true). 격리 테스트 Lavalink(.9:2334)를 별도로 띄워
클라이언트/OAuth/poToken 조합을 바꿔가며 직결 재생을 검증했다. 프로덕션 무영향.
[직결 재생 — 전부 실패]
- ANDROID_VR 우선 + OAuth + poToken : 실패
- ANDROID_VR 단독 + OAuth off : 실패
- ANDROID_VR 단독 + OAuth/poToken off: 실패
Lavalink 측 실패 사유(클라이언트별):
ANDROID_VR "This video requires login" / TVHTML5 "page needs to be reloaded"
WEB "No supported audio streams available"(응답이 sabr=1 + serverAbrStreamingUrl 뿐)
WEB_EMBEDDED "player configuration error" / MWEB 403
→ youtube-source 1.18.2(최신)는 SABR 미지원. 어떤 조합으로도 직결 불가 → ytresolver 필수.
[리졸버 고속화 — 유효한 개선 발견]
yt-dlp 클라이언트별 실측(동일 영상 5개, --get-url):
현재 default,web_safari,tv : 5/5 성공, 평균 2.95s, itag 251
default 단독 : 5/5 성공, 평균 2.00s, itag 251 ← 약 1.0s 단축
android_vr 단독 : 1.6s로 가장 빠르나 오디오 전용 포맷 없음(항상 itag 18)
→ Lavalink loadtracks 실패, 사용 불가
검증: default 단독 URL을 Lavalink가 loadType=track 로 정상 로드,
실제 재생까지 성공(자가 테스트 position 증가 확인).
4번 안(yt-dlp 단계 제거) 독립 검증용 실험 브랜치. master 에는 병합하지 않는다.
- Config.ytresolverEnabled 플래그 추가(YTRESOLVER_ENABLED, 기본 true=기존 동작).
false 면 resolvePlayable 이 Lavalink youtube-source(poToken) encoded 를 그대로 사용.
- SelfTest 추가: 사람이 음성채널에 없어도 봇이 스스로 입장→재생→position 증가를
확인해 실제 오디오 흐름 여부를 판정(환경변수 미설정 시 비활성).
실측 결과(테스트봇, Redis off, 프로덕션 무영향):
- A) ytresolver ON : 재생 성공, 첫 소리까지 4779ms (오디오 리졸브 3166ms)
- B) ytresolver OFF: 첫 소리까지 1279~1391ms 로 빠르지만 재생 실패.
Lavalink 예외 "All clients failed to load the item." 반복, position 0 고정.
서로 다른 2곡에서 동일 재현 → 곡 특성 아닌 구조적 차단(SABR).
결론: poToken 주입만으로는 스트림 로드가 안 되므로 ytresolver 는 계속 필요.
