Displays wrong cover image for files on SD card

[L20]

I use TC on Android to listen to my playlist of downloaded music. For some reason though, since a few months ago, whenever I add new music (with a cover image as JPEG or PNG defined inside the audio file), it only displays that image while in the downloads directory on my internal storage. As soon as I move the file to my SD card (where my playlist lives), it permanently associates another preview image with that file in TC, as far as I could tell simply the top-most preview image in the directory that is open in the other panel. When I open the file in VLC it displays the correct cover, but in TCMP and the file list in TC itself it displays the wrong cover. Also, creating a new directory and moving the file into there makes TC believe there is no cover image at all, despite the file still being identical to how it was in the downloads folder where the correct cover showed up just fine.
I've even tested the radical method to try and get this association with the wrong cover image removed by completely nuking TC's data, but the exact same wrong cover image is applied again when I open it again.
I also tried switching from the Play Store beta to the stable F-Droid release, same issue despite deleting all of TC's data in-between. Then I added the F-Droid beta repo, deleted all of TC's data again, still same problem.
The only way to get TC to display the correct cover again is to move it back to the internal storage, where I don't have enough space for the entire playlist.

Over half a year ago, when roughly the same issue appeared, I could circumvent it by simply re-tagging the file in VLC and then uploading it to the phone, downloading it again and uploading that downloaded copy, but that workaround now no longer works.

Also, interestingly, after moving one of those mp3 files to my downloads folder and directly into the "Music" folder on the SD card had it show the correct cover, but then when I copied it from there to a subdir again (so more than 1 level deep in the SD card) it showed the wrong cover again, this time the one that it wrongly shows for all files in that directory. I tried the same with a .oga, and it simply kept the wrong cover while on the SD card no matter where.

Although I somehow managed to get it to display the correct cover for one of the files after moving it to the downloads folder while having its location in the "Music" folder in my playlist and selected. Then I tried to play it in the playlist, as expected "FileNotFound". I then moved it back and went to it by the "skip forward" button in the media player notification, and it suddenly showed the correct cover there, but still not in the file list. After killing TC and opening the playlist again (directly through the TCMP icon on the home screen, not through the main TC app), to ensure the notification still showed the correct cover, I long-pressed it in the list and tapped "Go to file", and then it had the correct cover. But when I tried it again with a different file from the same subfolder in "Music", it did not work.

I've recorded my phone screen during my attempt to recreate what I did to the file mentioned in the above section, and also how I inadvertently re-broke one file that had just a few minutes prior to the recording regained its cover image: https://lampe2020.de/files/tc-cover-issue/XRecorder_20260111_02.mp4

[L20]

Note: I have now found a new workaround, see https://lampe2020.de/files/tc-cover-issue/XRecorder_20260111_03.mp4
(the first one was a little stubborn and I misclicked a bit, the second one starting at minute 3:07 went exactly how I discovered the workaround)
(the long thinking pauses at the start of the video are me not remembering what files I had already fixed, and searching through the list with my eyes for ones in the "basilchan" subfolder of "Music")

Warning: This fix is undone by rebooting the phone, as I just found out…

