diff --git a/docs/backlog/README.md b/docs/backlog/README.md index 807c431..f0c674a 100644 --- a/docs/backlog/README.md +++ b/docs/backlog/README.md @@ -45,6 +45,7 @@ Tududi (проект `jellybit`) больше **не** держит беклог - [Шум ERROR фоновых циклов при недоступной зависимости](oshibki-klassifikaciya-i-konvencii-logirovaniya.md) — Остаток задачи логирования: ext.* ERROR-шторм при недоступном qBittorrent + эскалация устойчивого сбоя тика _(ревью Fable)_ - [Версии/качество одного тайтла (репаки, апгрейд 1080p → 2160p)](versii-kachestvo-repaki.md) — По калибровке болей (2026-07-02) — не боль, из приоритета выпало - [[идея] Многоступенчатая верификация привязки](mnogostupenchataya-verifikaciya.md) — ИДЕЯ (требует проработки) +- [Согласование канона нумерации серий с провайдером тега](kanon-numeracii-vs-provajder.md) — Косметика/редкость: порядок просмотра ок, но у тайтлов со спорным порядком (Бибоп) Jellyfin подтягивает не те подписи серий, если канон файлов ≠ дефолтный порядок провайдера тега - [Выбор из нескольких находок метабазы в Telegram](telegram-vybor-nahodok.md) — Когда распознавание даёт несколько подходящих кандидатов в метабазе, предлагать их в… - [Улучшения UI: показывать матч с записью метабазы в Telegram](telegram-match-metabazy.md) — Название/год/провайдер+id в боте уже выводятся; осталась кликабельная ссылка на запись - [Добавление торрентов файлом/ссылкой — «единое окно» (остаток: URL)](dobavlenie-edinoe-okno.md) — magnet и .torrent-файл приняты; остался фетч .torrent по URL (нужен SSRF-гард) diff --git a/docs/backlog/kanon-numeracii-vs-provajder.md b/docs/backlog/kanon-numeracii-vs-provajder.md new file mode 100644 index 0000000..01a79dd --- /dev/null +++ b/docs/backlog/kanon-numeracii-vs-provajder.md @@ -0,0 +1,72 @@ +# Согласование канона нумерации серий с провайдером тега + +**Приоритет:** низкий + +Косметика и редкий случай: порядок просмотра не страдает (файлы уже +пронумерованы канонически и лежат по порядку), разъезжаются только подписи серий +в Jellyfin — не то название/описание у части эпизодов. Задевает лишь тайтлы с +исторически спорным порядком, таких мало. + +## Проблема + +У некоторых сериалов есть несколько *легитимных* порядков серий, и разные +метабазы придерживаются разных. Каноничный пример — «Ковбой Бибоп»: в титрах и +на дисках/IMDb/TVDB порядок «сессий» (Session #1 «Asteroid Blues» … #26), а TMDB +по своей политике нумерует по **самой ранней дате эфира**. Часть серий вышла +раньше на TV Tokyo вразнобой (2, 3, 7–15, 18) — при сортировке по дате они +всплывают вперёд, и диапазон ~1–18 перемешивается. Это не баг одной базы: оба +порядка «правильные», просто разные каноны. У TMDB канон отдаётся отдельной +episode group (тип DVD/production), у TVDB — отдельными order-типами +(Aired/DVD/Absolute). + +## Где это бьёт по jellybit (и где нет) + +jellybit **не** матчит серии по `(season, episode)` между провайдерами — +описанного класса бага у нас нет. Номер эпизода рождается из имён файлов через +LLM (`recognize.PlanFile.Episode`), проходит без изменений в раскладку и +печатается в `SxxEyy`; метабаза даёт лишь `SeasonEpisodeCounts` для гейта +полноты пака. То есть мы **доверяем нумерации релиз-группы** и про порядок вообще +не знаем. + +Настоящий риск — тихий и уже существует: + +> jellybit пишет `SxxEyy` **и** тег папки `[tmdbid-…]`/`[tvdbid-…]`. Дальше +> Jellyfin по этому тегу заново скрейпит серии у *того же* провайдера. Номер в +> имени файла и порядок, который ждёт скрейпер, обязаны быть **из одного +> канона** — иначе метаданные разъедутся на именно тех сериях. + +Для Бибопа: релиз почти всегда пронумерован канонически (session order). Если +матч ушёл на TVDB и написан `[tvdbid-…]` — Jellyfin скрейпит aired order TVDB, +для Бибопа = канон, всё сходится. Если матч ушёл на **TMDB** и написан +`[tmdbid-…]` — Jellyfin ждёт airing order TMDB (перемешанные 1–18), а файлы +канонические → метаданные поедут. Инвариант «канон нумерации файлов ↔ провайдер +тега» сейчас нигде не проверяется. + +## Что можно сделать (варианты, не решение) + +- **Минимум (дёшево, ценно):** осознать инвариант и эскалировать в review, когда + у распознанного тайтла провайдер матча — из тех, где порядок известно спорный + (episode groups у TMDB, absolute order у TVDB), а нумерация файлов может не + совпадать с дефолтным скрейп-порядком этого провайдера. Лучше явный вопрос + человеку, чем тихий разъезд. +- **Предпочтение провайдера тега:** для сериалов с известным расхождением тегать + папку провайдером, чей дефолтный порядок совпадает с каноном файлов (обычно + TVDB), даже если матч найден в TMDB. +- **Максимум:** знать про порядок явно — тянуть episode group (TMDB) / order-тип + (TVDB) и сверять нумерацию файлов с выбранным каноном. Требует, чтобы у нас + появилось понятие «канон эпизода», которого сейчас в модели нет (эпизодов как + сущностей в БД нет, план — JSON-блоб). + +## Связи + +- Тот же класс «у тайтла несколько легитимных порядков», что и + [Аниме с абсолютной нумерацией](anime-absolyutnaya-numeraciya.md) (absolute + order через TVDB) — стоит проработать совместно, возможно как одну тему. +- [Сложные сериальные раздачи](slozhnye-serialnye-razdachi.md) — соседний пласт + крайних случаев раскладки. +- Схема «локальная сущность каноническая, provider id — опциональный внешний + ключ» уже заложена (draft `logical-title-model.md`, сущность `title` осознанно + отвергнута) — эту же логику надо дотянуть до эпизодов/порядка, если пойдём в + «максимум». +- specs/recognition.md (гейт полноты пака, крайние случаи), specs/jellyfin-layout.md + (нумерация серий, тег провайдера), specs/review-ux.md (эскалация в review).