Ошибки в обс WriteN, RTMP send error 10060 10038 10054

[ser]

Здравствуйте

В последнее время часто стали реконекты в обсе к нашему серверу ФФ (5.2.2008). Ошибок подключений к другим сервисам с этого компьютера нет.

11:30:11.925: WriteN, RTMP send error 10054 (4097 bytes)
11:30:11.925: WriteN, RTMP send error 10038 (128 bytes)
11:30:11.925: WriteN, RTMP send error 10038 (42 bytes)
11:30:11.925: [rtmp stream: 'multi-output'] Disconnected from rtmp://origin-eu-1
11:30:11.925: Output 'multi-output': stopping
11:30:11.925: Output 'multi-output': Total frames output: 285971 (287144 attempted)
11:30:11.925: Output 'multi-output': Total drawn frames: 287200 (287201 attempted)
11:30:11.925: Output 'multi-output': Number of lagged frames due to rendering lag/stalls: 1 (0.0%)
11:30:11.925: Output 'multi-output': Number of dropped frames due to insufficient bandwidth/connection stalls: 1173 (0.4%)
11:30:11.925: Output 'multi-output': Reconnecting in 2.00 seconds..
11:30:11.925: [rtmp stream: 'multi-output'] Freeing 828 remaining packets
....
12:44:28.811: WriteN, RTMP send error 10060 (4104 bytes)
12:44:28.812: WriteN, RTMP send error 10038 (128 bytes)
12:44:28.812: WriteN, RTMP send error 10038 (42 bytes)
12:44:28.812: [rtmp stream: 'multi-output'] Disconnected from rtmp://origin-eu-1.
12:44:28.812: Output 'multi-output': stopping
12:44:28.812: Output 'multi-output': Total frames output: 133244 (133591 attempted)
12:44:28.812: Output 'multi-output': Total drawn frames: 133641 (133643 attempted)
12:44:28.812: Output 'multi-output': Number of lagged frames due to rendering lag/stalls: 2 (0.0%)
12:44:28.812: Output 'multi-output': Number of dropped frames due to insufficient bandwidth/connection stalls: 347 (0.3%)
12:44:28.812: Output 'multi-output': Reconnecting in 2.00 seconds..

На фороме обса пишут что проблема с железом

WriteN, RTMP send error 10060/10054/10038

LOG: https://obsproject.com/logs/RnsIuCNqwUsVwUAc Been experiencing this for like a whole week, any solution? I am constantly disconnecting from the stream in facebook, in the log provided, I just connected my OBS to a test Facebook Live and just monitoring it, and it disconnects like every 3...

obsproject.com

Random RTMP Disconnects #6366

Spoiler: или что проблема с роутером или сетью

Fenrirthviti commented on Apr 22, 2022

This is likely going to be something with your network route between the server and client, or a bug in the streaming server itself. The high bitrate disconnects mentioned is a long-standing bug in nginx-rtmp (and derivatives), and I wouldn't be surprised to see it somewhere else, but that usually only triggers above 40Mbit. Even though it's unlikely this is anything on the OBS side, I will leave this open, just please understand that any kind of troubleshooting or work on this is likely to be very slow going without more information and a repeatable test setup where the issue is proven across multiple environments.

сервер настроен на отключение неактивных стримов
flash_rtp_activity_enabled=true
rtp_activity_timeout=10
пробовали стримить черный экран без звука - реконекта не было

стрим из RU в FR
напишите если нужны доступы для проверки логов на сервере


мне непонятны значения кодов 10060 10038 10054.
почему сначала был первым 54 или 60 и потом подряд 10038 ?

 

[Max]

1) Другой сервер

Попробуйте отправлять стрим на другой WCS сервер, который находится в другом датацентре с другой локацией.
Например demo.flashphoner.com

Будут ли проблемы в этом случае?

2) Снятие дампов

Если проблема стабильно воспроизводится, снимите дамп RTMP трафика одновременно на стороне компьютера и на стороне сервера.

