Чому після перепідключення OBS на YouTube з'являється новий ефір

Перепідключення OBS саме по собі не створює новий ефір

Обрив зв'язку з сервером YouTube і повторне підключення OBS зазвичай мають стосуватися однієї трансляції. Глядачі можуть побачити паузу, заставку або пропуск частини ефіру, але посилання, чат і запис залишаються тими самими. Якщо в YouTube Studio з'являється окрема сторінка, причина частіше не в реконекті як такому, а в зміні прив'язки між вхідним потоком і ефіром.

На боці YouTube існують дві різні сутності: сторінка трансляції з назвою, доступом, чатом і налаштуваннями, а також RTMP-потік, який надсилає OBS. Новий ефір з'являється, коли сервіс отримує потік, прив'язаний до іншої трансляції або іншого сценарію запуску.

Чим сторінка ефіру відрізняється від ключа трансляції

Ключ трансляції потрібен OBS для надсилання відео й звуку на сервер YouTube. Сторінка ефіру — це об'єкт, який відкриває глядач: у неї є посилання, прев'ю, опис, чат і майбутній запис. За стабільного налаштування один вхідний потік обслуговує одну вибрану сторінку ефіру.

Після короткого обриву OBS може відновити з'єднання з тим самим RTMP-входом. Але якщо під час збою було створено новий ефір, вибрано інший ключ або зовнішній інструмент змінив прив'язку, YouTube починає приймати потік для іншої сторінки. Ззовні це виглядає так, ніби програма розділила один стрим на два, хоча рішення ухвалено на рівні налаштування трансляції.

Нова сторінка створюється вручну в YouTube Studio

Поширений сценарій починається після втрати сигналу. Власник каналу відкриває Studio, бачить попередження про проблему і створює нову трансляцію, замість того щоб дочекатися відновлення попередньої. Потім OBS запускається заново вже з параметрами нової заготовки, а перша сторінка залишається з коротким записом.

Помилитися легше, якщо на каналі одночасно є запланований стрим, чернетка, тестовий ефір і кілька старих заготовок зі схожими назвами. Недолік ручного відновлення в стресовій ситуації очевидний: складно швидко визначити, яка сторінка пов'язана з поточним сигналом, а глядачі можуть залишитися на старому посиланні.

Зміна ключа в профілі або на іншому комп'ютері

Ключ вещання може відрізнятися між профілями OBS, робочими комп'ютерами й резервним обладнанням. Наприклад, основний комп'ютер використовує ключ запланованого ефіру, а резервний — ключ від тестової трансляції, збережений раніше. Під час перемикання на резерв YouTube отримує потік за іншою схемою і може запустити іншу сторінку.

Перевірте налаштування вещання OBS на кожному пристрої: вибраний сервіс, сервер і ключ. Корисно також звірити, який профіль був активний до обриву і після нього. Один спільний ключ для всієї команди спрощує запуск, але в цього варіанта є недолік: випадковий старт з іншого комп'ютера може потрапити в робочий ефір.

Автоматизація створює ефір замість повторного підключення

Панелі керування, боти, плагіни й власні скрипти можуть працювати з API YouTube. Такі інструменти створюють трансляцію, задають назву, доступ та інші параметри, а потім пов'язують її з вхідним потоком. Якщо автоматизація запускається не лише перед першим стартом, а й після відновлення мережі, вона може створити нову сторінку.

Особливо уважно перевірте обробники запуску OBS, зміни сцен, мережевих подій і команди від віддаленої панелі. Недолік автоматизації в тому, що помилка в логіці не завжди помітна одразу: зображення вже передається, але глядачі й модератори продовжують дивитися попередній ефір за старим посиланням.

Як має виглядати схема прив'язки потоку

Для одного запланованого стриму ланцюжок має бути простим: OBS надсилає потік за одним RTMP-ключем, а YouTube приймає його в одну конкретну сторінку ефіру. Під час повторного підключення OBS повертається в той самий вхід, якщо ключ, налаштування Studio і зовнішні сценарії не змінювалися.

