-
-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when reading some audio #960
Comments
I only just now saw this mentioned earlier in #941. My autoloading is disabled, turning it on doesn't help. It's this initial loading of media just will not happen for me. Might be more useful log here
|
how large is your library?, because mine is 200 songs and on the latest CI build there is no crash |
Around 5000 if I recall correctly. Edit: 5667 |
Cannot reproduce with a library size of 1920 songs |
I don't want to spoil anything (because I am not an android dev), but that If you could identify the offending album and upload a sample file for us, that would help a lot.Move albums out of all scanned |
Nope! The problem is that one of the JNI calls throws an error, which then cascades and brings down the entire app since I wind up passing a |
Fascinating. I guess I have to stay out of your hair. |
Can you test and take logs on this @e-zk? Should I think report the errors I'm getting in the console instead of crashing. |
Hmm seems to have crashed again.
This is what's reported in the error dialog when I re-open the app (after crash 1 from above):
When I hit "retry" the app closes. When I re-open the app, it's started the media rescan process. It goes just under halfway then crashes with the following logcat (this is crash 2):
Looks like OOM? |
Weird, I think that's actually a memory leak @e-zk. Going to switch approaches and instead handle exceptions in Kotlin rather than CPP. Will get back soon. |
Okay, turns out Musikr's native code is full of memory leaks. It probably is an OOM on your library. |
Try this @e-zk? |
@OxygenCobalt okay so I get further and I don't crash. It gets stuck at 2332/5676. And it just stays there (it's been like 6+ hrs I've left it running). The application is still responsive, there's no crash anymore. So I think there is a file in my library causing this? Is there a way to log the filename of each file as the scan progresses? That way I can see which file it's getting stuck on. If not, I'll try and narrow this down by moving folders to/from my music dir and rescanning. and get back as soon as I can (free time permitting - with how huge my library is this may take a bit). |
Try this new APK, it should actually the file an error occurs on and I think fix one of the circumstances causing the loading bar to get stuck @e-zk |
Hey @OxygenCobalt Sorry for late response. I think I do need to buckle down and just find out what file is causing this but I'm lacking in free time at the moment. |
Okay, that's really confusing to be honest @e-zk. It seems like the pipeline is actually getting stuck and not just failing to report progress. Not sure what to do here until you can identify the problem file or if someone else reports it with an identified root cause. |
@e-zk could you share your audio library via Google Drive / Mega / Proton? Or, at least share what albums & formats. I want to find the root cause, either being a specific format (FLAC, Opus, etc), file count, or a specific file. WHat I do know is that the image size in FLACs don't matter, as all of mine have 3mb+ album covers embedded. |
Hi again @e-zk, I've managed to squash a pretty big memory leak that might have been causing your issues. Care to try this new APK? |
Describe the Bug/Crash
dev-4
Let me know what other details may help diagnose.
Describe the intended behavior
It should load media files.
What android version do you use?
Android 15
What device model do you use?
Pixel 6a (Android 15) (GrapheneOS)
Provide a sample file
No clue what audio is actually crashing the app.
Bug report
Auxio log 594b00a2af8a.txt
Duplicates
The text was updated successfully, but these errors were encountered: