[BUG]: Recovering app setting and the database on a new system after PC's SSD fail

[areksobiczewski]

Brief description of the issue

I kindly ask for help regarding recovering RSS Guard's app settings and its database after my PC's SSD died yesterday. I unfortunately reached a dead end trying to do that myself.

What I tried that didn't work:

1. A new RSS Reader installation and moving previus files to the new app's location: /home/xxx/.config/RSS Guard 4/*
2. A new RSS Reader installation where I took config.ini and database.db files from the old one, renamed them config.ini.backup and database.db.backup and tried to use the built in import mechanism in the app. Both the options and a databe were detected this way in the importing process, but that didn't work either.

In both above cases RSS Guards' process hangs.

I'm looking for a way to recover my data, where the only "backup" files I have are the app's files from my previus installation before the crash: /home/xxx/.config/RSS Guard 4/*.
Any ideas how I could proceed?

(Not sure if this qualifies as a bug, though)

How to reproduce the bug?

Only by using my app's files from the previous installation.

What was the expected result?

I was hoping the app could somehow detect files from the old installation and work with them, or that they could be imported somehow.

What actually happened?

The app crashes.

Debug log

I'm not entirely sure a debug is valid in my case.

Operating system and version

• OS: Debian Bookworm + KDE
• RSS Guard version: (a new installation) 4.0.4. The old one was also up to date but on Fedora instead of Debian.

[martinrotter]

WEll, it could be that sqlite database file is (semi)corrupted.

Can you send mi both ini and db files? I could try to fix them.

rotter.martinos(at)gmail.com

[martinrotter]

Checked your database file, looks good. The app freezes or crashes? If it crashes, can you obtain stacktrace? You can generate stacktrace with gdb.

https://wiki.archlinux.org/title/Debugging/Getting_traces

[areksobiczewski]

Thank you @martinrotter, this is great news.

Meanwhile, before I'll prepare stack traces, let me paste app logs (its output to terminal when running), as these say some interesting things.

The app always freezes, a GUI window is nower shown and the app's process freezes with ca. 8% constant CPU usage ad infinitum.

Logs for the app freeze scenario:
{file logs-1} logs-1.txt

For reference - logs of an empty, new installation of the app:
{file logs-2} logs-2.txt

It seems that logs for the app freeze scenario say that there was no problem with loading the configuration file, but there are some peculiar entries about issues with the database (?).
Also, I just realized that I was using RSS Reader with proxy option connecting to my localhost. But that proxy service is already up and running on my new environment where I'm trying to restore my old RSS Reader data.

---

@martinrotter - is it worth to try a different thing in this case: me trying to load a database backup coming from your export of my DB, that seems to open fine in your RSS Reader?

[areksobiczewski]

gdb stack trace obtained when I try to start RSS Reader using my old app's files in /home/xxx/.config/RSS Guard 4/*:
{file stack_trace.txt} stack_trace.txt

For the scenario with trying to import app's old database and config file (renamed with .backup extensions) generating stack trace seems to be imposible as RSS Reader needs to restart itself after using the import option which braks gdb's stack trace gathering process. I can select import files within the app, but after the restart the app freezes, similarly as in the previous scenario. I suppose both logs and a stack trace look very similar to those in the previus scenario.

In both cases the app's process freezes like this in activity manager:

[martinrotter]

Perfect, can you share the user app data which triggers the bug with me? Maybe send to my email? I will only use to identify the bug and fix.

[areksobiczewski]

@martinrotter I'm not sure what you're requesting. To generate all of the scenarios mentioned by me I used either a whole _ /home/xxx/.config/RSS Guard 4/*_ catalog from my previous RSS Reader installation (from backups), as a drop-in replacement on a new computer [this is what I reffer to as "scenario 1], or I took the config file and the database one from the same source and renamed them with ".backup" file extension and I was trying to import them in into RSS Reader using it's import option, so they could be recognized by the app at all [this is "scenario 2"]

Now, all the files I have at my disposal, all the _ /home/xxx/.config/RSS Guard 4/*_, you alredy have, as I've uploaded them for you yesterday to my Dropbox account ;)
Do you want me to send that again? Did you want something else?

[martinrotter]

Oh, yes, nevermind, I made a mistake, yes, I have the files.

[martinrotter]

Can you generate new dump like the above but instead of (y) quitting the gdb right away, try to print the actual stacktrace with "bt 10" command?

[areksobiczewski]

Martin, this is what I did (and it changes the situation a little bit).

I remember that on previous OS I was using RSS Reader as a flatpack. Now, on Debian, I just installed a regular package. It came to me that maybe it's worth to install the flatpak again which I did. Suprise! With the flatpak version on new OS I was able to read both the database and configuration files from the old flatpak installation. I simly took the files from the old one and copied them to the new flatpak's directory.
Now the problem is getting insteresting. Since I was able successfuly to start the flaptak RSS Reader with old data and settings I exported that configuration via RSS-flatpak ina proper way. Yet, when I try to import backup files into a regular RSS Reader, installed via a package manager, the problem with the app hanging on startup remains. Exactly the same behaviour like in the first post:
type="debug" -> core: Custom ID of feed when loading from DB is '0'.

I can live with RSS-flatpak. I leave it up to you to decid whether you'd like to pursue the problem with the regular RSS Reader version and import/export issues between flatpak and the regular version of the app. Please let me know what you think and how we are going to proceed from this point on.
(It might be not worth it, my old database might have been just corrupted. But I also wonder why flatpak works fine and the regular version doesn't. Since you have my data you can replicate the path I followed).