App keeps crashing or returns to previous menu after trying to play any track with a cover image

[ShadyMedic]

Checklist

• [x] I can reproduce the bug with the latest version given here.
• [x] I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• [ ] I made sure that there are no existing discussions - open or closed - to which I could contribute my information. No I didn't, because the links are dead.
• [x] I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• [x] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• [x] This issue contains only one bug.
• [x] I have read and understood the contribution guidelines.

Affected app version

1.2.3

Affected Android/Custom ROM version

Android 15 / RisingOS Revived 6.3

Affected device model

Moto Edge 30 Neo

How did you install the app?

GitHub releases

Steps to reproduce the bug

1. Install the app (I did so from F-droid, after trying to reproduce with the newest version, I did so from newest the GitHub release – bug persisted).
2. Open it, grant any permissions needed.
3. Everything looks as it should (as far as I remember) – menus works etc. Tracks from the Folders and Artists tabs can be played normally.
4. Go to the Tracks tab and try to play any track from there. Or go to the Playlists tab, open All tracks and try to play any track from there. Or try to play a song from the Albums menu.

Expected behavior

Playing tracks from the Tracks tab or All tracks playlist should work just like from the other tabs and not crash the app.

Actual behavior

(continuation of the list from Steps to reproduce the bug) 5. App crashes (usually in case of the Tracks tab) or returns back to the previous activity (usually in case of the All tracks playlist or the Albums tab). 6. Try to reopen the app in case of a crash. 7. If there was a song playing before the crash (from one of the other three tabs), the app stays open, the last playing song is displayed in the bottom bar as paused. 8. If there was no song playing before the crash, the app crashes immediately again. 9. The only way to recover from this is to delete all application data or reinstall the app. After that, the app starts behaving as after step 1.

Screenshots/Screen recordings

https://github.com/user-attachments/assets/c5543650-8ba1-4867-b286-b0f793ce29ee

Additional information

Quite interestingly, some tracks play just fine from the "All tracks" playlist – compare the attempt to play "26-12-2" at 0:52 of the video with the attempt to play "20250707_094427.m4a" at 0:56 of the video. This m4a file is a recording created by Fossify Voice Recorder app, the other songs were downloaded tracks.

[naveensingh]

Please share the full path where those files are stored.

Also, if you are familiar with ADB, it would help if you could capture and share a crash log.

No, I didn't, because the links are dead.

Working on that.

[ShadyMedic]

All of the files I tried to play in the video are stored in /storage/emulated/0/Music/[ALBUM NAME]/, except for the one m4a recording that is in /storage/emulated/0/Recordings/.

I have ADB installed, but I only ever used it to paste commands found on the internet, I'm not really familiar with how to use it to get a crash log of a specific app. But if you can point me to a tutorial or write me commands to execute, I'll be glad to help.

[naveensingh]

Here are the basic steps:

• Connect the phone to your computer
• Run adb logcat > logs.txt
• Open Fossify Music Player and crash it
• Stop capture with CTRL+C and share the logs.txt file here

[ShadyMedic]

Okay, this should be the part that is interesting to you, right?

https://paste.nolog.cz/?37e45c178d6b7535#8H7pkukmJVxwVpAsEt3tvaBhqpgNq7yPGL9WtTC8debZ (edit: updated the link to a non-expiring one)

[naveensingh]

Yep, that's all, thanks!

[jguegel]

Solution idea: MediaItem.kt -> check if ArtworkUri is not blank:

fun Track.toMediaItem(): MediaItem {
    val notBlankArtworkUri = coverArt.takeIf {
        it.isNotBlank() }?.toUri()
    return buildMediaItem(
        mediaId = mediaStoreId.toString(),
        title = title,
        album = album,
        artist = artist,
        genre = genre,
        mediaType = MediaMetadata.MEDIA_TYPE_MUSIC,
        trackNumber = trackId,
        discNumber = discNumber,
        sourceUri = getUri(),
        artworkUri = notBlankArtworkUri,
        track = this
    )
}

