Bug 443519

Just realized I'm also running into this. I intentionally named all my Opus-encoded music with the ".ogg" extension so that it could easily sync with my Android phone, because Android does not support the ".opus" extension before version 10. Seeing Elisa have essentially the same bug but in the opposite direction is funny, in a depressing kinda way...

That's weird, Elisa does advertise support for ogg files:

application/x-ogm-audio;audio/x-vorbis+ogg;audio/ogg

Can you run `file --mime-type [path to file]` on one of those files and paste the output here?

file --mime-type gives me audio/ogg, regardless of extension:
brendon@theta:~/media/music/cds/Audioslave/Audioslave$ mv 01.\ Cochise.ogg 01.\ Cochise.opus
brendon@theta:~/media/music/cds/Audioslave/Audioslave$ file --mime-type 01.\ Cochise.opus
01. Cochise.opus: audio/ogg
brendon@theta:~/media/music/cds/Audioslave/Audioslave$ mv 01.\ Cochise.opus 01.\ Cochise.ogg
brendon@theta:~/media/music/cds/Audioslave/Audioslave$ file --mime-type 01.\ Cochise.ogg
01. Cochise.ogg: audio/ogg

Now if I run
QT_LOGGING_RULES="*.elisa.*=true" elisa
and then try to open the ".ogg" file in Elisa (from Dolphin), I get this output:

org.kde.elisa.playlist: MediaPlayList::enqueueMultipleEntries 1
org.kde.elisa.playlist: MediaPlayList::enqueueMultipleEntries QMap((DataTypes::ResourceRole, QVariant(QUrl, QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg")))(DataTypes::ElementTypeRole, QVariant(int, 5)))
org.kde.elisa.playlist: MediaPlayList::enqueueMultipleEntries new url QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg") ElisaUtils::Track
org.kde.elisa.indexer: scanOneFile QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg") using KFileMetaData QMap((DataTypes::RatingRole, QVariant(int, 0))(DataTypes::ResourceRole, QVariant(QUrl, QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg")))(DataTypes::FileModificationTime, QVariant(QDateTime, QDateTime(2022-08-23 11:07:54.972 EDT Qt::LocalTime)))(DataTypes::ElementTypeRole, QVariant(int, 5)))
qrc:/qml/MediaPlayListView.qml:296:33: Unable to assign [undefined] to bool

However, when I rename the file to ".opus", the interesting difference starts here:

org.kde.elisa.indexer: scanOneFile QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.opus") using KFileMetaData QMap((DataTypes::TitleRole, QVariant(QString, "Cochise"))(DataTypes::DurationRole, QVariant(QTime, QTime("00:03:42.000")))(DataTypes::ArtistRole, QVariant(QString, "Audioslave"))(DataTypes::AlbumRole, QVariant(QString, "Audioslave"))(DataTypes::TrackNumberRole, QVariant(int, 1))(DataTypes::RatingRole, QVariant(int, 0))(DataTypes::YearRole, QVariant(int, 2002))(DataTypes::ChannelsRole, QVariant(int, 2))(DataTypes::BitRateRole, QVariant(int, 120000))(DataTypes::SampleRateRole, QVariant(int, 48000))(DataTypes::ResourceRole, QVariant(QUrl, QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.opus")))(DataTypes::HasEmbeddedCover, QVariant(bool, false))(DataTypes::FileModificationTime, QVariant(QDateTime, QDateTime(2022-08-23 20:26:17.835 EDT Qt::LocalTime)))(DataTypes::ElementTypeRole, QVariant(int, 5)))
org.kde.elisa.playlist: MediaPlayList::trackChanged QVariant(QString, "Cochise")

I'm guessing the relevant implementation of scanOneFile() is the one in filescanner.cpp, which initially creates a list of candidate extractors. Evidently a candidate is chosen (else it would say "no extractors"), but it seems that extractor ultimately fails to actually extract any metadata. This may (or may) not be the cause of Elisa not reading the ".ogg" file - I notice it does add a "no entry" icon to the playlist, but plays nothing. (FWIW, my Elisa is at 21.08.3, but my Frameworks which has KFileMetaData is at 5.97.0.)

Good sleuthing! Would you be interested in continuing to investigate and submitting a merge request to https://invent.kde.org/multimedia/elisa/-/merge_requests?

I wouldn't expect to have time to get as far as a merge request, but I can probably do more sleuthing. I just took another dive into the code and found that the likely extractor is the one based on Taglib. So I installed pytaglib and tried to open the file. In python3:

>>> import taglib
>>> song = taglib.File("/home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "src/taglib.pyx", line 87, in taglib.File.__cinit__
OSError: Could not read file /home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg

Well, I'm pretty sure I didn't get the path wrong. I tried renaming the same file to ".opus", and then:

>>> song = taglib.File("/home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.opus")
>>> song.tags
{'ALBUM': ['Audioslave'], 'ARTIST': ['Audioslave'], 'COMPILATION': ['false'], 'DATE': ['2002'], 'ENCODER': ['opusenc from opus-tools 0.1.10'], 'ENCODER_OPTIONS': ['--bitrate 128'], 'TITLE': ['Cochise'], 'TRACKNUMBER': ['01']}

So, if I'm not mistaken, conclusion is this is a bug in Taglib.

Looking through the Taglib Github issues page, I found this:
https://github.com/taglib/taglib/pull/1013
Judging by the dates, the fix has been in master for over a year, but no stable release in that time...

Aha that makes perfect sense. Yeah, TagLib needs to make a release.