For local music libraries, queue tab cannot load album art covers from music file's directory about ampd

[rain0r]

This was indeed a bug in ampd. I fixed it in this commit.

OK, tested it and now it finds my cover art files alright. Thanks for fixing!

You're welcome!

However I suggest letting users configure the cover art filename pattern(s) they wish to use. This may come as a surprise, but in my case, within some folders I have more than one image file lying around; these can be back covers, cd pictures, liner notes etc. So using astherisks matches the first one in alphabetical order, regardless of which one it is.

In my last commit I've added the property artwork.filename.pattern which can be used to specify the glob when looking for artwork.

But it's only used when browsing and not when viewing the queue.

This is because javampd can only return the artwork for the file currently played. For browsing, ampd itself looks for artwork using the value of mpd.music.directory.

For this, we could just use String.hashCode() and it would be a better solution than what we have now.

Yes, that's simple enough.

Implemented the use of String.hashCode() on the associated branch

Unfortunately, the mpd library in use (javampd) does not offer an option to read specific id3 tags.

That's too bad. Think it could be requested as a new feature for javampd?

You could do that, yes. The repository is https://github.com/finnyb/javampd
But it seems inactive at the moment.

Also, sorry if my next question is dumb, but I really need some orientation in regards to mpd in general, so here goes: Can this client integrate a plugin to scrobble to last.fm? Or that's a concern for mpd itself?

There is no system for plugins in ampd. Also, scrobbling is something which should be done on the server-side, in my opinion.

For example, I'm using mpdscribble

[rain0r]

Hi there,

happy to hear you're enjoying ampd!

To problem 1:

Things concering the cover cache and loading covers from MusicBrainz:

You're totally right, I also got some weird covers from the MusicBrainz API. Especially for non-popular tracks. I just checked the code and the "min score" for a cover to appear in the search query results is 60. The higher it is the higher is the chance it's the correct cover. To be honest I don't know which value would give us well balanced search results.

I made it configurable via the application.properties, the name is min.score. You could try different values with the -Dmin.score=XX flag when starting ampd.

You could also turn off the local cache completely via -Dlocal.cover.cache=false. ampd won't make any calls to the MusicBrainz API in that case.

No cover in the queue

This is indeed a bug, thanks for reporting it! Fixed that.

To problem 2:

It looks like ampd fails to read the file. Java cannot read files on Windows that contain a colon (:).
Just tested it on OSX and it works, so that's something I can't fix.
Personally, I would recommed to abstain from these "problematic" characters (:*\ etc.) in filenames.

For now, I placed a try catch around it.

I'm glad to hear your ideas on it!

[TwelveP]

Sorry, I think I didn't make myself clear. My issue was thinking that the queue tab should display cover arts from local filesystem only. If I disable caching with MusicBrainz it just shows nothing. Is this by design as of right now?

About the second issue, I thought a simple way to avoid illegal characters in those filenames: calculating a cheap hash function from the artist/album name and using said hash to create and read files. So, instead of creating a cache file named DEVO - Q: Are We Not Men? [...].jpg, it could be created like as89g63490g23as9fa8[...].jpg and from the artist/album, refer to that same file by calculating said hash every time. That's my quick thought; I know it may not look clean...

Also btw some artists like Caetano Veloso happen to have released three, four albums named exactly the same, only in different years. This will fool the algorithm into thinking they're the same album when they're not. Maybe a better solution is to use the MusicBrainz album ID.

[rain0r]

Hi there!

Sorry, I think I didn't make myself clear. My issue was thinking that the queue tab should display cover arts from local filesystem only. If I disable caching with MusicBrainz it just shows nothing. Is this by design as of right now?

This was indeed a bug in ampd. I fixed it in this commit.

About the second issue, I thought a simple way to avoid illegal characters in those filenames: calculating a cheap hash function from the artist/album name and using said hash to create and read files. So, instead of creating a cache file named DEVO - Q: Are We Not Men? [...].jpg, it could be created like as89g63490g23as9fa8[...].jpg and from the artist/album, refer to that same file by calculating said hash every time. That's my quick thought; I know it may not look clean...

For this, we could just use String.hashCode() and it would be a better solution than what we have now.

Also btw some artists like Caetano Veloso happen to have released three, four albums named exactly the same, only in different years. This will fool the algorithm into thinking they're the same album when they're not. Maybe a better solution is to use the MusicBrainz album ID.

Yes, this would also be my preferred solution. Unfortunately, the mpd library in use (javampd) does not offer an option to read specific id3 tags.

[TwelveP]

This was indeed a bug in ampd. I fixed it in this commit.

OK, tested it and now it finds my cover art files alright. Thanks for fixing!

However I suggest letting users configure the cover art filename pattern(s) they wish to use. This may come as a surprise, but in my case, within some folders I have more than one image file lying around; these can be back covers, cd pictures, liner notes etc. So using astherisks matches the first one in alphabetical order, regardless of which one it is.

For this, we could just use String.hashCode() and it would be a better solution than what we have now.

Yes, that's simple enough.

Unfortunately, the mpd library in use (javampd) does not offer an option to read specific id3 tags.

That's too bad. Think it could be requested as a new feature for javampd?

Also, sorry if my next question is dumb, but I really need some orientation in regards to mpd in general, so here goes:
Can this client integrate a plugin to scrobble to last.fm? Or that's a concern for mpd itself?