timothy
6fa6dd76a0
PR Gates / CI image pin matches docker/ci (pull_request) Successful in 11s
Build ErsatzTV Image / API docs in sync (OpenAPI + endpoint index) (pull_request) Successful in 14s
PR Gates / Docs update reminder (pull_request) Successful in 14s
PR Gates / decisions lifecycle (pull_request) Successful in 26s
Build ErsatzTV Image / Build & test (.NET) (pull_request) Successful in 33s
Build ErsatzTV Image / Functional E2E (curl contracts) (pull_request) Successful in 32s
Build ErsatzTV Image / EF migration integrity (SQLite + MySql) (pull_request) Successful in 34s
Build ErsatzTV Image / Formatting (changed .cs conform to .editorconfig) (pull_request) Successful in 15s
Build ErsatzTV Image / Build & push image (amd64) (pull_request) Has been skipped
The skill told every session that music videos are typed "Movie" in Jellyfin. That described a deliberate DB reclassification workaround which existed only because ErsatzTV could not consume MusicVideo items. #42 shipped that sync (and #177 just extended it), so the workaround's premise is gone -- but the note outlived it and would send a session querying includeItemTypes=Movie and finding nothing. Verified live: the Music Videos library (/data/music, collection type "musicvideos") holds 1437 items typed MusicVideo and zero typed Movie. Also records two Jellyfin API traps found while working #177: - Album is NOT an ItemFields value. It is a plain BaseItemDto property serialized whenever set, so it returns regardless of `fields=` -- adding it there would be cargo-culted from Genres/People/Chapters, which ARE ItemFields. 111 of 1437 items returned Album with fields=Path alone. - IndexNumber is the track number; ParentIndexNumber is the disc/season axis. Frequency misleads: ParentIndexNumber is populated 16x more often (66 vs 4), but where both exist it is 1 while IndexNumber holds the real ordinal, and alone it is a collection grouping tracking the album. Scoped to this repo's copy. The canonical skill is owned by server-management and is corrected separately -- see the issue filed there. refs #177