Cover art shows first file's cover art for all files #50

Activity

1. knuxyl

   added

   bugSomething is not workingSomething is not working

   needs triageIssue is not yet ready for PR authors to take upIssue is not yet ready for PR authors to take up

   on Apr 21, 2024
2. knuxyl

   changed the title [-]Covert art is not updated upon song change[/-] [+]Covert art shows first file's cover art for all files[/+] on Apr 21, 2024
3. Aga-C commented on Apr 21, 2024

   

   Aga-C

   on Apr 21, 2024

   Contributor

   More actions

   I couldn't reproduce it just by opening the app after unpacking these files. After manual rescanning of media, those files indeed lost their covers. I could also reproduce it by clearing all app data. What's interesting, I don't have this problem with covers saved in FLAC files.
4. Aga-C

   removed

   needs triageIssue is not yet ready for PR authors to take upIssue is not yet ready for PR authors to take up

   on Apr 21, 2024
5. knuxyl

   changed the title [-]Covert art shows first file's cover art for all files[/-] [+]Cover art shows first file's cover art for all files[/+] on Apr 21, 2024
6. knuxyl commented on Apr 21, 2024

   

   knuxyl

   on Apr 21, 2024

   Last edited by knuxyl

   Author

   More actions

   I have a temporary fix working but it's not perfect. I'm at a dead end. I found that if I set coverArt to "" (blank string) it works, but is a little glitchy on loading them, like takes a half second or so, and the track list in the activity sometimes loads the wrong one.

   SimpleMediaScanner.kt
   app/src/main/kotlin/org/fossify/musicplayer/helpers/SimpleMediaScanner.kt
   line 248

   //val coverUri = ContentUris.withAppendedId(artworkUri, albumId)

   line 249

   //val coverArt = coverUri.toString()

   line 250

   val coverArt = ""

   The problem I'm facing now is the difference between how getTracksSync() and getAlbumsSync() differ in their MediaStore. getTracksSync() uses Android.Media while getAlbumsSync() uses Android.Albums for the cursor query. It seems that the album sync is able to set the artwork fine but the tracks sync does not. I have no idea what exactly is going on but this is a temporary fix for me.

   If you want to test this build I uploaded it. It's a debug build, couldn't figure out how to build a release apk.
   https://drive.google.com/file/d/1p5_Y5k47GdsNqWovdH3x0Z_0d29OkWf5/view?usp=sharing
7. naveensingh

   added

   confirmed

   accepted

   and removed

   confirmed

   on Jan 27, 2026
8. naveensingh

   removed

   accepted

   on Jul 14, 2026
9. aicode8000 commented on Oct 3, 2026

   

   aicode8000

   on Oct 3, 2026 – with ChatGPT Codex Connector

   More actions

   I can confirm this behavior with MP3 files on Fossify Music Player 1.8.1, installed through F-Droid, on a Volla Phone Quintus running Android 15. This also seems related to #400.

   Reproduction

   1. Put multiple MP3 tracks in the same folder, with the same artist and album tags.
   2. Embed a different front-cover image in each file.
   3. Scan the media library in Fossify and switch between the tracks.

   In my case, 31 tracks originally shared the album tag Aster Null, while each track had its own embedded cover. Fossify displayed the cover of Break the Mirror for all of them.

   Checks performed

   • All 31 files contain a single, distinct JPEG front cover in an ID3v2.3 APIC frame (picture type 3).
   • The embedded images were checked against the corresponding source covers.
   • The files were downloaded through Nextcloud. SHA-256 checks over ADB confirmed that all 31 copies on the phone were byte-for-byte identical to the local files, ruling out a transfer or synchronization discrepancy.

   Removing the album tags did not solve the problem. After deleting and downloading the files again, Android MediaStore assigned all 31 tracks to an album named mp3, derived from their containing folder. They all had the same album_id. Reading that album's artwork URI over ADB returned the Break the Mirror cover.

   Workaround confirmed

   Setting each file's album tag to its own track title, then rescanning, resolved the issue:

   • MediaStore assigned 31 distinct album IDs.
   • Each album artwork URI returned the correct cover for its track.
   • Fossify then displayed the correct individual covers.

   The audio and embedded images were unchanged; only the album metadata was changed. This workaround is undesirable for a real album because it splits one album into multiple albums.

   Possible cause and desired behavior

   These observations appear consistent with the existing analysis in this thread. In getTracksSync() in version 1.8.1, track coverArt is built from the album ID, so tracks in the same album share the same artwork URI. getTrackCoverArt() prefers this non-empty value over loading artwork from the individual file.

   Could Fossify prefer a track's embedded artwork when displaying an individual track, with album artwork as a fallback? The album grid could still use a representative album cover, while the track list and Now Playing screen use each track's own image. A per-track artwork cache could preserve performance without requiring users to change their album tags.

   👍React with 👍3Reacted by pindragin, scavi and marcosox
