Insta-crash when opening large folder

[Mrnofish]

I have a podcasts of sorts that uses no standard podcasting technology, it was scraped manually and is a single folder containing over 300 hundred files.

Previously, this folder used to work in AudioAnchor albeit slowly. Nowadays, the app will crash as soon as the folder is entered from the library screen.

May be related to #167. I'm also on Android 11 (LOS 18.1). It's been a while since I last tried opening this particular folder in AudioAnchor and I'm not entirely sure whether, back then, the OS had already been upgraded.

[J0J0]

Based on the available information, i'm unable to reproduce this bug with

• my phone (Android 10)
• emulator Android 11
• v2.3.2 (last realease on f-droid?!)

nor with

• master branch at 51660c7 against emulator Android 11.

I can open albums with 300, 500, 1000 and 5000 files almost without delay. I used mp3 files of 1 second length.
I also have audiobooks with more than 500 files, which never caused me problems so far (all mp3, though).

[Mrnofish]

I can still reproduce just fine, and rolling back to 2.3.0 as reported in the OP and in #167 does indeed fix the issue.

v2.3.2 (last realease on f-droid?!)
Well, since it is the latest release...

Flackbash already wrote she was having trouble reproducing in the emu, and that the issue is likely related to changes in Android 11, so I'm afraid testing under circumstances that are markedly different from the ones reported is kind of a waste of time.

Thanks for trying, though.

[J0J0]

I apologize for this "waste of time", but to spare other volunteers a similar fate, i suggest to close this issue and/or make it obvious that it does not concern the current release and dev branch.

Contrary to your claim

rolling back to 2.3.0 as reported in the OP

i am unable to see any reference to releases/versions/git commits whatsoever in the OP. Together with the fact that this issue is open, it is natural to assume that it affects the most recent release or dev branch.
Furthermore, #167 is closed, its discussion does not mention this issue at all and also describes different crash behaviour ... Altogether, its tight link to the present issue was not at all obvious to me.

[lexillar]

I have a smaller, but still large library of .opus files on weak phone with 32gb memory.

The problem is that when it scans (or accidentally scans after missswap upwards) the program and ui becomes irresponsive for the time longer than crash manager proposes to kill or wait, longer than phone's backlight off.

It would be better to scan in parallel low priority process, so ui remains responsive.