Cannot backup Antennapod

mase76 commented 2 years ago

Hi! Since Neobackup, I cannot backup Antennapod any more. I am using version 8.0.2 and backing up this app takes forever and the backup folder for Antennapod stays completely empty. Also the filesystem isn't accessable any more. I have to reboot to get my device to work normally again. No problems backing up all other installed apps. Everything worked in the past with version 7.x. I am using a Redmi Note 10 Pro with Crdroid 8, no Gapps and Neobackup from F-droid. Are there any things I can do to get a log for this issue?

hg42 commented 2 years ago

use an app like "Logcat Reader" to get a logcat (before using the possible workaround below). Or you may also use adb logcat command for that, using verbose options. Please add it here as a file (dragndrop should work)

may be disabling pauseApps helps (in NB settings / advanced prefs / developer settings, expand "Advanced") it may stop some process that is working on files of this app, that is necessary for NB itself (although we tried to avoid this, Android sometimes comes up with new schemes).

What Android version is it? I know crDroid 8.5 would probably be 12.1, not sure about crDroid 8 (or perhaps you mean 8.5?)

mase76 commented 2 years ago

Disabling Pause does not help. crDroid is version 8.5, and Android is show as version 12.

hg42 commented 2 years ago

Everything worked in the past with version 7.x

and still does?

the backup folder for Antennapod stays completely empty

the Antennapod folder or the folder for that specific backup (with date etc.)?

Also the filesystem isn't accessable any more

all files? or only on the external or internal storage? and what about /system ?

In general, there are a few possibilities for such a problem:

