It does indeed happen quite often that a download (sometimes several) gets stuck at the “verifying” step, and is not considered “completed” despite its 100% completion status, it can stay that way for hours, and can stop further files from being downloaded from a specific source (very problematic for rare files which have only one source). So one has to manually resume it for the verification to complete (and for the next file in the queue to start, if the source is still available). And since it's so problematic to temporarily change the sorting mode, in order to pinpoint which file(s) could be responsible for transfers suddenly stopping even though the source should still be available, one has to painstakingly scroll down to find the culprit.
It also happens quite oftens that the hashing process gets stuck altogether, completely freezing Shareaza (it seems more likely to happen when many files are downloaded in short succession, and especially when files in Shareaza's library are moved at the same time). I found a clunky cure : examining Shareaza's threads with Process Explorer, there's usually a “ucrtbase.DLL” thread created shortly before the interface got frozen, if I selectively “kill” that thread, Shareaza's interface gets unstuck and can be used again, albeit with a dysfunctional hashing / indexing process (files are still verified but no longer get the “verified” status and do not appear in green — until they get properly re-hashed and indexed at the next startup). It might be better to create yet another report for that related but more general issue...
It does indeed happen quite often that a download (sometimes several) gets stuck at the “verifying” step, and is not considered “completed” despite its 100% completion status, it can stay that way for hours, and can stop further files from being downloaded from a specific source (very problematic for rare files which have only one source). So one has to manually resume it for the verification to complete (and for the next file in the queue to start, if the source is still available). And since it's so problematic to temporarily change the sorting mode, in order to pinpoint which file(s) could be responsible for transfers suddenly stopping even though the source should still be available, one has to painstakingly scroll down to find the culprit.
It also happens quite oftens that the hashing process gets stuck altogether, completely freezing Shareaza (it seems more likely to happen when many files are downloaded in short succession, and especially when files in Shareaza's library are moved at the same time). I found a clunky cure : examining Shareaza's threads with Process Explorer, there's usually a “ucrtbase.DLL” thread created shortly before the interface got frozen, if I selectively “kill” that thread, Shareaza's interface gets unstuck and can be used again, albeit with a dysfunctional hashing / indexing process (files are still verified but no longer get the “verified” status and do not appear in green — until they get properly re-hashed and indexed at the next startup). It might be better to create yet another report for that related but more general issue...