Replace property class with something sane

[Jussi Pakkanen]

The property class is poorly designed in multiple different ways. The main one of these being that it is a massive dependency injector. Since it converts all data to and from all possible backend types, it must include all said dependencies. Since property is used in many places it makes every part of the code base dependent on every other part of the code base.

The fix is to create a simple class that holds media information. Each backend then deals only with these objects, converting between the common data model and their own. This decouples e.g. Grilo from Lucene, which is how it should be.

The current implementation is also a massive garbage pile of templates and too much cleverness. Getting rid of it should noticeably cut our compile times (especially since so many files include property.h).

[James Henstridge (jamesh)]

If we were going to redo the internals (which I don't think is on the table until we've fixed up the other missing features and bugs), I'd seriously consider getting rid of mediascanner's internal metadata representation all together.

At the moment, we've got the MediaInfo class with the following conversion routines:

 * to and from GrlMedia
 * to and from Lucene::Document
 * from GstDiscovererInfo/GstDiscovererStreamInfo

Apart from not being written in C++, the GrlMedia type seems like it could fill this role. And if the GstDiscoverer code was packaged up as a Grilo metadata resolver plugin, the media scanner daemon's job boils down to:

 1. watch for file system changes
 2. run a series of Grilo metadata resolver plugins
 3. store results in Lucene index.

[Jussi Pakkanen (jpakkane)]

After a quick look this makes sense. A rough outline:

- terminate Property
- make MediaInfo specific, that is, give it methods such as "get_album_name"
- hide internals and make it take only elementary data types
- make it value assignable

[Jim Hodapp (jhodapp)]

You might also want to check out this project: https://github.com/nemomobile/qtgrilo

I'm not sure yet if it applies directly to this bug or not as I haven't examined the code of qtgrilo, but Michael Hall made me aware of this project and I thought I'd pass on the info in case any of you aren't aware of it.

[James Henstridge (jamesh)]

Hi Jim,

qtgrilo (or something equivalent) will almost certainly be part of the any music or video app on the phone, we're mainly discussing the internals of the scanner here.

If we did any of this refactoring (and that isn't a given), it would not change the Grilo plugin interface that users of the media scanner currently rely on.

[Michi Henning (michihenning)]

mediascanner is no longer being maintained, marking as won't fix.