А что за проект вообще? Какие языки, какая архитектура, насколько сложная бизнес-логика? Ведь 50K строк могут быть как набором типовых CRUD-операций и бойлерплейта, так и довольно сложной системой. Само количество строк мало что говорит о сложности переноса.
И что за 700 тестов — unit, интеграционные или E2E? Какое покрытие? Для проекта в 50K строк само количество тестов мало о чём говорит, особенно при миграции между языками.
Не сомневаюсь, что Вы могли успешно перенести свой проект, но из Вашего описания пока не очень понятно, насколько полно проверена совместимость. Тем более что даже у флагманских моделей с такими задачами возникают серьёзные проблемы, о чём я выше привёл исследование.
И главное, даже если принять, что перенос полностью успешен, каким образом это подтверждает десятикратное преимущество DeepSeek по скорости закрытия задач? Особенно с учётом последующего ревью и исправлений старшими моделями.
Мне кажется, Вы делаете слишком широкие выводы из одного частного эксперимента.
Ради интереса проверил свою локальную историю Claude Code и Codex. У Sonnet 5.5 доля входных токенов из кэша составляет 99,1%, у Opus 5.5 — 99,4%, у GPT-6.1 Sol — 97,4%.
Скрытый текст
Не возможно, если перепроверять и исправлять на более взрослой модели перед комитом.
А зачем мне это делать, если я уже написал всё взрослой моделью? Напоминаю, речь о подписке.
Техдолг есть и на взрослых моделях.
Я с этим и не спорил, а говорил, что слабые модели, вероятно, чаще будут приводить к его накоплению.
Измерял на своем коде, с какой скоростью модель напишет 50к строк кода.
Корректность переноса тестировали? А условия переноса какие? Например, требовалось ли сохранить контракты, архитектуру, тесты? Скорость написания 50K строк кода вообще не показатель в реальной работе, ведь важен результат.
А ещё Вы в курсе, насколько сложен для coding-агентов перенос целого проекта между языками с сохранением поведения?
В свежем препринте SWE Refactor Bench только 5,4% из 520 запусков прошли полную проверку миграции, включая сохранение поведения. Причём при переносе между языками средний результат составил всего 5,6 балла из 100. Лучший результат среди протестированных моделей показал Claude Opus 5 (DeepSeek там вообще не участвовал).
Учитывая, что Вы сами признаёте преимущество Claude и GPT в качестве кода, интересно понять, насколько вообще уместно оценивать такую задачу по скорости генерации строк, если корректность итоговой реализации не подтверждена?
Так же по бенчмаркам более дешевые модели от Claude и GPT уступают в качестве кода и цене.
А какие конкретно модели и бенчмарки Вы сравнивали? По независимым замерам Artificial Analysis, GPT-6.1 Sol на Medium показывает 48% против 26,8% у DeepSeek V4.1 Flash на Terminal-Bench 4.0. Причём средняя стоимость задания в тестовом наборе — $0,21 против $0,27.
Даже Claude Haiku 5.5 на Xhigh немного опережает DeepSeek на этом тесте. А Sonnet 5.5 показывает уже 63,6%.
Поэтому утверждение, что младшие модели Claude и GPT одновременно хуже и дороже, выглядит слишком категоричным. Тем более что мы изначально обсуждали подписки, а не API.
Разница в скорости достигается за счет меньшего ограничения ресурсов оборудования по подписке...
А как Вы это проверяли? Сугубо по ощущениям?
...в подписке фиксированное количество токенов, без временных лимитов.
Насколько я понял, у QwenCloud лимиты всё-таки считаются в Credits, а не в фиксированном количестве токенов. Причём расход зависит от модели, соотношения входных и выходных токенов и кэширования. Система Credits не вполне прозрачна, поэтому однозначно сравнивать её с лимитами других подписок сложно.
Плюс лучшее кеширование в Deepseek v4.1 flash и Qwen 3.8 flash-next.
В чём именно лучшее кэширование — по hit rate, задержкам или стоимости? И с чем конкретно сравнивали?
Что лучше: сделать работу в 10 раз быстрее ценой 30% деградации кода, или в 10 раз медленее, но с лучшим качеством кода?
Звучит слишком громко. Как Вы измеряли это и учитывали ли время последующих исправлений?
Кроме того, при таком подходе есть риск накопления техдолга, которого более сильные модели могли бы избежать ещё на этапе реализации, тем самым сэкономив время в будущем. Разумеется, более сильная модель не гарантирует меньшего техдолга, но я исхожу из предположения, что в среднем она способна принимать более удачные технические решения.
Так я изначально и говорил об экономике подписок, а не API. Если даже по API стоимость закрытия задачи примерно одинаковая, то в чём тогда выгода DeepSeek относительно Claude Pro или Codex за $20?
А по скорости всё ещё не очень понимаю, откуда разница в десятки раз. Если речь об ожидании сброса лимитов, то это вопрос интенсивности использования подписки, а не скорости решения задачи самой моделью.
Я бы давно перешёл на DeepSeek, будь это для меня реально выгоднее. Помню, как у меня загорелись глаза, когда у них вышли модели V4. В итоге за неделю потратил $8 и решил свернуть эксперимент. Казалось бы, $32 в месяц — дешевле двух подписок за $40.
Решил поднять локальную историю OpenCode за тот период. Оказалось, что часть задач DeepSeek так и не довёл до рабочего состояния, а его код потом приходилось исправлять через Claude и GPT. Например, при реализации по фану VLESS REALITY на Rust DeepSeek не смог добиться рабочей совместимости с Xray, позже проблему исправлял Claude. В другой задаче с XUDP DeepSeek продолжал работу Claude, а затем Claude нашёл и исправил четыре конкретных бага, включая потерю данных и неправильную адресацию пакетов.
И это как раз к вопросу о стоимости закрытия задачи. Дешёвые токены не особо помогают, если потом приходится тратить время и лимиты другой модели на исправления.
А за $40 я получаю доступ к флагманским моделям Claude и GPT, причём для рутины могу использовать модели попроще, которые по ряду агентных бенчмарков всё равно превосходят DeepSeek.
Разумеется, это мой опыт, а не универсальный вывод. Но пока ни бенчмарки, ни собственная практика не убеждают меня в преимуществе DeepSeek по скорости получения готового результата.
В сентябре у клода вообще под $2K, но я там очень плотно его использовал и сбросил один раз недельный лимит в рамках акции с opus 5.5.
Пока не нашел ни одного независимого бенчмарка, который подтверждал бы Ваши слова. Судя по ним, Claude и GPT в сложных агентных задачах зачастую заметно сильнее DeepSeek.
Мой личный опыт тоже это не подтверждает, но не претендую на объективность.
Какой-то скрытой имбой DeepSeek не является. Дешевле по API, но это может нивелироваться большим числом иттераций для закрытия задачи. ИМХО, разумеется.
Там есть недельные лимиты и пятичасовые. Чихнуть и потратить не получится.
В моём проекте 62K строк кода. Очень часто юзаю Sonnet для рутинных задач и его хватает в моём графике лимитов. Opus для задач посложнее, но они не каждую неделю появляются.
Зависит от объёма задач в неделю. Если не хватает лимитов, то можно взять подписку дороже и это будет все еще выгодней API.
Я не ощутил выгоды DeepSeek, если брать подписку от Claude за $20. А эти часы пиковые, где дороже цена за токены вообще "песня". Если чисто API сравнивать, то да, DeepSeek по цена/качество норм, но только по этой метрике. Но если в Claude забанили, то есть Codex и он все равно за свои деньги гораздо лучше, по моему скромному мнению. Даже если брать подписку и там, и там — это выгодней, чем DeepSeek.
Смотря сколько человек зарабатывает, потому что разница по фактической доступности получается огромной. Даже обычные $20 за Claude для россиянина по отношению к доходу ощущаются примерно как $120 для американца. При этом для активного пользователя сама подписка Claude Pro за $20 может давать примерно в 5–8 раз больше использования, чем те же $20 через API, поэтому после блокировки аккаунта и перехода на API/агрегаторы разница становится ещё сильнее. Поэтому в случае бана просто переходят на Codex.
А ты использовал совместный просмотр в Jellyfin? Я этим не пользовался, смотрел его только как способ гонять видео с ПК на ТВ. У меня в плеере он сделан по-своему, интересно бы было сравнить
Сам не пользовался, но отзывы неоднозначные: рассинхроны, зависания, неожиданные паузы, плюс поддержка на разных клиентах неравномерная. Хотя есть конечно и те, у кого все работает. Планирую в ближайшее время сам потестить.
Раздачу кстати тоже можно включить, это одна галочка в настройках. Почему выключено по-дефолту я расписывал в другом комменте.
Например qBittorrent и TorrServer по дефолту разрешают upload, не пытаясь отдельно “защитить” пользователя от базового поведения протокола. Для фичи, куда пользователь сам приносит magnet-ссылку, разумнее считать P2P-поведение осознанным по умолчанию, а юридические риски явно обозначать в интерфейсе, чем молча превращать клиент в leech-only режим.
Если для отдельных юрисдикций upload действительно несёт дополнительные риски, это хороший повод показать предупреждение при первом использовании торрентов или дать явный выбор “раздавать/не раздавать”. Но делать leech-only универсальным дефолтом для всех пользователей — довольно странный выбор именно для торрент-клиента.
На лагучих ТВ (а они все лагучие в плане интерфейса) процесс открытия видео был долгим (раз 5 надо нажимать кнопки), и иногда клиент подключался к серверу не с первого раза
Бывало такое, но это обычно мелочь. Не могу сказать, чтобы прям значительно мешало, имхо.
Сериалы у меня в основном появлялись не как что-то структурированное, а просто как набор файлов в папке. Одной кнопкой на следующую серию не переключиться, приходилось выходить в папку и выбирать следующий файл, и выбор озвучки/субтитров между сериями не сохранялся. Возможно, при идеальном именовании это все работает, но с раздачами у меня так не выходило
Решается использованием Sonarr, который отвечает за скачивание и нормализацию названий серий, сериала по шаблонам. Через него можно настроить, например, чтобы при поиске рейтинг у раздач с 4K был выше, а с таким-то кодеком, которого нет на телике — ниже. Получаешь чаще всего качественный вариант автоматом. Еще я прикрутил Seerr и там вообще простой пайплайн получается: нашел фильм, нажал кнопку заказать, сервис сам в sonarr поставил его, далее sonarr поставил на скачивание в qBittorrent и потом уже в Jellyfin все доступно с описанием сериала, серий, рейтингами, лого сериала, пропуск интро/аутро через анализ видео/аудио, скроблингом в Yamtrack, Simkl, Shikimori.
Все привязано к ПК: сервер должен быть запущен (пару раз приходилось идти и поднимать его руками, хотя вроде все стояло в автозагрузке), файлы тоже должны лежать там. А иногда хотелось просто запустить что-то с мака на диване и отправить на ТВ. У меня это через Cast/DLNA, на телевизор вообще ничего ставить не надо.
Поднятие такого стека, как я описал, — это скорее осознанное решение на долгосрок. Преимущество Вашего подхода очевидно: он сильно проще и не требует постоянно работающего медиасервера.
Но для регулярного просмотра сериалов Jellyfin заметно удобнее, особенно если сериал длинный, смотришь с перерывами и хочется опыта, близкого к онлайн-кинотеатру: библиотека, история просмотров, продолжение с нужного места, сезоны и серии, постеры, метаданные и доступ с разных устройств. То есть это просто два разных сценария: у Вас — быстро открыть и отправить на ТВ, у Jellyfin — один раз настроить инфраструктуру и потом постоянно ей пользоваться. Даже доступ друзьям можно дать, которым вообще ничего не придется делать :)
Плюс Jellyfin хорошо закрывает более сложные сценарии с медиатекой. Например, у меня отдельной болью было аниме с внешними аудиодорожками. Локально mpv это умеет, и Ваш плеер, как я вижу, тоже научился автоматически их подхватывать. Но при Cast/DLNA это уже не переносится на телевизор как единый источник: DLNA отдаёт исходный файл как есть, а Cast готовит дорожку из аудиопотоков самого файла.
В Jellyfin внешние дорожки можно включить в общий серверный пайплайн, и дальше уже неважно, продолжаю я смотреть на компьютере, телефоне или телевизоре.
Но справедливости ради, вероятно при правильной настройке Jellyfin может с тем же транскодингом стримить на ТВ какой-нибудь тяжелый bluray, который бы лагал при “чистом” стриминге (но у меня обычно был одинаковый опыт - лагало и с Jellyfin, и с моим плеером. Мб как-то нужно было настроить сначала)
У меня как раз обратный опыт: если клиент умеет Direct Play, транскодинг там вообще не нужен. Я спокойно смотрел через Jellyfin 4K Blu-ray ремуксы “Властелина колец” примерно по 130 ГБ каждый без каких-либо лагов. Причём телевизор подключён по Wi-Fi 5 ГГц — Ethernet-порт у него вообще 100 Мбит/с, хотя сам телевизор 2025 года :)
Более того, в админке Jellyfin в реальном времени видно, что происходит с конкретным клиентом: идёт Direct Play, ремукс или полноценный транскодинг, и по какой причине он был включён.
Тут ведь важен не размер файла сам по себе, а его битрейт, пропускная способность сети и то, умеет ли клиент декодировать исходный формат. В нормальной локальной сети даже довольно большой 4K-ремукс не представляет чего-то необычного. А транскодинг нужен уже тогда, когда клиент не понимает исходный кодек/контейнер/аудио либо когда ты сам ограничиваешь качество на клиенте: например, ставишь лимит 50 Мбит/с, и всё, что выше него, Jellyfin уже будет пережимать под этот предел.
Есть альтернатива — использовать Jellyfin и сопутствующие ему сервисы. Есть клиент для каждой популярной платформы (и ТВ), веб-интерфейс, система плагинов для сервера и даже совместный просмотр с друзьями.
Конечно, я понимаю, что это гораздо сложнее все развернуть и поддерживать неподготовленному пользователю, но это прям другой опыт в лучшую сторону, имхо. А главное, что скачанные фильмы раздаются до ratio >= 1 при настройке в *arr, чтобы помочь другим и не быть забаненным на маленьких трекерах (например, кинозал).
Есть минус, что стабильно нельзя смотреть скачивающиеся фильмы (и да, это реальная боль), но я мирюсь с этим…
Нет, он не путает. В Уругвае и ставки налогов, и общая налоговая нагрузка существенно выше. При этом аналоги СБП есть в обеих странах.
Такая длинная!
А что за проект вообще? Какие языки, какая архитектура, насколько сложная бизнес-логика? Ведь 50K строк могут быть как набором типовых CRUD-операций и бойлерплейта, так и довольно сложной системой. Само количество строк мало что говорит о сложности переноса.
И что за 700 тестов — unit, интеграционные или E2E? Какое покрытие? Для проекта в 50K строк само количество тестов мало о чём говорит, особенно при миграции между языками.
Не сомневаюсь, что Вы могли успешно перенести свой проект, но из Вашего описания пока не очень понятно, насколько полно проверена совместимость. Тем более что даже у флагманских моделей с такими задачами возникают серьёзные проблемы, о чём я выше привёл исследование.
И главное, даже если принять, что перенос полностью успешен, каким образом это подтверждает десятикратное преимущество DeepSeek по скорости закрытия задач? Особенно с учётом последующего ревью и исправлений старшими моделями.
Мне кажется, Вы делаете слишком широкие выводы из одного частного эксперимента.
Ради интереса проверил свою локальную историю Claude Code и Codex. У Sonnet 5.5 доля входных токенов из кэша составляет 99,1%, у Opus 5.5 — 99,4%, у GPT-6.1 Sol — 97,4%.
Скрытый текст
А зачем мне это делать, если я уже написал всё взрослой моделью? Напоминаю, речь о подписке.
Я с этим и не спорил, а говорил, что слабые модели, вероятно, чаще будут приводить к его накоплению.
Корректность переноса тестировали? А условия переноса какие? Например, требовалось ли сохранить контракты, архитектуру, тесты? Скорость написания 50K строк кода вообще не показатель в реальной работе, ведь важен результат.
А ещё Вы в курсе, насколько сложен для coding-агентов перенос целого проекта между языками с сохранением поведения?
В свежем препринте SWE Refactor Bench только 5,4% из 520 запусков прошли полную проверку миграции, включая сохранение поведения. Причём при переносе между языками средний результат составил всего 5,6 балла из 100. Лучший результат среди протестированных моделей показал Claude Opus 5 (DeepSeek там вообще не участвовал).
Учитывая, что Вы сами признаёте преимущество Claude и GPT в качестве кода, интересно понять, насколько вообще уместно оценивать такую задачу по скорости генерации строк, если корректность итоговой реализации не подтверждена?
А какие конкретно модели и бенчмарки Вы сравнивали? По независимым замерам Artificial Analysis, GPT-6.1 Sol на Medium показывает 48% против 26,8% у DeepSeek V4.1 Flash на Terminal-Bench 4.0. Причём средняя стоимость задания в тестовом наборе — $0,21 против $0,27.
Даже Claude Haiku 5.5 на Xhigh немного опережает DeepSeek на этом тесте. А Sonnet 5.5 показывает уже 63,6%.
Поэтому утверждение, что младшие модели Claude и GPT одновременно хуже и дороже, выглядит слишком категоричным. Тем более что мы изначально обсуждали подписки, а не API.
А как Вы это проверяли? Сугубо по ощущениям?
Насколько я понял, у QwenCloud лимиты всё-таки считаются в Credits, а не в фиксированном количестве токенов. Причём расход зависит от модели, соотношения входных и выходных токенов и кэширования. Система Credits не вполне прозрачна, поэтому однозначно сравнивать её с лимитами других подписок сложно.
В чём именно лучшее кэширование — по hit rate, задержкам или стоимости? И с чем конкретно сравнивали?
Звучит слишком громко. Как Вы измеряли это и учитывали ли время последующих исправлений?
Кроме того, при таком подходе есть риск накопления техдолга, которого более сильные модели могли бы избежать ещё на этапе реализации, тем самым сэкономив время в будущем. Разумеется, более сильная модель не гарантирует меньшего техдолга, но я исхожу из предположения, что в среднем она способна принимать более удачные технические решения.
Так я изначально и говорил об экономике подписок, а не API. Если даже по API стоимость закрытия задачи примерно одинаковая, то в чём тогда выгода DeepSeek относительно Claude Pro или Codex за $20?
А по скорости всё ещё не очень понимаю, откуда разница в десятки раз. Если речь об ожидании сброса лимитов, то это вопрос интенсивности использования подписки, а не скорости решения задачи самой моделью.
Я бы давно перешёл на DeepSeek, будь это для меня реально выгоднее. Помню, как у меня загорелись глаза, когда у них вышли модели V4. В итоге за неделю потратил $8 и решил свернуть эксперимент. Казалось бы, $32 в месяц — дешевле двух подписок за $40.
Решил поднять локальную историю OpenCode за тот период. Оказалось, что часть задач DeepSeek так и не довёл до рабочего состояния, а его код потом приходилось исправлять через Claude и GPT. Например, при реализации по фану VLESS REALITY на Rust DeepSeek не смог добиться рабочей совместимости с Xray, позже проблему исправлял Claude. В другой задаче с XUDP DeepSeek продолжал работу Claude, а затем Claude нашёл и исправил четыре конкретных бага, включая потерю данных и неправильную адресацию пакетов.
И это как раз к вопросу о стоимости закрытия задачи. Дешёвые токены не особо помогают, если потом приходится тратить время и лимиты другой модели на исправления.
А за $40 я получаю доступ к флагманским моделям Claude и GPT, причём для рутины могу использовать модели попроще, которые по ряду агентных бенчмарков всё равно превосходят DeepSeek.
Разумеется, это мой опыт, а не универсальный вывод. Но пока ни бенчмарки, ни собственная практика не убеждают меня в преимуществе DeepSeek по скорости получения готового результата.
Скрытый текст
В сентябре у клода вообще под $2K, но я там очень плотно его использовал и сбросил один раз недельный лимит в рамках акции с opus 5.5.
Пока не нашел ни одного независимого бенчмарка, который подтверждал бы Ваши слова. Судя по ним, Claude и GPT в сложных агентных задачах зачастую заметно сильнее DeepSeek.
Мой личный опыт тоже это не подтверждает, но не претендую на объективность.
Какой-то скрытой имбой DeepSeek не является. Дешевле по API, но это может нивелироваться большим числом иттераций для закрытия задачи. ИМХО, разумеется.
Читал статью, как триллер. Было чувство зловещей долины. Так держать! :)
Radarr в помощь. Он умеет класть фильм в отдельную папку после скачивания и добавлять год после названия.
Там есть недельные лимиты и пятичасовые. Чихнуть и потратить не получится.
В моём проекте 62K строк кода. Очень часто юзаю Sonnet для рутинных задач и его хватает в моём графике лимитов. Opus для задач посложнее, но они не каждую неделю появляются.
Зависит от объёма задач в неделю. Если не хватает лимитов, то можно взять подписку дороже и это будет все еще выгодней API.
Я не ощутил выгоды DeepSeek, если брать подписку от Claude за $20. А эти часы пиковые, где дороже цена за токены вообще "песня". Если чисто API сравнивать, то да, DeepSeek по цена/качество норм, но только по этой метрике. Но если в Claude забанили, то есть Codex и он все равно за свои деньги гораздо лучше, по моему скромному мнению. Даже если брать подписку и там, и там — это выгодней, чем DeepSeek.
Блин, даже не получится пошутить про "в России самые большие LLM-модели" ;(
Смотря сколько человек зарабатывает, потому что разница по фактической доступности получается огромной. Даже обычные $20 за Claude для россиянина по отношению к доходу ощущаются примерно как $120 для американца. При этом для активного пользователя сама подписка Claude Pro за $20 может давать примерно в 5–8 раз больше использования, чем те же $20 через API, поэтому после блокировки аккаунта и перехода на API/агрегаторы разница становится ещё сильнее. Поэтому в случае бана просто переходят на Codex.
Сам не пользовался, но отзывы неоднозначные: рассинхроны, зависания, неожиданные паузы, плюс поддержка на разных клиентах неравномерная. Хотя есть конечно и те, у кого все работает. Планирую в ближайшее время сам потестить.
Например qBittorrent и TorrServer по дефолту разрешают upload, не пытаясь отдельно “защитить” пользователя от базового поведения протокола. Для фичи, куда пользователь сам приносит magnet-ссылку, разумнее считать P2P-поведение осознанным по умолчанию, а юридические риски явно обозначать в интерфейсе, чем молча превращать клиент в leech-only режим.
Если для отдельных юрисдикций upload действительно несёт дополнительные риски, это хороший повод показать предупреждение при первом использовании торрентов или дать явный выбор “раздавать/не раздавать”. Но делать leech-only универсальным дефолтом для всех пользователей — довольно странный выбор именно для торрент-клиента.
Бывало такое, но это обычно мелочь. Не могу сказать, чтобы прям значительно мешало, имхо.
Решается использованием Sonarr, который отвечает за скачивание и нормализацию названий серий, сериала по шаблонам. Через него можно настроить, например, чтобы при поиске рейтинг у раздач с 4K был выше, а с таким-то кодеком, которого нет на телике — ниже. Получаешь чаще всего качественный вариант автоматом. Еще я прикрутил Seerr и там вообще простой пайплайн получается: нашел фильм, нажал кнопку заказать, сервис сам в sonarr поставил его, далее sonarr поставил на скачивание в qBittorrent и потом уже в Jellyfin все доступно с описанием сериала, серий, рейтингами, лого сериала, пропуск интро/аутро через анализ видео/аудио, скроблингом в Yamtrack, Simkl, Shikimori.
Поднятие такого стека, как я описал, — это скорее осознанное решение на долгосрок. Преимущество Вашего подхода очевидно: он сильно проще и не требует постоянно работающего медиасервера.
Но для регулярного просмотра сериалов Jellyfin заметно удобнее, особенно если сериал длинный, смотришь с перерывами и хочется опыта, близкого к онлайн-кинотеатру: библиотека, история просмотров, продолжение с нужного места, сезоны и серии, постеры, метаданные и доступ с разных устройств. То есть это просто два разных сценария: у Вас — быстро открыть и отправить на ТВ, у Jellyfin — один раз настроить инфраструктуру и потом постоянно ей пользоваться. Даже доступ друзьям можно дать, которым вообще ничего не придется делать :)
Плюс Jellyfin хорошо закрывает более сложные сценарии с медиатекой. Например, у меня отдельной болью было аниме с внешними аудиодорожками. Локально mpv это умеет, и Ваш плеер, как я вижу, тоже научился автоматически их подхватывать. Но при Cast/DLNA это уже не переносится на телевизор как единый источник: DLNA отдаёт исходный файл как есть, а Cast готовит дорожку из аудиопотоков самого файла.
В Jellyfin внешние дорожки можно включить в общий серверный пайплайн, и дальше уже неважно, продолжаю я смотреть на компьютере, телефоне или телевизоре.
У меня как раз обратный опыт: если клиент умеет Direct Play, транскодинг там вообще не нужен. Я спокойно смотрел через Jellyfin 4K Blu-ray ремуксы “Властелина колец” примерно по 130 ГБ каждый без каких-либо лагов. Причём телевизор подключён по Wi-Fi 5 ГГц — Ethernet-порт у него вообще 100 Мбит/с, хотя сам телевизор 2025 года :)
Более того, в админке Jellyfin в реальном времени видно, что происходит с конкретным клиентом: идёт Direct Play, ремукс или полноценный транскодинг, и по какой причине он был включён.
Тут ведь важен не размер файла сам по себе, а его битрейт, пропускная способность сети и то, умеет ли клиент декодировать исходный формат. В нормальной локальной сети даже довольно большой 4K-ремукс не представляет чего-то необычного. А транскодинг нужен уже тогда, когда клиент не понимает исходный кодек/контейнер/аудио либо когда ты сам ограничиваешь качество на клиенте: например, ставишь лимит 50 Мбит/с, и всё, что выше него, Jellyfin уже будет пережимать под этот предел.
Есть альтернатива — использовать Jellyfin и сопутствующие ему сервисы. Есть клиент для каждой популярной платформы (и ТВ), веб-интерфейс, система плагинов для сервера и даже совместный просмотр с друзьями.
Конечно, я понимаю, что это гораздо сложнее все развернуть и поддерживать неподготовленному пользователю, но это прям другой опыт в лучшую сторону, имхо. А главное, что скачанные фильмы раздаются до ratio >= 1 при настройке в *arr, чтобы помочь другим и не быть забаненным на маленьких трекерах (например, кинозал).
Есть минус, что стабильно нельзя смотреть скачивающиеся фильмы (и да, это реальная боль), но я мирюсь с этим…
Хорошо, что я увидел Ваш коммент, так как только хотел написать об этом!
44 лайка у поста пятичасовой давности и ни одного коммента? Странно…
Подписка гораздо дешевле обходится, поэтому именно её и берут.
Так было и 10 лет назад, а сейчас вообще пропасть, мне кажется