[Bug]: FreeTube not working with my latest database backup files

[vF360]

Guidelines

• I have encountered this bug in the latest release of FreeTube.
• I have encountered this bug in the official downloads of FreeTube.
• I have searched the issue tracker for open and closed issues that are similar to the bug report I want to file, without success.
• I have searched the documentation for information that matches the description of the bug I want to file, without success.
• This issue contains only one bug.

Describe the bug

I automatically back-up the database .db files found in User/AppData/Roaming/FreeTube (preferences.db, playlists.db, settings.db & profiles.db) so that I do not have to re-subscribe and search again for every video/channel I saved whenever I install FreeTube. Instead, I just replace the default files with my own saved copies.
However, this seems to no longer work as I keep getting an "Object has been destroyed" error similar to the one from #4762 whenever I open FreeTube or if that does not appear, it is just a blank page. This issue only presents itself when I try to replace the default database files with my own.
Did FreeTube modify the .db files to render the old ones incompatible? I fetched the old versions I had from yesterday, which seem to work. The .db files from today do not work on either the latest version or 0.19.1.

Expected Behavior

I expected FreeTube to work regardless of the age of the .db files it is using.

Issue Labels

causes crash, content not loading, inconsistent behavior

FreeTube Version

v0.19.2, v0.19.1

Operating System Version

Windows 10 LTSC 1809

Installation Method

.exe

Primary API used

Local API

Last Known Working FreeTube Version (If Any)

No response

Additional Information

No response

Nightly Build

• I have encountered this bug in the latest nightly build.

[absidue]

Hi there, no we haven't modified the file format to make it incompatible for the same version of FreeTube (you mentioned you are using the same FreeTube version so there is no way it could have happened).

When you close the last FreeTube window, it does some cleanup on the database files before the program ends completely. What I suspect happened is that you backed up the files in the middle of FreeTube doing its cleanup, so you have half finished/corrupted files.

In the future I recommend waiting a bit after closing the last FreeTube window, before doing your backups so that FreeTube has time to finish doing the cleanup.

[vF360]

Hi there, no we haven't modified the file format to make it incompatible for the same version of FreeTube (you mentioned you are using the same FreeTube version so there is no way it could have happened).

When you close the last FreeTube window, it does some cleanup on the database files before the program ends completely. What I suspect happened is that you backed up the files in the middle of FreeTube doing its cleanup, so you have half finished/corrupted files.

In the future I recommend waiting a bit after closing the last FreeTube window, before doing your backups so that FreeTube has time to finish doing the cleanup.

My backups are done automatically with a script that copies the .db files to a new folder every 10 seconds. This is the first time it has happened since I implemented it a few months ago.
I can't sync the files individually from the folder they are in through Gdrive, and syncing the entire FreeTube folder is not an option as I do not have enough space. Can you move the database files into a separate folder in the next version of FreeTube?

[absidue]

TL;DR don't go anywhere near the files while FreeTube is running, that is how you end up with corrupted files like in your case.

My backups are done automatically with a script that copies the .db files to a new folder every 10 seconds.

That'll be the problem then, you should not be going anywhere near the files while FreeTube is running, you probably got an incomplete copy in your backup then. Ideally we would be locking the files so no other program can touch them while FreeTube is running, but I haven't figured out how to do that yet.

I can't sync the files individually from the folder they are in through Gdrive

Even if Google Drive offered that option, I would highly recommend not doing it, as messing with the files while FreeTube is running is how you end up with corrupted files like you did.

Can you move the database files into a separate folder in the next version of FreeTube?

You can already try using symlinks (creating them requires admin privileges on windows 10, on window 11 you can do it without admin privileges): https://www.howtogeek.com/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

[vF360]

TL;DR don't go anywhere near the files while FreeTube is running, that is how you end up with corrupted files like in your case.

My backups are done automatically with a script that copies the .db files to a new folder every 10 seconds.

That'll be the problem then, you should not be going anywhere near the files while FreeTube is running, you probably got an incomplete copy in your backup then. Ideally we would be locking the files so no other program can touch them while FreeTube is running, but I haven't figured out how to do that yet.

I can't sync the files individually from the folder they are in through Gdrive

Even if Google Drive offered that option, I would highly recommend not doing it, as messing with the files while FreeTube is running is how you end up with corrupted files like you did.

Can you move the database files into a separate folder in the next version of FreeTube?

You can already try using symlinks (creating them requires admin privileges on windows 10, on window 11 you can do it without admin privileges): https://www.howtogeek.com/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

I've implemented symbolic links and everything runs smoothly, thanks! A lot of people who use open source software like FreeTube usually experiment with a lot of files, so I would not try to lock anything down (a warning message during install should be more than enough).