xupnpd - eXtensible UPnP agent

[mesb]

Ну вообще, учитывая что у меня набор подписок редко меняется, меня эта проблема начала преследовать относительно недавно.
До этого был перерыв и всё было стабильно.

[ZigZag]

Ну вообще, учитывая что у меня набор подписок редко меняется, меня эта проблема начала преследовать относительно недавно.
До этого был перерыв и всё было стабильно.

В своих примочках я использую ютубовские плейлисты и там со свежими видяшками часто такая херня происходит минимум полгода, а то и больше. Просто я тогда не увязывал проблемы с 720p и тупо игнорировал проблему. Иногда ютуб отдупливался и отдавал спустя какое-то время 720p и приоритет проблемы снова понижался. А тут я таки заморочился. Вот к слову, ещё один образчик https://www.youtube.com/watch?v=ZBMJl9J90Os Даже подготовил лог загрузки youtube-dl, но он таки не пригодился, т.к. issue прихлопнули

 

bash-4.4# youtube-dl -v -f 22 'https://www.youtube.com/watch?v=ZBMJl9J90Os'
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-v', u'-f', u'22', u'https://www.youtube.com/watch?v=ZBMJl9J90Os']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2020.11.17
[debug] Python version 2.7.14 (CPython) - Linux-3.10.65-aarch64-with-glibc2.4
[debug] exe versions: ffmpeg 3.3.2
[debug] Proxy map: {}
[youtube] ZBMJl9J90Os: Downloading webpage
[debug] Invoking downloader on u'https://r4---sn-gvnuxaxjvh-3i8l.googlevideo.com/videoplayback?expire=1605694267&ei=2560X-DmL4iBpASm0aeoCQ&ip=x.x.x.x&id=o-AGPWekWJLL_z9fDC2FYjZO1nUALr_Fz3zEw_bu_aAQO1&itag=22&source=youtube&requiressl=yes&mh=Yn&mm=31%2C29&mn=sn-gvnuxaxjvh-3i8l%2Csn-n8v7kn7k&ms=au%2Crdu&mv=m&mvi=4&pl=18&initcwndbps=1175000&vprv=1&mime=video%2Fmp4&ns=TPJca99oNnMTCkzG2za0L9IF&ratebypass=yes&dur=2127.505&lmt=1605634610900454&mt=1605672538&fvip=13&c=WEB&txp=3416222&n=uxnoVNFUdZ-kwL-&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Cmime%2Cns%2Cratebypass%2Cdur%2Clmt&sig=AOq0QJ8wRAIgVo1rfe_wpwvW-In2qEmSr83AYfeYBCfijfrr1A6pzcUCIFRgLJqaOKC652tJ0g_hgRP11mroO2RiJRHsSqVGWfSr&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRAIgJ9-G-K7HDu7TidJwNTMO73-YykV8hzFOyW3YiizrVGwCIF1DfUr01tJ_fpeqh0WauKHlNKUuHtUbM5BJTFbr0u1d'
[download] Destination: 'Сегодня' - 17 ноября 2020 года. 19_00-ZBMJl9J90Os.mp4
[download] 0.1% of 450.64MiB at 83.62KiB/s ETA 01:31:56[download] Got server HTTP error: Downloaded 244960 bytes, expected 472534522 bytes. Retrying (attempt 1 of 10)...
[download] Destination: 'Сегодня' - 17 ноября 2020 года. 19_00-ZBMJl9J90Os.mp4
[download] 0.1% of 450.64MiB at 1.64MiB/s ETA 04:35[download] Got server HTTP error: Downloaded 459272 bytes, expected 472534522 bytes. Retrying (attempt 2 of 10)...
[download] Got server HTTP error: HTTP Error 503: Service Unavailable. Retrying (attempt 3 of 10)...
[download] Destination: 'Сегодня' - 17 ноября 2020 года. 19_00-ZBMJl9J90Os.mp4
[download] 0.2% of 450.64MiB at 125.34KiB/s ETA 01:01:15[download] Got server HTTP error: Downloaded 786432 bytes, expected 472534522 bytes. Retrying (attempt 4 of 10)...
[download] Got server HTTP error: HTTP Error 503: Service Unavailable. Retrying (attempt 5 of 10)...
[download] Got server HTTP error: HTTP Error 503: Service Unavailable. Retrying (attempt 6 of 10)...
[download] Got server HTTP error: HTTP Error 503: Service Unavailable. Retrying (attempt 7 of 10)...
[download] Got server HTTP error: HTTP Error 503: Service Unavailable. Retrying (attempt 8 of 10)...
[download] Got server HTTP error: HTTP Error 503: Service Unavailable. Retrying (attempt 9 of 10)...
[download] Got server HTTP error: HTTP Error 503: Service Unavailable. Retrying (attempt 10 of 10)...
ERROR: giving up after 10 retries
Traceback (most recent call last):
File "/opt/bin/youtube-dl/youtube_dl/downloader/http.py", line 349, in real_download
establish_connection()
File "/opt/bin/youtube-dl/youtube_dl/downloader/http.py", line 187, in establish_connection
raise RetryDownload(err)
RetryDownload