the data for that app is no more accessible (it seems to hang on that access)
the backup directory cannot be written and hangs the file system (e.g. a damaged sdcard could do that)
a bug in NB (that's not very likely, basically an app cannot hang the file system, only the system or hardware failure can do that, though with root there are some more possibilities, but the only I could imagine is pausing apps)

btw. from your description it seems that it fails at the first access...

Please try each part as a single operation (apk, data, device protected data, external data, etc.), to see which one works and which doesn't or may be none of them.

If we know that you can try to access the corresponding directories via shell. May be this gives some error message from the commands. Though, a hanging file system is usually a hardware problem.

machiav3lli commented 2 years ago

@mase76 what about compression level?

mase76 commented 2 years ago

I have set it to the lowest compression level now. It seems to have no effect. However sometimes the backup works. I had one hang when backupping the apk only. Antennapod is the only app with problems.

hg42 commented 2 years ago

ähem, no effect? doesn't it compress? or do you mean "no effect" related to the problem? if so, "no effect" compared to no compression or to level 5?

sometimes the backup works

if it's not always the same it's even more weird. And more likely to be a hardware problem. Though it's unusual that this is only happening for this one app.

Theoretically, it could mean something like the storage blocks being damaged at the area where Antennapod lives. It often only one block. That's why I said try each apk, data, device_protected_data, etc. alone. If not all have the problem, it may be such a problem.

If it is something like this, you could uninstall Antennapod. Then install another app (that you don't need!), hopefully overwriting the damaged area. There is a big chance that uninstalling will hang, too. Which is at least a good hint.

Though flash devices are much more complicated. The flash cells are assigned to storage addresses via tables and this is not necessarily in sequence. The cells may also be exchanged on errors (changing an erroneous cell against a working cell). Also if you remove data and add it again, it will usually get another cell assignment (to prevent wear). So uninstalling it and installing another app might not assign those damaged cells to the other app. They might be assignied later.

The next data getting assigned to the damaged cells would inherit the problem. To make it even more complicated, the tables can get corrupt (e.g. if power drops unexpectedly). This can give very weird results. Overall workarounds (by forcing cells to switch) are mostly temporary. I would have an eye on such things, because your data is at risk, if it is really such a hardware problem.

mase76 commented 2 years ago

With "no effect" I mean, that the backup folder is created, but is completely empty. I installed Antennapod on another identical device. I will see, what happens...

hg42 commented 2 years ago

I am still waiting for the most important answer:

you said it worked with v7, so...

does it still work with v7? (meaning filling the backup directory and not hanging the file system)

you are implying, that v8 makes the difference, but as far as I know, it wasn't an ABA test (what you said, only reports A then B).

So there could have been a change in "the system" (in the broadest sense, everything outside OABX/NB) affecting both v7 and v8 or it could be caused or(!) triggered by a change between v7 and v8.

mase76 commented 2 years ago

v7 does not backup anything. Not even filling the folders. Only messages "Could not list contens of /data/user/0/". But it does not hang the filesystem, and the update process comes to an end.

hg42 commented 2 years ago

it's also "interesting" that it depends on compression.

Let's assume for now, that v7 still works, which I doubt, but everything is possible. Please check v7, it's important.

Compression is done by a library and this code didn't change at all between v7 (tarapi) and v8 (tarcmd).

File access to the backup directory is different between v7 and v8. But it should be the same between compressed or not.

So, as a conclusion:

compression must be involved (so I think it's the cause or trigger)
between v7 and v8 the main change in compression is probably in the library version

this may imply an endless loop in the compression library, but it is unlikely that it can hang up "the file system"

the first conclusion has a counter argument:

you said backing up only apk can hang, too??? This is reasonable, because apks should be the first to be copied to the backup. However: in this case compression is not involved (apks are only copied).

Please check again, if an apk-only backup hangs the file system. (you seemed to be a bit uncertain)

From the current assumptions and conclusions, this looks like something n8t following a simple logic, so it could have some random factor (e.g. timing, coincidence with other system activities) or there are other factors you change in parallel.

Please try to only do one thing at a time and do ABA tests, which is best done as working, failing, working, because failing means reboot.

roadmap:

works = backup created fails = backup empty and/or file system hangs

test v7
if it works:
  test v8
  test v7

-> v7 fails (but does not hang the file system)

test apk without compression
if it works:
  test apk with compression
  if it works:
    test again several times
    otherwise

for all other data (one at a time):
  test datax without compression
  if it works:
    test datax with compression

hg42 commented 2 years ago

v7 does not backup anything. Not even filling the folders. Only messages "Could not list contens of /data/user/0/". But it does not hang the filesystem, and the update process comes to an end.

ok, thanks

may be v7 stops before doing the critical step and v8 tries one step more...exception handling is more forgiving with v8 so the process may continue with v8 while the whole backup stops with v7 (crash).

So it seems to boil down to a compression problem for now. apk backup will tell more

mase76 commented 2 years ago

apk backup works with v7.

hg42 commented 2 years ago

v7 does not backup anything. Not even filling the folders

vs.

apk backup works with v7

wait... apk is the first part of a normal backup, so it would add something to the backup folder, even if it stops afterwards.

note, v8 tries to delete incomplete backups, so this may be unexpected, but in this case the backup instance folder (that one with with the backup time in the name) is also deleted (not empty).

v7 does not backup anything. Not even filling the folders

does it mean there are backup instance folders (with the time) and they are empty? v7 does not try to delete an incomplete backup, so at least the instance folder(s) should be there. If they are missing, it would be very early in the process.

mase76 commented 2 years ago

Yes, when I try a backup incl. data, the folder stays empty.

hg42 commented 2 years ago

v7/v8? can you try both? compress or not? does it hang? (probably only on v8) which kinds of data were enabled?

if apk works but apk+data doesn't, there must be some code messing with the data (e.g. the app's data directory) before apk is backed up. However, assuming compression must also be involved, then it's extremely weird.

Basically, the backup process goes like this:

if apk enabled:
  copy apks to backupdir
if data enabled:
  if compression enabled:
    stream tar of datadir through compressor to backup file
  else:
    stream tar of datadir to backupfile

which means, if data is enabled or not or if compression is enabled or not doesn't really matter, the apk should already be copied before

NeoApplications / Neo-Backup

Cannot backup Antennapod #556