Migrate mediaindexer to com.webos.service.mediaindexer

[Herrie82]

Currently we have our own mediaindexer service which is mainly used by FilePicker currently. (https://github.com/webOS-ports/luna-systemui/tree/webOS-ports/master/app/FilePicker) and some alerts.

In legacy webOS these were used by the various media players (audio, video and images).

https://github.com/webOS-ports/luna-systemui/blob/webOS-ports/master/app/SystemManagerAlerts/SystemManagerAlerts.js#L1030

In general we don't need these kinds anymore in LuneOS, since we don't have these legacy apps available anyway (unless we want to get some legacy app working/ported).

We need to see how we want to proceed with this going forward, seeing OSE provides it's own MediaIndexer service (which is used by the OSE media apps).

[Tofee]

What about all the apps available via MuseumApp ?

[Herrie82]

What about all the apps available via MuseumApp ?

That's a good question. I guess we'd need to grep their source code for "com.palm.media." and see how often it's used.

@codepoet80 Do you have this available somewhere to grep around in?

[codepoet80]

Hmm, not easily. The full archive of rescued IPKs is here https://archive.org/details/webOSAppCatalogArchive-Complete but, we'd need to recurse the folder, unpack each package, grep its contents (then probably clean-up.)
Unfortunately, I don't see that there's any metadata that "declares" an app's dependency on this, but the Catalog does have 210 apps in the "Music" and "Photography" categories.

Question: would it be possible/easy to "wrap" the new indexer in an implementation of the legacy service calls, so that old apps don't know the original functionality has been replaced? For third-party apps, I think only FilePicker would need to be preserved.

[Herrie82]

Hmm, not easily. The full archive of rescued IPKs is here https://archive.org/details/webOSAppCatalogArchive-Complete but, we'd need to recurse the folder, unpack each package, grep its contents (then probably clean-up.) Unfortunately, I don't see that there's any metadata that "declares" an app's dependency on this, but the Catalog does have 210 apps in the "Music" and "Photography" categories.

Question: would it be possible/easy to "wrap" the new indexer in an implementation of the legacy service calls, so that old apps don't know the original functionality has been replaced? For third-party apps, I think only FilePicker would need to be preserved.

I don't think the mediaindexer had any API calls available to be honest. What is what doing was running in the background populating db8 kinds, but my memory might be wrong here as well.

[codepoet80]

That's my understanding as well. As long as FilePicker works, I think legacy stuff should be fine.

[Herrie82]

I checked the source code of Media Player Remix and that does seem to query the db8 kinds directly. So I guess for any compatibility we'd need to keep them.

[codepoet80]

That one might be an edge case...

[Herrie82]

Agreed, but located my unpacked IPK directory with almost 600.000 files to grep around in, so we'll find out sound enough

[Herrie82]

I checked 4500 IPK's I had unpacked, seems the following apps use the db8 kinds directly:

Seeing we have 10.000+ IPK's I would expect it to be a dozen or more in the total Museum.

com.epik.audiophilehd
com.7digital.src
se.jelica.bob.plex-client
com.epikwarlord.audiophilehdpro
com.wikidili.dilitimer
com.thewbman.ampachexl