Annoying new feature?

[andar]

i have the same problem as sluthead, running deluge 0.5.8.4 on ubuntu 7.10 i386. it's really annoying!

After a proper shutdown of Deluge, can you check for .fastresume files for the torrents in your session? They will generally be in ~/.config/deluge/torrentfiles.

Also, what type of allocation do you use? Compact or Full?

Do you set any file priorities?

[paprika]

whats the difference of choosing compact or full? I choose full, and i`ve always have crashs and after crash i do somethingh sweet so i dont have to recheck, but that only works in 0.5.8.3

In the new one i have more crashs and i cant do the sweet thing i usual do to avoid this rechecking anoying problem...

Oh, when i have the error, dont send or even microsoft visual c++ or soemthingh like that, i didnt answer ok or dont send, first i run deluge again and wait in the process manager to appear a new deluge and then disappear, after that i choose ok or dont send in the errors, i shut down dmaeonplus process too mannually and after that i run deluge again and i have no rechecking problems, but only in 0.5.8.3 and previous versions, now i cant, and i`m sad because 0.5.8.4 gives me better speeds

[Bzzz]

Just removed all the torrents and added them bit by bit. 90% percent of the re-added torrents get an extra file "fastresume" - which means 10% do NOT. I think there is no correlation to file size, hash size or .torrent size, but most of or their names actually started by an "a", "b", "c" or "d" (strange).
Again, I removed those files with no fastresume check created, re-added them. 50% now got one, 50% did not. Next time again ~50%...but after that none ever gets fastresume data when adding it again. BUT they do when restarting deluge...

Now I reboot my system and see what happens
(you asked about the type of allocation: I set "full")

Okay, so, I readded 145 torrents, and 145 of them worked without rechecking. So far: great
For testing, they were added paused. I clicked on the start button, and all of the fastresume files were gone!?
Closing deluge + reopening means checking them all again!
Do I have to make them write-only until next release?

[andar]

Just removed all the torrents and added them bit by bit. 90% percent of the re-added torrents get an extra file "fastresume" - which means 10% do NOT. I think there is no correlation to file size, hash size or .torrent size, but most of or their names actually started by an "a", "b", "c" or "d" (strange).
Again, I removed those files with no fastresume check created, re-added them. 50% now got one, 50% did not. Next time again ~50%...but after that none ever gets fastresume data when adding it again. BUT they do when restarting deluge...

Now I reboot my system and see what happens
(you asked about the type of allocation: I set "full")

Okay, so, I readded 145 torrents, and 145 of them worked without rechecking. So far: great
For testing, they were added paused. I clicked on the start button, and all of the fastresume files were gone!?
Closing deluge + reopening means checking them all again!
Do I have to make them write-only until next release?

I believe that I have fixed the issue in svn. I would ask for some testing, but it's very difficult to use svn on windows.

[waltherbans]

After a proper shutdown of Deluge, can you check for .fastresume files for the torrents in your session?

for some torrents there are .fastresume-files but for the most there are no .fastresume-files.

Also, what type of allocation do you use? Compact or Full?

[x]Full

Do you set any file priorities?

none

edit: nice to read that you might have fixed the issue. i didn't tried svn but maybe anyone can report if the problem is gone?

[zhark]

Same problem here, all my 40+ torrents starts rechecking every time i start Deluge after i updated to 0.5.8.4.
File allocation: Full
I haven't changed a single setting after updating Deluge. With 0.5.8.3 I actually thought the problem with rechecking finished files was gone, because Deluge crashed a couple of times without rechecking seeding torrents at all. Now with 0.5.8.4 it rechecks even after clean shutdown of Deluge.

Frustrating to say the least, as rechecking takes nearly an hour. Hope you get it fixed soon.

EDIT: After downgrading to 0.5.8.3 today the problem vanished.

--
Ubuntu 7.10 (i386)

[sluthead]

Yeah it's a bug then because it is happening even when shut down properly.

I just assumed that because it seemed to appear in the changelog that this was a feature

it doesnt appear on the changelog. "RESAVING" is not the same thing as "saving". that's why they're different words

There's no need to be defensive about it. I don't know how the engine works, I didn't code it. All I know is that the change log said exactly what I quoted and no longer fast resumed my torrents. It's what you call a no-win situation. Had I come in here and not read the changelog I'd have gotten a bollocking for reporting a problem that was in the change log I'm a fairly intelligent person and when something stops working that has a similarity to the changelog then one puts two and two together. Anyway, we've established it's not a feature, thank god, and it's a bug, so hopefully it will be fixed in the future.

Thanks for the great work with deluge, I am always appreciative of it.

[Bodega]

amd64, ubuntu 7.10
Same problem here. "Funny" enough, when first starting the new version (0.5.8.3 -> 0.5.8.4), every finished torrent was instantly seeding.
However, after shutting down Deluge cleanly/nice/as-one-should, and then starting it again... it started checking *all* the torrents

[Bodega]

Since only the non-finished torrents have a .fastresume with this version (0.5.8.4), this will not go away until it is fixed.

[Bzzz]

Since only the non-finished torrents have a .fastresume with this version (0.5.8.4), this will not go away until it is fixed.

Thats wrong. Didn't you read all the posts above?