Closed HazyDuck closed 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.
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
Yeah auto backup creates 0 byte files on internal storage too.
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
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.
Looks like it's working fine now, will report if anything changes. Thank you.
How did you trigger an automated backup?
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
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
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 .
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 didn't save any data on the daily auto backups.
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)
@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
You can access the described log file, if you use
Send Feedback
in the bottom of theSettings
, 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]
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.
So it still makes no sense as what the cause might be?
Sorry I didn't really get the technical stuff :-)
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.
There you go: https://github.com/PhilKes/NotallyX/releases/tag/v6.1-RC4
Just wanted to confirm of successful backup, thank you.
What happened?
Auto backup seems to not be baking up any data. Works fine when I manually backup.
App Version
version 6.1-RC1
Android Version
Android 15 (AP41.240925.009)
(Optional) Relevant log output
No response