If more than 100 downloads pending or active, after about 18 hours of Shareaza uptime some will spontaneously revert to Queued status. After that, more will revert every few tens of minutes until Shareaza is restarted.
Making matters worse, it does not restrict itself to deactivating only Pending downloads. It can and will deactivate remotely queued downloads, losing queue position. This actually makes it impossible to get files from some of the slower emule sources, as it will take more than 18 hours to reach the front of the source's queue and the download will revert to Queued before that happens.
Classing this under Network, as that's the closest thing that seems to fit though it seems to be more Shareaza's queue management than the protocol implementation per se, and classing it as major since it renders some files actually impossible to download, at least without resorting to clearing most other pending downloads and perhaps even having to delete files (if over 99 incomplete, partly-downloaded files have accumulated).
The spontaneous-revert-to-queued behavior doesn't seem useful or desirable. The user can always pause downloads manually. If for some reason you feel it necessary for Shareaza to limit the number of locally-active downloads after 18 hours of uptime (but not before?!), it should prefer downloads with no sources in order from bottom of list to top, then downloads that are not remotely queued or otherwise truly active in order of descending time elapsed since last active, then from bottom of list to top if somehow there are over 100 downloads remotely active.
[Source: https://sourceforge.net/p/shareaza/tickets/180/]
If more than 100 downloads pending or active, after about 18 hours of Shareaza uptime some will spontaneously revert to Queued status. After that, more will revert every few tens of minutes until Shareaza is restarted.
Making matters worse, it does not restrict itself to deactivating only Pending downloads. It can and will deactivate remotely queued downloads, losing queue position. This actually makes it impossible to get files from some of the slower emule sources, as it will take more than 18 hours to reach the front of the source's queue and the download will revert to Queued before that happens.
Classing this under Network, as that's the closest thing that seems to fit though it seems to be more Shareaza's queue management than the protocol implementation per se, and classing it as major since it renders some files actually impossible to download, at least without resorting to clearing most other pending downloads and perhaps even having to delete files (if over 99 incomplete, partly-downloaded files have accumulated).
The spontaneous-revert-to-queued behavior doesn't seem useful or desirable. The user can always pause downloads manually. If for some reason you feel it necessary for Shareaza to limit the number of locally-active downloads after 18 hours of uptime (but not before?!), it should prefer downloads with no sources in order from bottom of list to top, then downloads that are not remotely queued or otherwise truly active in order of descending time elapsed since last active, then from bottom of list to top if somehow there are over 100 downloads remotely active.