I have a CD album whose ID3 information is in a non-latin unicode character encoding. Naturally, when loading this new album into Banshee it tries to scan it's online database for matching cover art and it can't because the website only contains English album information. I am assuming this so far, I have no idea if this is what banshee is actually doing.

Not being able to find this information automatically is fine, for I have included the cover.jpg in the album's directory. However, Banshee does not load this file. 

I have noticed the following behavior: when Banshee finds cover art (whether online or provided in the directory) it copies the jpg to ~/.cache/album-art. The file is then named "[artist]-[album].jpg"

Using this information I then copied my cover.jpg to the album art directory and named it using the same convention. However, Banshee yet again failed to load this image.

I then erased my entire album art cache directory and placed the same cover.jpg from the non-english album into an english album's directory and loaded this into Banshee. Banshee then found the cover.jpg and displayed it. (The included cover.jpg was NOT the matching cover.jpg for that album. This was done so that I could verify the included jpg was loading, and not an automatically downloaded copy)

I have come to the conclusion that Banshee does not support unicode file names when looking for cover art. This is odd because Banshee supports unicode mp3 filenames. There must be a bug in the coverart functionality that does not match unicode strings properly - or at all.

Of course I could be completely wrong, but this is what I am inferring based on the behavior I have observed. Hopefully this will help in fixing this bug - it is a very irritating bug as over half of my music collection has unicode ID3 information.

Thank you