И это не нормально. Это вне http/rtsp, какая то особенность устройства которую надо знать и в логах этого не видно. Ну или не там смотрю.
Снова вспоминается sat>ip, где в результате получилось, что есть штатный софт - который работает, и ProgTV который работает через пень колоду. И вся история ни пользователям ненужна, ни мне, потому что портит репутациюю

На данном этапе может быть всего 4 причины косяков и предельно понятно как их проверить и устранить:
1. Отличие формы запроса от оригинала.
2. Отличие порядка следования запросов от оригинала.
3. Некорректные интервалы между запросами ( отсутствие необходимой паузы и/ или длительное отсутствие запросов).
4 Косяк в приложении при обработке ответа ресивера.
С чего начнем?

1. Нету отличий.
2. Ни в rtsp ни http нет последовательности строк. Все кроме первой могут идти как угодно. Неизественые серверу строки тоже могут быть в любом количествею
3. Сомнительно. Мешьей задержки не получить, Большая - зачем?
4. Дак нету ответа. Есть "конфликт" или "нет конктента" или вовсе отсутвие ответа на setup.

1. в оригинале другая длина сообщения ( всегда на 2 больше правильной !) - исправили?
2. Я в данном пункте про порядок следования запросов, а не строк в запросе.
3. Зачем задержка между запросами - например, переключение каналов - процесс не мгновенный и возможно, что какое то время ресивер неправильно реагирует на следующий запрос.
4. В моих экспериментах "конфликт" возникал когда в установившийся обмен лез второй клиент с другим UA. В нашем случае это может быть результатом нарушения порядка следования запросов. Мы же с середины начали, а нужно по порядку
" Нет контента" - это такой же ответ, как в оригинале. У них он просмотру не мешает, я бы не парился по этому поводу.

. Ни в rtsp ни http нет последовательности строк. Все кроме первой могут идти как угодно. Неизественые серверу строки тоже могут быть в любом количествею
- Где гарантия, что ребятки из GS не накосячил или не сделали капканчик для разработчиков стороннего софта? Да и совет " тупо скопировать запросы" тоже в эту же тему.

Не исключено. Но я реально уже эксперментов десятки делал. В том числе и копией ваших логов. Всё равно PUT и SETUP не работают. Не чуствую какой то зависимости от самих запросов.

Насчёт длинны - это же не абстрактная цифра - а длинна json строки. Если у меня длиннее, значит у меня должны быть лишние символы. А они есть?
В конце концов можно посчитать строки там и тут

Включаем логику. Сейчас у нас самым первым стоит put, который косячит и может влиять на setup.
И мы тут упёрлись.
Предлагаю обходной вариант - слать запросы в том же порядке, что у оригинала, начиная с самого первого ( на скриншоте в первом посте темы). Там много неинтересных запросов, но зато put идёт намного позже получения ссылки на поток и воспроизведения.
То есть даже если косяк в нем , он не будет влиять на просмотр вообще никак. У них запускается последний просматриваемый канал.
Зачем нам искать приключений и делать по другому?

Пауза между запросами всё-таки нужна: Для просмотра переименовать в 500.txt

50 55 54 20 2f 76 31 2e 33 2f 63 68 61 6e 6e 65 PUT /v1. 3/channe
6c 73 2f 63 75 72 72 65 6e 74 20 48 54 54 50 2f ls/curre nt HTTP/
31 2e 31 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 1.1..Con tent-Typ
65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6a e: appli cation/j
73 6f 6e 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e son..Con tent-Len
67 74 68 3a 20 34 34 0d 0a 55 73 65 72 2d 41 67 gth: 44. .User-Ag
65 6e 74 3a 20 44 61 6c 76 69 6b 2f 32 2e 31 2e ent: Dal vik/2.1.
30 20 28 4c 69 6e 75 78 3b 20 55 3b 20 41 6e 64 0 (Linux ; U; And
72 6f 69 64 20 35 2e 31 2e 31 3b 20 4c 65 6e 6f roid 5.1 .1; Leno
76 6f 20 54 42 32 2d 58 33 30 4c 20 42 75 69 6c vo TB2-X 30L Buil
64 2f 4c 65 6e 6f 76 6f 54 42 32 2d 58 33 30 4c d/Lenovo TB2-X30L
29 0d 0a 48 6f 73 74 3a 20 31 39 32 2e 31 36 38 )..Host: 192.168
2e 30 2e 31 30 30 3a 35 30 30 30 30 0d 0a 43 6f .0.100:5 0000..Co
6e 6e 65 63 74 69 6f 6e 3a 20 4b 65 65 70 2d 41 nnection : Keep-A
6c 69 76 65 0d 0a 41 63 63 65 70 74 2d 45 6e 63 live..Ac cept-Enc
6f 64 69 6e 67 3a 20 67 7a 69 70 0d 0a 0d 0a 7b oding: g zip....{
22 63 68 61 6e 6e 65 6c 4c 69 73 74 49 64 22 3a "channel ListId":
22 54 56 22 2c 22 63 68 61 6e 6e 65 6c 4e 75 6d "TV","ch annelNum
62 65 72 22 3a 34 31 35 7d 0d 0a ber":415 }..

Это у них после строки ещё и /r/n добавлены. Но я и так уже пробовал...

Сейчас смотрел, у них от запроса rtsp ссылки до работы с rtsp примерно 2 сек ( там без долей секунд, может на самом деле 1-3 сек).
Вдруг это критично?

Точно нашел косяк!!!!!
Transport: RTP/AVP;unicast;client_port=56543-56544
Первый порт должен быть чётный !!!!!

Да ну. Такие мелочи были важны в 90ых когда rtsp делали. Сейчас не важною
В сегодней версии сделаю там чётные, но у меня без измененийю setup так же висит.

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

А это про что картинка?