Artwork not cached to disk for MPRIS

[olib14]

Album artwork caching does not create a file for the current track for use with MPRIS, so no artwork is visible in KDE Plasma's Media Player widget.

"mpris:artUrl" = [Variant(QString): "file:///home/oliver/.cache/fooyin/covers/MPRISCOVER.jpg"],

No such file is created, and there are no warnings or debug output.

[ludouzi]

Strange, it's working fine here. Are you running from master? Does other artwork get cached?

[olib14]

From master, yep, and artwork appears as expected in the application itself - it just isn't saved to disk (i.e. there is no MPRISCOVER.jpg file).

[ludouzi]

I'm guessing the artwork isn't embedded? I've just been able to reproduce this for directory artwork.

Only embedded artwork is extracted and saved as a thumbnail in the disk cache, but MPRIS is still expecting it there. I'll have a fix out in a bit.

[olib14]

That's it! Glad I could help. 🙂

[LukeZBaker]

I don't think browser artwork is fixed where artwork is not embedded.

For many albums, a cached (but not the right) album art cover is being shown when navigating around the filesystem. Restart the app and the correct artwork is shown, but navigating to a different album often again shows a cached (wrong) album cover.

[ludouzi]

When you say wrong cover, do you mean it's the cover of a different album, or the right album but wrong resolution?

[LukeZBaker]

Sorry for not being clear. I mean it's the cover of a different album (a previously viewed album cover).

[ludouzi]

How are the files affected tagged?

The key used for accessing the cache is currently based on the album, artists and date/year tag, so I'm thinking it may see untagged/poorly tagged tracks as identical album wise.

[LukeZBaker]

They may well be poorly tagged. But the strange thing is following restarting fooyin, the album cover is then correctly displayed for an album that was previously showing a different album cover), so fooyin is correctly identifying the cover.

[ludouzi]

Exactly. On a fresh run, the in-memory cache is empty and the first album cover is read and saved to the cache. When playing the next album, if the key (generated from a files tags) is the same, it will see the previous cover in the cache already and use it.

I'll investigate another method of generating the key to test this.

[ludouzi]

With commit 0b6b0fb, I've adjusted how a track's album hash (used for the cache key) is generated by using the parent directory if there's no album tag. If that doesn't fix it, the issue lies somewhere else.

[LukeZBaker]

Looks like its fixed with that commit, thanks!