1. Запустить wireshark, убедиться что он захватывает трафик и в этот трафик попадают пакеты, которые идут на порт 1935 сервера.
2. Запустить wireshark для записи трафика.
3. На сервере запустить tcpdump для записи трафика:
sudo tcpdump host 192.168.1.61 -B 10000 -w log.pcap
Здесь 192.168.1.61 - это внешний адрес стримера, как его видит сервер. Например можно использовать whatismyip dot com чтобы определить внешний адрес компьютера, на котором OBS.
4. Запустить стрим из OBS и воспроизвести проблему.

В результате, у нас будет 2 дампа.
Один - со стороны сервера. Второй - со стороны стримера.
Оба дампа начали снимать до начала стрима, поэтому в них попадет стрим от начала до окончания съема.

По дампам должно быть понятно что происходит.
Пришлите ссылку на скачивание дампов через эту форму.

3) Какая нагрузка на сервер? Сколько и каких RTMP потоков туда заходят одновременно.
- битрейт
- fps
- разрешение

4) Предположительно, до этого сервера плохая связь.
Можно измерить с помощью iperf полосу до этого сервера
Результаты измерений также сбросьте пожалуйста через форму.

5) Установить OBS на сервер с UI Windows или Linux в том же датацентре, что и сервер, принимающий RTMP стрим.
И застримить видео ролик с похожим битрейтом и характеристиками на реальный стрим. Будут ли проблемы.

6) Дайте пожалуйста скриншоты с настройками OBS. Попробуем воспроизвести проблему с нашими серверами.
Дайте через форму урл сервера. Попробуем воспроизвести проблему с вашим сервером.

 

[ser]

У проблемных компьтеров провайдер снижает скорость к зарубежным серверам.
Похоже причина вылета в этом.
Проверили скорости до ДЦ внутри страны - скорость нормальная
До ДЦ с приемным - меньше 10 мегабит

Сейчас видим два варианта:
1 использовать прокси для ртмп
2 поднять дополнительный приемный сервер ближе к стримерам

Можете посоветовать как лучше сделать?


1)
с проблемных компьтеров не делали
2)
дампы получились большого объема. смысла их передавать нет т.к. кажется поняли причину
3)
сервер: Intel(R) Xeon(R) E-2388G CPU @ 3.20GHz, 16 cores / 62.68 GiB total
количество одновременных потоков: от 10 до 25
битрейт: от 3600 до 6000 кбс
фпс: 30-60
разрешение: 1080р.
иногда могут быть стримы через браузер ( 360р - 720р 1100-2500 кбс)

4)

5)
когда стрим локально не повторяется

6)

 

[Max]

До ДЦ с приемным - меньше 10 мегабит

Да, если стримить с битрейтом 5 Мбит/с, канал на upload до сервера должен быть не менее 10 Мбит/с.

Сейчас видим два варианта:
1 использовать прокси для ртмп
2 поднять дополнительный приемный сервер ближе к стримерам

Можете посоветовать как лучше сделать?

Лучше поднять дополнительный приемный сервер ближе к стримерам, в том ДЦ, до которого пропускная способность не ограничена.

 

[Nikitanaev]

Мы подняли дополнительный сервер ближе, пропускная способность до него порядка 30 мбит. Стало гораздо лучше, % реконнектов сильно уменьшился.
Также мы наблюдали следующую картину: в разное время отключались трансляции на разные сайты с теми же ошибками
WriteN, RTMP send error 10054 (4097 bytes)
WriteN, RTMP send error 10038 (128 bytes)
WriteN, RTMP send error 10038 (42 bytes)
Мы предполагали, что у пользователей может быть кратковременная просадка сети, в связи с чем пропускной способности не хватало и происходил реконнект. Но как объяснить то, что эти ошибки в разное время происходят на разных сайтах мы пока не поняли. По идее, они должны были разом все упасть, если случилась просадка сети.
Возможно ли такое, что каким-то образом канал от стримера до определенного сервера падает? Притом остальные каналы могут нормально работать.

Также на просторах интернета нашел человека с подобной проблемой до его сервера. Вот что пишет:

Was able to catch the cause, it was an /odd/ one! The TL;DR is that Intel nics just aren't as solid as they used to be, e1000e tso issues with enp0s25.

Caught re-transmissions that happened exactly when the disconnect occurred

