«We have detected multiple streams using the same stream key» — чому виникає і як припинити
YouTube повідомляє, що дві трансляції борються за один ключ. Зазвичай ніхто не робив цього навмисно — ключ тихо скопіювала функція, якою ви скористалися.
Повідомлення звучить так: «We have detected multiple streams using the same stream key with auto-start enabled.» Приходить воно зазвичай у найгірший момент — посеред ефіру або рівно тоді, коли мала початися запланована трансляція.
Це не баг і рідко коли диверсія. Майже завжди функція, якою ви скористалися свідомо, скопіювала ваш stream key туди, де ви цього не очікували, і тепер дві трансляції змагаються за нього. Нижче — що таке ключ насправді, чотири способи появи дублікатів і порядок, у якому це лікується.
Про що насправді звітує це повідомлення
YouTube каже дві речі одночасно, і якщо їх розділити, виправлення стає очевидним. Перше: більш ніж один обʼєкт трансляції налаштований на той самий stream key. Друге: щонайменше в одного з них увімкнено auto-start, тобто YouTube готовий почати трансляцію тієї миті, коли на цей ключ прийдуть дані.
Разом це означає, що YouTube не може визначити, якій саме трансляції належить ваше відео. Він міг би запустити будь-яку з двох. Замість того щоб гадати, він попереджає — а залежно від таймінгу може запустити не ту трансляцію, розділити глядачів між двома сторінками перегляду або взагалі відхилити зʼєднання.
Чому це частіше трапляється на безперервних стрімах
Стрім, який іде годину, майже не дає цьому шансу. Стрім, який іде тижнями й час від часу перезапускається, дає безліч. Кожен перезапуск — це ще один момент, коли нова сесія може зіткнутися з тією, яку YouTube ще не згорнув; а кожна запланована трансляція, створена кілька місяців тому, досі лежить і тримає той самий ключ.
Що таке stream key — словами самого YouTube
Документація YouTube про налаштування трансляції формулює прямо: «Stream key — це як пароль і адреса вашої трансляції на YouTube. Він каже енкодеру, куди надсилати сигнал, і дозволяє YouTube його прийняти».
Важливі обидві половини цього речення. Як адреса ключ маршрутизує ваше відео до конкретної трансляції — тому дві трансляції з однією адресою неоднозначні за визначенням. Як пароль він єдине, що вас автентифікує, — тому витік ключа дає рівно ту саму помилку, що й помилка в налаштуваннях.
Ingest URL, на відміну від ключа, публічна й однакова для всіх стрімерів YouTube на планеті. Якщо не зовсім зрозуміло, що є що, гайд по RTMP для YouTube розбирає весь рядок на частини.
Три наслідки, які варто засвоїти:
- Один ключ має нести одну живу сесію одночасно. Не одну на енкодер, не одну на сцену — одну.
- Ключ не привʼязаний до моменту в часі. Трансляція, яку ви запланували й забули, тримає свій ключ безстроково.
- Скидання ключа в Live Control Room миттєво знецінює старе значення всюди, де воно використовувалось.
Чотири способи, якими це стається
У порядку того, як часто вони виявляються причиною:
«Reuse settings» скопіювала ключ разом з усім іншим
Це головна причина, і вона дивує людей, бо функція робить рівно те, що написано, — просто ретельніше, ніж очікуєш. Документація YouTube зазначає, що вибір Reuse settings копіює «метадані, налаштування та stream key попередньої трансляції», а також «скопіює ваш вибір auto-start і auto-stop».
- Перечитайте: копія містить ключ і прапорець auto-start. Обидві половини умови помилки приїжджають одним кліком.
- Кожна трансляція, створена таким чином, тримає той самий ключ — незалежно від того, чи виходили ви в ефір з неї взагалі.
- Відкрийте список майбутніх і минулих трансляцій і подивіться, скільки з них показують той самий ключ. Дублікати ховаються саме там.
Кілька запланованих трансляцій з увімкненим auto-start
Auto-start означає, що YouTube починає трансляцію, щойно побачить дані на ключі. Налаштуйте дві заплановані події таким чином — і перші ж байти зможуть запустити будь-яку з них.
- Вимкніть auto-start на всіх запланованих трансляціях, окрім тієї, яку ви справді збираєтесь вести.
- Для безперервного стріма краще взагалі не використовувати заплановані події: постійний ключ з однією трансляцією не має з чим стикатися.
- Видаляйте старі заплановані трансляції, а не лишайте їх спати. «Спить» не означає «нешкідлива».
Два енкодери або перезапуск, який наклався
Другий енкодер, спрямований на той самий ключ — тестовий стенд, застосунок на телефоні, машина колеги, — дає помилку одразу. Так само і перезапуск власного енкодера швидше, ніж YouTube згортає попередню сесію.
- Зупиніть усі енкодери, дочекайтеся, поки Live Control Room покаже, що дані не надходять, і запустіть рівно один.
- Якщо ви перезапускаєтесь автоматично після збою — зробіть, щоб повтор чекав і збільшував паузу, а не підключався миттєво.
- Той самий надто швидкий повтор дає й фантомні збої зʼєднання — про це в гайді про «no data».
Ваш ключ є в когось іншого
Найрідший і найсерйозніший випадок. Оскільки ключ — єдиний реквізит доступу, будь-хто, хто ним володіє, може стрімити на ваш канал, і YouTube звітує про це саме такою помилкою.
- Пригадайте, чи не потрапляв ключ у скриншот, у звернення в підтримку, у спільний документ або в оверлей на екрані.
- Скиньте ключ у Live Control Room. Старе значення помирає миттєво.
- Оновіть значення в усіх ваших легітимних енкодерах перед наступним ефіром — скидання ламає і їх.
Виправлення, по порядку
Ідіть по цих кроках послідовно, а не намагайтесь зробити все одразу. Перші два вирішують переважну більшість випадків і займають близько хвилини.
Зупиніть усе, що може відправляти
Перед діагностикою приведіть систему у відомий стан. Зупиніть кожен енкодер, який контролюєте, і дочекайтесь, поки Live Control Room покаже, що дані не надходять.
- Не забудьте про пристрої, про які легко забути: застосунок на телефоні, другу машину, тестовий інстанс.
- Саме дочекайтесь, а не перезапускайте одразу — YouTube потрібен час, щоб звільнити попередню сесію.
- Переконайтеся, що control room не показує вхідних даних, перш ніж рухатись далі.
Знайдіть усі трансляції, що тримають ключ
Відкрийте майбутні й минулі трансляції та звірте їхні stream key. Дублікати, створені через Reuse settings, невидимі, поки не подивитись у цей список свідомо.
- Перевірте заплановані події, з яких ви ніколи не виходили в ефір, — вони досі тримають свій ключ.
- Подивіться на все, що створювалося копіюванням попередньої трансляції.
- Позначте, де ввімкнено auto-start: саме вони й спричиняють зіткнення.
Вимкніть auto-start скрізь, де він не потрібен
Помилці потрібні обидві половини — дубльований ключ і auto-start. Прибравши другу, ви зупините зіткнення навіть при дублікатах ключа, що лишились.
- Лишіть auto-start рівно на одній трансляції — або на жодній, якщо стартуєте вручну.
- Видалити непотрібні трансляції чистіше, ніж вимикати їм прапорець, якщо історія вам не потрібна.
- Reuse settings копіює й цей прапорець, тож перевіряйте його після кожного майбутнього копіювання.
Скиньте ключ, якщо щось лишилось непоясненим
Якщо не вдається пояснити кожну трансляцію, що тримає ключ, вважайте ключ скомпрометованим і скиньте його. Кнопка скидання є поруч із прихованим ключем у Live Control Room.
- Попереднє значення перестає працювати тієї ж миті — жодного пільгового періоду немає.
- Кожному легітимному енкодеру потрібне нове значення, щоб підключитись знову.
- Ставтеся до нового ключа як до пароля: ніколи не вставляйте його у скриншот чи спільний документ.
Як не допустити повторення
Кроки вище прибирають поточне зіткнення. Чи повернеться воно — залежить від того, як узагалі влаштований стрім, і безперервним стрімам потрібна інша конфігурація, ніж разовим трансляціям.
Що тримає цілодобовий стрім поза проблемами:
- Одна трансляція, один ключ, жодних копій. Не використовуйте Reuse settings для чогось, що ділить ключ із живим стрімом.
- Постійна трансляція краща за заплановані події. Заплановані накопичуються, постійна — ні.
- Дайте перезапускам зростаючий backoff. Миттєвий повтор — найчастіша причина, яку створюють собі самі.
- Час від часу переглядайте заплановані трансляції. Видалити їх нічого не варте, а ховається все саме там.
- Ставтеся до ключа як до реквізиту доступу. Це єдине, що стоїть між вашим каналом і будь-ким, хто цей ключ бачив.
Є ще структурний різновид цієї проблеми, який варто назвати, бо ми самі на нього наштовхнулись. Коли софт керує трансляціями від імені користувача, він має перевіряти, чи ключ уже зайнятий, перш ніж запускати стрім. І якщо ця перевірка порівнює не те — наприклад, внутрішні ідентифікатори записів замість самих значень ключа, — два різні записи з однаковим ключем пройдуть перевірку, яка мала б їх зупинити. Тоді два стріми стартують на одному ключі й вибивають один одного з ефіру. Якщо ви будуєте таку автоматизацію, порівнюйте саме значення ключів.
Якщо ж не хочеться думати про це взагалі — цілком розумний висновок. TheLoops веде життєвий цикл трансляції за вас, включно з перевіркою конфліктів, яка не дає двом стрімам зійтись на одному ключі.
Один стрім, один ключ, без сюрпризів
Завантажте відео, а життєвий цикл трансляції — конфлікти ключів, перезапуски й решту — ми беремо на себе, щоб нічого не зіткнулося о третій ночі.
Часті питання
Ні. Сам YouTube описує ключ і як адресу, і як пароль трансляції, а адреса, що вказує на два місця, неоднозначна за визначенням. Дві одночасні сесії на одному ключі — рівно та умова, про яку звітує ця помилка. Якщо потрібні дві паралельні трансляції, кожній потрібен власний ключ.
Майже завжди через трансляцію, створену раніше копіюванням наявної. Функція Reuse settings копіює stream key і прапорець auto-start разом із метаданими, тож дублікат може місяцями спати й зіткнутися лише при наступному перезапуску.
Воно прибирає помилку, бо помилці потрібні одночасно дубльований ключ і ввімкнений auto-start. Але дублікати ключа лишаються, тож будь-що, що згодом знову ввімкне auto-start, поверне проблему. Надійне рішення — видалити непотрібні трансляції.