Because somehow at android.media.session.MediaSession.setMetadata(MediaSession.java:512 can not use the Uri of Metadata according to the error log you posted. But i am unable to reproduce the issue locally, this is purely based on log analysis

[ShadyMedic]

Solution idea: MediaItem.kt -> check if ArtworkUri is not blank: Because somehow at android.media.session.MediaSession.setMetadata(MediaSession.java:512 can not use the Uri of Metadata according to the error log you posted. But i am unable to reproduce the issue locally, this is purely based on log analysis

I just checked and can confirm, that tracks that do not have a cover image play just fine, while those with an album art crash the app (or the activity).

[ShadyMedic]

Also I now see that the tracks with a cover image fail to play even from the Folders tab and Artists tab. Renaming the issue to make it clear that the tab from which a track is played plays no role in this.

[jguegel]

@naveensingh would my fix be ok? it's not necessarily solving the cause but catches the app crash

[naveensingh]

No, it's a library/platform-level crash. It's not caused by a blank URI.

It might be fixed by https://github.com/FossifyOrg/Music-Player/pull/217, but if not, an in-app workaround will be needed.

[naveensingh]

@ShadyMedic If you switch to another ROM anytime soon, please check if this problem is also there.

[ShadyMedic]

@ShadyMedic If you switch to another ROM anytime soon, please check if this problem is also there.

Sadly, any plans to switch anytime soon now when school year started and I have a lot of other things that I need to get done :-(

[naveensingh]

Please check if you still have this problem in the latest version.

[ShadyMedic]

Sadly, yes. But I noticed, that quite a number of songs from albums with a cover image play just fine. But then there are a few albums, that behave just like before. I'm not sure if that was the case before as well though.

Relevant exception gathered from logcat is as follows:

AndroidRuntime: FATAL EXCEPTION: PlayerThread
AndroidRuntime: Process: org.fossify.musicplayer, PID: 13088
AndroidRuntime: java.lang.IllegalArgumentException: cannot use a recycled source in createBitmap
AndroidRuntime: 	at android.graphics.Bitmap.createBitmap(Bitmap.java:932)
AndroidRuntime: 	at android.graphics.Bitmap.createScaledBitmap(Bitmap.java:854)
AndroidRuntime: 	at android.media.MediaMetadata$Builder.scaleBitmap(MediaMetadata.java:996)
AndroidRuntime: 	at android.media.MediaMetadata$Builder.build(MediaMetadata.java:970)
AndroidRuntime: 	at android.media.session.MediaSession.setMetadata(MediaSession.java:512)
AndroidRuntime: 	at f3.f1.D(Unknown Source:144)
AndroidRuntime: 	at e4.d.n(Unknown Source:36)
AndroidRuntime: 	at p5.w.run(Unknown Source:668)
AndroidRuntime: 	at android.os.Handler.handleCallback(Handler.java:991)
AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:102)
AndroidRuntime: 	at android.os.Looper.loopOnce(Looper.java:232)
AndroidRuntime: 	at android.os.Looper.loop(Looper.java:317)
AndroidRuntime: 	at android.os.HandlerThread.run(HandlerThread.java:85)

If you want the full log, let me know.

[naveensingh]

Could you share one of those affected albums here?

[ShadyMedic]

I'd rather not, it's all pirated music and I don't want to get my GitHub account suspended. But if you make a private filedrop and send me a link, I can upload it there for you only.

[ShadyMedic]

Okay, I was preparing a file to send and I'm just so puzzled... Let me explain:

1. I have the album in a folder on my laptop (running Linux)
2. I copy the folder via USB cable into my phone
3. I delete all application data of Music Player 1.5.0, launch it, grant permissions.
4. Try to play a song from the copied album
5. Crash, as expected.
6. I zip the folder on my laptop so I can send it
7. Gut instinct kicks in, I feel like I should unpack this archive on my phone to make sure all the files are there.
8. I copy the ZIP file via USB cable into my phone and delete the folder with the album I transferred before.
9. I open the destination directory via Fossify File Manager
10. Select the ZIP file, choose "Unpack"
11. Delete all application data of the Music Player again, launch it, grant permissions.
12. Try to play a song from the unpacked album
13. Works

What the heck? Did the zip/unzip process somehow fix the files, that were corrupted in some way? I don't even know how would I send you the files when zipping changes them. Well, it doesn't, I just copied one of the tracks back to my computer, run sha256sum on that and on the file that went into the archive and the checksums are the same. Or were there perhaps some corrupted metadata that were causing problems and were unlinked by the zipping process?

[naveensingh]

Did you transfer the original uncompressed files using ADB or MTP?

Best guess is, the files you transferred directly did not get scanned by MediaStore (think system DB), but the files extracted by Fossify File Manager did get scanned because FFM usually schedules a scan.

[ShadyMedic]

All file transfers were done using MTP. But that applies to all the albums that work as well (they were also transferred directly, not within an archive, using MTP).

[naveensingh]

The stacktrace points to a platform bug (or maybe it is specific to your ROM).

Could you try playing those files in other music players that use Media3 ExoPlayer? Auxio is one example.

[ShadyMedic]

Auxio can play all the playlist that don't work in Fossify Music Player without any problems.

[ShadyMedic]

Also, to make things even more confusing, that one album that I made work yesterday by copying in an archive and unpacking on the phone is no longer working again. 🙃