A playlist member is kept from a library upstream will not draw from #237

New issue

Closed

opened 2026-09-16 06:28:08 +02:00 by Claude · 1 comment

Claude commented

2026-09-16 06:28:08 +02:00

Collaborator

A playlist's members are resolved against what exists on disk. Upstream additionally requires the resolved file to sit inside a library it is willing to draw from.

Both sides

Upstream's TryResolvePlaylistItem keeps a name only when the resolved path starts with the physical location of a library whose collection type is not livetv, boxsets or playlists.

Ours (crates/ephyra-app/src/scan/playlists.rs:69-106) keeps any name that resolves, and the link is then written only if a scanned row carries that path — so nothing escapes into the filesystem at large, but the three excluded kinds are not excluded.

What differs

A .m3u naming a file that lives inside a box-set or playlist library is linked here and dropped upstream. Both servers show the playlist; ours shows a member upstream does not.

Verifying

The library-kinds tree already carries playlists and several library kinds. A list naming a file inside one of the three excluded kinds, regenerated, shows upstream dropping it.

Found reviewing #230.

A playlist's members are resolved against what exists on disk. Upstream additionally requires the resolved file to sit inside a library it is willing to draw from. ## Both sides Upstream's `TryResolvePlaylistItem` keeps a name only when the resolved path starts with the physical location of a library whose collection type is not `livetv`, `boxsets` or `playlists`. Ours (`crates/ephyra-app/src/scan/playlists.rs:69-106`) keeps any name that resolves, and the link is then written only if a scanned row carries that path — so nothing escapes into the filesystem at large, but the three excluded kinds are not excluded. ## What differs A `.m3u` naming a file that lives inside a box-set or playlist library is linked here and dropped upstream. Both servers show the playlist; ours shows a member upstream does not. ## Verifying The library-kinds tree already carries playlists and several library kinds. A list naming a file inside one of the three excluded kinds, regenerated, shows upstream dropping it. Found reviewing #230.

Claude referenced this issue

2026-09-16 06:56:48 +02:00

A scanned playlist is filed with no members and a null blob #230

Claude referenced this issue

2026-09-16 07:42:05 +02:00

A playlist name spelled with different accent normalization loses its member #238

Claude commented

2026-09-16 16:27:42 +02:00

Author

Collaborator

Fixed, and landed on main at 60dd4302.

A playlist file keeps a member only from a library the server draws from. Upstream builds that set from the libraries whose collection type is both known and not livetv, boxsets or playlists, and keeps a name only when the resolved path starts with one of their locations — a raw prefix, so /media/music covers /media/musicals there as it does here.

The half that does the work in practice is the "known" one: a mixed library writes a mixed.collection marker, but the enum upstream parses it into has no mixed member, so the parse fails, the type stays null, and no member is drawn from a mixed library at all. This port registers none of the three ignored kinds, so the rule reduces to that.

A folder-shaped playlist is not filtered: upstream's items provider returns before any of this for a directory, and the playlist.xml reader keeps what it names with no library check and no existence check. The review caught the first fix applying the filter to both.

What the key measures. The tree gained cross-library names in three lists and a playlist.xml in the mixed library. Upstream filed:

mixed/Loose List.m3u — the mixed-library name dropped, one music-library member, blob Unknown;
mixed/Inner List.m3u — no members, and the resolver's Audio left standing, because a list emptied by the filter never reaches the merge that would overwrite it;
music/Loose List.m3u — the mixed-library name dropped;
mixed/Mix [playlist] — both members kept, including the one reaching into another library, since a folder is not filtered.

The comparison fails in both directions if either rule is wrong, and the selection itself is now a function the test calls rather than a rule the test re-derives.

Filed while doing it: #238, a name spelled with different accent normalization loses its member, where upstream retries both spellings.

Fixed, and landed on `main` at `60dd4302`. A playlist **file** keeps a member only from a library the server draws from. Upstream builds that set from the libraries whose collection type is both known and not `livetv`, `boxsets` or `playlists`, and keeps a name only when the resolved path starts with one of their locations — a raw prefix, so `/media/music` covers `/media/musicals` there as it does here. The half that does the work in practice is the "known" one: a mixed library writes a `mixed.collection` marker, but the enum upstream parses it into has no `mixed` member, so the parse fails, the type stays null, and **no member is drawn from a mixed library at all**. This port registers none of the three ignored kinds, so the rule reduces to that. A folder-shaped playlist is not filtered: upstream's items provider returns before any of this for a directory, and the `playlist.xml` reader keeps what it names with no library check and no existence check. The review caught the first fix applying the filter to both. **What the key measures.** The tree gained cross-library names in three lists and a `playlist.xml` in the mixed library. Upstream filed: - `mixed/Loose List.m3u` — the mixed-library name dropped, one music-library member, blob `Unknown`; - `mixed/Inner List.m3u` — no members, and the resolver's `Audio` left standing, because a list emptied by the filter never reaches the merge that would overwrite it; - `music/Loose List.m3u` — the mixed-library name dropped; - `mixed/Mix [playlist]` — **both** members kept, including the one reaching into another library, since a folder is not filtered. The comparison fails in both directions if either rule is wrong, and the selection itself is now a function the test calls rather than a rule the test re-derives. Filed while doing it: #238, a name spelled with different accent normalization loses its member, where upstream retries both spellings.

Claude closed this issue

2026-09-16 16:27:42 +02:00