Prefer local covert art in current directory

[ramjet]

Hello, I’ve just installed Mopidy to test it out but, as usual, I dont like the covert art feature

My problem is that a large part of my music collection is made up of demos, rehearsal & live gig recordings from bands I either know, have been in, or am currently playing in. So obviously most of the tracks I have do not relate to formally released works.

All my tracks are organised into directories held in the format (where "YYYY is the year):

…\Artist\YYYY Album\01-track 01
…\Artist\YYYY Album\01-track 02 etc.

What I would really like to be able to do is place a file named “Cover.jpg” (or “Cover.png” etc.) in each local directory and then have Mopidy use this file instead of trying to go and find something on the 'net or parse embedded images from the file itself (putting the same image in lots of files is a waste of disk space).

In other words when deciding the cover image to display the presecence a local file of a defined name, should take precedence over trying to automatically find a remote filename.

This should be relatively easy to implement and should not impact the current code/use. All it would take is something like two new config items:

Use_Local_Cover_Art = Y
Local_Cover_Filename = Cover.jpg

Plus something like this Psuedo code when a file is loaded:

localCoverFile = “Directory of file playing” + config.Local_Cover_Filename

If config.Use_Local_Cover_Art && File.Exists(localCoverFile)
LoadCoverArt(localCoverFile)
Else
GetCoverArtFromLocalCache()
End If

Sadly I’ve had this exact same problem with all the Linux audio programs I’ve used that support cover art. Either no cover art is displayed, or in some cases, some completely wrong “random” covert art is displayed which has been fetched from the 'net. Whilst this can occasionally be funny it’s mostly really irritating - I’d far rather have the option to simply switch off cover art altogether than get any old random crap !

I’d really like to be in charge of providing my own artwork

Cheers

[kingosticks]

Great, a PR is welcome. I’m assuming you are talking about Mopidy-Local here.

There’s a guide to contributing your changes at Contributing — Mopidy 3.2.0-5-gc36524a0 documentation and setting up an dev environment at Development environment — Mopidy 3.2.0-5-gc36524a0 documentation

There’s also a stagnant PR at File: Implemented get_images for file library by parth-verma · Pull Request #1925 · mopidy/mopidy · GitHub for Mopidy-File you could finish / extend.

[ramjet]

Sorry I wouldn’t know where to start on doing the actual coding myself (or I’d have already done it). My day job is maintaining mainframe COBOL so I’ve played with Python etc. but don’t have the free time to get up to full sped with it. So I can hack together basic stuff but don’t have the free time to do much more than dabble.

[ramjet]

Ok I’ve had a good look around and I think mopidy stores the cover art at “/var/lib/mopidy/local/images” (I’m using the default but this is obviously configurable) The filenames all appear to be created using some sort of hash value (e.g. " 7eccba5b7eda6ae62a4131047ec28b64-754x777.jpeg") and from looking at the code I think these values are calculated from tags in the file ? (Artist & Album ?)

So my thinking is I can create a temporary workaround for my immediate needs. If I can work out how to create the hash values from my tracks then I can write something that:

1. Reads my music directory and looks for any directories that contain an image file named “Cover” (“Cover.jpg”, “Cover.png” etc.)

2. I can then read the tags from the first mp3 file in the directory, create the hash, then, if the file doesn’t exist in the images directory, copy my custom image file over to the images directory whilst renaming it to the hash.

If someone could give me a few pointers on how to generate the hashes I’d therefore be most grateful. Or if I’m “barking up the wrong tree” then a few pointers as to how this works would be appreciated.

Or, if mopidy logs the hashes for files it doesn’t find images for, I could parse the log(s), get the expected cover file names, and then place a file of the expected name ?

n.b. As I said in my last reply I don’t currently write Python so I’m not familiar with how it all hangs together. So a “plain english” overview would be much appreciated. e.g. “Read file tags A, B, C, concatenate them in some way, then call module/algorithm X to create the hash” etc.). I’ve already been looking through the code and think I’m getting some idea but I don’t understand how all the Python “hangs together” or exactly where/how mopidy creates the hashes.

Or if someone could tell me which mopidy module(s) I could import ? and which function I can call to return a hash for an arbitary file ? I could do that ? (not knowing how Python works makes it very difficult to work this out at present)

As a starter for 10 I’ve just spent about three hours learning a bit of Python and have written a basic script which creates a series of random playlists from my music collection. This has parameters for number of songs per playlist, number of playlists to create etc. and it works fine (I’m listening to one now) But it’s quite primitive as I’m currently having to supply the media and playlist directories as parameters as I’ve not worked out how to read the mopidy config properly. My install is running as a server so I could just read “/etc/mopidy/mopidy.conf” but that wouldn’t work for a non server install.

Anyway if I can find a way to place custom images for my home made tracks then, once my Python’s to an acceptable standard, I’ll be delighted to share the code as I’m sure other people will have the same requirements. All my personal rehearsal/live/demo recordings are all tagged consistently but, not being commercial relases, they obviously don’t have music brainz IDs !

[kingosticks]

Mopidy-Local already provides a mechanism to use album cover art it finds in the directory. The filenames it looks for are controlled with the local/album_art_files config option. If you turn on debug logging while doing local scan you should see that it picks up these images copies this to Mopidy-Local’s image directory and gives it a hash-style name . It combines these images with any embedded image data that was present in the file and they all get associated with the track and with the album.

Mopidy itself will never go and find images online for local files. Some Mopidy frontends/clients might do this but usually only if Mopidy didn’t provide any image data. Note that if a track/album has multiple images associated with it then it’s up the client to pick which one to use. I guess they’d just pick the first one.

and from looking at the code I think these values are calculated from tags in the file ? (Artist & Album ?)

Are you looking as Mopidy-Local ? The hash is calculated from the actual image data.

[ramjet]

Thanks for the reply ! And apologies for not getting back sooner but I’ve not had much spare time recently.

But from a user point of view I think it would be far nicer to use some sort of “human readable” file name rather than a hash (derived from say artist and album/single/title tags ?). Obviously I assume there’s a good reason for using a hash but it’s not very user friendly. Since my first days of using computers it’s always made it easy to understand/hack about with stuff when a program is using understandable file names.

Hopefully I can make some time over the weekend to look into the code a bit more and properly understand how I can use local cover art images for my own stuff.

In the meantime I’ve written a small Python script which creates a random playlist of 250 tracks (configurable) from my entire collection . I’ve set this to run from a cron job at 6am every day so it’s been fun to rediscover lots of stuff I haven’t played for ages. At some point I’ll look to make this into a proper extension.

So at least I’m getting to grips with Python - which I don’t really like because of it’s totally inconsistent “VB” style shortened naming “standards”, dynamic typing (URGHHH !) and whitespace organisation style ("{" and “}” are SO much more logical for delimiting logical blocks… )

Obviously it’s really easy to start learning and can do lots of powerful things but… It’s a fugly language that would be more at home in the 70’s along with 8.3 format file names and abbreviated variable names simply because the compiler/interpreter couldn’t cope with anything else

Cheers.