I'm pretty sure that Strawberry sorts by metadata. A song needs a track number, independent of the file name. The suggestion of renaming files numerically is a good idea. Organizing your album folders alphabetically, by song name, runs counter to the way albums are presented -- which is numerically, by track number.

Right click on a song and select "Edit track information". There should be a number in the "Track" field at the right. Don't change anything yet, until you figure out the root of your problem, but if there is no number, that might be of concern.

Hope that helps.

@silver-sun Done, done, and partially done.

I'm on Ubuntu and have already cracked it open with DB Browser. 'It' being the .db file, I didn't know the .db.bak was a backup I could also check.

I know some rudimentary SQL and how databases work, but I still don't know how to interpret the data. I've found the playlists table and it's full of the plaintext names of the playlists, but not the songs or any data about the playlist contents. There's also playlist_items with columns like playlist, collection_id, and playlist_url, which I assume has to mean something but all the columns are integers bereft of context (playlist_url is entirely full of NULL cells). Does anyone know how to interpret the data in the database? Is there any documentation on how the database is meant to work?

Update: Reading through the rest of the columns in playlist_url it seems like there are supposed to be plaintext cells with song titles, artists, albums, etc. They're all empty. At first I figured this meant the data was destroyed, but I copied the .db file I've been using with new playlists so I could see what the data was supposed to look like. Just like in the old database, every column which should hold the titles and such was empty. The only data that differed consistently (to a point) row to row was collection_id. Does collection_id represent a unique identifier to a song? How does Strawberry actually interpret the playlist_items to get data about the items in playlists out?

@amour8440083555 How does you post thematically fit in the current thread?

I'm pretty sure the volume slider behavior is hard coded. Is there no point down the chain, i.e., computer master volume, system preamp, powered speaker volume, etc., where you could tweak the volume?

Look for Menu -> Tools -> Settings... -> Playlist -> Use alternating row colors

@Ausron46
Might be some space or different characters in the name.
Try Tools / Console and enter:

SELECT distinct albumartist, artist, album from songs where artist like '%ventures%';

See if all the albums under The Ventures shows up, and check if there is a difference in naming, ie.: if there is a space before | album.

@Sharky-PI this would be incredibly useful.

Following up on this — the moodbar workaround is a fair suggestion, but I think it is worth distinguishing because moodbar and a real waveform actually solve different problems/features. The moodbar shows the spectral "mood" of a track as a colour gradient, which is fine for a vibe, but the colour bands do not reliably correspond to where the loud parts, drops, breaks, or quiet sections are. As a DJ I find myself wanting to see the actual amplitude shape of the track — the peaks and troughs over time — so I can spot a drop, a build-up or a breakdown by eye in a few hundred milliseconds. Mixxx and most DJ-oriented tools display this as a horizontal waveform strip with a playhead, and it is hard to go back to scrubbing without one.

What I would propose for Strawberry is a proper waveform visualization that lives in the analyzer area above the progress bar, alongside Block, Boom, Turbine and the others, as just another option in the right-click "Analyzer" menu. Selecting it would render the loudness contour of the entire current track as a horizontal waveform, with a playhead moving across it as the song plays. It would not replace the moodbar (moodbar can stay exactly where it is, painted into the slider groove), and it would not replace the live spectrum analyzers either.

It would just be one more option in that menu, for the users who want it.

I had a look at the code and the feature seems quite feasible without adding any new dependency. The moodbar pipeline already handles the hardest part: running a GStreamer pre-pass over a track on a worker thread and caching the result. A waveform pipeline would essentially be the same pattern, but storing peak/RMS values instead of FFT-derived colours. Other parts of the engine (Chromaprint, EBU R128 loudness analysis) already extract raw PCM from GStreamer in the exact way a waveform would need.

I am planning to open a GitHub issue to gauge the maintainers' interest. Would anyone else here find this useful? Especially curious whether other DJs, or people working with mixes and live recordings, would back this up.