Lead me to catch the bridged adapter the RTMP server was on hanging which only seemed to happen when streaming, no other VM caused it, problem would not manifest unless streaming, something about that workload caused things to break badly.


The fix was:

ethtool -K enp0s25 tso off

or on boot:

ExecUpPost='/usr/bin/ethtool -K enp0s25 tso off'

Did about 6 hours of streaming to test afterwards, no further issues, no further interface hangs, all boils down to flaky drivers for certain Intel nics, bet other with this unsolvable problem are having the same general problem given the proliferation of this particular driver/chipset combination. Not so much a network problem as much as a device driver and hardware issue with TCP segmentation offload.

 

[Max]

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

Да, такое вполне возможно. Если стримеры используют различных провайдеров, то и каналы у них могут вести себя по-разному.

ethtool -K enp0s25 tso off

По описанию похоже, что эта проблема касается физической сетевой карты на железном сервере. Возможно, изменение настройки внутри виртуального сервера не приведет к ожидаемому эффекту. Необходимо пробовать в той среде, где проблема воспроизводится.

 

[ser]

Пришлите ссылку на скачивание дампов через эту форму.

ссылки прислали

Много ошибок с неправильной формой пакета

в обсе биртрейт нулевой был
сделали iperf на этом компе до приемного - он показывает 200мбит

 

[Nikitanaev]

Еще дополню:

Разрыв в ОБС случился в это время (-1 от мск как и дамп):
15:15:41.406: WriteN, RTMP send error 10060 (4097 bytes)
15:15:41.407: WriteN, RTMP send error 10038 (128 bytes)
15:15:41.407: WriteN, RTMP send error 10038 (42 bytes)

Наблюдал за битрейтом уже после реконнекта. Он сильно плавал, от 300кб до 18 мб. При этом, в самом обс FPS также пишет 30, а в статистике FF было 86.

Затем заметил, что битрейт в обс упал до 0 и держался пару секунд.

Сразу же делаю на этом компе iperf до приемного сервера, получаю следующие значения:

