Аудиодвижок: умная предзагрузка и ленивая инициализация

[Scream034]

Суть проблемы

Текущая архитектура аудиосистемы принудительно ожидает выполнения запроса /player (через YoutubeProvider.RefreshStreamUrlAsync) для получения метаданных формата перед началом буферизации любого трека. Это создаёт ощутимую задержку (лаг) при переключении треков:

1. Для полностью кэшированных треков: Вызов /player абсолютно избыточен, так как файл уже лежит на диске, но плеер всё равно обращается к сети, тратя трафик и время.
2. Для онлайн-воспроизведения: Сетевой запрос блокирует инициализацию декодера, из-за чего пользователь слышит паузу между треками вместо бесшовного перехода.

Возможное решение (Теория и архитектура)

1. Ленивый запуск кэшированных треков: В AudioSourceFactory.CreateAsync проверять наличие локального кэша (IsFullyCached / FindAnyCachedTrack). Если трек полностью загружен на диск, мгновенно отдавать LocalFileSource без вызова сетевых методов YoutubeProvider.
2. Параллельная фоновая стабилизация: Если трек частично закэширован или воспроизводится из сети, запускать воспроизведение сразу по первому доступному чангу. Запрос /player уводить в фоновый поток (Task.Run) параллельно воспроизведению, чтобы «догрузить» недостающие сегменты без задержки старта.
3. Умная предзагрузка (Preloading): Внедрить в AudioEngine или PlayerControlService событие-триггер (например, «Осталось 15 секунд до конца текущего трека»). По этому триггеру асинхронно запускать фоновый прогрев следующего трека в очереди:
   • Вызов RefreshStreamUrlAsync (сбор n-token / sigcipher).
   • Прогрев TCP-соединения (Pre-warm HTTP/2 socket) с CDN Google.
   • Первичная буферизация первых чанков следующего трека в RAM-кэш.