mcravener
Member-
Content count
15 -
Joined
-
Last visited
Posts posted by mcravener
-
-
It works now, but I'll keep an eye open for intermittent behavior.
-
Seems like searching for alternate users via TTH does not work - neither from a right-click on a file and user and "Search for alternates" in the Transfer window nor from files in the Download Queue. Interestingly the newly implemented search progress bar is when searching for alternate users set for over 5 hours. So perhaps it does work if you have the patience to wait for 5 hours: ;)
-
Sure, which version of StrongDC? Or why don't I compare the StrongDC versions for both 1.0.1 and 1.1.0... :)
-
Source of bug found!
With Queue/Enable Multisource => Disabled - I get the buggy CPU use (and TTH inconsistencies after downloading for a while)
With Queue/Enable Multisource => Automatic - things are running very smoothly.
I can't say what caused GregJ's CPU problems but now all works well on my computer.
-
I'm running 1.1.0 now but the download queue seems to be the cause of the drag on the CPU. With 5 files in queue and all paused but one, and this one file has 20 user sources but no downloading going on, Apex 1.1.0 is intermittently running on 2% to 84% of my CPU (see upper figure).
With all files in queue paused Apex 1.1.0 runs 2-10% of my CPU, with occasional spikes of 40% (see lower figure). The difference with the queue actively on and off is substantial and is producing quite different behavior from my experiences with Apex 1.0.1.
As a footnote the upload going on was 3 slots at a total of ca 260 kB/s.
-
The DC++ client had this issue too from clients post 0.691 and pre 0.700. I haven't seen it yet in 1.1.0 due to my restricted use of Apex as my CPU runs high from 1.1.0
but it is a most irritating bug as the more active the hub admin is with keeping their hub clean the less functional main chat becomes. -
Well Apex will wait your predefined search interval before starting a search so that cant be the prob. Dont think it is anyway.If you have such a large queue that is the reason, unless these files are all huge and in essence the xml file is still small that is.
Queuing up thousand's of files will swamp the client as it is opening numerous connections at once.
Well yes but this does not explain my CPU usage when running Apex. What GregJ and I have both noticed is that downloading may be connected to the high CPU use.
-
High CPU use has been my issue too - see my post from the 14th of June. Thanks for process logging GregJ.
It seems to me to have to do with when Apex starts up, possibly when files are downloaded directly from when the Apex program starts. Yesterday I did manage to keep 1.1.0 stable with reasonable CPU use (10 connected hubs) for several hours, even downloading 4 files at a total speed of 2 mbit/s, though these downloads were put in queue during the same session. Today when I started the Apex program with the same four files in queue, and a known available user to download from, one connected hub was enough to overload my processor.
Queue size has not affected CPU use. I suspected it might, so I reduced my queue from 60 to 30 files but CPU use still runs high.
Hashing has worked fine. I did it with no hubs online though.
-
Hey,
I've been a superlatively satisfied user of ApexDC 0.4 and 1.0.1, but the 1.1.0 just does not work for me. Apex 1.1.0 consumes all my CPU resources for no apparent reason (no hashing going on or anything like that). My CPU usage does occasionally drop down to what I'm used to with the 1.0.1 - to around 5-10% but after about 30 seconds it surges again and stays that way for up to 90 seconds. These surges block and lag the use of any program, including ApexDC. Since the use of earlier versions of Apex is no longer allowed, this unresolved issue will force me to change P2P program
Now I am using an antique (almost) 1.8 Mhz Intel Celeron Processor and Win XP Pro SP2, but since the 1.0.1 responded very well to my OS and hardware, I have a hard time thinking it's because of this. Oh yes and I've tried doing both an upgrade install and a clean reinstall of 1.1.0 adding the .xml files from the 1.0.1.
Any ideas?
-
Weeell what you did was shut down downloading from multiple users for the same file. What you additionally need to do is to restrict the number of segments created for each file download (multisource and segmented downloading go hand in hand but they are separate functions). This is found in Settings/Queue - "Manual Settings of number of Segments" (min = 2). There is the option (not tested by me) to go down to 1 segment downloading, but then you have to manually specify that for each file (right click on file) in your download queue and select "Max number of segments" (=1).
-
Looks like Size - At least/At most __ Mb has no effect on Search - it just rams through with all files matching the search string.
-
mind , this bug only affects me with the b5 version, the b4 version worked fine.Isn't this all a bit academic since the Bug report is supposed to be about the latest client:
Bug report rule 4: Please also ensure that you are using the latest ApexDC++ version"
Hmmmm? :)
-
Very impressive response time. Cudos to you Crise. :thumbsup:
-
After I upgraded to 1.0.0 i found out two problems:a) file share was reset so I had to select shared directories again
:thumbsup: I cannot change width of main chat chat and user list windows. Vertical separator among them is not clickable.
Congrats on the 1.0.0 Final.
I have the same experience as Pedja, i.e. that the vertical separator between main chat and the user list is not clickable, with the inclusion that the width proportion between main chat and the user list varies between hubs.
Share size
in 1.2.0
Posted
A bit irritating yes, but it's not a new bug, and perhaps not even a bug as Big Muscle says but dependent on the hubsoft settings.