Свернуть

Ну ОК, чё. Как только проблема станет массовой и народ начнёт создавать аналогичные запросы, то про мой issue вспомнят и начнут решать проблему ибо с прямыми линками на 720p из браузера проблем нет. Там похоже какая-то иная схема для получения ссылок используется, нежели та, что применяется в youtube-dl. Иначе бы 720p не работало в браузере тоже и по прямым ссылкам из него видяшки бы спокойно не качались без каких-либо ошибок.

[ZigZag]

Примечательно, но браузерная 720p версия отличается от загружаемой youtube-dl. У браузерной версии ролика 7Z3u88lBtiM Content-Length - 118001468 (112 Мб), а у версии youtube-dl - 137225562 (130 Мб). Т.е. то, что отдаётся браузером в данном случае отличается от того, что пытается стянуть youtube-dl.

p.s. Очередная 720p поломашка https://www.youtube.com/watch?v=2syhvVeL7nk
p.p.s Я их специально не ищу ))) Просто врубаю свежий новостной выпуск как обычно и он к чёрту валится.

[mesb]

Я надеюсь вы это всё проверяете запуская на одной и тойже машине то?

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

Источник цитаты Т.е. то, что отдаётся браузером в данном случае отличается от того, что пытается стянуть youtube-dl

А вот это в тикетосе ютубдл упоминалось?

[ZigZag]

А вот это в тикетосе ютубдл упоминалось?

Отличия в размере (ака Content-Length) были замечены уже после прихлопывания тикета. Ну и справедливости ради, в тикете я написал

Direct links to 720p videos (22) extracted via youtube-dl via links https://www.youtube.com/watch?v=7Z3u88lBtiM , https://www.youtube.com/watch?v=pjuukLUCEac and https://www.youtube.com/watch?v=VUtJR8qOF-U are not played via VLC or downloaded via curl or browser (with 360p everything is OK), but through the browser (via youtube web interface) 720p it is played and downloaded (via flashgot, mp4, not dash). youtube-dl also downloads part of the file with errors.

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

But through the browser, videos from YouTube in 720p are downloaded and played. WITHOUT any errors. Direct links from the browser to 720p videos are loaded via curl without errors. Direct links to 720p video extracted via youtube-dl fail when downloading via curl

но комментарий остался без внимания и был проигнорирован. Могу снова написать там про различия в габаритах или этот комментарий тоже проигнорируют ? Наверное лучше новый тикет тогда открыть ? Я хз.

p.s. К слову. Один раз youtube-d утянул 720p видео 7Z3u88lBtiM размером в 260 мб и оно даже воспроизводилось, но мне тогда показалось что он тогда тупо скачал битый файл и кучу нулей надобавлял. Проверить Content-Length и глянуть файл хекс-редактором я не сообразил и удалил его. Хотя логи остались, посмотрю, что там было с Content-Length.

p.p.s. Очередной "слом". Что-то многовато их в последнее время развелось. До этого не так часто было.

[mesb]

А старых версий ютубдл не пробовали?

[ZigZag]

А старых версий ютубдл не пробовали?

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

p.s. Интересно сервер по прямой ссылке youtube-dl отдаёт данные. Закачка велась в 4 секции/потока и секции 2,3,4 уже успели скачаться, а первая вознобновлялась по кругу с ошибками. Мб имеет смысл форсировать всю эту историю на уровне проксика ? Реализовать что-то типа skip-size ? Т.е. если сервер отдаёт кривоватые хедеры или сбрасывает коннект, попробовать скипнуть заданный отдельным ключом кусок данных (тот самый skip-size) и начать брать данные чуть дальше ? Т.е. пропустить 3 - 5 минут воспроизведения, но зато воспроизвести, чем сбросить ролик целиком.

[mesb]

И потерять четверть ролика?
Эт чот такое себе кмк.

А есть вопроизводимость, система какая-то?

[ZigZag]

И потерять четверть ролика?
Эт чот такое себе кмк.

Не четверть. Это просто DM так качал. Речь о задаваемом размере пропуска. В мегабайтах или минутах. Надо будет с ранжированием в curl'e поиграться, там по моему от начала скипнется секунд 10 - 30, тут затык именно в начале стартового блока. Я думаю ими можно будет пожертвовать, дабы не сбрасывать ролик целиком.

А есть вопроизводимость, система какая-то?

Не отслеживал. Возможно сервер, возможно хедеры, возможно что-то ещё.

upd: Накидал в issue ещё ссылок-поломашек, прошлый лог и упомянул про разницу в габаритах файлов по ссылкам из браузера и youtube-dl. Не пропадать же набранным данным

[mesb]

А вот этот момент с разными ссылками и контент длинной - на потоках для 360p проявляется?

И пробовали ли вы поломашки с разных хостов дёргать, есть ли разница в размерах?