-
Notifications
You must be signed in to change notification settings - Fork 5
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
Using too many voice recordings #9
Comments
Well, I honestly haven't tested such a huge number of recordings 😉. Anyway the optimization of recordings directory access already was on my TODO list. Starting from Android 10, the only way to let an app access any directory (after the user selects it) is by using Android SAF (Storage Access Framework), which is well-known for its "inefficiency" (at least on some implementations). Actually the app reads all the filenames in a single shot then, for each of them, it looks for the optional These are the optimizations I'd like to add:
The latest point is not so hard to add, so I'll add it ASAP 👍 PS: what you mean with 500 recordings? 250 audio + 250 json? or 500 audio + 500 json? or some recordings were created by old BCR versions, so they don't have json files? |
All 500+ audio recordings I have accumulated since October 2022 (that is, almost 1 year), of course (except for a couple of recent audio recordings) all of them are without a json file, the function with metadata file appeared quite recently, so I have practically no audio recordings with this file. |
Ok, this is what I've supposed.
Yes, you're right, filenames loading it's already asynchronous, so the app does not freeze. |
Just released v0.0.4 with deep speed improvements on recordings database. It's blazing fast on my side. |
Please try this test version (still 0.0.4, so maybe you need to uninstall current then install this one) |
everything works fine, there is no more error |
Just released v0.0.5 with the fix, closing this. |
I hope you don't mind commenting on a closed issue, but I suffer from the same issue. I know 500 might sound like a huge number but I managed to gather nearly 2000 such recordings and the app no longer seems to handle this. Whenever I refresh, it is able to find new recordings, however the refresh as such takes like 10 seconds and any further work with the app is sluggish. I noticed the json files were generated for some older recordings but they don't seem to be created any further. Is there any way to help you debug this? |
No problem, it's the same issue actually...
What you mean with no longer? v0.0.13 switched from an "Internal storage DB" to an "Android SAF" based DB, and this could be slower; but DB content is actually kept in memory and saved only on changes (i.e. after a refresh). Sadly Android SAF implementations are really bad, and they could impact both audio files scanning and DB read/write. This was done to let DB be "accessible" to the user and avoid Android delete it in case of application uninstall/reinstall/data cleanup.
This is something I've already seen, and I'm going to switch from a "monolithic" recordings list to a "virtual" one, where only the visible items are rendered and the ones "out of screen" are loaded on demand. This should deeply improve list rendering performance in case of huge databases. Another thing I'm going to add is refresh improvements: will try to ask AndroidSAF to only list files created AFTER a given date, to avoid refreshing the same files over and over.
Could you please elaborate on this? BCR-GUI only reads JSON files (if existing)...
Of course, stay tuned... 😉 |
@nicorac : I tried to take a short video showing it. Any service you prefer for sharing? There are phone numbers seen in the video so I prefer to share in private. |
I created an obfuscated version of the video where you can hopefully see the issue. bcr-gui.mp4 |
Thanks for the video, I was able to reproduce the bug on my side:
app first startup timeFirst startup of the app requires a huge lot of time, pointing out the first optimization possible: list refresh once app is startedRefreshing the (huge) list is also slow, because the app actually re-apply the same logic as first startup. DOM optimizationBCR-GUI is built with web technologies (Ionic, Angular), and runs in a "browser" (WebView). so what?I'm working on all of these optiimizations and I hope I can came up with a fix for the bug... please stay tuned 😉 |
Well, it was a huge job but finally there's an update. SAF improvementsCan't simply get files added after last scan, because deleted files must also be removed from the DB. Database improvementsDatabase is still in-memory and its update algorithm has been improved. Now searching for existing/removed items is much faster, so the update task completes in a shot. List improvementsRecording list is now "virtual"; it can contain even thousands of records (beware of memory 😉) but only a visible few are rendered. It's actually much faster and responsive. Finally...Unzip and test the attached version (still 0.0.14...) and report its bugs here (please do not open new issues for this test version) |
Just released v0.0.15 with improvements to handle big recordings sets (2000+) |
The application does not cope well (it takes a long time to load) if more than 500 audio recordings are stored in the call directory. On my old smartphone, it takes about 30 seconds.
I suggest adding a loading animation meaning that the application loads information about calls. At the beginning, without this animation, I was confused and I thought that the application was not working at all, but after waiting more than 30 seconds, I realized that it had been loading all this time.
Also, I suggest making an optimization that loads this information, I think it's not worth reading all existing audio recordings at once.
The text was updated successfully, but these errors were encountered: