Qbittorrent[-nox] loses Torrents after restart

[MPW1412]

Hello,

actually I have 563 Torrents in qBittorrent-nox Version 3.0.0 beta2 from the launchpad repo. I'm using Ubuntu 12.04 64bit. And qbittorrent-nox is started and stoped via an init-Skript.

Sometimes I notice that qBittorrent forgets about many of the torrents. After my last reboot for example, it just knew about around 100 torrents and forgot roundabout 400 Torrents.

Then I have to reinsert them and they all need to be rehashed, which takes long time.

Any ideas?

Bye
MPW

[MPW1412]

Hello,

this is a very annoying bug. Everytime I reboot, qbittorrent-nox forgets all torrents and rechecks them all. Every reboot!

Is there a way to force qbittorrent to accept them as "checked"? And skip that annoying rechecking?

[sledgehammer999]

Does it forget labels and custom paths also?
We have similar reports from Windows's users that say that qbittorrent forgets various things after a restart.

[MPW1412]

There are no labels in qbittorrent-nox. I just use /home/mpw/Downloads as download folder, guess that is the standard one.

The point is, that the torrents are not stored, when quitting qbittorrent with sudo service qbittorrent-nox-daemon stop. The daemon is killed, and any information is lost.

There should be a soft way to stop qbittorrent, when it runs as daemon.

[MPW1412]

Okay, I got some more details:

I guess that with my 500+ torrent, it is overextended to save the current state, when I shut qbittorrent down.

I control it via init-skript: sudo service qbittorrent-nox-daemon stop

If I just switch off the power of the pc or kill qbittorrent the hard way, it just forgets the past few minutes. But when I try to shut it down regularly, it probably starts overwriting the save state, runs out of time and loses everything.

Maybe you could look into the stop sequence. Or is there any smart way to terminate qbittorrent-nox from terminal?

[MPW1412]

I upgraded to 3.1-alpha, and I am testing now and will report in a few days, if it was succesfully fixed. The first tests are auspicious.

[MPW1412]

Did not appear in V3.0.11 yet. So I declare it to be fixed. Thanks!