mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Losing all settings when closed to taskbar and Windows shuts down #951
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#951
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MilesWilford on GitHub (Nov 29, 2013).
Title describes the issue pretty well. I am losing nearly all application settings nearly every time I allow Windows to shut down without manually closing qBittorrent first. I lose my saved RSS feeds and everything set in the options, and am splashed with the first boot warning about torrent applications when qBittorrent starts up. Sometimes I will see the error reported here as well, but this is infrequent.
I do not lose RSS download settings, strangely, but I do need to re-add the feeds and check the rules to the feed.
Let me know if you need any information provided to help with anything
@sledgehammer999 commented on GitHub (Nov 30, 2013):
Do you confirm that this DOESN'T happen if you manually close qbt first? (I mean really exit through file->exit)
Also marking related bugs here for future reference: #1126, #1135, #1116, #1115, #842.
@MilesWilford commented on GitHub (Nov 30, 2013):
Yes. It started happening with an update roughly within the last 2-3
months. If I manually close qBt, I have never seen settings disappear.
On Nov 30, 2013 5:48 AM, "sledgehammer999" notifications@github.com wrote:
@sledgehammer999 commented on GitHub (Nov 30, 2013):
I might have an idea how to solve this. Can you reproduce the problem 100% of the time? If yes, would you be interested to test a patched build?
@MilesWilford commented on GitHub (Nov 30, 2013):
I had believed I could reproduce it 100%, but am finding it harder to
perfectly reproduce than I had originally thought. I'd be happy to test a
patched build, but am starting to doubt how useful I can be as a tester.
-Miles Wilford
On Sat, Nov 30, 2013 at 9:02 AM, sledgehammer999
notifications@github.comwrote:
@sledgehammer999 commented on GitHub (Nov 30, 2013):
If you can reproduce it most of the time, it is fine by me. As a tester all you have to do is try to reproduce with the patched build I'll provide. If it doesn't occur after a few shutdowns then I can assume it is fixed.
@devilsystem commented on GitHub (Dec 9, 2013):
Guys!
Same problem at me!
I tried everything:
But none of them worked!
It starts to happen after 3.0.0. maybe, and the only victory is when my settings doesn't dissapear after maximum 1 reboot...
Guys, i really love your client, but we aren't in the 90's, this problem seems to me very small, but fking annoying, please try to solve it. Thanks!
@Reliant commented on GitHub (Dec 10, 2013):
I've been having this problem as well for a while now. At first, I thought it was just an upgrade issue, but when I reboot, settings disappear. I lose my list of RSS feeds, torrent download locations, connection settings, speed settings. It doesn't happen every time I reboot, but often enough that it's becoming a very annoying problem. My PC is one that gets rebooted daily.
@devilsystem commented on GitHub (Dec 10, 2013):
temporarly solution: i went back at versions, from 3.1.3. until 3.0.0.
the 3.0.0. seems to be stable, its about 10 reboot now(both reboot and shut down too).
starts correctly, and settings didn't dissappear
i hope it helps to find the origin of the problem.
@sledgehammer999 commented on GitHub (Dec 25, 2013):
Can you all try my experimental build->http://qbforums.shiki.hu/index.php/topic,2344.msg9137.html#msg9137
It contains a possible fix about this. Please, report back if it works.
@MilesWilford commented on GitHub (Dec 28, 2013):
After having the error this morning, I installed the alpha and have it
running with my typical settings. I'll report back if the problem
manifests again.
-Miles Wilford
On Wed, Dec 25, 2013 at 3:11 PM, sledgehammer999
notifications@github.comwrote:
@MilesWilford commented on GitHub (Dec 29, 2013):
Unfortunately, I've experienced the same error using the alpha. The circumstances weren't identical - in this case, the computer shut down unexpectedly (overheated), but it's the same apparent problem. All my settings reset to default and I received the first-open warning dialogue. The only thing that made it (as has always been the case) is my RSS download rules (but not my saved feeds).
-Miles Wilford
On Sun, Dec 29, 2013 at 1:43 PM, sledgehammer999
notifications@github.comwrote:
@sledgehammer999 commented on GitHub (Dec 29, 2013):
Unfortunately I cannot do anything about this. If qbt is in the middle of writing the settings file and system crashes obviously the file will be corrupted.
PS: I have released 3.1.4 that contains the fix I mentioned earlier.
@MilesWilford commented on GitHub (Dec 29, 2013):
When exactly does qbt write its setting files? Does it have them open r/w constantly?
I was not actively changing any settings at the time of the crash - qbt was fully in the background and not active (other than possibly RSS refreshes going on).
Is there anything I can do to minimize the time in which qbt is writing to setting files so that crashes don't trigger a reset?
@sledgehammer999 commented on GitHub (Dec 29, 2013):
Unfortunately the way settings are implemented is a bit of a mess. So no, you can't do something to minimize it.
@woffko commented on GitHub (Mar 14, 2014):
"Unfortunately I cannot do anything about this. If qbt is in the middle of writing the settings file and system crashes obviously the file will be corrupted."
I've run into this issue several times, before googling this thread. I don't understand why qbittorent writes something into settings when I did not change anything on it. I lost my settings every BSOD or reset. Yes I know that BSOD or reset is not "normal" behavior, but shit happens is not it?
Ok, you write that settings implement is a bit of a mess... I see only two solutions. The one and the best is clean up a mess and the second is to use a backup. Every time time qbittorent starts it should backup the current settings to .bak file and next time, when it found corruption, use .bak file instead resetting everything to default.
@sledgehammer999 commented on GitHub (Mar 15, 2014):
@woffko What version are you using? Most of these problems are mitigated in the latest version(v3.1.9)
@bloodgain commented on GitHub (May 9, 2014):
I'm running v3.1.9 and just had this problem. I found this issue when I searched to see if it was known. I don't know if Windows auto-rebooted or my kid hit the power button, but it had clearly been rebooted (I don't reboot my machine unless necessary).
I second the idea of a settings backup file, especially if you're keeping it in r/w mode constantly. At least then, worst case, you only lose any changes since the last restart.
An option to import/export the settings would be useful here, and also allow folks to import the backup if qBittorrent fails to notice (or they just want to backup their default settings, transfer to a new machine, nuke Windows from orbit, etc.).
@elichai commented on GitHub (May 10, 2014):
Just happened to me at v3.1.9 in Debian
@Pembe commented on GitHub (Aug 3, 2014):
Just happened on windows host. v3.1.5. It is not the first time.
@chrishirst commented on GitHub (Aug 4, 2014):
3.1.9 is current,
@sledgehammer999 commented on GitHub (Aug 4, 2014):
I am pushing a major code refactor on how settings are saved and handled. The new code will be available for 3.2.x.