PhilKes / NotallyX

Minimalistic Android note taking App | Notally, but eXtended.
GNU General Public License v3.0
70 stars 1 forks source link

Empty Auto Backup #101

Closed HazyDuck closed 2 weeks ago

HazyDuck commented 2 weeks ago

What happened?

Auto backup seems to not be baking up any data. Works fine when I manually backup.

Screenshot_20241103-014954

App Version

version 6.1-RC1

Android Version

Android 15 (AP41.240925.009)

(Optional) Relevant log output

No response

ippocratis commented 2 weeks ago

Is it a WebDAV mount? Happened to me with WebDAV mounts. Davx⁵ mount can't backup at all (creates 0 byte files) manual or auto. Encrypted nextcloud mount manual works auto not. Checking internal storage now.

I'm not sure if remote mounts makes sense for another feature request. Probably is beyond the app scope.

PhilKes commented 2 weeks ago

Interesting, the other day I think I had this too, but I thought it was probably because I played around with debug versions of the app. Will look into it

ippocratis commented 2 weeks ago

Yeah auto backup creates 0 byte files on internal storage too.

PhilKes commented 2 weeks ago

I wasnt able to properly reproduce this just now, but I made some small adjustments for the scheduling of the auto-backup job. I thought maybe it has something to do with battery optimization kicking in or something

@ippocratis @HazyDuck It would be great if you could check again with the new https://github.com/PhilKes/NotallyX/releases/tag/v6.1-RC3 if the problem still exists

HazyDuck commented 2 weeks ago

I wasnt able to properly reproduce this just now, but I made some small adjustments for the scheduling of the auto-backup job. I thought maybe it has something to do with battery optimization kicking in or something

@ippocratis @HazyDuck It would be great if you could check again with the new https://github.com/PhilKes/NotallyX/releases/tag/v6.1-RC3 if the problem still exists

Looks like it's working fine now, will report if anything changes. Thank you.

ippocratis commented 2 weeks ago

Looks like it's working fine now, will report if anything changes. Thank you.

How did you trigger an automated backup?

HazyDuck commented 2 weeks ago

Looks like it's working fine now, will report if anything changes. Thank you.

How did you trigger an automated backup?

By turning off then turning on automatic backup

ippocratis commented 2 weeks ago

By turning off then turning on automatic backup

Oh! Thanks

@PhilKes triggering an autobackup by turning the feature off and on creates proper buckups for internal storage but also for encrypted nextcloud mounts and generic WebDAV mounts.

As @HazyDuck said what left to see is if scheduling after 1 day will work properly

ippocratis commented 2 weeks ago

The scheduled backup didn't work on a WebDAV mount set as backup location . A zero byte zip created. Setting internal storage now and see if it works.

Maybe I had to check internal storage first .

We have to wait one more day .

HazyDuck commented 2 weeks ago

I wasnt able to properly reproduce this just now, but I made some small adjustments for the scheduling of the auto-backup job. I thought maybe it has something to do with battery optimization kicking in or something

@ippocratis @HazyDuck It would be great if you could check again with the new https://github.com/PhilKes/NotallyX/releases/tag/v6.1-RC3 if the problem still exists

Screenshot_20241105-120703

Looks like it didn't save any data on the daily auto backups.

ippocratis commented 2 weeks ago

Looks like it didn't save any data on the daily backups.

Backup location in internal storage right?

ps: Sidenote , the android options pause app if unused and allow background useage did not help (if this issue is related to backroud jobs running)

PhilKes commented 2 weeks ago

@ippocratis @HazyDuck Very strange behaviour, since the actual zip file is written at the very end of the AutoBackupWorker, so that probably means copying the database + attached files all fail. I just remembered that at many points in the app if an exception occurs its stacktrace gets written to a separate internal log file. I did find an Exception from the auto-backup in there but couldnt reproduce it really, nevertheless I will fix the exception's cause. You can access the described log file, if you use Send Feedback in the bottom of the Settings, it will create a Draft Email (I created a support mail for NotallyX) with this log file attached. If you could provide that log file that would be great. Btw. if you use Settings -> Create Issue on Github -> Report issue it will also append the last exception's stacktrace from the described log file (if there ever was an exception written to it) automatically to the new GH Issue.

