Shareaza

I'm finding some downloads always showing as "queued" and never as "pending" or "searching" (or, of course, actually "downloading"). These show resume rather than pause as an option. If I resume them, they behave correctly for a while and then revert to perma-queued.

I'm not pausing them.

What is causing this?

I suppose there is lack of active sources sending anything. Try "find more sources".

You can move them to top.

You can have set 100 but connection bandwith (in the same place) set to be diveded on less number of parts, so there can be not enough number of connections at the same time to serve all of them (downloads of files), so surplus becomes qued: connection per file * MaxFiles > Max number of Connections in your case (perhaps). Make it < or =, by changing those 3 number mentioned above. Perhaps you will have better effect with lower number of downloads at the same time.

There's a difference between the theoretical amount of bandwidth it would require if it connected to 100 sources for each of 100 files simultaneously, and the actual amount it requires in practice when it seems to be contacting sources one at a time for 25 files.

See what bandwith takes your downloads and make some calculations. Also in practise Shareaza use some bandwith to check only if there are aviable sources "around" so it is used not only for downloading but also for comunication with hubs and other clients. I'd suggest to make some experiments, but in general you set to high values IMHO. What connection to you have?
Number of downloads * number of connections per file can be only lower or equal ( =< ) then max number of connections (total number of connections) Shareaza use, in my limited knowleadge. And max number of connections is number of parts on which connection bandwith (dedecated to Shareaza so set in settings > internet > connection) is divided. From this implies how wide single connection can be. And this value is constant unless you will change settings. Make calculations and find out what values are in your case.

This problem remains unresolved. It seems to be changed behavior since 2.4, which only paused downloads if there were over 100 of them.

I have the same issue, all my files go "Queued". Everything was working fine until I upgraded from version 2.4.0.0 to the latest 2.5.1.0 version. I did not change any settings such as Maximum Files in Download.

I have to resume every single file about every 2 hours. Well except when I have a torrent that's popular. I guess that all the active connections and almost constant progress keeps it alive.

I find this bug very frustrating since I have a dedicated PC for Shareaza, I keep it up 24/7! (male bragging)

I hope there will be a patched update soon because I haven't made much progress on my files since this upgrade. I tried to install 2.4 on top in the hopes that I could keep all my settings and the progress on my queued files but it failed.

I guess Shareaza follows the mainstream belief that we can't allow an older version to be installed. After all, it's completely impossible that the newer version contains a bug, right!?

I didn't mean to attack when I said "impossible". I just wish that we could install a old version as easily as we can install a new one. I guess the technical term would be like "software revision regression". Duh, what was I thinking, the software should allow "Downgrades".

Intel Core2 Duo
E8400 @ 3.00 Ghz
1.99 Gb of Ram
Win XP SP2

Thanks!

I have this problem too and it only started when I upgraded to 2.5.1.0.

It takes several hours to happen. Last night my downloads were running but this morning they were all Queued.

It seems it queues the downloads without ever un-queuing another download...

If it helps, I am on XP SP2 with AMD 9950 and 3gb. I usually leave Shareaza running 24/7 but yesterday it had only been on since 22:30.

First I thought it is about set of 3 significant numbers of: maxfiles, connections and transfers/file. Now I am not so sure. But still I would suggest to read pervious posts in this thread, because there is no one "the best" set of them. So I sometimes change them when I want obtain different results. Some experiments can give you some results, so you should try. But after change numbers you will not obtain immediate results, there is a kind of "inercion", sometimes minutes but sometimes hours. Anyway, even if this would be a bug, and would be fixed, but you will still not set those 3 numbers adequately to YOUR particular conditions, downloads, aviable sources etc. it simply will disallow to obtain good performance.

This could be a reason to publish 2.5.2.0 if this would be a case, and if this is common problem IMHO.

What I posted is a link to the changes to the Shareaza source code that have been committed by wildcard_25 and that might fix the problem you are experiencing. In order to check whether this is really the case, you should download and use a debug build with a revision number higher or equal to r8431 on the debug builds page (once it has been compiled and uploaded).
http://shareaza.sourceforge.net/?id=debug

I'm not sure I want to try a debug build, worried that something else could go wrong. Any idea when then next official build might come out?

Is this on ED2K? If it is you can check the number of max ED2K clients and that you actually have an ED2K server connection. IIRC this is what happens to ED2K downloads without a server connection. Was too busy getting connected to really pay attention, so might be wrong though. You can also try a clean reinstall.

This is emerging as a big problem for downloads that have long queues on the remote host. Not just ed2k; I have several files remotely queued on a g2 host that has a queue length of 50. It will start around 44 and get down into the teens before it pauses itself. I'll resume it and it'll soon be remotely queued again -- back around position 44. It rarely gets to the head of the queue and downloads anything before the pause kicks in, and unfortunately, once downloading it also won't STAY downloading; I'll get one or two chunks and then be booted back to the end of the line by that particular remote host. That would ordinarily be merely annoying, but combined with the local-downloads-pause-themselves-if-not-actually-downloading bug introduced in 2.5 ...