Ogg Vorbis song titles ignored by Media app

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): (Suomenlinna)
HARDWARE (XA2, X10, X10 II, …): Jolla C
REGRESSION: (compared to previous public release: Yes, No, ?): Yes, compared to 3.x


When I browse the contents of albums in the default Media player app, song titles of Ogg Vorbis files on my SD card aren’t displayed in the list. Instead the app lists the actual file names without the “.ogg” suffix. The correct titles are stored in the files as standard TITLE tags but the app ignores them. It does seem to read and understand the ARTIST and ALBUM tags, because songs are placed under the correct artist and album. Also titles from songs in MP3 format seem to be shown correctly.

Furthermore I notice that the albums of any given artist are listed alphabetically instead of chronologically like they used to be, which indicates that DATE tags are also being ignored. Or is this by design? I would hope not.

Unfortunately I cannot say exactly which SFOS version introduced the problem, because until recently my Jolla C was still running what I think was 3.2, and all Ogg Vorbis tags worked fine. I upgraded to the latest SFOS over the course of two days, going through each stop release offered to me. I didn’t try the Media app until I was at 4.3.

I’m having other issues with the Media app in 4.3, such as playlists not working and album cover art appearing and disappearing, but this is the one I would like to get fixed first.


  • Have some Ogg Vorbis audio files that have at least the comment tags TITLE, ARTIST and ALBUM in them. See Ogg Vorbis Documentation for more info.
  • My files are stored on an SD card, but files in /home/nemo/ don’t seem to work any better.


  1. Open the built-in SFOS Media app
  2. Browse Artists > select an artist > select an album
  3. Examine the track list of the album


  • The song titles should appear exactly as they are given in the TITLE tags.


  • Instead of actual titles, the track list contains file names (without the “.ogg” suffix). If your files have the track number as a prefix in the file name, like most of mine do, you’ll see the number as if it was part of the title.


(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

  • This is my first post here, so please excuse the lack of logs and screenshots. How do I collect them?
  • No errors appear in the terminal when starting jolla-mediaplayer there.
  • I cleared the media database once using Settings > Utilities and once running tracker3 reset --filesystem, but the titles still don’t appear.
  • I couldn’t find any forum posts about this issue, and I would welcome any suggestions on how to troubleshoot it. Thank you!

I first encountered this error in 2018. Jolla doesnt care at all.


Also, cover art is missing from OGG Vorbis files.

1 Like

I confirm this error. My exception is cover art - those are displayed by stock media player (but I keep them as image file in album directory, not as a tag inside the file).

My workaround is to use other players - either Muuzik! or QuasarMX. And of those two IMHO Muuzik! has better UI and gets most of usage.

How can I get Muuzik! to search for music on my sd card? It doesn’t work for me on XA2 Ultra SFOS 4.3

I have Muuzik! 2.4.8 under SFOS 4.3 and in Muuzik! Options (from pulley menu) the first selection is Sdcard - Where is your music on the sdcard.

1 Like

Yeah, I see that option, but I can’t interact with it.

I have no idea why this may happen. Maybe others can help why UI does not work.

But meanwhile you could try a workaround. Check if Muuzik! is closed. If you know how to access your phone with ssh or other means that allow the changing of files, then open folder /home/nemo/.config/harbour-vostok_muuzik/ (or if you are not using username nemo, then the respective home folder of the username you use) and add to the end of harbour-vostok_muuzik.conf file the following (e.g by using nano):


where you replace “yoursdcardfoldername” with the exact name of the folder.

1 Like

I can’t find the muusik! app neither in the Jolla Store, in storeman nor in chum?

By searching “Muuzik” it comes up in Jolla store.

There is no aarch64 version and Muuzik! seems to be closed source.

1 Like

Thanks that explains why

Thanks for a thorough explanation, but it doesn’t work for me. I’ve tried adding the name of the folder, the path to the folder, the name of the card. It doesn’t work. :frowning:
Nvm, I’ll still use Quasar MX. :wink:

Thanks for suggesting those alternative apps. I haven’t tried them yet, but I might have to. The ideal solution would still be to continue using the stock Media app, and I find it very unfortunate that it’s so broken in its current state.

I did some digging and asking around and I’m suspecting that Tracker 3 might not be functioning quite as it should, at least on my phone. I found out that the tracker3 info command works differently than it did in the previous version of Tracker, where the corresponding command tracker info would print out all metadata collected from the file. Now you basically have to run it twice; first to get the nie:interpretedAs UUID that corresponds to the content of the file, and then with that UUID as the parameter.

I created a test file silence-10s.ogg, and when I ran tracker3 info on that file in Ubuntu and Sailfish OS, I got different results. The main difference that I can see is this:

Ubuntu 21.10 LTS:

  'nie:title' = 'Ten Seconds of Silence'
  'http://purl.org/dc/elements/1.1/date' = '2022-01-01T00:00:00Z'
  'http://purl.org/dc/elements/1.1/contributor' = 'urn:artist:Some%20Artist'
  'http://purl.org/dc/elements/1.1/title' = 'Ten Seconds of Silence'

Sailfish OS

  'nie:title' = 'silence-10s'
  'http://purl.org/dc/elements/1.1/contributor' = 'urn:artist:Some%20Artist'
  'http://purl.org/dc/elements/1.1/title' = 'silence-10s'

These are the tags in the file:

COMMENTS=Audacity 2.2.2
TITLE=Ten Seconds of Silence
ALBUM=Some Album
ARTIST=Some Artist

Tracker on Sailfish OS fails to see the TITLE and DATE tags in the file, and instead uses the file name as the title and doesn’t index any date at all. tracker3 --version says “Tracker 3.1.2” on both systems. I double-checked the MD5 checksum of my file and it’s not corrupted.

I really hope this info could help someone debug the issue and fix it. If there’s further assistance I could provide, please let me know.

1 Like

Thanks for raising this @Faroe, and the helpful info you’ve provided on it. I’ve created an internal issue about it and tagged it here as “tracked”. If there are updates in the future we’ll do our best to post them back here.

Hello again!

For most of last year I have continued to use the default Media app on my Jolla C, regardless of the fact that song titles and album dates of Ogg Vorbis files aren’t working. I guess that shows I’m ~95% satisfied with the app and haven’t bothered to look for a competing media player. However, the problem with the Ogg Vorbis files still persists on SFOS, and I recently got inspired to look into it a bit further.

I mentioned earlier that the same Tracker version (i.e. 3.1.2) running in Ubuntu 21.10 manages to read all Ogg Vorbis tags correctly. Now I know that Tracker 3 uses a different library/module for parsing Ogg Vorbis files in Ubuntu, which feels like it’s probably relevant.

  • Sailfish OS uses /usr/lib/tracker-miners-3.0/extract-modules/libextract-libav.so
  • Ubuntu uses /usr/lib/x86_64-linux-gnu/tracker-miners-3.0/extract-modules/libextract-gstreamer.so

On both systems, the library to use is determined by the files in /usr/share/tracker3-miners/extract-rules. Sailfish OS has 90-libav-audio-generic.rule in there while Ubuntu has 90-gstreamer-audio-generic.rule instead; both systems only contain the libextract-*.so file under /usr/lib/ that corresponds to the *.rule file, not the other.

Now I wonder if someone could tell me why Tracker 3 has been packaged this way on Sailfish OS 4.x. Is there some known issue with libextract-gstreamer.so that has made libextract-libav.so seem like a better choice?

Another thing I’ve learned since my last post is that there’s no point in fiddling with tracker3 info, because a command like tracker3 extract --output-format=json-ld <oggfile> shows you all the tags that Tracker 3 can parse from the file. When run with G_MESSAGES_DEBUG=Tracker in front, it also tells you which extractor is being used.

If anyone is interested in trying to reproduce the problem on their SFOS devices, I can provide a couple of tiny Ogg Vorbis files that I have been experimenting with.

Thank you very much for reading.


Probably not so helpful, but since I’m working on gst stuff. Tracker has all the info that I write to the file (using Audioworks).

[defaultuser@VollaPhone ~]$ tracker3 extract Music/Tick-1_edit.ogg 
@prefix nmm: <http://tracker.api.gnome.org/ontology/v3/nmm#> .
@prefix nie: <http://tracker.api.gnome.org/ontology/v3/nie#> .
@prefix nfo: <http://tracker.api.gnome.org/ontology/v3/nfo#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<urn:artist:Blue> nmm:artistName "Blue" ;
  a nmm:Artist .

<urn:album:Tock> nie:title "Tock" ;
  a nmm:MusicAlbum .

<urn:album-disc:Tock:Disc1> nmm:setNumber 1 ;
  nmm:albumDiscAlbum <urn:album:Tock> ;
  a nmm:MusicAlbumDisc .

<file:///home/defaultuser/Music/Tick-1_edit.ogg> a nmm:MusicPiece , nfo:Audio ;
  nmm:trackNumber 1 ;
  nfo:channels 1 ;
  nfo:averageBitrate 78658 ;
  nfo:sampleRate 44100 ;
  nfo:duration 2 ;
  nmm:artist <urn:artist:Blue> ;
  nmm:musicAlbum <urn:album:Tock> ;
  nmm:musicAlbumDisc <urn:album-disc:Tock:Disc1> ;
  nie:title "Tick-1 edit" .

Musicplayer show the Artist name in the list (also for other tests files I set). It lists the Album as Tock as you’d expect. The tracks is listed as it appears in the tags. So it looks like at least that works. I need to create a whole album to test it end to end.

Thanks for your input. What is the exact content of the TITLE tag of your file? Is it “Tick-1 edit” or something else? It seems to me that, whenever Tracker 3 fails to read that tag (or just ignores it for whatever reason), it takes the file name, discards the suffix, replaces underscores with spaces, and puts the result in nie:title. What does tracker3 extract show you if you give it e.g. a file named “abcd.ogg” in which the TITLE tag is “xyz”?

Also allow me to recap: as far as I can tell, at least the ARTIST, ALBUM and TRACKNUMBER tags in Ogg Vorbis files are parsed correctly by Tracker 3 on SFOS 4.x, while TITLE and DATE are not.

Yes, and that’s wrong :slight_smile: I just tried again with a completely different name and the file name seems to be what is being used, not the name tag. Otherwise, the Album name and artist are correct. And, it is tracker that is getting it wrong:

  nmm:musicAlbum <urn:album:Tock> ;
  nmm:musicAlbumDisc <urn:album-disc:Tock:Disc1> ;
  nie:title "Tick-1 edit" .

The name tag is set to TickTick :slight_smile: So as you suggest, Title is not set correctly and Date is not set at all. I’m going to see if I can construct a gst-inspect-1.0 pipeline to read the tags by other means.

1 Like

FWIW, I installed gstreamer1.0-plugins-base-apps so that I could run this:

gst-discoverer-1.0 --verbose ./test-300ms-a.ogg

The output from that command contains this:

      artist: Test Case
      title: OK
      album: Alpha
      datetime: 1995
      track number: 9

And yet, tracker3 extract ./test-300ms-a.ogg mentions

  nie:title "test-300ms-a" .

and the correct nie:title would be “OK”. This suggests to me that GStreamer would be capable of parsing all the tags correctly if only Tracker 3 was configured to use it, and judging by those *.rule files it’s not. However, I’m only guessing what Tracker is or isn’t doing.

Ok, you beat me to it :slight_smile: I wanted to do it the hard way. This suggests, as I believed, that it’s not gst or it’s implementation of libav but tracker3. Now we know :slight_smile: Thanks!

EDIT: not so handy cli file player:

gst-launch-1.0 filesrc location=Music/Tick-1_edit.ogg ! oggdemux ! vorbisdec ! audioconvert ! audioresample ! pulsesink