[Bug]: AURRAL_IDS in native ID3 TXXX:comment is ignored during library scans, causing duplicate tracks/downloads

[xbit18]

Before submitting

• I searched existing issues and did not find a duplicate.
• I removed passwords, tokens, private URLs, and other secrets from the report.

Affected area

Flows, playlists, or downloads

Steps to reproduce

1. Import a Spotify playlist with sync enabled and existingFileMode: "reuse".

2. Let Aurral download an MP3 for a playlist track. The resulting file contains an embedded AURRAL_IDS comment with the expected trackMbid.

3. For some MP3/ID3v2.4 files, inspect the file with music-metadata:

const m = await parseFile(file, { skipCovers: true });

console.log(m.common.comment);
console.log(m.native);

4. Observe that m.common.comment is undefined, while the Aurral metadata is present only in the native ID3 tags:

ID3v2.4 {
  id: 'TXXX:comment',
  value: 'AURRAL_IDS={"artistMbid":"...","albumMbid":"...","trackMbid":"b81e29bb-..."}'
}

5. Trigger a Library refresh.
6. Observe that libraryFileScanner.js does not recover the embedded trackMbid, because applyMetadataEnrichment() only reads common.comment.
7. If the MP3 contains a MusicBrainz Release Track ID, the scanner can fall back to common.musicbrainz_trackid and create a different canonical identity.

In my test case, the Spotify/Aurral track MBID was:

b81e29bb-4fde-404c-98aa-9b58d4809dde

but the file was indexed as:

recording:9a1d5ff7-3fd5-4640-a529-d6ac07fdb506

where 9a1d5ff7-... was the MusicBrainz Release Track ID.
8. On a later playlist sync, Aurral does not recognize the existing track as reusable and downloads another copy.

Expected behavior

During a library scan, Aurral should recover AURRAL_IDS from the file even when music-metadata exposes the comment only through native ID3 tags.

The embedded trackMbid should be used as the trusted recording identity, so an existing downloaded track is matched to the corresponding playlist track and reused instead of being downloaded again.

For the example above, the canonical identity should be:

recording:b81e29bb-4fde-404c-98aa-9b58d4809dde

Actual behavior

applyMetadataEnrichment() only calls

parseAurralIdentityComment(common.comment)

For affected ID3v2.4 MP3 files, common.comment is undefined, even though AURRAL_IDS is available as a native TXXX:comment tag.

The embedded trackMbid is therefore not recovered.

The scanner can then use another MusicBrainz identifier, such as the Release Track ID, as the canonical recording: identity.

This creates multiple canonical identities for the same track. Subsequent playlist syncs fail to reuse the existing file and may download the same song again, creating files such as:

Song.mp3
Song (2).mp3
Song (3).mp3

These copies are also indexed as separate tracks and appear separately in the Aurral library.

Impact

Causes a major failure or frequent errors

Aurral version or image tag

2.8.0

Environment

Ubuntu server 26.04.1 LTS, Aurral 2.8.0, Docker deployment via Runtipi custom app, Spotify playlist import with automatic sync enabled

Logs or stack traces

music-metadata output for an affected MP3:

=== COMMON COMMENT ===
undefined

=== NATIVE COMMENT-RELATED TAGS ===
ID3v2.4 {
  id: 'TXXX:comment',
  value: 'AURRAL_IDS={"artistMbid":"163218c2-9e0f-4d2d-aecb-ebbdef6aab70","albumMbid":"4e75b549-46fb-45fb-95a6-836d8e31ede7","trackMbid":"b81e29bb-4fde-404c-98aa-9b58d4809dde"}'
}

Before applying the workaround, a library refresh indexed the track as:

recording:9a1d5ff7-3fd5-4640-a529-d6ac07fdb506

After modifying the scanner to also inspect native TXXX:comment / COMM tags and rebuilding the track, the same file was correctly indexed as:

recording:b81e29bb-4fde-404c-98aa-9b58d4809dde

Screenshots or supporting files

No response

Workaround

I applied a local patch to libraryFileScanner.js.

When parseAurralIdentityComment(common.comment) does not find an embedded identity, the scanner also searches metadata.native for ID3 comment tags such as:

• TXXX:comment
• COMM

and passes their value to the existing parseAurralIdentityComment() function.

After applying this fallback, deleting the stale canonical record and refreshing the library, the test track was correctly indexed using the embedded AURRAL_IDS.trackMbid:

recording:b81e29bb-4fde-404c-98aa-9b58d4809dde

instead of the unrelated MusicBrainz Release Track ID.

This also allows the playlist track identity and library track identity to match again, which should allow existingFileMode: "reuse" to work as intended.

I can submit a PR with this fallback and a regression test if desired.

[github-actions]

Included in stable release 2.9.0

This change is included in the Aurral 2.9.0 release.

docker pull ghcr.io/lklynet/aurral:2.9.0

View the release