Description
I encountered a reproducible MP4 metadata parsing problem while migrating and normalising a music library.
The affected album was:
ABBA — Gold Greatest Hits
It contains 19 ALAC tracks in M4A containers.
After an LMS library scan:
- one track was correctly associated with the album;
- the other 18 were not;
- those 18 appeared under No Album / Various Artists rather than the correct ABBA album.
All 19 files were located in the same correct album directory and the expected Album and Album Artist metadata was present.
The same 19 files were interpreted correctly as one coherent album by Emby.
Diagnosis
The LMS scanner log contained exactly 18 corresponding warnings:
Invalid MP4 file (bad ilst box)
Inspection of the MP4 metadata structure identified a consistent difference.
The 18 files LMS failed to scan correctly contained an empty 8-byte ©wrt (composer) child atom inside the MP4 ilst metadata container.
The single correctly scanned track contained an actual composer value and therefore had a non-empty ©wrt atom.
The empty atoms had been introduced through a beets/MediaFile item.write() metadata-writing path.
The affected files were nevertheless accepted by:
The ALAC audio itself remained valid and playable.
Audio::Scan, however, reported the "bad ilst box" error. LMS consequently failed to obtain the expected Album/Album Artist information and grouped the affected tracks incorrectly.
I searched the existing slimserver Issues and Discussions and could not find an existing report describing this specific Audio::Scan failure with an empty MP4 ilst child.
Steps to reproduce
- Take a valid ALAC/M4A file containing normal Album, Album Artist and other metadata.
- Include an empty 8-byte MP4 ©wrt child atom in its ilst metadata.
- Add the file to the LMS music library.
- Clear/rescan the LMS library.
- Examine scanner.log.
Observed:
Invalid MP4 file (bad ilst box)
In my album-level test, LMS then failed to obtain the expected Album/Album Artist metadata for every affected file.
Controlled repair and confirmation
I performed a bounded repair on exactly the 18 affected files.
The repair removed only semantically empty MP4 tags.
To verify that the test did not inadvertently change the music or meaningful metadata:
- the unaffected 19th track was not modified;
- core metadata was compared before and after repair and remained unchanged;
- MP4 mdat audio-payload SHA-256 hashes matched before/after for all 18 repaired files;
- no empty ilst child atoms remained after repair;
- immutable source copies were retained separately.
All 19 files subsequently passed structural and metadata verification.
I then performed an LMS clear/rescan.
Result:
ABBA — Gold Greatest Hits imported correctly as one coherent 19-track album.
Therefore I was able to reproduce the failure, isolate the empty MP4 atom, remove only that condition, and confirm that LMS subsequently scans the same album correctly.
Expected behaviour
Even if an empty MP4 metadata atom is considered undesirable or technically invalid, it would seem preferable for Audio::Scan to ignore that individual empty metadata item rather than reject enough of the ilst structure that otherwise valid Album/Album Artist metadata is lost.
Other parsers tested were tolerant of this condition.
Our own metadata pipeline has now been changed to remove semantically empty MP4 tags, but making Audio::Scan more defensive here could prevent similar library mis-grouping for M4A files produced by other metadata-writing software.
Additional evidence available
I have retained:
- original affected M4A files;
- repaired versions;
- LMS scanner evidence;
- atom-level before/after evidence;
- SHA-256 verification data;
- exact repair audit data.
I can provide a minimal affected M4A sample together with its repaired counterpart if useful for reproducing the Audio::Scan behaviour.
Environment
Lyrion Music Server:
9.1.1 - 1779815526 @ Wed Jun 17 12:31:42 UTC 2026
Operating system:
Ubuntu - EN_GB - utf8
Platform architecture:
x86_64-linux
Database:
SQLite
Perl:
5.38.2 - x86_64-linux-gnu-thread-multi
Audio::Scan:
1.10
DBD::SQLite:
1.76 (SQLite 3.46.1)
IO::Socket::SSL:
2.085
Net::SSLeay:
1.94 - OpenSSL 3.0.13 30 Jan 2024
Hardware/host:
x86_64 unRaidNUC
Browser:
Not relevant — issue occurs during server-side library scanning.
Description
I encountered a reproducible MP4 metadata parsing problem while migrating and normalising a music library.
The affected album was:
ABBA — Gold Greatest Hits
It contains 19 ALAC tracks in M4A containers.
After an LMS library scan:
All 19 files were located in the same correct album directory and the expected Album and Album Artist metadata was present.
The same 19 files were interpreted correctly as one coherent album by Emby.
Diagnosis
The LMS scanner log contained exactly 18 corresponding warnings:
Invalid MP4 file (bad ilst box)
Inspection of the MP4 metadata structure identified a consistent difference.
The 18 files LMS failed to scan correctly contained an empty 8-byte ©wrt (composer) child atom inside the MP4 ilst metadata container.
The single correctly scanned track contained an actual composer value and therefore had a non-empty ©wrt atom.
The empty atoms had been introduced through a beets/MediaFile item.write() metadata-writing path.
The affected files were nevertheless accepted by:
The ALAC audio itself remained valid and playable.
Audio::Scan, however, reported the "bad ilst box" error. LMS consequently failed to obtain the expected Album/Album Artist information and grouped the affected tracks incorrectly.
I searched the existing slimserver Issues and Discussions and could not find an existing report describing this specific Audio::Scan failure with an empty MP4 ilst child.
Steps to reproduce
Observed:
Invalid MP4 file (bad ilst box)
In my album-level test, LMS then failed to obtain the expected Album/Album Artist metadata for every affected file.
Controlled repair and confirmation
I performed a bounded repair on exactly the 18 affected files.
The repair removed only semantically empty MP4 tags.
To verify that the test did not inadvertently change the music or meaningful metadata:
All 19 files subsequently passed structural and metadata verification.
I then performed an LMS clear/rescan.
Result:
ABBA — Gold Greatest Hits imported correctly as one coherent 19-track album.
Therefore I was able to reproduce the failure, isolate the empty MP4 atom, remove only that condition, and confirm that LMS subsequently scans the same album correctly.
Expected behaviour
Even if an empty MP4 metadata atom is considered undesirable or technically invalid, it would seem preferable for Audio::Scan to ignore that individual empty metadata item rather than reject enough of the ilst structure that otherwise valid Album/Album Artist metadata is lost.
Other parsers tested were tolerant of this condition.
Our own metadata pipeline has now been changed to remove semantically empty MP4 tags, but making Audio::Scan more defensive here could prevent similar library mis-grouping for M4A files produced by other metadata-writing software.
Additional evidence available
I have retained:
I can provide a minimal affected M4A sample together with its repaired counterpart if useful for reproducing the Audio::Scan behaviour.
Environment
Lyrion Music Server:
9.1.1 - 1779815526 @ Wed Jun 17 12:31:42 UTC 2026
Operating system:
Ubuntu - EN_GB - utf8
Platform architecture:
x86_64-linux
Database:
SQLite
Perl:
5.38.2 - x86_64-linux-gnu-thread-multi
Audio::Scan:
1.10
DBD::SQLite:
1.76 (SQLite 3.46.1)
IO::Socket::SSL:
2.085
Net::SSLeay:
1.94 - OpenSSL 3.0.13 30 Jan 2024
Hardware/host:
x86_64 unRaidNUC
Browser:
Not relevant — issue occurs during server-side library scanning.