search

NeoApplications / Neo-Backup

backup manager for android
GNU Affero General Public License v3.0
2.37k stars 120 forks source link

[Bug] "The filtered list is empty" (only) for Scheduled Backups #734

Closed tomcat-xx closed 1 year ago

tomcat-xx commented 1 year ago

Description Since upgrade to 8.2.5 my scheduled backups don't work anymore. I'm only getting message in subject. When starting manually all is fine, list is not empty even when starting right after scheduled backup.

With 8.3.0 there was no change. I also tried to create new backup/selection, but with same result. After upgrading to 8.3.1 it worked once (for 3 different backups) and I thought it is solved. But last night I got it again.

My backups are scheduled only once a week, so there is something to backup every time.

phyrz91 commented 1 year ago

I have the same error. Last version, Android 13, Xiaomi 12.

tomcat-xx commented 1 year ago

For me I found out, that it is not only for scheduled backups, it happened sometimes also on homepage. It seems it only happens with filter "Old Backups", so maybe it is related to existing backup files. That could also be the reason, it stoppend happening one day. What I explicitly changed, was adding DiagMonAGent to blocklist, because it caused extremely long running backups. Due to big backup file it may also have influence on reading backups for filter.

hg42 commented 1 year ago

The size of the apk or archive files doesn't have any influence on finding the backups, either, because NB is only reading directories and the properties files.

hg42 commented 1 year ago

[wait, I was confused...so forget what I wrote about the schedule list, deleted that sentence]

the "filtered list is empty" when executing a schedule is the number of packages that match the filter. I think, the message would not be shown if the backups couldn't be found due to a hanging scan routine. So, it seems like the scanning was finished.

The size of the archives still don't play a role in both cases (packages in schedule or homepage).

Damaged properties files could eventually have an influence, but usually this should only invalidate the backup. Properties files are only created after the archives are all written, so if you stop the backup (e.g. hard killing NB), it is simply missing.

It's unlikely that a properties file is written partly, though this is theoretically possible. This could eventually create an endless loop in the reading routine (not from us), because of missing end brackets (that would be a bug in the library routine). We don't know how mature those json-reading routines really are. I would expect some bugs.

If that is the case, please pack all properties files of the corresponding backup directory into an archive and sent it to my github email (see account).

hg42 commented 1 year ago

you could start the schedule on a fresh backup directory.

I suggest to save the current backup directory to somewhere else, at least for reference. It might have corrupted files or similar.

tomcat-xx commented 1 year ago

Thanks for explanations. Might help analysis if it happens again. As written, for me it is "solved", at least issue doesn't exist anymore. Maybe just because damaged file of older backup generation has been deleted automatically. So nothing that I can check now.

hg42 commented 1 year ago

ok, so I close it for now