Database source for semi-offline operation

[chrysn]

I'm migrating my MPD server's storage backend from regular network filesystems towards something that behaves like a network filesystem, but with elaborate caching and pre-loading such that directory listings and frequently accessed media is present even in offline situations; for the media itself, that is well under control.

Trouble is with the index database, which I used to run through the proxy plugin (but that won't fly for offline operation). Building (and regularly updating) the index locally is certainly possible, but it upsets the "frequently accessed files" aspect (yeah it'll seek to the right parts of the file, but that's not a well-supported granularity in the storage backend), and/or is slow over the network. So I have multiple avenues to explore – is there maybe already something implemented in either of them?

• Manually copy around the database from the server (which used to be the database proxy plugin's reference source).
  • Yeah, but if a user presses "update", and also, it's manual and prone to version mismatches.
• Have (write?) a database plugin that ingests a provided file (probably distributed along with the media) and takes that as a database. Being a database plugin it can probably turn any user's "update" clicks into "let's see if that file changed". The file could be in MPD's database format or other.
• Have something that, when doing a regular database update, goes "hey there's a special file in here that gives me the metadata of this file (or even all files in the current directory?), so I don't have to read them from the file". This could be sidecar-style, but would need to convey metadata for any kind of file.
  I could then mark those files as "relevant" so that they're locally available on all systems; that'd need regular "update" runs, but the updates would now be cheap to execute.

Which of them would be most promising?

[MaxKellermann]

1. manually copy database is easy, of course, but is a kludge
2. could be a new feature of the "simple" database plugin
3. that could also be a new feature of the "simple" database plugin, and might be useful for people who have read-only access to files (or don't want to modify them in order to preserve hashes) but who want to fix broken tags or add missing tags

2 and 3 are features that could both be useful. Why not.