Shareaza

The "searching" does not seem to be directly connected to when Shareaza actually is searching, for that you will need to refer to the system log in the network window/tab. With the correct level of verbose this will tell when Shareaza is searching and for what and when it gets answers, etc... And yes, having to use the log to find out if anything is happening is annoying, but on a positive side it does give lot more information than just a properly working "searching" text would...

P2P searches are actually relatively fast, so Shareaza does not need to spend lots of time doing them. So even when an item is "searched" the actual search takes little time and most of the time Shareaza is waiting for a timer for the next search to run out. This is because searches are expensive in terms of resources required from hubs, ultra-peers and servers and having Shareaza search more aggressively would get few results (shorter the interval less likely having a new source connect is) and slow down all searches to a crawl. In case of ED2K servers and Gnutella ultra-peers it would also get Shareaza banned for bad behaviour.

Anyway, the bottom line is that searching is throttled and there is a limit on how often you can do a search, so if you make several searches at the same time, later ones won't be able to connect to servers/hubs previous searches just queried and since, like I said before, P2P searches are pretty fast, the later searches often end up doing nothing expect noticing that none of the known servers/hubs can be queried right now and ending. This results in the user seeing "erratic and buggy" behaviour when another search has recently happened, even if that was an automated search invisible to the user.

Shareaza will automatically look for new sources, but only for active searches in the search window and downloads without any sources. Downloads with even a single source are assumed to get more from source exchange. Usually this works just fine, but sometimes it doesn't which is why you can do a "search for more sources". But it is better to do it to just one download most likely to in your opinion have new sources than to do it to all downloads that seem to not have enough sources to you.

Shareaza development process seems to be pretty casual: developers work on features they like and do bug fixes and when enough features/fixes are present they stop adding features and focus on getting all known bugs fixed. And once all known bugs are fixed a release happens. The reason there is a long time between releases is simply because making new features is much more fun for the devs than debugging is. Also we have too few people using the debug versions which means that finding the bugs can be slow.

Honestly, I find the "searching" status confusing myself... It used to correspond to actual searching, so I guess that some of the connections are still left to give feedback.

As for the stable version having bugs, it does, but IIRC it didn't have known (new ones ; bugs already in the previous stable and still unfixed are no reason not to release) bugs when it was released. Having few testers for the debug builds unfortunately means that most bugs are not found until stable release happens and more users start using it. Lots of complaining about stupid developers then follows.

I've been using debugs for a while myself and the quality is variable. A build right after a new feature was added might crash on start. A build right after lots of bugs were fixed might be more stable than the "stable" release you get from the web site... My advice would be (from my personal experience, YMMV): go debug, but be prepared to go back to a previous build and don't feel compelled to keep up-to-date with builds if the current one is working and you are not in the mood to deal with weird problems right now. I usually only update every month or two since most improvements are to things I don't use. But the debug has lots of bug fixes for problems in the "stable" build... So going from the stable to debug might be worth it.

1. No way to know in advance, really. But it is pretty obvious after a while whether you are having stability problems or not. If you are, reinstall the previous build or install a newer build. If not, everything is fine. As long as you don't update at a time when reinstalling the previous build that worked or waiting for a fix would be a problem it is fine. And of course the main benefit of using the debugs is that when you do have a problem, you can report it to the devs, have it fixed, and actually install a fixed version right away instead of having to wait several months for the next stable release.

2. Yes, it could. Rarely does. And most long time users already know how to rebuild the library or recover lost downloads since this sometimes happens with stable versions as well.

3. Sometimes, usually not. If there is a change in the partial file format, older versions will not know how to read it. This happens with stable versions as well, so using debugs does not really make it worse. Also the downloads are not really "lost" as they can be recovered by the user, Shareaza just can't do it automatically. In recent years there has been exactly one change that actually was too big to revert easily and that only affected batch torrents.

4. Only when starting and you can tell them not to. I haven't bothered. The notice is actually kind of scary (meant to prevent anyone using a debug build accidentally or without understanding the possible problems), but if you do know what you are doing you just click thru it without even noticing.

@tharrison:
@1: You can subscribe to the RSS feed on this page to get informed about what has been changed on what revision. It contains a short note on the changes made by the devs, as well as a link to a page showing the actual code changes in case you are interested.

@4: There is a command line switch available to disable that warning on startup. Have a look at the command line switches Wiki page and edit your shortcuts to Shareaza.exe accordingly. Note that you need to edit the registry to change the behaviour if you use the option to automatically start Shareaza with Windows.

1. Recommended builds would essentially be beta builds. It has been suggested before (by me among others). But it is not really related to the debug builds we are talking here. The idea of a debug builds is that the developers (and forum people like myself) only need to support the latest build in addition to the release version and get feedback on the current up-to-date code. There would be extra work and no real benefit having several people using the same "recommended" out-of-date build. Betas are for when you are feature complete and only looking for bugs while preparing for release. I am hoping we will get one before the next release.

3.No, partials are not always lost. But, if the two versions are incompatible then the downgrade always loses partials. Basically, if the partial file format changes between build X and build X+1 then downgrading from X+1 or anything later to X or anything before always loses the partials. But downgrading between builds after the change does not. Changes in the partial file format are relatively rare, there often hasn't been one even between two release builds. Obviously YMMV, but personally I have never had a problem with this.

It probably could be automated in most cases, you might want to do a feature request on that. I honestly can't remember anyone ever requesting that, maybe that is why Shareaza can't do it? Currently the most practical method to deal with a high number of partials is to make a backup before you upgrade. If the new version is unstable enough that downgrading is necessary (instead of it being practical to wait for the bug to be fixed; crash bugs actually get fixed pretty fast currently due to Shareaza now having automated crash reporting) it will be obvious before you'll lose much progress.

I don't talk with you anymore tharrison1 just like grey-hame.

ok, that's enough. Some of you (not pointing any fingers) clearly can't act like mature adults so I am closing this thread.