In OS 10.2.6, xNap5-r2, the GUI will freeze after on line for awhile (>24 hours) have to quit to get the screen to re-draw. Have over 12,000 files and the program will sometimes freeze when uploading to servers during start-up (set at 30 servers max.), have to quit to get re-draw back. Program usually is working in the background (sometimes not so during start-up).
Other than that the program is great, no other problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2003-06-16
This has been happening to me, as well, since Mac OS X 10.2.5, and perhaps earlier versions than that (though I can't remember exactly when I started using this release of Xnap).
While I've found no way to remedy the situation, I have noticed that, in general, hiding Xnap when you're not interacting with it tends to prevent these GUI freezes from biting you in the ass. This isn't an exact science though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have also noted that the freeze is associated with a significant increase in xnap's memory use -- it goes from about 500mb to almost a gb of vm, according to Process Viewer.
I also note that LimeWire used to have exactly this same problem -- something in their UI code was leaking (my inference) and eventually the whole UI layer would lock up. Limewire was able to fix their problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Argh, beware of right-clicking into the user's list to direct browser a user. Frequently, once you get the pop-up menu selected for a specific user, that's the last you'll see from the xnap gui. As mentioned by above, file upload and download continues as normal but you've got to force-quit to get the gui back.
Otherwise, I do so like this better than Gnutella!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OS/2 has the same freeze, checking the list of processes shows that XNap uses about 8000 semaphores (leaking about 20+ an hour) after a while, then the system goes haywire. Could the XNap developers please look into this leak??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I often sort the download on progress. After some hours I want to update the list. So I click the progress bar one more time. Then the gui hangs. To solve that I just click one time on search menu and one click back on transfer menu. That works for me. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In OS 10.2.6, xNap5-r2, the GUI will freeze after on line for awhile (>24 hours) have to quit to get the screen to re-draw. Have over 12,000 files and the program will sometimes freeze when uploading to servers during start-up (set at 30 servers max.), have to quit to get re-draw back. Program usually is working in the background (sometimes not so during start-up).
Other than that the program is great, no other problems.
This has been happening to me, as well, since Mac OS X 10.2.5, and perhaps earlier versions than that (though I can't remember exactly when I started using this release of Xnap).
While I've found no way to remedy the situation, I have noticed that, in general, hiding Xnap when you're not interacting with it tends to prevent these GUI freezes from biting you in the ass. This isn't an exact science though.
I have also noted that the freeze is associated with a significant increase in xnap's memory use -- it goes from about 500mb to almost a gb of vm, according to Process Viewer.
I also note that LimeWire used to have exactly this same problem -- something in their UI code was leaking (my inference) and eventually the whole UI layer would lock up. Limewire was able to fix their problem.
Argh, beware of right-clicking into the user's list to direct browser a user. Frequently, once you get the pop-up menu selected for a specific user, that's the last you'll see from the xnap gui. As mentioned by above, file upload and download continues as normal but you've got to force-quit to get the gui back.
Otherwise, I do so like this better than Gnutella!
OS/2 has the same freeze, checking the list of processes shows that XNap uses about 8000 semaphores (leaking about 20+ an hour) after a while, then the system goes haywire. Could the XNap developers please look into this leak??
I often sort the download on progress. After some hours I want to update the list. So I click the progress bar one more time. Then the gui hangs. To solve that I just click one time on search menu and one click back on transfer menu. That works for me. :-)