[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 21.6 MBytes 181 Mbits/sec
[ 5] 1.00-2.01 sec 26.6 MBytes 222 Mbits/sec
[ 5] 2.01-3.01 sec 27.0 MBytes 226 Mbits/sec
[ 5] 3.01-4.00 sec 26.4 MBytes 224 Mbits/sec
[ 5] 4.00-5.01 sec 27.8 MBytes 232 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-5.01 sec 129 MBytes 217 Mbits/sec sender
[ 5] 0.00-5.06 sec 128 MBytes 213 Mbits/sec receiver

iperf Done.

И спустя еще несколько секунд происходит реконнект. То есть, в этот момент пропускная способность не упала, но тем не менее, обрыв случился.

Настройки ОБС такие же, как ранее показано в этой теме.

 

[Max]

Наблюдал за битрейтом уже после реконнекта. Он сильно плавал, от 300кб до 18 мб. При этом, в самом обс FPS также пишет 30, а в статистике FF было 86.

Большой fps на стороне WCS в этот момент объясняется тем, что данные доходят не равномерно, а кусками. То есть медиаданных не было, потом пришли пачкой. Тогда FPS подскочит, т.к. он считается по количеству распакованных фреймов. Но это также говорит о проблемах именно с RTMP трафиком, как и плавающий битрейт.
В дополнение к тем настройкам, которые выставлены на сервере, предлагаем включить буферизацию входящего RTMP потока

rtmp_in_buffer_enabled=true
rtmp_in_buffer_start_size=1000
rtmp_in_buffer_initial_size=3000
rtmp_in_buffer_polling_time=30
rtmp_in_buffer_max_bufferings_allowed=-1

Это буферизует потоки, в которых данные приходят неравномерно (из-за проблем с каналом или по другим причинам).

Много ошибок с неправильной формой пакета

Дампы большие, их скачивание и анализ займет продолжительное время.
Сообщение Mailformed packet может выдавать Wireshark, когда не может разобрать пакет. Eсли это входящий дамп на стороне сервера, это может говорить и о сетевых проблемах, особенно Connection reset.
Ошибка 10060 - это невозможность установить TCP соединение с удаленным сервером по таймауту. Ошибка 10038 - это ошибка записи в локальный TCP сокет, который сокетом уже не является. Выглядит так, что OBS пытался соединиться с сервером, но не смог.Если это происходит у всех клиентов данного сервера одновременно, можно предположить, что сервер перестал принимать RTMP соединения. Если нет, то больше похоже на сетевую проблему.
Мы также можем проверить серверные логи, если вы укажете точные время и дату, когда это произошло, и если логи еще сохранились.

 

[Nikitanaev]

rtmp_in_buffer_enabled=true rtmp_in_buffer_start_size=1000 rtmp_in_buffer_initial_size=3000 rtmp_in_buffer_polling_time=30 rtmp_in_buffer_max_bufferings_allowed=-1

Применили эти настройки, понаблюдаем

Выглядит так, что OBS пытался соединиться с сервером, но не смог.Если это происходит у всех клиентов данного сервера одновременно, можно предположить, что сервер перестал принимать RTMP соединения. Если нет, то больше похоже на сетевую проблему.

Эта проблема возникает стихийно у многих пользователей, никак между собой не связанных и находящихся в разных городах. То есть у кого-то может произойти реконнект, а другие в этот же момент времени не испытают проблем. Мы тоже думали, что это может быть связано с сетевыми просадками, но в этом случае, реконнект был бы у всех стримов, запущенных в обс. Но в логах обс мы видим, что это не так, и разрыв идет только с нашим сервером. Поэтому мы предполагаем, что проблема все таки кроется на нашей стороне, не на стороне клиента.

Логи остались, время проблемы, когда мы записывали дамп трафика: 17.09.2024 16:15:30 - 16:15:45 по мск. В это время начались проблемы и случился обрыв. В обс это время обозначено 17.09.2024 16:15:41.406.

 

[Max]

Эта проблема возникает стихийно у многих пользователей, никак между собой не связанных и находящихся в разных городах. То есть у кого-то может произойти реконнект, а другие в этот же момент времени не испытают проблем. Мы тоже думали, что это может быть связано с сетевыми просадками, но в этом случае, реконнект был бы у всех стримов, запущенных в обс.

Это говорит о проблемах с исходящими каналами пользователей до определенного сервера, а не с входящими каналами сервера. Если бы реконнект был у всех RTMP стримов, запущенных в это же время на этот же сервер, тогда да, мы вправе заподозрить проблему на стороне сервера либо датацентра.
Посмотрели логи, разобрали дамп, снятый на стороне сервера.
В логах сервера есть завершение публикации RTMP потока lCMVb6QNв 16:15:35 по времени сервера по отсутствию медиатрафика в течение 10 секунд

После этого сервер все-таки получил от этого клиента RTMP команду unpublish

Затем в 16:15:43 установка соединения с этого же адреса с публикацией этого же потока

После этого поток публиковался, пока не был в 16:33:27 остановлен клиентом

К сожалению, серверный дамп выглядит отфильтрованным по адресу другого клиента, поэтому этих событий в серверном дампе мы не видим.
При этом в клиентском дампе действительно видно, что OBS в течение 10 секунд не отправлял медиапакеты (последние данные были отправлены в 13:15:26). После этого было несколько попыток ретрансмита на уровне TCP, пока наконец не был получен TCP RST

Это выглядит как проблема с каналом именно между клиентом и сервером, а не с каналом на стороне сервера, т.к. другие публикации на этот сервер в это время продолжались (пример из серверного дампа)

Unknown в данном случае пишет Wireshark: он понимает, что это RTMP пакет с видео данными, но не может его разобрать. То есть это не битые пакеты, а проблемы разбора. Также Wireshark может помечать как Mailformed определенные секции в пакетах с RTMP командами

Это также не является признаком сетевой ошибки. О том, что есть проблемы с сетью, говорит остановка отправки медиаданных и ретрансмиты.

 

[Nikitanaev]

flash_rtp_activity_enabled=true
rtp_activity_timeout=10

rtmp.server_read_socket_timeout = 10

В таком случае, нам стоит изменить значение на 20 или 30 секунд, чтобы было больше времени на повторное подключение?

 

[Max]

В таком случае, нам стоит изменить значение на 20 или 30 секунд, чтобы было больше времени на повторное подключение?

Нет, не стоит, лучше оставить значение по умолчанию.
Если проблема воспроизводится, необходимо сделать следующее:
1. Включить RTMP буфер, как мы рекомендовали выше, и включить запись метрик RTMP буфера в настройках сервера

rels_enabled=RTMP_IN_BUFFER

2. Включить запись статистики медиасессий по их окончании

media_session_connection_stats_log=true

3. Собрать дампы на клиенте и на сервере, причем дамп на стороне сервера фильтровать по внешнему IP именно проблемного клиента. Дамп клиента лучше не фильтровать, если в этот же момент есть публикация на другой сервер и она работает.
4. Если для клиента зафиксированы проблемы (скачет битрейт), нужно включить запись метрик RTMP буфера для проблемного клиента. Для этого получить mediaSessionId для этого потока по REST API /stream/find, и дать запрос

POST /rest-api/rels/startup HTTP/1.1
Host: localhost:8081
Content-Type: application/json
 
{
    "rtmpInBuffer": {
        "ids": [
            "xxx-yyy-zzzz"
        ]
    }
}

где xxx-yyy-zzz - mediaSessionId проблемного потока.

Затем нужно прислать нам ссылки на дампы и логи сервера, включая каталог /usr/local/FlashphonerWebCallServer/logs/rels.
Собранные таким образом данные позволят более точно определить, сетевая ли это проблема, или проблема сервера.

 

[ser]

доступ к серверу и логи передали через форму

дампы пишутся в /usr/local/FlashphonerWebCallServer/logs/dumps/

время ошибки по МСК
13:06:22.134: WriteN, RTMP send error 10060 (4097 bytes)
13:06:22.134: WriteN, RTMP send error 10038 (128 bytes)
13:06:22.134: WriteN, RTMP send error 10038 (42 bytes)
13:06:22.134: [rtmp stream: 'multi-output'] Disconnected from

 

[Max]

Получили и проверили логи и дампы.
Подтверждается сетевая проблема между публикующим клиентом и сервером. По клиентскому дампу, последний пакет размером 2958 байт был успешно отправлен в 10:06:07 UTC, после чего следующий пакет не отправился с ошибкой TCP Window Full

После этого данные не отправлялись.
При этом на стороне сервера пакет размером 2958 байт получен уже не был. По истечении таймаута 10 секунд сервер зафиксировал остановку медиатрафика от клиента с записью в клиентский лог no Video RTP activity (в серверном логе никаких сообщений нет, т.к. уровень вывода в серверный лог ограничен до ERROR) и попытался закрыть соединение, однако не смог отправить TCP FIN в сторону клиента

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

после чего успешно установил новое соединение и возобновил публикацию

При этом по статистике RTMP буфера на стороне сервера, во время публикации трафик заходил в целом ровно, буфер не переполнялся, разрывов в трафике не было.
Обращаем внимание, что порт источника, зафиксированный в дампе на стороне клиента (61128) не соответствует порту источника в RTMP пакетах, полученных сервером (2998). Это касается и TCP пакетов. При следующем успешном соединении порты также различаются: 6977

и 8079 соответственно

Обычно, даже если клиент находится за NAT, порт источника в пакетах не подменяется. Проверьте, не работает ли какое-то устройство фильтрации пакетов между клиентом и сервером.

 

[Nikitanaev]

Проверьте, не работает ли какое-то устройство фильтрации пакетов между клиентом и сервером.

Проверим

При этом на стороне сервера пакет размером 2958 байт получен уже не был.

С чем это может быть связано и возможно ли это пофиксить?

И вопрос касаемо rtp_activity_timeout=10
Это означает, что если от клиента в течение 10 секунд не приходят медиаданные, то мы отключаем его. Почему не стоит увеличивать значение, чтобы дать клиенту больше времени на переподключение, в случае возникновения проблемы?

 

[Max]

С чем это может быть связано и возможно ли это пофиксить?

Пакеты могут не доходить до сервера из-за проблем в конфигурации роутера или фильтрации трафика. Других проблем, кроме эпизодических Out-of-Order пакетов (то есть TCP пакет дошел, но не в свое время), в дампах не видно.

И вопрос касаемо rtp_activity_timeout=10
Это означает, что если от клиента в течение 10 секунд не приходят медиаданные, то мы отключаем его. Почему не стоит увеличивать значение, чтобы дать клиенту больше времени на переподключение, в случае возникновения проблемы?

В течение времени, заданного параметром rtp_activity_timeout, сервер считает поток живым, даже если не получает аудио и видео данных. Если это время увеличить (например, вернуть к значению по умолчанию 60 секунд), то может возникнуть ситуация, при которой клиент уже отключился и хочет подключиться заново с тем же именем потока, но сервер не даст ему этого сделать, т.к. поток еще существует на сервере. В этом случае OBS переподключится значительно позже, а для зрителей будет больше перерыв в трансляции.

 

[Nikitanaev]

Если клиент отключился самостоятельно, то в логах мы видим это как normal disconnect. Или даже в этом случае этот параметр будет считать этот поток живым?
Основной вопрос, как это сработает в реальной ситуации. Если мы поставим этот параметр, например, на 30 секунд.
Из-за сетевой проблемы клиент перестал отправлять данные, например, в течении 10 секунд. Переподключение самим ОБС заняло 5 секунд.
Какое поведение нам стоит ожидать:
1. Разрыва не произойдет, тк поток считается еще живым
2. Разрыв произойдет, и пользователю придется ждать 15 секунд, чтобы иметь возможность переподключиться.

Возможно, нам стоит отказаться от этого параметра, если мы сталкиваемся с таким количеством проблем? Чем это будет чревато?

 

[Max]

Если клиент отключился самостоятельно, то в логах мы видим это как normal disconnect. Или даже в этом случае этот параметр будет считать этот поток живым?

Нет. Этот прараметр работает только в случае, если клиент не закрыл соединение, но перестал отправлять аудио и видео данные. При normal disconnect этот таймаут не запускается.

Основной вопрос, как это сработает в реальной ситуации. Если мы поставим этот параметр, например, на 30 секунд.
Из-за сетевой проблемы клиент перестал отправлять данные, например, в течении 10 секунд. Переподключение самим ОБС заняло 5 секунд.
Какое поведение нам стоит ожидать:
1. Разрыва не произойдет, тк поток считается еще живым
2. Разрыв произойдет, и пользователю придется ждать 15 секунд, чтобы иметь возможность переподключиться.

Если OBS остановил передачу данных на 10 секунд, но потом сам закрыл соединение, и сервер увидел, что соединение закрыто другой стороной, то таймаут не сработает.
А вот если OBS остановит передачу данных, потом закроет соединение на своей стороне, но до сервера не дойдет TCP FIN (например, если схлопнулся канал), то сервер будет считать поток живым, пока не истекут 30 секунд. И, даже если канал восстановится, OBS должен будет ждать 30 секунд, чтобы переподключиться.
То есть rtp_activity_timeout имеет смысл держать таким, чтобы, с одной стороны, не было ложных срабатываний (если, например, OBS остановил трафик на 5 секунд, а потом возобновил отправку, не переподключаясь), с другой стороны, чтобы не приходилось долго ждать переподключения.

По разрывам соединения. Похожее поведение может воспроизводиться при проблемах с виртуальной сетью, если сервер расположен на виртуалке. Поэтому, если проблемы с этим сервером воспроизводятся, рекомендуем перенести его в другой датацентр на другой хост или поднять новый железный сервер с более свежей версией Ubuntu (22.04 LTS).

 

[Nikitanaev]

По разрывам соединения. Похожее поведение может воспроизводиться при проблемах с виртуальной сетью, если сервер расположен на виртуалке. Поэтому, если проблемы с этим сервером воспроизводятся, рекомендуем перенести его в другой датацентр на другой хост или поднять новый железный сервер с более свежей версией Ubuntu (22.04 LTS).

У нас все сервера физические. Пробовали разные ДЦ: Варшава, Москва, Питер. На всех воспроизводится. Единственное, что отметили - на Origin в РФ эта проблема возникает реже, чем в Польше.
Попробуем обновить Ubuntu, о результатах напишем позже