GNOME Bugzilla – Bug 752054
Add read-only support for .mediaartlocal directories
Last modified: 2021-05-25 11:25:39 UTC
(Filed a new bug instead of bug #722795 to avoid blowing that up again.) The arguments made against .mediaartlocal directories in bug #722795 are quite reasonable: • .mediaartlocal folders are visible on other OSs (for example, Windows) • libmediaart/Tracker should ideally not write to any filesystems it indexes (it should observe, not modify) • Removable drives typically only get used in one or two computers, so .mediaartlocal doesn’t save too much space across many machines However, this doesn’t address the embedded situation where storage space on $HOME is expensive. For example, in a car IVI system, $HOME is stored on automotive grade flash memory, so is a precious resource. Car passengers would be expected to plug a variety of removable drives into the system, each containing almost exclusively thumbnailable media — that can add up to a lot of cache space. I know the possibility of a $STORAGE/.mediaartlocal directory or a compile-time option for this was considered on the mailing list — is this still a possibility? Either solution would work for this use case, but the current (1.9) API which just supports $XDG_CACHE_HOME doesn’t really work. https://mail.gnome.org/archives/tracker-list/2014-September/msg00024.html
In fact, even if it turns out that re-adding .mediaartlocal support to the extractor is universally frowned upon, could we re-add support for .mediaartlocal (or $STORAGE/.mediaartlocal, if the spec is updated) to the cache? That way, at least we’re following the read-only part of the spec, and any custom patches which embedded systems have to carry to implement .mediaartlocal have a smaller diff (i.e. only in the extractor, not the cache as well). I suspect that would mean a reversion to the 0.7 API for media_art_get_file() and media_art_get_path().
I'd be interested in knowing if any of Philip's suggestions would be acceptable / desirable?
(In reply to Mathieu Duponchelle from comment #2) > I'd be interested in knowing if any of Philip's suggestions would be > acceptable / desirable? Sorry this bug went unheard... It indeed makes sense to optionally observe local storage. Although maybe a bit late now that Tracker 1.11.x is leaving albumart extraction up to clients (deemed as "safer if not in our hands" after the sandboxing effort)... This option is still good for clients themselves. IMHO would be nice to have variants of media_art_get_*() that take a flags argument, so it can optionally look up on local storage before ~/.cache. Likewise, a flag value could be added to MediaArtProcessFlags to optionally store stuff in that same place.
(In reply to Carlos Garnacho from comment #3) > IMHO would be nice to have variants of media_art_get_*() that take a flags > argument, so it can optionally look up on local storage before ~/.cache. > Likewise, a flag value could be added to MediaArtProcessFlags to optionally > store stuff in that same place. Thanks for responding, Carlos. :-) I’m no longer working on that project, so I’m not going to pick this up. However, your flags suggestion seems reasonable to me.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/libmediaart/-/issues/ Thank you for your understanding and your help.