You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
An upload's file format is read from its title, which never has an extension #690
An uploaded track's format is shown in two places, and both are worked out from the track's source_url (local:<title>). That string never carries an extension. The server builds the title with Path(filename).stem, and the frontend mirrors it, so an upload of Hollow Veins.wav becomes local:Hollow Veins.
What goes wrong
The format thumbnail from Uploaded files show a generic note instead of their file extension #678 never appears. Every upload still shows the generic note. It was caught in a manual test run: the automated tests passed because the e2e fixture writes local:e2e-fixture.wav by hand, a shape no real upload has.
The "Lossless (WAV)" and "Compressed (MP3)" quality labels never appear for uploads either. They parse the same string and fall back to "Local file".
A title containing a dot is misread. A file named v1.2.wav would be treated as having the format 2.
Where the truth is
The server knows the real format. It validates the upload's extension against the allowed list and keeps the upload on disk as source.<ext>, which re-split already relies on through _retained_source. Nothing reports it to the client.
Constraints
The format should come from the server as a fact, not be parsed from a display string.
Existing uploads need it too, without a migration: their kept source.* already says what they are. Uploads finished before sources were kept have none, and should keep the plain note.
Tests must use the source shape real uploads actually have, so this cannot pass on an impossible fixture again.
Activity
Show an upload's format from the server, as a coloured file icon (ste…