Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Scanner update path silently drops contributor_track for tag-less files; 'status' with artist tags then skips the track

Open
  • Is something wrong?
#1,706 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
perl, sql
Domain
backend, database

Research direction

Start in Slim/Schema.pm at _createContributorRoleRelationships and _mergeAndCreateContributors to see how the update path (via updateOrCreateBase → _postCheckAttributes) drops contributor_track rows for tag-less files. Also inspect Queries.pm statusQuery and Slim/Schema.pm _getTagDataForTracks. Reproduce with a tag-less MP3 scan, then verify contributor_track gains a NO_ARTIST row or status returns the playing track in playlist_loop.

Written by the indexing model from the issue text.

Description

Describe the bug

When an audio file without any tags (no TPE1/TIT2 — common with old, loose-download MP3s) is picked up by the "changed" scan path, the track ends up with primary_artist set (to the NO_ARTIST singleton, e.g. "Unknown Artist" / "Kein Interpret") but zero contributor_track rows.

Afterwards, status queries that request artist tags silently skip the track, with visible consequences for clients:

  • status <player> - 1 tags:alygdue (current track) returns an empty playlist_loop while that track is playing,
  • status <player> 2 tags:aAlyjegdKNu returns a playlist_loop starting at the next track, so a now-playing display shows the wrong (next) song while the current one plays.

To reproduce

  1. Library with an MP3 that has no ID3 tags (e.g. Audio::Scan reports only PRIV/TCON, no TIT2/TPE1), already in the DB.
  2. Touch the file (or create a mtime/size mismatch) so the scanner classifies it as "changed".
  3. Observe in library.db:
SELECT id, primary_artist FROM tracks WHERE url = '...';   -- primary_artist set (NO_ARTIST id)
SELECT * FROM contributor_track WHERE track = <that id>;    -- 0 rows
  1. Play the track and query the player:
status <player> - 1 tags:alygdue     -> playlist_loop: []
status <player> 2 tags:aAlyjegdKNu   -> playlist_loop starts at next index (wrong current song)

Expected behavior

Either the update path keeps a NO_ARTIST contributor_track row (like the create path does), or the tag-data query does not silently drop tracks (Queries.pm statusQuery has next if !$data;).

Root cause (analysis of 9.1.1 code)

  • Slim::Schema::_createContributorRoleRelationships deletes all contributor_track rows for the track, then re-inserts from the freshly read tag set.
  • Slim::Schema::_mergeAndCreateContributors only creates the NO_ARTIST fallback contributor if ($create && !$foundContributor).
  • The update path (updateOrCreateBase → _postCheckAttributes with create => 0) therefore re-inserts nothing for a tag-less file, while primary_artist retains its stale value (on creation the same file correctly gets primary_artist = NO_ARTIST plus a matching contributor_track row).
  • Slim::Schema::_getTagDataForTracks joins contributor_track ((contributors.id = tracks.primary_artist OR tracks.primary_artist IS NULL) when queried by trackIds); a track with no rows produces no result, and Queries.pm statusQuery does next if !$data; — the track vanishes from playlist_loop without any log message.

We found 8 such tracks in a ~88k track library; nightly "changed audio files" scans had silently broken them one after another. Reproduced deterministically with a silent squeezelite instance: while the tag-less track plays, status 1 with artist tags returns an empty loop, status 2 returns the next track as "current".

Additional context

A second effect of the same re-read churn: because tracks.url is COLLATE NOCASE (bug 17457), case-insensitive duplicate files on disk (e.g. Song.mp3 with tags + song.mp3 without tags) both match the same DB row, keeping it permanently "changed" and re-breaking it on every nightly scan. This may explain some "rescan seems unreliable" reports (e.g. #977).

Workaround we applied

Write TPE1/TIT2 into the affected tag-less files; the next scan restores correct contributor_track rows. A client-side fallback (re-query without artist tags when playlist_loop is unexpectedly empty/short) can mask the display bug but not the history/statistics loss.

LMS 9.1.1 (Debian package), Perl 5.36, library on btrfs.

Dominant language
Perl
Stars
1.8k
Forks
386
Avg merge
2d 7h
Merged PRs (30d)
14

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LMS-Community/slimserver

All issues in LMS-Community/slimserver

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.