Re: emms cache db best practices

[Yoni Rabkin]

Grant Shoshin Shangreaux <grant@churls.world> writes:

> Hello emms devs!
>
> I've been digging into the application and hope to contribute to it a
> bit in the future. Specifically I'm trying to figure out the a good way
> of editing tags on .opus files, and perhaps using the cache db for
> additional metadata storage.
>
> Unfortunately, I had an unexpected Emacs crash this morning, and
> discovered on relaunching that my emms cache had lost information. After
> looking through the code, it appears that the cache is only saved when
> you ask it to be or if you kill Emacs.
>
> Normally, this might not be a huge deal. Most track data is actually
> metadata on the media files. I could just re-add them. However, in this
> case I'd only recently discovered that the tags i'd authored for some
> .opus files had not actually been saved. This set me off on finding out
> why the tag editor had "silently failed" to save the metadata to the
> file, while revealing the feature that the emms-cache-db could preserve
> metadata not attached to the file! similarly, i'd been experimenting
> with the emms-bookmarks.el which also uses the cache to store timestamps
> on a track.
>
> Anyhow, i was wondering if there might be some way to mitigate this
> problem in the future that doesn't demand manually saving the cache or
> killing Emacs?

This should be considered a bug in Emms.

Perhaps one way of solving this is to make the tag editor immediately
re-read the edited tag, compare what was written to what was re-read,
and notify the user if there is a difference.

The cache-saving behavior isn't robust, but isn't surprising either
since the cache implementation in Emms is naive (and is old enough to be
a teenager.)

We'll fix both of these, and try to have them tried and tested for the
May release. As usual, if anyone wants to beat me to the code, they are
welcome to claim this project and run with it.

-- 
   "Cut your own wood and it will warm you twice"