amp

Member
  • Content count

    299
  • Joined

  • Last visited

Posts posted by amp


  1. I've got more info about how to reproduce. It 100% works in my case.

    Go to Waiting Users, works only if you have someone there, then close this tab, start downloading someone's big filelist, so it took some time to download, go into Download Queue, click on Filelists and... Apex would crash without a word of exception...

    Oh, found the reason:

    Unhandled exception, floating point operation.

    BarShader.cpp, void CBarShader::Draw

    Fail on

    while((pos != NULL) && (m_Spans.GetKeyAt(pos) <= qwStart))
    
    			crColor = m_Spans.GetNextValue(pos);
    
    		}


  2. A friend of mine made some fixes and improvements to 0.2.2 version:

    1) added [AWAY] into description

    2) limiting limits removed *

    3) range check error bug fixed

    4) slow users bug

    5) scrolling bug even if autoscroll is disabled

    6) pressing Esc will clear message text

    7) some other small fixes and a bit changed VS2005 project files

    8) full file recheck on download finish (experimental)

    * yes, this edits are forbidden, but we here have very small up and down speeds and we use this version in one and only hub. So just ignore them). I'm just too lazy to delete them from this patch.

    Hope you like it and include in next release. This version is MUCH more stable than mine)

    1.txt


  3. I did a quick n' dirty patch to add this abilities to 0.2.2. Unfortunelly i'm not pro in C++ :blink:, so problems still exist:

    - Progress bar on file recheck won't show

    - Even newly added files are rechecked then temporary file is created

    - other things I might not found

    Hopefully, you can fix them and include into next release.

    Or at least, maybe you'll made this features in the right way.

    1.txt


  4. Found a simple workaround.

    Set FreeBlocks="0 1 " and VerifiedParts=" ". Also, set MaxSegments="5".

    So, file should resume downloading after rechecking.

    I did some workaround in the source, so if all goes well, I'll submit a patch).


  5. Returning to this topic. I was downloading 2.32 Gb file for a couple of weeks (slow source). And my queue was wiped one day. I've restored it using older versions of Strong. As result - every time source return online, Apex seeks hardly something on HDD and only after that restarts. VerifiedBlocks etc aren't saved into queue.xml file. Segmented downloading ain't working at all, even though I'm not only who downloads this file and major client on our hub is Strong 2.02.

    Today I've also rechecked almost downloaded file (95%) with uTorrent, because there is a torrent for it, but no seeders, I have to stick with DC. So, it says, file is only 88% complete! It has couple of zero-filled gaps in the middle. As you can see, 7% of file is corrupted already!

    I think you must recheck the file before download restarts and also recheck it when it's finished (both are options). I hope you accept that current solution is not perfect.


  6. Seems like i'm living in another universe with another physical principles...

    My PC is 4 years old P4 Northwood 1.8GHz with 1Gb DDR2 RAM. When I click on close button, Strong/Apex remains in memory for 10s up to couple of minutes. My queue and favourite list aren't much big - they both less than 100kb in size. So, If I wouldn't wait until it disappear from task list, my favlist or queue would 50/50% wiped.

    Yes, my world seems to be not so perfect as yours.


  7. My settings were wiped again. Now it was Favourites.xml.

    I'm sick of it and made a simple bat to backup vital files.

    tar -cf settings.tar Queue.xml DCPlusPlus.xml Favorites.xml
    
    bzip2 -z settings.tar
    
    for /F %%i in ('f:\bin\date +%%s') do move settings.tar.bz2 bak\settings.%%i.tar.bz2

    tar, bzip2 and date are from cygwin installation. I run it through nnCron.


  8. Absolutelly failsafe system doesn't exist! I could speak so, because I'm an hardware engeneer (microcontrollers and so). Errors would happen, this is a rule for any system. And programmer should take into consideration any possibilities might happen in a working system and handle them.


  9. How about situation when seeder sends corrupted data? Bad client/blocking software or hardware failure on his side - this might happen for short period and you'll get faulty packet. I still think that full rechecking according to TTH is a must.

    My queue.xml was wiped. I've restored download with old SDC version (1.0RC10). So now I'm downloading it. But everytime source appears online, new Strong (Apex too) is seeking something on HDD (for a couple of minutes) and only after that restarts download. FreeBlocks and VerifiedParts are not saved into the queue.xml.

    I hope you will add some method to check and resume such downloads painlessly. Old methods won't work anymore :).