@Smalyshev Do you have any thoughts on this? I'm not sure what's going on.

Search is using already existing file data, which is generated by MimeAnalyzer::getMediaType. Looks like there are some code for OGG there, but maybe needs updating. In any case, it's not really a search thing, it's general core file type detection thing.

@MichaelSchoenitzer_WMDE could you give an example of a file that produces this result? I cannot tell from the code which thing is going wrong, and it would be useful to have a debug case. Thanks for reporting!

@MarkTraceur, almost all files in https://commons.wikimedia.org/wiki/Special:Search/filetype:multimedia should not be classified as "multimedia" but as "audio". You should find plenty of examples there, plus the specific example given in the task description.

Adding TimedMediaHandler tag as the determination will be in there somewhere.

Change 332072 had a related patch set uploaded (by TheDJ):
Special case opus mime detction

https://gerrit.wikimedia.org/r/332072

This is because we don't actually know the difference between these files, they are all mapped to application/ogg. We really should figure out a way to stop guessing mime types for A/V and just analyze the actual file and then return a proper mimetype.

For now, we can add one more hack...

@EBernhardson @Smalyshev Is this something we could review, since it touches on our work?

Change 332072 merged by jenkins-bot:
Special case opus mime detction

https://gerrit.wikimedia.org/r/332072

Change 332640 had a related patch set uploaded (by Brion VIBBER):
Add test case for Opus file check

https://gerrit.wikimedia.org/r/332640

Change 332640 merged by jenkins-bot:
Add test case for Opus file check

https://gerrit.wikimedia.org/r/332640

Quarry call to list these types of files:
https://quarry.wmflabs.org/query/15764

We should probably run a bot to purge out the remaining metadata: https://quarry.wmflabs.org/query/15764

Note that requeueTranscodes used for the formats cleanup won't redo the media type in the image table; it just does transcodes. I'll check if there's anything suitable in core to rerun them or if I need to add a maint script.

This should work:

maintenance/refreshImageMetadata.php --wiki=xyz --force --mime=application/ogg --verbose

I'll do a test run.

Seems to work (quarry shows the old data tho). Went ahead and ran on terbium:

mwscript maintenance/refreshImageMetadata.php --wiki=commonswiki --force --mediatype=MULTIMEDIA --verbose |2>&1 tee refresh-image-metadata.log

Finished refreshing file metadata for 327 files. 0 needed to be refreshed, 327 did not need to be but were refreshed anyways, and 3 refreshes were suspicious.

Does this need to be run on all wikis?

(Now running on all wikis :D)

So... this is done, but the search links in the task summary still return the old data, probably due to CirrusSearch index being out of date? Do the pages need to be refreshed somehow in the search index or will this 'just happen' after some time?

In T151352#3280735, @brion wrote:

So... this is done, but the search links in the task summary still return the old data, probably due to CirrusSearch index being out of date? Do the pages need to be refreshed somehow in the search index or will this 'just happen' after some time?

It'll happen over time as pages get re-parsed. I purged the cache of the two files in the example queries in the description; after a few minutes, the first query correctly returned two results and the second correctly returned none. :-)

A reindex would speed this process up, but reindexing takes effort and is somewhat error prone. In this case, it does not seem urgent enough to warrant the risks and time that come with a reindex.

Thanks for fixing this, @brion!