fix: cut long names from the middle, not the end
Build and publish container / build (pull_request) Canceled after 1m18s
Build and publish container / build (pull_request) Canceled after 1m18s
The shortening fitted the path and destroyed its meaning. Lidarr writes "Artist - Album - 07 - Flamethrower.mp3" inside a directory already named for that artist and album, so a long album title occurs three times in one path and everything that distinguishes one track from another sits at the very end. Cutting from the end removed precisely that: King Gizzard & the Lizard Wizard - PetroDragonic Apocalypse; or, Dawn of Eter~c526.mp3 All seven tracks on that record reduced to the same string bar the hash. The path fitted; the result was seven files nobody could tell apart on the device, which is a worse outcome than the failure it replaced. Cut from the middle instead, giving two thirds of the remaining room to the tail because the head is generally a restatement of the directory the file already sits in: King Gizzard & the Lizard~c526~ginning of Merciless Damnation - 07 - Flamethrower.mp3 The eight real paths that prompted this are now regression tests: every track on that album keeps its number and title, all seven names stay distinct, and The Beatles' "The Long One" -- whose length is the title itself rather than a repeated album name -- keeps both ends.
This commit is contained in:
@@ -246,10 +246,26 @@ from `--max-path` to get what a mirror-relative path may spend.
|
||||
Over-budget paths are shortened from the **deepest component outward**: the
|
||||
track name carries the least navigational value and the artist directory the
|
||||
most, so the filename goes first and the artist is touched only if nothing else
|
||||
will do. A shortened component keeps its extension and gains four hex digits of
|
||||
the original name — two long names sharing a prefix would otherwise cut to the
|
||||
same string, and a silent collision between two tracks is worse than an ugly
|
||||
filename.
|
||||
will do.
|
||||
|
||||
A component is cut **from the middle**, not the end, because of how these names
|
||||
are built. Lidarr writes `Artist - Album - 07 - Flamethrower.mp3` inside a
|
||||
directory already named for that artist and album, so a long album title
|
||||
appears three times in one path and the informative part — the track number and
|
||||
title — is at the very end. Cutting from the end throws exactly that away:
|
||||
|
||||
```
|
||||
before King Gizzard & the Lizard Wizard - PetroDragonic Apocalypse; or, Dawn of Eternal
|
||||
Night - An Annihilation of Planet Earth and the Beginning of Merciless
|
||||
Damnation - 07 - Flamethrower.mp3
|
||||
after King Gizzard & the Lizard~c526~ginning of Merciless Damnation - 07 - Flamethrower.mp3
|
||||
```
|
||||
|
||||
Two thirds of the remaining room goes to the tail, since the head is usually a
|
||||
restatement of the directory it sits in. A shortened component gains four hex
|
||||
digits of the original name: two names sharing both a head and a tail would
|
||||
otherwise produce the same string, and a silent collision between two tracks is
|
||||
worse than an ugly filename.
|
||||
|
||||
The result is stable: the same source always produces the same shortened name,
|
||||
so a pass does not rename what the previous pass wrote. A path too deeply
|
||||
|
||||
Reference in New Issue
Block a user