onetagger
onetagger copied to clipboard
Marekkon5
100% yet incomplete
I tried running onetagger over my entire collection. I expected it would take days, however it seems to have finished, claiming 100% yet had only got through 7%
Is there a hard coded timeout somewhere?
I assume I have to run from cli and capture the output? I don't see any log settings, I'll rerun and capture, is this what you want?
The log is in: %AppData%/OneTagger on Windows ~/.config/onetagger on Linux.
Ah thanks, looks normal I think but at the end it has this;
Oct 14 19:29:23.765 ERRO PANIC: panicked at 'range end index 31256947 out of range for slice of length 14479731', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/metaflac-0.2.4/src/block.rs:747:24 Oct 14 19:29:23.765 ERRO LOCATION: File: /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/metaflac-0.2.4/src/block.rs, Line: 747 Oct 14 19:29:23.776 INFO Tagging finished, took: 19119 seconds. Oct 20 11:47:55.397 INFO
Is that enough or do you need the whole log?
Cheers
It seems that one of the FLAC files might be corrupted / causing issues with the library. Could you split your library to smaller portions and try to determine which specific FLAC file is it? Thanks
Just returning to this issue now sorry. With respect I think your idea of splitting the collection to try and identify the offending flac is not practical. The main directory is split into bands/artists and has 3405 folders which contain 7195 albums. These are indexed by multiple players around the house which would mess them up also. But manually splitting, re-running etc would probably take months. Could it be possible to have a debug mode which shows the track onetagger is about to load in a log?
Yes, I do understand that, however - OneTagger already logs the paths of finished file. The problem in your case is panic (fatal error) caused by an library, so I can't just easily "catch the exception" and print the path. I will add printing the path to the track that is starting the tagging, however it won't be as easy either, because there are many threads running at once, so you won't have just a single track.
I'll try to figure out something better, sorry for the inconvenience.
Thank you, that's great. Testing the file for each thread won't be a problem for me, that would be excellent :)
In the latest commit I've added logging of the currently tagged track (you can get the binary to test from the Actions tab).
It is currently logged as info level, because all debug/trace logs are removed from release builds (so I can't easily enable them). I'll figure out a better solution after Christmas.
Let me know if this works for you, thanks.
Thanks to your patch I've now identified the offending file. It's not immediately obvious to me what's wrong with it although if I run picard over that file then onetagger is happy with it, probably corrupt or invalid tag formatting.
I have kept a copy of the original file, would it help you to test. Not sure if its possible, but the ideal would be that onetagger logs the invalid file and continues without crashing. If you want it let me know how I can send you a download link privately please.
Thanks for the work, it would be great if you could send me the file, so I can look what's wrong.
And as I said before - the issue is with a library causing panic (fatal error), which it shouldn't do. So I have to patch that, rather than fix OneTagger.
Can you let me know how to send you that file please?
I was wondering if there was a way to instruct one tagger to only work on files not previously done before, eg. if te custom onetagger tag is found then skip, to speed up subsequent runs. I guess then it would make sense that onetagger does not add its own custom tag if a match wasn't made with discog etc.
You can post a link here to a google drive, mega, or any file sharing service if it's just a few tracks. Or you can sent them to my email: marekkon50 (at) gmail (dot) com.
I'll add the skipping tracks feature when I get time. Thanks.
I've added the skipping of tagged tracks in the latest commit. You can get the binary from the Actions tab to test it out. Thanks
Fantastic, its working well so far.
I did find the the CLI path doesn't work anymore though, ie.
nice -n19 ./repos/onetagger_release/onetagger /mnt/Audio/Lossless error: Found argument '/mnt/Audio/Lossless' which wasn't expected, or isn't valid in this context
Sorry, this is because of #76 - I had to change the argument parsing.
The new way to start with path is just ./onetagger --path /mnt/audio/123 or ./onetagger -p /mnt/audio/123
Thanks