Clarification on wiped database-post

[cos]

Whenever a forum post mentions AntennaPod having dropped the database and recreated an empty one, this bugs-first-aid/database-error tends to be mentioned. I believe more people would be helped if the current content of that article could be clarified and extended.

Currently that documentation page strongly suggests the only reason for encountering a corrupted database would be #2463. We could probably assume that will be the case for fewer and fewer users.

How about lifting out the instructions for recovery, rather than immediately linking into GitHub? In that way, the post can be updated and the instructions refined as we better learn how to examine and repair corrupt databases. (Providing deep-links first after giving the reader context on whether the link might be relevant.)

During the last two days, AntennaPod has reset my database three times. I have discovered that merely importing CorruptedDatabaseBackup.db is the best action, since it has in fact not been corrupt at all. Maybe explicitly typing phrasing that as a suggestion should be among the first things to attempt? (There’s likely a mis-detected corruption bug to also be discussed, but lets please keep this post about improving this disaster-recovery documentation.)

Maybe one crucial clarification would be replace the fuzzy very old AntennaPod version description with something more precise, like prior to version 1.6.4.5 of AntennaPod (released January 2018)? Or is it perhaps 1.7.1 (November 2018) that is the cautious choice?

As for other clarifications;

Do I understand correctly that the #2463 issue was about those earlier versions using WAL? In that case; Would the output of PRAGMA journal_mode; determine whether #2463 could be the cause or not? Is the expectation that users affected by the bug would get WAL rather than DELETE, or would more recent version of AntennaPod have successfully updated that already?

The corrupted SQLit��� ��Ft 3 header seems to be a known recurring indicator? Can one rule out the #2463 bug in case the header is indeed intact?

I fail to see any kind of timestamp on the mentioned documentation page. Is that me not bringing my eyes, a known decision or something one might wish to add?

[ByteHamster]

@cos

I have discovered that merely importing CorruptedDatabaseBackup.db is the best action, since it has in fact not been corrupt at all.

The fact that it happened again soon afterwards suggests that the database is already corrupted. It just doesn’t surface. To detect whether the database is already corrupted, you can run PRAGMA integrity_check.

@cos

Maybe one crucial clarification would be replace the fuzzy very old AntennaPod version description with something more precise

Unfortunately we don’t know when exactly this was introduced. There were multiple database related bugs around 2018 that could have caused this

@cos

The corrupted SQLit��� ��Ft 3 header seems to be a known recurring indicator?

Not always. We has various broken things, not just that.

@cos

Would the output of PRAGMA journal_mode; determine whether #2463 could be the cause or not?

I don’t think so. It was likely caused by having multiple open connections to the database that write at the same time.

---

You seem to know about SQLite. You could try to run the following script: GitHub - ByteHamster/AntennaPodDbFixer

[cos]

@ByteHamster

The fact that it happened again soon afterwards suggests that the database is already corrupted.

I stand corrected. Thanks!

@ByteHamster

Unfortunately we don’t know when exactly this was introduced. There were multiple database related bugs around 2018 that could have caused this

How about being slightly less precise, but still indicate the year. E.g. In AntennaPod versions from before 2019…

@ByteHamster

You seem to know about SQLite. You could try to run the following script: GitHub - ByteHamster/AntennaPodDbFixer

Python. That’s been a while. I cloned, tried, ran into some problem, patched and eventually got all the way to a hopefully no longer corrupt database.

Please do a pull from git.netizen.se/AntennaPodDbFixer and see if you agree to merging some or all of my suggested changes. There’s a mix of commits, everything from opinionated nitpicks to up to addition of actually integrity checking the files as you suggested.

[cos]

@cos

Please do a pull from git.netizen.se/AntennaPodDbFixer and see if you agree to merging some or all of my suggested changes. There’s a mix of commits, everything from opinionated nitpicks to up to addition of actually integrity checking the files as you suggested.

I had lunch earlier today with someone who actually speaks python, discussing my short-comings when hacking on this script. Thus I just pushed a couple of more commits, which one might or might not agree to.

[cos]

@cos

I had lunch earlier today with someone who actually speaks python…

Yet it required him to review my attempt before I managed to hear python properly. A fixup!-commit was just pushed. I’m probably done with that branch now. Unless we’re finding improvements deserving to be done.

[ByteHamster]

Would be great if you could open a PR on GitHub Then we can discuss which of the changes we want to merge. Doing it on GitHub makes things a lot easier for me because everything is in one place. I already have dozens of unanswered AntennaPod related emails in my inbox. Using a different process for different PRs adds more overhead

[cos]

Understood. Not forgotten about.

I do feel quite strongly about unnecessary use of MSGH’s horrible UX. To the level that I’ve spent some time reading up on API documentation and experimenting a bit with scripting. More or less I’m half-way done with obtaining tooling for a sustainable contribution workflow. Will make sure to find the remaining time required to complete it shortly, and then update this thread.