A playlist name spelled with different accent normalization loses its member #238
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A playlist name that spells its accents differently from the filesystem loses its member, where upstream tries both spellings.
Both sides
upstream/MediaBrowser.Providers/Playlists/PlaylistItemsProvider.cs'sTryNormalizePathretries a path that does not exist in NFC and again in NFD before giving up.Ours (
crates/ephyra-app/src/scan/playlists.rs) asks the filesystem once, for the name as written.What differs
A
.m3uwritten on macOS, which spellsédecomposed, naming a file on a filesystem that stores it composed — or the reverse. Upstream resolves the member; we drop it, and the playlist is short a track.This is pre-existing rather than introduced by the member filtering, and it is the kind of thing a household library hits exactly once, on the one album with an accent in its name.
Verifying
A list naming a file whose name carries an accent, spelled the other way round. The library-kinds tree can carry both, and the key then shows upstream keeping the member.
Found reviewing #237.
Landed in
f75a3841: a member missing as written is retried in NFC and then NFD, in the order and under the conditions of upstream'sTryNormalizePath. Verified by unit tests over real files in both directions; the library-kinds key was not extended with an accented member, so upstream keeping the member is read from the C#, not measured.