Steps in instruction form: (discovered in "version 3.61d" (version number according to Android's "app info" thingy) from `totalcmd` (stable) F-Droid repo on Android 15 on Fairphone 4 5G, TC installed on the day of this post, tested using .oga files containing OPUS-encoded sound with single PNG or JPEG cover image set by Mp3tag and moved to the phone via KDE Connect)
In preparation to this, a shortcut to TC itself and another one to TCMP directly should be added to the home screen.

1. Open TCMP with playlist including the broken file(s) through dedicated shortcut on home screen
2. Select broken file in playlist, should start playing (and not be last file in list)
3. Pause playback
4. Switch to home screen without closing TCMP
5. Open TC through home screen shortcut
6. Open internal "Downloads" folder in left panel (and ensure there are no audio files in there (at least not directly, in subfolders may be fine), as they could interfere with the workaround!)
7. Open subfolder of "Music" on SD card with broken file in it in right panel
8. Drag-move broken file to left panel
9. Swipe to left panel to check if the correct cover image loads there (the workaround will most likely not work if that isn't the case, but could still work if the correct cover suddenly shows up in step 22)
10. Close TC by "hamburger menu → Exit" (TCMP should automatically come up)
11. Attempt to play the broken file from the playlist (should give a "FileNotFoundException" error and start playing the next file in the playlist)
12. Pause playback
13. Go into TCMP's app info and force-stop bg processes
14. Go into Android's app overview and swipe TCMP away
15. Open TC through home screen shortcut
16. Swipe to right panel (that should show the folder where the broken file was before)
17. Go up into the root of the SD card
18. Create a new folder there, choose a name for it that you have never had audio files in before (name it something similar to the audio file to make it easier) → This seems to be one of the most deciding steps, but the other steps are necessary to get the file back to where it was without re-breaking it, and for making this step somewhat reliable
19. Open the new folder
20. Swipe to left panel and scroll to the broken file (should look as if it wasn't broken)
21. Drag-move broken file to right panel
22. Swipe to right panel to check if the correct cover image loads there
23. (Skip to step 28 if the correct cover image is shown)
24. Go up 1 level
25. Rename the new folder, by e.g. inserting a dash somewhere in the middle of the name (this new name must also be one you never had any audio files in before!)
26. Open the now renamed new folder again
27. (Go back to step 24 if again wrong or no cover image shown)
28. Open original folder of broken file in left panel
29. Swipe to right panel
30. Drag-move broken file to left panel
31. Go into Android's notifications panel to see playback notification (if the notification is missing or not in "stopped" mode, open TCMP from the dedicated shortcut on the home screen and skip to step 34)
32. Tap "Previous" button in notification a few times
33. Tap middle of playback notification to open the playlist
34. Tap the "Previous" button to select the broken file, should start playing
35. Check playback notification if correct cover image is shown (if yes, congrats, that one file is fixed for now!; if not, fully close and stop TC, then restart from step 1, or give up)
36. (Optional) Go to TC's right panel, 1 level up, and delete the folder created during this workaround if you no longer need it
37. (if more files are broken) fully close and stop TC, then restart from step 1

(note that moving the files fixed this way or moving the folders they're in could end up re-breaking the files' cover images, but the workaround should work again on the same files)
Also I have no clue just how specific this workaround is, so I included all the variables here.

I hope this bug gets fixed eventually, this that whole "move here, then there, then that way, kill TC's bg processes 3 times and do a barrel roll" dance to get the bug to bug out is a little bit annoying to do for each and every file.

[ghisler(Author)]

Android uses the album name to store cover images per album, so when I query the media database for an image, it returns the image for that album. So make sure your tracks are correctly tagged.

[L20]

Most of the songs I listen to are singles, so I leave the album field blank. And even those songs that are in the same album sometimes have different cover images. And it seems that all other apps ignore whatever Android uses, because it's only TC that shows the wrong cover images.
Also, if TC purely relies on the tags - why then does it show the same exact file (so same exact combination of tags) differently depending on where I put it, and why are some files that have no album tag either completely fine? Even inside the same physical drive and logical volume the shown image sometimes changes.

Could you maybe add a setting that makes TC and TCMP always load the icon from the file (maybe with caching, but ignoring the album name or other tags), at the cost of a little bit of performance?

[ghisler(Author)]

The problem is described in the Android issue tracker here:
https://issuetracker.google.com/issues/36959625

It seems that these other players just ignore the Android media database and read the cover images directly from the files. I do that too when a track isn't in the media database, but otherwise I prefer to use the database because it's so much faster...

[ghisler(Author)]

Could you please add your tags to the following (silent) mp3 file and send it to me for testing?
https://www.ghisler.com/b/silence.mp3
Please add the tags and a test image exactly as you did for one of the singles. I will then check whether I can find a way to detect the missing or empty album tag, and use the image from the file instead.

[L20]

I applied the tags as I always do, and transferred the file to my phone to test it. TC didn't bother displaying the cover image at all, neither in the Downloads folder, nor when I moved it onto the SD card into a folder with several incorrectly-shown covers (including after tapping the reload button a few times). But I know it has been saved to the file, because when opening it in VLC the image appears for a split-second. So I made an own silence file, ~3.5s long instead of 0.07s. Applied the tags and cover, transferred it, at first no cover at all, just the diskette symbol. When reloading the folder it displayed the correct cover. So I just copied all tags from the most-recently-downloaded actual song (which was still in /tmp on my laptop) and transferred it. This time it first showed no icon, just the diskette. When reloading it showed the cover from another song in that dir.
Below is a screenshot of the tags as applied in Mp3tag and a link to the file, uploaded via TC's FTP plugin directly to my website.
Screenshot: Image: https://lampe2020.de/files/tc-cover-issue/Sk%C3%A4rmbild_20260113_175216.png
Audio: https://lampe2020.de/files/tc-cover-issue/silence.oga
And I know that Android's storage framework or whatever KDE Connect uses to dump shared files (when not using full filesystem access like for remote filesystem browsing) renamed the file I created, from `silence.opus` to `silence.oga`, but renaming it back didn't fix the issue, so that doesn't seem to play a role in the behaviour of the bug. And I noticed that it happens both for MP3/M4A files and for OGG/OGA/OPUS files.
I suspect that maybe quotes or dots in the title may make the bug more likely, but I cannot confirm that. I removed all quotes and punctuation from the broken files in that folder and re-uploaded them, when tapping reload it seemed to have noticed that the files changed (because the cover disappeared for a split-second, unlike with the songs whose files didn't change), but the same wrong cover appeared again.

[ghisler(Author)]

Hmm, that's odd, I have transferred your test file from Windows to my phone via Share - Smartphone Link, and the file does have a preview image!

How did you transfer the file to your phone? It looks like the media database wasn't updated this way.
To force a media database update, please do the following
1. Add a new button to the lower toolbar via "+" button with the following content:
Function type: Internal command
Command: Click on >> and pick command Nr. 130
2. Select the tracks without images
3. Press the button
4. Refresh the directory.

[L20]

It does have a cover for me as well, just not the correct one. Also, as described in the workaround message, the image works fine if the folder you put it into has never had an audio file with cover in it (i.e. the database doesn't know that folder yet). This is what the folder looks like: Image: https://lampe2020.de/files/tc-cover-issue/Screenshot_20260114-124037.png
In the screenshot only the top-most and bottom-most file show the correct cover. All those in-between should have each their own cover.

It took me a while to find the "+" button, but when I found it and tried to use command 130, it only reloaded the contents of the folder but changed nothing. Which I kinda expected, since completely deleting TC's data and reinstalling it did not change what wrong image was displayed.
I tried to get a log file, but it stays at 0B size, which isn't really helpful. [EDIT]: I now have a log file (seems it only gets written when TC exits and immediately emptied when it gets opened again), but it only shows when I've moved what file where, nothing else. So not really useful.

If you want I can upload the actual contents of the folder seen in the above screenshot.
To recreate how I moved the files there, then first unpack it into your downloads folder on the phone, and move them one by one into `<SD card>/Music/basilchan`, reloading that dir between each. Then you should have the issue appear the same way it does for me.

And as I said somewhere in this thread already, I use KDE Connect (on Fedora 43) to send the files to my phone. But I doubt that has any influence on the issue, as the renaming to a standardized filename extension doesn't affect it (renaming it back on the phone doesn't solve the bug), and the file stays binary-identical through the transfer.

[ghisler(Author)]

the image works fine if the folder you put it into has never had an audio file with cover in it

Thanks, I can reproduce that. I have checked it in the debugger, Android returns the folder name as the "Album" when no album name was set in the ID3 tags. This makes it difficult to find out whether a file has an Album tag or not.

[L20]

Android returns the folder name as the "Album" when no album name was set in the ID3 tags. This makes it difficult to find out whether a file has an Album tag or not.

So I could circumvent it by putting the title of the song as the album tag as well on singles?
Also, that sounds kinda like a "tryign to be too helpful" moment right there in the API…

[ghisler(Author)]

So I could circumvent it by putting the title of the song as the album tag as well on singles?

Yes, this should work.

Also, that sounds kinda like a "tryign to be too helpful" moment right there in the API…

The problem is that the Android media database stores album art by album, not by file, to save space.

[L20]

What I meant by "trying to be too helpful" wasn't storing the cover by album (which I deem reasonable), it's that they don't say "No album defined" and instead just assume the folder the file is in is the album. Which causes albumless audios to often have the wrong cover, instead of for those falling back to per-file covers.

[ghisler(Author)]

This should be fixed in Total Commander 3.62 beta 1. Please test it!
https://www.ghisler.ch/board/viewtopic.php?p=479126

I made two changes for this:
1. If the returned album name is the same as the current folder name, read the metadata directly from the file
2. Support the newer ogg/oga format which doesn't use the VORBIS header

[L20]

Now all files that do show a cover show the correct one, but many simply show the TCMP logo (i.e. no cover at all). Interestingly, while the old MP3 files that I put onto my phone years ago still all show their covers, among the newer files all MP3 and M4A files have stopped showing their preciew and only the OGA ones now show it. I'll go through and convert those to OGAs, which seems to work (I tested it with one file before sending this and making the effort of converting it all).
[EDIT]: Okay, seems some of my files got corrupted when I updated the phone and that's why they don't show a preview anymore in TC/TCMP. I'm pretty certain about that because even Mp3tag struggles to read the tags from several of them and I have to use another tagging program to re-save the tags to make them show up in Mp3tag again. Also, some completely lost their preview image and even VLC doesn't find it anymore.