I think it would be best also to re-introduce the notifications permission, so that the AutoBackupWorker will show a notification to the user while the auto-backup is in progress and if it succeeded/failed

ippocratis commented 2 weeks ago

You can access the described log file, if you use Send Feedback in the bottom of the Settings, it will create a Draft Email (I created a support mail for NotallyX) with this log file attached. If you could provide that log file that would be great.

[Start]
java.lang.IllegalArgumentException: Required value was null.
    at com.philkes.notallyx.utils.backup.AutoBackupWorker.f(SourceFile:231)
    at androidx.work.B.run(SourceFile:3)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
    at java.lang.Thread.run(Thread.java:1012)
Version code : 603
Version name : 6.1-RC3
Model : 22101320G
Device : redwood
Brand : POCO
Manufacturer : Xiaomi
Android : 34
Time : Nov 4, 2024 21:31:38
[End]
[Start]
java.lang.IllegalStateException: Cannot invoke observeForever on a background thread
    at androidx.lifecycle.z.a(SourceFile:35)
    at androidx.lifecycle.z.e(SourceFile:3)
    at com.bumptech.glide.manager.e.c(SourceFile:117)
    at com.bumptech.glide.manager.e.e(SourceFile:27)
    at com.philkes.notallyx.utils.backup.a.c(SourceFile:32)
    at com.philkes.notallyx.utils.backup.AutoBackupWorker.f(SourceFile:141)
    at androidx.work.B.run(SourceFile:3)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
    at java.lang.Thread.run(Thread.java:1012)
Version code : 603
Version name : 6.1-RC3
Model : 22101320G
Device : redwood
Brand : POCO
Manufacturer : Xiaomi
Android : 34
Time : Nov 5, 2024 21:37:24
[End]
[Start]
java.lang.IllegalStateException: Cannot invoke observeForever on a background thread
    at androidx.lifecycle.z.a(SourceFile:35)
    at androidx.lifecycle.z.e(SourceFile:3)
    at com.bumptech.glide.manager.e.c(SourceFile:117)
    at com.bumptech.glide.manager.e.e(SourceFile:27)
    at com.philkes.notallyx.utils.backup.a.c(SourceFile:32)
    at com.philkes.notallyx.utils.backup.AutoBackupWorker.f(SourceFile:141)
    at androidx.work.B.run(SourceFile:3)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
    at java.lang.Thread.run(Thread.java:1012)
Version code : 603
Version name : 6.1-RC3
Model : 22101320G
Device : redwood
Brand : POCO
Manufacturer : Xiaomi
Android : 34
Time : Nov 5, 2024 21:37:24
[End]
PhilKes commented 2 weeks ago

Thats the exception I also got, this can only occur if the app itself has not been opened yet, because the observeForever is called on preferences.biometrickLock (since if the lock is enabled the database has to be reinitialized with SQLCipher). I was now able to reproduce the bug and fixed it so that the auto-backup Worker does not even try to call observeForever since it doesnt even have to, it just gets the database once at makes a snapshot of it. Also I misread the code, the ZIP file is actually created as the first thing the AutoBackupWorker does, as soon as it tries to create the database snapshots it fails.

ippocratis commented 2 weeks ago

So it still makes no sense as what the cause might be?

Sorry I didn't really get the technical stuff :-)

PhilKes commented 2 weeks ago

Just it still makes no sense as what the cause might be?

Sorry I didn't really get the technical stuff :-)

No it makes sense now, I just couldnt reproduce it up until now. I merged the fix and will release a v6.1-RC4 for you guys to test.

PhilKes commented 2 weeks ago

There you go: https://github.com/PhilKes/NotallyX/releases/tag/v6.1-RC4

HazyDuck commented 2 weeks ago

There you go: https://github.com/PhilKes/NotallyX/releases/tag/v6.1-RC4

Screenshot_20241107-223225

Just wanted to confirm of successful backup, thank you.