Apparent incompatibility between LMS and beets-tagged M4A files

[ralph-irving]

Originally reported by Lyrion Forums member benh in https://forums.lyrion.org/forum/user-forums/ripping-encoding-transcoding-tagging/1825879-apparent-incompatibility-between-lms-and-beets-tagged-m4a-files

I have been cleaning up metadata, primarily albumartist_sort and genre, on my music library using beets and have run into a strange issue.

My library is a 60/40 mix of FLAC and ALAC. I ran through a large batch of cleanup of both FLAC and ALAC files and eventually did a clear and rescan of my LMS library. I then noticed that LMS is not reading most of the tags from some significant portion of the changed files, and all of the affected files appear to be ALAC.

I noticed this when I looked at a particular artist, and most of his albums were missing from his artist listing, but he had a "No Album" album that contained 24k+ songs, pretty much all ALAC, and comprised largely of artists/albums I had made metadata changes to.

In LMS, going to More->More Info->View Tags I see only ART and NAM tags for randomly selected files in that "No Album" album.

I started poking:

In beets, all of the metadata/tags are visible, and beets is able to list by album.
I set Navidrome to scan my library and it was able to properly scan and group albums that LMS was having trouble with.
I ran an ffprobe extract of the tags from an affected file, and the correct tags were indeed present.

I then ran another clear and rescan with debug turned on, and it seems that many files exhibiting this issue throw the same error in the scanner logs:

Audio::Scan::scan (64) Warning: Error: Unable to read at least 8 bytes from file.

Some searching led me to this old issue: LMS-Community/slimserver#883

I rewrote (without changing any tags or other data) an album's worth of files per the comment in that issue, and that album subsequently scans without error and is organized properly in LMS.

It's not clear to me if this is a beets issue, or an LMS issue, but thought I'd start here since other music systems seem to work with these files. If this turns out to be a beets issue, happy to raise that with them.

Software versions:
Lyrion Music Server Version: 9.1.1 - 1779815526 @ Wed May 27 06:04:33 UTC 2026
Operating system: Debian (Docker) - EN - utf8
Platform Architecture: x86_64-linux
Database Version: SQLite

Perl Version: 5.36.0 - x86_64-linux-gnu-thread-multi
Audio::Scan: 1.11
DBD::SQLite: 1.76 (sqlite 3.46.1)
IO::Socket::SSL: 2.081
Mozilla::CA: Unknown
Net::SSLeay: 1.92 - OpenSSL 3.0.20 7 Apr 2026

beets version 2.11.0; Python version 3.12.13

I can't directly upload a working and non-working version of a file, as they are too large, so I have shared them via Box:

https://app.box.com/s/a5hjrsvv38ni72u21r7sj7n2jscd3sai

[ralph-irving]

There are 2 issues exposed by the "NotWorking" mp4 example file.

1. The wrt (composer) atom contains multiple tags; album and multi value genre. Audio-Scan attempts to decode wrt but fails due to a failed validation that the box size should be smaller than the size of the atom.

  ilst rsize 3996
  ©wrt size 8
    box size 39
    invalid data size 39, skipping value
  seeked past -4 bytes to 11403
Buffering from file @ 11403 (min_wanted 8, max_wanted 4096, adjusted to 4096)
Error: Unable to read at least 8 bytes from file.
Invalid MP4 file (bad ilst box): (filehandle)

2. The code that handles the validation calculates the seek forward value incorrectly hence the -4 and the entire file is ignored.

I have fixed this in my local build which now results in the file being added to LMS but without any of the tags contained in the wrt atom.

  ilst rsize 3996
  ©wrt size 8
    box size 39
    invalid data size 39, skipping value
  skipped buffer data size 35
  ilst rsize 3949

--- a/src/mp4.c
+++ b/src/mp4.c
@@ -1710,7 +1710,8 @@ _mp4_parse_ilst(mp4info *mp4)
       }
       else {
         DEBUG_TRACE("    invalid data size %d, skipping value\n", bsize);
-        _mp4_skip(mp4, size - 12);
+        _mp4_skip(mp4, bsize + size - 12);
+        mp4->rsize -= bsize;
       }
     }

Most of the mp4 parsing examples I reviewed; consider the wrt atom to contain a single tag as does Audio::Scan. As a test I forced Audio::Scan to treat wrt to contain multiple tags and both files then appear under the Lost & Rootless album by Tim Barry.

I appears that beets created the wrt (composer) atom incorrectly and should have placed the album and genre tags in their respective atoms. I plan to commit the above change after more testing but will not apply the second test change.