Tagger: Tagger crashes when loading files
I just installed Tagger and added my Music folder. After a few seconds of loading, it crashes. Every subsequent attempt to open the app, results in a crash. I guess it tries to load the same folder again.
Running it from the command-line, it outputs this exception and stack trace:
# flatpak run org.nickvision.tagger
Unhandled exception. TagLib.CorruptFileException: MPEG audio header not found.
at TagLib.Mpeg.AudioFile.ReadStart(Int64 start, ReadStyle propertiesStyle)
at TagLib.NonContainer.File.Read(ReadStyle propertiesStyle)
at InvokeStub_AudioFile..ctor(Object, Object, IntPtr*)
at System.Reflection.ConstructorInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr) at TagLib.File.Create(IFileAbstraction abstraction, String mimetype, ReadStyle propertiesStyle)
at NickvisionTagger.Shared.Models.MusicFile.LoadTagFromDisk() in /run/build/org.nickvision.tagger/NickvisionTagger.Shared/Models/MusicFile.cs:line 238
at NickvisionTagger.Shared.Models.MusicFile..ctor(String path) in /run/build/org.nickvision.tagger/NickvisionTagger.Shared/Models/MusicFile.cs:line 98
at NickvisionTagger.Shared.Models.MusicFolder.<>c__DisplayClass17_0.<ReloadMusicFilesAsync>b__0() in /run/build/org.nickvision.tagger/NickvisionTagger.Shared/Models/MusicFolder.cs:line 58
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
at NickvisionTagger.Shared.Models.MusicFolder.ReloadMusicFilesAsync() in /run/build/org.nickvision.tagger/NickvisionTagger.Shared/Models/MusicFolder.cs:line 52
at NickvisionTagger.Shared.Controllers.MainWindowController.ReloadFolderAsync() in /run/build/org.nickvision.tagger/NickvisionTagger.Shared/Controllers/MainWindowController.cs:line 225
at NickvisionTagger.Shared.Controllers.MainWindowController.OpenFolderAsync(String path) in /run/build/org.nickvision.tagger/NickvisionTagger.Shared/Controllers/MainWindowController.cs:line 198
at NickvisionTagger.Shared.Controllers.MainWindowController.StartupAsync() in /run/build/org.nickvision.tagger/NickvisionTagger.Shared/Controllers/MainWindowController.cs:line 169
at NickvisionTagger.GNOME.Views.MainWindow.StartAsync() in /run/build/org.nickvision.tagger/NickvisionTagger.GNOME/Views/MainWindow.cs:line 326
at NickvisionTagger.GNOME.Program.OnActivate(Application sedner, EventArgs e) in /run/build/org.nickvision.tagger/NickvisionTagger.GNOME/Program.cs:line 118
at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state)
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
Unfortunately my file collection is quite big (~25k files), so it’s impossible to find which one triggers the error. I guess a good first step would be to handle the exception above, by skipping the file (and maybe printing the file path).
# flatpak info org.nickvision.tagger
Tagger - Tag your music
ID: org.nickvision.tagger
Ref: app/org.nickvision.tagger/x86_64/stable
Arch: x86_64
Branch: stable
Version: 2023.7.0
License: MIT
Origin: flathub
Collection: org.flathub.Stable
Installation: system
Installed: 81,6 MB
Runtime: org.gnome.Platform/x86_64/44
Sdk: org.gnome.Sdk/x86_64/44
Commit: dbc50788da4ce13050fc78f42301aec7302e31f852d1697ec7acbeb753bb3479
Parent: 02e79508c23cca93891850cc31f547c1ad6b0f5e920e65f9b409cf3d4134e7bf
Subject: V2023.7.0 (f5c161d0)
Date: 2023-07-02 03:03:32 +0000
I’m using ArchLinux with Gnome 44.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 24 (17 by maintainers)
@teoulas Nick is on vacation, so he sent me the file to inspect it and to work on the issue #124. As you said, it contains HTML and it seems to be not in the tag, but right after it. This doesn’t look like something that is easy to fix automatically in Tagger. FFprobe detects this HTML as junk data and warns that the length of the track may be innacurate, leading to possible playback issues (and I can say that it’s true for Clapper - no playback slider there when opening the file). This is not ideal solution, because it does require to use another program - even command-line program - but I think it’s the easiest fix for your file and probably any other similarly corrupted audio files:
Re-encoding removes junk data and new file can be opened in Tagger.
And Tagger now shows a dialog with a list of corrupted files if they are found.
Funny that you mentioned EasyTag. It’s my fallback app for editing tags! That said, its UI is outdated and quite complicated. I don’t think a directory tree would be a good addition.
I was thinking sorting by file path (because most of my files are already grouped in their own directory by album). Album, or a combination of Artist-Album would be good too (assuming the tags are present). I guess it depends on the state of the files. If they are organized well in directories and you only need to update tags, file path would be best. If they are spread all over the file system and they have good tags, album would be best.
Yup, makes sense. But EasyTag is orders of magnitude faster, so there’s certainly a way to optimize this.
I didn’t write it down, because it wasn’t huge. BTW, xdg-document-portal still uses 11GiB of memory, even after quitting Tagger. Most likely there’s a memory leak, but I wouldn’t know where to start debugging that issue.
Sent via e-mail.
I’ll add the option for file path and album as well…doesn’t take much to add new sorting options
@teoulas thanks for feedback! Would you find it easier to use if there would be directory tree (similar to EasyTag)?
It’s OK, I can live with one file not being loaded into Tagger. Not sure how common it is to justify the development of such a feature 🙃
What kills the app is the huge amount (~25k total, maybe ~22k audio) of files:
xdg-document-portaltakes up 10.7GiB)I know you didn’t ask for feedback, but thought it’s useful to highlight the usability issues I’m facing with my big file collection 😁
Found the culprit. It’s just one file 😒. It seems the ID3 tag is present and the file plays just fine. The error says “MPEG audio header not found”, so maybe it’s been encoded with a weird/obscure encoder 🤷. Thanks for the quick fix!
I confirm that new beta is available to download from flathub-beta.
I got
2023.7.0-beta2, before. Uninstalled everything and re-installed the beta, got2023.7.1-beta1now 🤷♂️. Let me try again.If you run from
mainor wait for a beta version (hoping later tonight or tomorrow), it’s fixed with that commit ^ https://github.com/NickvisionApps/Tagger/commit/1704a8ab096e000da8d8a7e2dabd407534961f7eYeah looks like your file is just corupted all together. I’ll make it where it will skip that file but warns with an error of which file it is.