Aac files break indexing

[headfog]

gonic version: 0.16.0

If a collection contains a mix of aac files (unsupported) and mp3 files (supported), indexing breaks and resumes with the next directory. This can result in many supported files to be skipped.

gonic.tar.gz

[sentriz]

aac files are supported actually, it just looks like that files tags are corrupt. which does hurt the integreity of the subsonic internal album/folder metadata

[sentriz]

could you email me an example broken aac file?

[headfog]

aac_test_file.zip

Sure, but note that this is more about the error handling logic than aac files in particular. Unsupported files shouldn't cause perfectly good/supported files to be skipped just because they've been stored in the same directory. The test file attached plays fine with mpv and vlc

[sentriz]

unfortunately that is the case. gonic considers 1 dir = 1 album (for many reasons including disambiguation of remasters/rereleases, albums of the same name like the American Football discography, and making the subsonic browse by folder mode feasible)

so gonic must choose a single file in the folder to find album metadata to use, at the moment it chooses the first - and I don't fancy writing "try next if current is broken logic"

in other words we need to keep the integrity of each folder

for the meantime I would suggest fixing your tags

I can help with that if needs be , I could check the aac file

[headfog]

I'm not sure your explanation applies here: the first file shown has metadata and is correctly indexed. Same with the rest of of the files beginning in A.

Compilation XYZ/ ├── Aural Float - Be As You Are.mp3 ├── Aural Float - Freefloat.mp3 ├── Aural Float - Gone Forever.mp3 ├── Aural Float - Life In Dub.mp3 ├── Baby Mammoth - Danger Of The Rocks.aac ├── Baby Mammoth - Deadpool.aac ├── Chicane - Low Sun.mp3 ├── Chicane - No Ordinary Morning.mp3 └── Chicane - Overlap.mp3

1 directory, 9 files

Only the files beginning with B - the aac files - have unreadable metadata. If i remove them from the directory and re-run the test, all mp3 files - including those beginning with C - are successfully indexed. No issue at all. Am i missing something?

[sentriz]

In that situation it could in theory be fine. but imagine the case where the first track beginning with A had the tag errors. now gonic can't read album metadata without some complex "try the next track" logic. meanwhile we still need to keep the entire folder processing inside a database transaction to keep integrity

hope this makes sense

if you can think of way be could be more robust here without adding much complexity I'd be happy to review

[headfog]

How about testing album_id when the processing encounters a tag error? If it's already set the processing can carry on the current album/dir. If album_id can't be used, use a dedicated flag to indicate when the 1st file rule is fulfilled