Схема корисна під час діагностики: вона показує, що обрив інтернету не дорівнює створенню нової трансляції. Новий об'єкт з'являється лише тоді, коли в ланцюжку змінюється ключ, цільова сторінка або автоматизація створює нову прив'язку. Не варто змінювати кілька параметрів одночасно: після цього важко встановити джерело проблеми.

Як знайти причину в історії трансляцій і журналі OBS

Відкрийте список ефірів у YouTube Studio і зіставте час створення сторінок, фактичного старту й закінчення запису. Якщо друга сторінка була створена точно під час обриву, перевірте дії в Studio і роботу автоматизації. Якщо обидві сторінки існували заздалегідь, найімовірніше, після реконекту змінилися ключ, профіль або пристрій.

• Зіставте момент втрати сигналу з часом появи нової сторінки в Studio.
• Перевірте активний профіль OBS до і після повторного запуску.
• Порівняйте параметри вещання на основному й резервному комп'ютері.
• Відкрийте журнал OBS: у ньому видно відключення, спроби перепідключення і новий старт передачі.
• Подивіться, чи не запускалися боти, панелі керування або скрипти в момент збою.
• Переконайтеся, що в Studio не була вручну відкрита й налаштована інша заготовка.

Запланований ефір допомагає зберегти одне посилання

Для важливого стриму зручно заздалегідь підготувати сторінку ефіру й використовувати її як постійну точку входу для аудиторії. Перед початком перевірте назву, доступ, прев'ю і надходження сигналу саме в цю трансляцію. Після обриву спершу відкрийте її статус і переконайтеся, що OBS намагається повернутися до попереднього підключення.

Не створюйте нову сторінку, поки не перевірені активний профіль, ключ і стан уже запущеного ефіру. У запланованого формату є недолік: коли на каналі накопичилися старі заготовки з однаковими назвами, легко вибрати не ту. Допомагають зрозумілі робочі назви й видалення непотрібних тестових трансляцій.

Багаторазовий ключ і окремі ключі для задач

Багаторазовий ключ позбавляє від постійного копіювання параметрів в OBS і знижує ризик помилки під час підготовки. Під час короткого мережевого збою він допомагає програмі повернутися в звичну точку приймання. Такий варіант зручний для одного робочого місця, де немає паралельних тестів і складних зовнішніх сценаріїв.

Недолік багаторазового ключа — менший контроль над доступом. Якщо він збережений на іншому комп'ютері або переданий помічнику, випадковий запуск може втрутитися в поточну трансляцію. Для тестів, резервного обладнання й окремих проєктів потрібен заздалегідь визначений порядок: який ключ використовується, до якої сторінки він належить і хто може запускати потік.

Тест перепідключення перед важливою трансляцією

Перевірку краще провести на закритому тестовому ефірі. Запустіть OBS, дочекайтеся сигналу в Studio, потім тимчасово перервіть передачу або мережеве з'єднання і дайте програмі спробувати відновити зв'язок. Після повернення сигналу перевірте посилання, чат, назву й наявність тієї самої сторінки в панелі керування.

Якщо після тесту з'являється новий ефір, не змінюйте налаштування навмання. Зафіксуйте час подій, активний профіль OBS, використаний ключ і список підключених інструментів. Потім вимкніть автоматизацію, повторіть тест і окремо перевірте перемикання між основним і резервним пристроєм. Недолік такого тесту — він не повторить усі проблеми реальної мережі, але дозволить відокремити помилку конфігурації від випадкового збою з'єднання.

Коли окремий ефір справді потрібен

Нова сторінка виправдана, якщо змінюються тема, доступ, оформлення, розклад або потрібен самостійний архів. Окремі трансляції також використовують для закритих показів, технічних тестів і паралельних проєктів. У цих випадках розділення допомагає не змішувати чати, записи й статистику різних подій.

Недолік такого рішення — аудиторії доводиться переходити за новим посиланням, а дані залишаються в різних ефірах. Якщо задача зводиться лише до відновлення OBS після короткого обриву, створювати нову трансляцію не потрібно: слід зберегти попередню прив'язку потоку до вже запущеної сторінки.