Open bmarwell opened 7 years ago
Hi! As I mentioned in the other issue:
When you do, we'd love to hear specific suggestions about where these errors should appear. I agree that just spamming log messages to the console is not ideal, but we need specific ideas about what to do instead.
Sure.
Perhaps collect them and print them out at the end. Or just wait.
Consider this: beet asks you about an album being tagged with a prompt:
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
CD 3
* In The Army Now (#1) -> In The Army Now (#38)
* Medley Milton Keynes (#2) -> Medley Milton Keynes (#39)
* Dreamin (#3) -> Dreamin (#40) (id)
* Running All Over The World (#4) -> Running All Over The World (#41)
* Burning Bridges (#5) -> Burning Bridges (#42) (id)chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
* Ain't Complaining (#6) -> Ain't Complaining (#43) (id)
* The Wanderer (#7) -> The Wanderer (#44) (id)
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
* Medley Roadhouse Medley (#8) -> Medley Roadhouse Medley (#45) (id)
* Restless (#9) -> Restless (#46) (id)
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
* In my Chair (#10) -> In my Chair (#47) (id)
* Joanne (#11) -> Joanne (#48) (id)
* Red Sky (#12) -> Red Sky (#49) (id)
* I Love Rock n Roll (#13) -> I Love Rock n Roll (#50) (id)
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
* Shady Lady (#14) -> Shady Lady (#51) (id)
* Don't Drive My Car (#15) -> Don't Drive My Car (#52) (id)
Apply, More candidates, Skip, Use as-is, as Tracks, Group albums,
Enter search, enter Id, aBort?
Enter one of A, M, S, U, T, G, E, I, B: A
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
Things like above CAN happen if you import your library anew or create it for the first time. When I ran beets for the first time with the fingerprinting plugin, I didn't even see that beet needed my attention, because I went out of the room and the past 80 lines or so were flooded with error messages.
So, i'd go with either:
I'd go with no. 3.
Additionally:
If you need additional info, just let me know.
Interesting idea! We could add a generic mechanism for "queueing up" warnings that occur during initial processing to show in the interactive prompt.
That works for the chroma plugin, which is invoked before the interactive prompt. Any bright ideas for what to do for plugins that do their work after this prompt?
Any bright ideas for what to do for plugins that do their work after this prompt?
I'd just queue everything to the very end.
Hmm, but that might be thousands of albums later—it might become impossible to associate log messages with the albums they apply to.
Do you think this is important? There are still possibillities:
Add an album to the log message Log the whole filename Discard the album entirely.
I mean, when chroma tells me that a file can't be read, I care about the file. Not about the album. Chroma could also get its own logfile after all.
OK—none of those are a panacea, but thanks for thinking through the options.
I'll change this to be a feature request specifically about queueing up pre-prompt visible log messages.
Oh yeah, the title. Sorry I forgot to put a good title.
And thanks a lot for considering anyway. If you see additional problems, just let me know. I'll be happy to think about other possibilities as needed. I just won't be a good contributor (I'm a java EE dev) ;-).
Any updates on this? I am trying to import a large library and fingerprinting errors keep flooding the terminal and I lose track of what beets is requesting.
Any updates on this? I am trying to import a large library and fingerprinting errors keep flooding the terminal and I lose track of what beets is requesting.
Generally, all development happens in the open: If there's no update here, there's none. Somebody with the time and motivation would need to pick it up. As it stands, asking for progress only sends useless notifications to lots of people.
Any updates on this? I am trying to import a large library and fingerprinting errors keep flooding the terminal and I lose track of what beets is requesting.
Generally, all development happens in the open: If there's no update here, there's none. Somebody with the time and motivation would need to pick it up. As it stands, asking for progress only sends useless notifications to lots of people.
Dear devs,
by your request cross-post from: https://github.com/beetbox/pyacoustid/issues/34 But: I suspect prints to stdout/stderr from pyacoustid, so this might not a beet issue. Anyway, I didn't take a look into the code yet.
I saw a lot of issues with this plugin. Now I read all of them, and nothing helped.
versions
description
$ beets import -s _unsortiert
All it gives:
chroma: fingerprinting of '/media/usb-hdd/Musik/_unsortiert/track.mp3' failed: audio could not be decoded
No, the verbose options don't add any info. But oddly, I see the fingerprint which was successfully read.
Now when I execute fpcalc:
But afterwards it does give me the correct fingerprint. So it seems to work.
The bad thing is that I can't use beet anymore, because my screen gets spammed with error messages, and I have to scroll WAY up to see what beets wants from me (Skip? Not? Select?).
I think this needs fixing -- please supress these messages or make them print synchronously at last. Also, how do I see if my files were identified by tags or by acousid? I haven't seen a hint yet.
actual behaviour
My screen gets spammed with fingerprinting failed -- audio could not be decoded. But it SEEMS it works, but there is no way to know.
expected behaviour
Screen not getting spammed would be a start ;-) Tell the user, if it actually failed, or if the corrupt header was silently ignored. Or don't tell him if it could be ignored. Ask the user what to do if the file could not be read. Tell the user in a better way that the current track was identified by acoustid.