search

webOS-ports / luneos-testing

Public testing images for LuneOS
4 stars 1 forks source link

Migrate mediaindexer to com.webos.service.mediaindexer #33

Open Herrie82 opened 9 months ago

Herrie82 commented 9 months ago

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.

image

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 commented 9 months ago

What about all the apps available via MuseumApp ?

Herrie82 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

Herrie82 commented 9 months ago

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 commented 9 months ago

That one might be an edge case...

Herrie82 commented 9 months ago

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

Herrie82 commented 9 months ago

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