Shoutcast: Ветеран стриминга, который до сих пор не выучил русский язык

Это дедушка стриминга. Протокол, который понимают вообще все плееры: от древнего Winamp до современного браузера через HTML5-плеер. Казалось бы — ставь и пользуйся. Но Shoutcast — это как драндулет с АЗЛК: едет, но трясет так, что зубы стучат, а бензин приходится смешивать с касторовым маслом.

Главная проблема Shoutcast в том, что его золотой стандарт (SHOUTcast DNAS 1.x и 2.x) застрял где-то в 2005 году. И теперь, когда вы решаете поднять на нем радио, вас ждет встреча с призраками прошлого.

Технический ад: Когда "просто работает" не работает

Вы думаете: "Shoutcast же есть во всех панелях управления, наверное, это стандарт". Стандарт — да. Удобный — нет. Вот маршрут, который вы пройдете, пытаясь завести эфир на чистом Shoutcast DNAS:

1. Конфиг из прошлого (sc_serv.conf): Забудьте про человеческий XML. Здесь у нас .conf файл с рудиментарным синтаксисом. Хотите поменять порт? Пишите PortBase=8000. Хотите включить логи? У вас есть LogFile=sc_serv.log. Хотите сделать админку по красивому URL? Тут начинается шаманство с секциями AdminPassword и перезапуском сервера. Одна лишняя точка с запятой или пробел — и DNAS просто не стартанет без внятного объяснения причины.
2. Кодировки и метаданные (Кракозябры-стайл): Shoutcast был заточен под латиницу. Точка. Когда вы попытаетесь передать в поток название на русском, слушатель увидит что-то вроде ������� — ������. Потому что Shoutcast тупо режет байты без понимания кодировок. "Решение" есть: перекодировать всё в UTF-8 еще на уровне источника, но даже тогда DNAS может перекодировать это обратно в Latin-1, потому что "так исторически сложилось". В итоге вы пишете костыли, которые перехватывают метаданные и вставляют их обратно уже после сервера.
3. Резервные потоки и переключения: Хотите, чтобы при падении основного источника у вас играла резервная "заглушка"? В теории Shoutcast умеет Fallback. На практике настройка резервного маунта (или аналога) в sc_serv.conf — это квест. Вам нужно прописать секцию ;FallbackMount и молиться, чтобы DNAS правильно обработал разрыв соединения. Если что-то пойдет не так, слушатели просто увидят "Server returned 404" и уйдут слушать другое радио.
4. Транскодинг на лету (Отсутствует): Shoutcast DNAS — это именно сервер, а не энкодер. Он не умеет пережимать ваш поток из 320kbps в 128kbps для мобильных слушателей. Вы либо вещаете в одном качестве, либо гоните два отдельных потока с двумя разными источниками (например, через OBS или Edcast). А это — двойная нагрузка на сервер и двойные танцы с настройкой.
5. Безопасность и устаревший протокол: Оригинальный Shoutcast DNAS не дружит с HTTPS из коробки. Максимум — можно поставить прокси перед ним (nginx, haproxy). Но тогда вы ловите геморрой с проксированием стримингового трафика. Браузеры любят HTTPS, Shoutcast любит HTTP. Кто уступит? Правильно, вы и ваш прокси-сервер.

В чем реальная боль вещателя на Shoutcast?

Вы хотели сделать радио с "тем самым" вайбом старых интернет-станций, а вместо этого:

• Правите конфиг через nano и не понимаете, почему при перезапуске всё слетает (подсказка: права доступа к папке с логами).
• Получаете жалобы от слушателей, что у них в плеере вместо названия песни — иероглифы.
• Настраиваете релеи, потому что ваш DNAS не тянет больше 100 слушателей на одном потоке (да, такое бывает).
• Роете форумы 2007 года в поисках ответа, как забанить пользователя по IP, потому что в современной документации этого просто нет.

Как я решил эту проблему: Python как машина времени

Я прошел через Shoutcast. Я видел эти логи, этот конфиг, эту боль. И однажды я плюнул и написал свой движок на Python, который эмулирует протокол Shoutcast, но работает как современное приложение.

Вы получаете ту же совместимость со всеми плеерами, что и у Shoutcast, но без необходимости вспоминать, как работали конфиги в нулевых.