cmus-notify
cmus-notify copied to clipboard
dcx86r
Configuration option enabling waiting for uncached album art
According to the README:
the placeholder image is shown if art has not yet been cached (e.g. on first play of a file), this is because ffmpeg takes anywhere between 1-5+ seconds to perform the extraction, so whatever is available is shown instead of waiting an indeterminate amount of time
Would you consider adding a configuration option to allow waiting until ffmpeg has completed processing the cover art for uncached images? There could be a warning in the documentation about the delay when enabling this option.
Sure, I can look into it this week. I've been thinking of adding some kind of precaching to solve the waiting problem, haven't settled on the best way to implement it but I'm thinking maybe based on playlists.
Has there been a development on this?
Not yet.
I'm planning to start on a rewrite the program soon, which will include a solution to this.
That's great to hear, I like this useful tool. Thank you for your work.
Somehow, the album covers get cached per song and not per album, so every song of an album will display the album art only if called a second time (by pausing/resuming, for example). Is this the expected behaviour? I thought the cache would be per album, so that one song is enough to have the correct album art cached for the rest of the album's songs.
That's great to hear, I like this useful tool. Thank you for your work.
Somehow, the album covers get cached per song and not per album, so every song of an album will display the album art only if called a second time (by pausing/resuming, for example). Is this the expected behaviour? I thought the cache would be per album, so that one song is enough to have the correct album art cached for the rest of the album's songs.
Thanks, I appreciate the feedback :)
Yes, unfortunately, the problem you mention is expected behavior. It is caused by the program not knowing about possible relationships between files, so ffmpeg is run to avoid making incorrect guesses.
The reason these relationships are difficult to predict is because of how inconsistent music metadata can be.
For the future I'm planning to use the Audio::Scan module to parse text metadata, as it supports a number of formats. That should improve the reliability of finding relationships between files.
This sounds very promising. In the meantime, is there a way to run the cover generating script so it batch-creates and caches all covers in one go?
This sounds very promising. In the meantime, is there a way to run the cover generating script so it batch-creates and caches all covers in one go?
Yes, that sounds like a good workaround. It is now available in the new testing branch.
To use it, first create and save a playlist file via cmus, then call from command line cmus-notify <filename> and it will start loading ffmpeg instances.
This was just hacked into the existing mess with minimal testing so there's nothing fancy like queuing, may hit resource limits trying to process too large a playlist...
This worked like a charm, thank you!
I'm glad it's working for you, thanks for the feedback.