OOM when restoring data from backup

[Luna712]

Steps to reproduce

Restore a backup file

Expected behavior

Data should be restored

Actual behavior

OOM is received, throwing the app into safemode:

Cloudstream version and commit hash

4.3.1 bd69054

Android version

Android 14

Logcat

No response

Other details

No response

Acknowledgements

• I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
• I have written a short but informative title.
• I have updated the app to pre-release version Latest.
• If related to a provider, I have checked the site and it works, but not the app.
• I will fill out all of the requested information in this form.

[fire-light42]

[Luna712]

OOMs are always the worst in any sort of development so I kinda figured it may not be fixable, but thought I'd open this incase something could be done to improve the performance of backup restoration.

[Luna712]

@fire-light42 feel free to close this if you don't think there is anything that can be done to improve this.

[Luna712]

@fire-light42

I increased my device RAM from 8GB to 12GB which helped somewhat here, but it still OOMs sometimes... maybe there is more we can exclude from backups... sometimes it will start restoring but crashes before it completes leaving it in only a half-imported state, and takes about 20 tries before it fully imports.

The backup file is about 2.87 MB now, before #970 it which I also made exclude DOWNLOAD_EPISODE_CACHE in addition to properly excluding the others, ir was 3.15 MB large and it crashed all the time, but now that backups also even store things like plots for the lib longhold bottom dialog, the backup file gets exponentially larger when re-adding or adding new items to the library.

I wonder if maybe there is some way to thread restoration or something to improve the performance of restoring backups? I think #623 might help with this a lot though if it can restore from Google rather than device itself, among other improvements it looks like that has...

[fire-light42]

After testing the issue has been found, this will be closed in eta 10min

[fire-light42]

5270467

[fire-light42]

#623 does not fix the issue, nor was the issue the size of the data like "plots". The issue was that calling apply after every key is "correct", but when doing 10000000 keys caused a major memory spike as it has to "atomically performs the requested modifications", meaning that is probs had to read the entire database or smth.

[Luna712]

#623 does not fix the issue, nor was the issue the size of the data like "plots". The issue was that calling apply after every key is "correct", but when doing 10000000 keys caused a major memory spike as it has to "atomically performs the requested modifications", meaning that is probs had to read the entire database or smth.

Oh that makes a ton of sense... thanks!

[Luna712]

That's amazing... so much faster restore also, almost does it instantly now... Thanks a ton for that fix!