[Bug] Media doesn't find all music files correctly
asked 2015-09-30 16:29:43 +0300
Affected Sailfish versions:
<= 2.0.2.48 Aurajoki
This bug does not just exist since 1.1.9.28 (time of report) but is already older and really annoys me.
Bug description & use case:
This bug appears everytime after transfering new Music (full Albums in Folders) to my 64GB micro SD card.
This bug causes the issue that after the successful music file transfer you won't find all the music files the Albums/Folders actually contain in the Album overview of the native Media app and that most of the newly added music files are not playable. Some part of the music files will be indexed without a problem with a working album cover, correctly shown id-tagged files and everything how it should work.
You will find some missing music files in an 'Unknown Album' in medias album overview with a wrong music duration of usually '0:00', an missing Artist name, a missing Cover and a messed up name with e.g. some numbers (e.g. 01) in front of the Title name but sometimes you are able to play them normally out of this 'Unknown Album'.
I have to manually re-build my media database to fix this issue everytime because a reboot doesn't fix this issue.
How to reproduce:
So you need a fully id-tagged Album with all music files in one folder. Also IMO there should be >10 music files in the folder so that the chances are better to reproduce this bug (even though I don't see there any pattern in correlation with the amount of music files). My music files usually are tagged with an Album cover, the Artist/Title name, the Album name, the track number, the year of release and the genre. I also tranfering my music via WinSCP so you need the SSH access to your Jolla activated but this shouldn't be necessary to reproduce this bug.
Also it seems that this bug is only reproducable after transfering many media files at once onto your device or only if your device already contains a significant amount of music/media files before the transfer of one album for reproduction. At the moment my Jolla contains about 10000 images listed in gallery and about 2000 mp3-files listed in media app (all media is located on my SD card).
- Connect your SSH client with your Jolla (I am using WinSCP)
- Navigate to your SD card (mine is a 64 GB Samsung microSD card formatted in FAT32)
- Drop your Album folder into another folder on your SD card, e.g. the Music folder
- Wait a few mintues to let the tracker index the music files
- Open the native Media App and navigate to the Album view (the album id tag is needed)
- You should find your Album in the Album list view - open your Album and mostly you will find out that some files are missing there. If you will notice some missing files also have a look in your 'Unknown Album' if you will finde some of them there with a 'half-indexed' messed naming etc.
Workarounds:
- I have to execute
tracker-control -esin terminal to fix this issue so that all music files will be indexed correctly - Use the 'Restore media database' option of the native 'Utilities' App from Jolla store (option is in Settings > Utilities)
Expected behaviour:
After transfering your favourite music onto your Jolla you shouldn't care about rebuilding your tracker database but you should just find all of your music correctly indexed inside of your native Media App. :)
Additional Information:
After indexing the files journalctl contains many of the following errors (but not for each added music file), even though the music is tagged:
[root@Sailfish nemo]# journalctl --no-pager | grep "tracker"
Aug 10 11:57:06 Sailfish tracker-extract[1418]: GLIB WARNING ** Tracker - Task for 'file:///path/to/file.mp3.filepart' finished with error: Could not get any metadata for uri:'file:///path/to/file.mp3.filepart' and mime:'audio/mpeg'
Aug 10 11:57:07 Sailfish tracker-miner-fs[1423]: GLIB WARNING ** Tracker - No urn for file:///path/to/file.mp3.filepart
Aug 10 11:57:08 Sailfish tracker-extract[1418]: GLIB CRITICAL ** libmediaart - media_art_set: assertion 'title != NULL' failed
Aug 10 11:57:08 Sailfish tracker-extract[1418]: GLIB WARNING ** Tracker - Could not process media art for 'file:///path/to/file.mp3', No error given
Aug 10 11:57:10 Sailfish tracker-extract[1418]: GLIB CRITICAL ** libmediaart - media_art_set: assertion 'title != NULL' failed
Aug 10 11:57:29 Sailfish tracker-extract[1418]: GLIB WARNING ** Tracker - Could not process media art for 'file:///path/to/file.mp3', Title is required, but was not provided, or was empty
Aug 10 11:57:48 Sailfish tracker-extract[1418]: GLIB WARNING ** Tracker - Task for 'file:///path/to/file.mp3.filepart' finished with error: Could not get any metadata for uri:'file:///path/to/file.mp3.filepart' and mime:'audio/mpeg'
Aug 10 11:57:53 Sailfish tracker-extract[1418]: GLIB WARNING ** Tracker - Could not process media art for 'file:///path/to/file.mp3.filepart', Error when getting information for file '/path/to/file.mp3.filepart': File or directory not found
Does the file format of the audio files make a difference? Or if you always use the same: which one?
ossi1967 ( 2015-09-30 16:47:05 +0300 )edit@ossi1967 I am just using .mp3-files so I can't make any statement about other file formats.
Alex ( 2015-09-30 16:54:51 +0300 )editcan not confirm. however, what i do notice when adding maaany files at once is that at some point you'll think tracker has finished even though the count shows it's still a couple of hundreds songs short. that's where i just wait and let it do whatever it is that it does there and after a while my collection is complete.
you say a simple tracker restart totally fixes your issue, which means your files must indeed have been tagged and transferred flawlessly all along. if you really want to get to the bottom of this try verbose from terminal, if you're lazy try the wait.
veloxneb ( 2015-10-01 13:47:13 +0300 )editwouaw! great report!
cemoi71 ( 2016-08-16 17:46:40 +0300 )edit@Alex do you know (or could you know) if each files may have different compression?
After looking at the log info, maybe the problem is by the format of the name of some file or their metadata.
If you have the possibility to change it and avoid some special characters.
i don't know which one could be wrong...you may test it a little bit.
I guess that you download some of these files, as i remember the *.filepart is a file downloaded as long as it is not finished. Maybe some of them with *.filepart are not completely downloaded and some data are missed.