Provide Local Library Extensions Access to Scanner Data

Some local lobrary extensions may benefit from having direct access to the data dictionary returned by mopidy.audio.scan.Scanner.scan. For example. Mopidy-Local-SQLite provides support for extracting album art for local media files, but has to re-scan every file to do so. I therefore propose changing the method signature of

mopidy.local.Library.add(track)

to

mopidy.local.Library.add(track, data=None)

The optional data argument would be the result from Scanner.scan(). Local library extensions (LLEs) would be free to use or ignore that additional data. As @adamcik pointed out [Local Library Limitations], there currently aren’t that many, so making this backwards-incompatible change is probably safe for now. This would also give LLEs proper access to a file URI for the media file, whereas now they have to extract that from the local track URI by reverse-engineering (AFAICS). LLEs could also be given appropriate time to change their method signature until Mopidy core actually passes a second argument to the Library.add() function (v0.20?).

I’ve been thinking about something similar for https://github.com/mopidy/mopidy/issues/742 Additionally I want a “standardized” tags format we can use as the low level output from the scanner and for use in metadata updates in running streams. By this I mainly just want to make sure no gstreamer data types leak out, but I’m fine just using their field namings.

I don’t expect to get the pipeline part done myself for 0.20, but starting to emit more raw tags to support use cases like this should very much be doable. And as a goal for 0.20 from my point of view is emitting metadata changed events it is something we need to handle anyway :slight_smile:

Ah, #702 slowly starts making sense to me :wink:
Would be glad if 0.20 contained some support for this!

You mean #742? If so yes it is a bit much to digest as it is without a doubt a brain dump to get the idea down on paper instead of trying to keep this all in my head.