Upgrade from 2.4 to 2.5 seems to fail

[omarr]

I installed 2.5 over an existing 2.4. The installation itself looked ok. Starting 2.5 first looked ok, the GUI came up, then a small box called "Shareaza remote" which remained white (empty), then another box saying "Updating bittorrent downloads". Then nothing happened anymore. Taskmanager said that the Shareaza process was consuming 99% cpu, so I killed it after a while and restarted, with the same result. Looks like I have to reinstall 2.4 .... Btw: I have never used remote control with 2.4.

[old_death]

Updating the torrents when running v2.5.0.0 for the first time can consume a big amount of time. There have been reported cases where this has taken up to one hour. So just let it run on background (with reduced process priority) and don't worry. It should end after some time - or just finish your downloading torrents before updating.

[ocexyz]

[omarr]

OK, I started 2.5 in the evening, left it running all night, and in the morning, there was no progress. But it showed all symptoms of a tightly looping program: The Windows task manager says it's not responding and eating up all CPU cycles, there is no noticeable disk I/O, and the Shareaza window is not repainted after covering/uncovering it. My guess is that I have some data structure that is corrupt or has otherwise unexpected content, maybe the bittorrent download itself or something in the environment.

[old_death]

[ocexyz]

+1
Last debug as I remeber r8300 was fixed against this. Please use debug for upgrade especioaly.

[old_death]

[ocexyz]

[omarr]

So here comes the user feedback
I installed Shareaza_2.5.0.1_Win32_Debug_r8309_2009-11-10.exe and started it.
At first sight, it looked the same as before. But when asking the Windows task manager about Shareaza, it is different! Task mgr says: Application not responding (as before), process not doing any I/O (as before), *BUT* this time it consumes 0% CPU time, not 99% as it did before. Strange, what reason could there be to get stuck ?? It can't be the network, because I'm posting this while Shareaza is running (if I may say so for a program not using the CPU).

[ailurophobe]

The first try that you interrupted might have left some corrupted files that cause this.

[raspopov]

[omarr]

I'm absolutely sure. There was no disk rattling, and there was a stable display in the Windows task manager for the process Shareaza, i.e. no change in the I/O columns. Furthermore, Shareaza opened pop-up window for this processing step, containing a progress bar. The progress bar showed no sign of life, i.e. it remained empty.

[ailurophobe]

Like I said the first try might have created a corrupted file when interrupted. Specifically an invalid new style partial that hangs Shareaza when it tries to process it. I assume Shareaza deletes the old partial when it is fully processed, so you probably should delete new type partials that still have a corresponding old partial. raspopov would know I assume.

[omarr]

Noone can expect a program to create valid output from corrupted input. But a program can be expected to recognize a problem with the input and create an appropriate error message. In short, it should remain in control of the situation, and a user should not have to face a hang or loop or crash.
I realize that you guys are doing a lot of excellent work just for the honor of it, but please don't put the blame on users when something goes wrong.

[ailurophobe]

Sorry, not trying divide blame, just trying to give a suggestion on how to get rid of the problem. You are of course right, but the sad reality is that most applications have difficulties if files created by "trusted" sources become corrupted. Creating the necessary error handling mechanism is actually more complex than it should be and involves significant performance overhead on every file read, usually without any benefit from the extra code.