10. pengusto commented on Oct 22, 2026

    

    pengusto

    on Oct 22, 2026

    More actions

    I reproduced the shared-cover behavior in the official Music Player 1.8.4 APK with two generated MP3 tones having identical album/artist tags and distinct red/blue embedded covers. Both tracks have the same MediaStore album ID. The original shows red for both; the patched APK shows each file's own cover. Generated Opus fixtures were also verified separately.

    Two reviewable paths are now available:

    1. Optional version-specific workaround: Penguin Patches v1.0.0-dev.5, compatible with Morphe, targeting only the original official 1.8.4 APK.
    2. Prepared native upstream candidate: source branch, comparison and Android tests. This is a published fork branch, not an upstream PR or merged fix.

    The workaround reads file-specific embedded artwork inside the original artwork worker before the original shared album/fallback path. MP3 uses the platform metadata reader; a bounded read-only OpusTags picture reader handles Opus when Android exposes no embedded picture. It retains album grouping, existing database cover values and original main-thread callbacks; it never edits audio tags or files. The parser caps scanning at 128 Ogg pages/8 MiB and validates lengths; malformed metadata fails back to the original logic.

    Native patch tests verify red/blue pixels for both MP3 and Opus, missing/empty/no-cover/corrupt fallbacks and malformed Opus metadata. Separately, two native source Android tests verify callback output, malformed metadata and unchanged source-file SHA-256 hashes using included synthetic fixtures. Build, Android Lint and Detekt passed.

    Before	After

    Same isolated Android 15 ARM64 emulator and native 1080 × 1920 viewport; synthetic data only. These screenshots show the Morphe-patched official APK. The native source build is tested separately, not the source of these images. Test output and evidence. Physical devices, other audio formats, document-only URIs and existing asynchronous recycled-view races remain unverified.

    Thanks to the issue author, @Aga-C, @knuxyl and @aicode8000 for the album-art analysis, reproductions and earlier workaround experiments. This implementation preserves album grouping and stored tags.

    Would maintainers welcome this focused native fix after triage? I will wait for explicit approval or the required help wanted label before opening an upstream PR and can adjust the scope. The workaround stays restricted to tested old versions; once an official fixed release is verified, that fixed version will not be added to patch compatibility.

    Existing same-key Morphe installations can update in place. Moving from a differently signed official installation needs verified backups and signing-key planning; do not uninstall a real app just to bypass a signature conflict.

    👍React with 👍1Reacted by FaberLiber
11. aicode8000 commented on Oct 26, 2026

    

    aicode8000

    on Oct 26, 2026

    More actions

    Thanks a lot @pengusto for reproducing this on 1.8.4 and for the detailed fix, tests and screenshots! Reading the embedded artwork per track while keeping album grouping is exactly the behavior I was hoping for. I'd be glad to see this land upstream as a PR. @Aga-C, would a PR along these lines be welcome?
12. pengusto commented on Oct 26, 2026

    

    pengusto

    on Oct 26, 2026 – with ChatGPT Codex Connector

    More actions

    Thanks! Until an upstream fix is available, the Penguin Patches workaround for the official 1.8.4 APK is available. The native source fix is also ready for review. I’m waiting for maintainer approval before opening an upstream PR.