With every restart deluge loses some torrent label's

[simonbcn]

With every restart of deluged daemon, most of my torrents lose the label.
Deluge have 96 torrents now:
The labels associated to one tracker still work (54).
6 torrents still conserve their correct label.
26 torrents lose the label.
Moreover, these torrents are old and new. There isn't a rule that explain this bug.
It was a very bad idea to use the version of deluge in development.

[simonbcn]

Is there any solution to this problem? How could I export easily 96 torrents from current configuration to the new to solve definitely this problem?

[Damien Churchill]

Is there any possibility you could tar up your config directory so I can see if I can reproduce this?

[simonbcn]

Ok, but not here, not as public. Please, give me an email address to send it.

[Damien Churchill]

Of course, wasn't expecting you to post it to the world!

My email is ​damoxc@gmail.com.

[Lysias]

I had a similar problem where all torrents' labels would get reset to a single label after restarting the daemon. After some digging I found out that somehow the settings for automatically assigning a label by the tracker name were messed up. Each letter of a tracker name in the edit field was on its own line. Let's say I had a line "mp3tracker". It was split to

m
p
3
t

and so on. Single letters of course match many tracker names... I wonder if it was the WebUI that did this? Now I'm using the GTK client to connect to the daemon and so far everything's fine.

[simonbcn]

I have stopped deluge-daemon, I have deleted the section "label" from label.conf and I have started deluge-daemon.
Now the problem is worst: now I lose all labels in every restart.
Any help here?

[simonbcn]

Sorry, I deleted the "torrent_labels" section from label.conf file

[Calum]

The OP issue has not been reported by anyone else and it was a dev build being used so I was considering closing this ticket.

However the issue with the tracker name splitting that lysias reported needs investigating.

Lysias could you confirm this still occurs and the version of deluge used?

[Lysias]

I haven't seen the problem since.

Using version 1.3.0-0ubuntu1 in a daemon/client setup.

[simonbcn]

It isn't fixed.
Deluge 1.3.1 installed from tarball.
Same problem.

[Calum]

Please describe exactly how we can repeat this. Including the label names used and debug logs.

[raxxy]

I've been able to consistantly cause torrents to lose labels:

100+ torrents (almost always minimum 100 in this client, theres a few of us using the one deluge instance) ~10 labels ~5-10 torrents/label, some with 20+.

Deluge begins to go unresponsive to our GTK ui's that are connected remotly so i kill the deluged instance on the server

kill -9 deluged-pid

deluged -q to restart deluged,

upon restart, ~80 - 95% of the torrents have been put back under "no label"

If you're still unable to get reproduce the problem with that information, I'll give you access to the installation of mine so you can see for yourself.

[Calum]

Thanks to the logs provided by raxxy I can now pinpoint the issue. Labels with autoadd enabled will trigger clean_config to be called before all the torrents have been loaded from the state file upon startup. This means any torrent not added to the session at that point will be removed from label.conf.

​Label core.py

A possible solution: Upon enabling the plugin, register the handler for SessionStartedEvent and when received apply the labels to those loaded torrents then register the handler for TorrentAddedEvent and carry on as per usual.

[andar]

Replying to raxxy:

I've been able to consistantly cause torrents to lose labels:

100+ torrents (almost always minimum 100 in this client, theres a few of us using the one deluge instance) ~10 labels ~5-10 torrents/label, some with 20+.

Deluge begins to go unresponsive to our GTK ui's that are connected remotly so i kill the deluged instance on the server

kill -9 deluged-pid

deluged -q to restart deluged,

upon restart, ~80 - 95% of the torrents have been put back under "no label"

If you're still unable to get reproduce the problem with that information, I'll give you access to the installation of mine so you can see for yourself.

Are you trying a TERM before the KILL? If you are doing a KILL then there is a very good chance your state won't be written properly and you'll lose label information. There shouldn't be any reason you need to do a KILL unless there is truly a badly hung deluged process.

[Calum]

Fixed in 1.3-stable: ​f7c21fd8

[carbncl]

For information, I had this bug, just installed the 1.3-stable version from source to check that fix, works perfectly, thanks. My server has been up for 5 months because of this one... ;) Btw, great stability, loving deluge!

[gnimsh]

I do not believe that this bug has been fixed. I just updated to the newest version 1.3.6 after adding the PPA to ubuntu and then I restarted and my label locagions have been completely reset. It's a very frustrating bug that causes me to have to reset the label location every time I restart deluge.

I'll provide any information needed to get this fixed.