amp

[Bug]Download queue wipe

25 posts in this topic

This thing is REALLY annoying. It was in Strong, now it is in Apex. Sometimes then I close the client, download queue became wiped. And If I haven't found this fast, backup copy (.bak) of the queue is also wiped.

Please, do something!

Share this post


Link to post
Share on other sites

This thing is REALLY annoying. It was in Strong, now it is in Apex. Sometimes then I close the client, download queue became wiped. And If I haven't found this fast, backup copy (.bak) of the queue is also wiped.

Please, do something!

the .bak file doesn't work well as it's overwritten on every launch (as far as i can remember) so when you find out your queue got wiped the .bak file has also already been overwritten...

i am not 100% sure if that's how it works, for current versions of SDC (and thus apexdc), but on earlier versions of SDC that was how it would have worked...

about your actual problem, i cannot say much since it could be a lot of things going wrong...

Share this post


Link to post
Share on other sites

Seems like it happens if program was terminated on its closure. For example if I close Apex and immediatelly click on Windows - Shut Down.

Or if I try to start another copy of the app while current one wasn't closed yet.

I need to look into task manager every time I'm closing Apex, which is annoying too(.

Share this post


Link to post
Share on other sites

Seems like it happens if program was terminated on its closure. For example if I close Apex and immediatelly click on Windows - Shut Down.

Or if I try to start another copy of the app while current one wasn't closed yet.

I need to look into task manager every time I'm closing Apex, which is annoying too(.

apexdc.exe remains in memory as long as it takes for it to close all connections... (assuming that i remembered that correctly :))

Share this post


Link to post
Share on other sites

So, please, do something, I really hate this.

Share this post


Link to post
Share on other sites

So, please, do something, I really hate this.

how you expect me to do something about it (assuming you speaking about the exe remaining in mem for closing connections)

Share this post


Link to post
Share on other sites

how you expect me to do something about it (assuming you speaking about the exe remaining in mem for closing connections)

Can't it be made less awkward, I mean to terminate faster without closing connections? (Sorry, shot in the dark...)

Edited by Zlobomir

Share this post


Link to post
Share on other sites

For example, you may quickly make an backup copy right after "close" command was received. And after that close it as it should be.

And on start up do some checking. Or, at least, make the download queue backup every hour and place them into separate folder. And clean it every 2 days, for example.

Share this post


Link to post
Share on other sites

Can't it be made less awkward, I mean to terminate faster without closing connections? (Sorry, shot in the dark...)

maybe, but i don't think just suddenly dropping connections is good idea (i also haven't taken much of a look at the "exit code" since pwdc)

For example, you may quickly make an backup copy right after "close" command was received. And after that close it as it should be.

And on start up do some checking. Or, at least, make the download queue backup every hour and place them into separate folder. And clean it every 2 days, for example.

I'll see how it's done atm. and try to come up with better solution, if i can...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

it's interesting to see how reliable your system is.

I don't believe that is the problem here. If he restarts his computer just after closing the client his queue is wiped, because it remains in the memory (and it does in mine) for a while after. It's not his unreliable system, but the program.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I don't believe that is the problem here. If he restarts his computer just after closing the client his queue is wiped, because it remains in the memory (and it does in mine) for a while after. It's not his unreliable system, but the program.

I always shutdown my PC immediately after closing StrongDC++ and it has never happened to me :D

Share this post


Link to post
Share on other sites

I always shutdown my PC immediately after closing StrongDC++ and it has never happened to me :D

...yet.

Unfortunately, this did happened to me too. Only once in several months. Empty queue.xml. And .bak did not help because there was already too late.

I have very simple idea how to avoid most serious problems. Do not make a backup of queue.xml if there are no downloads in queue. What do you think?

Share this post


Link to post
Share on other sites

i've already removed auto-saving queue on startup.

So when there is no downloads Strong will not try to overwrite .bak?

Share this post


Link to post
Share on other sites

So when there is no downloads Strong will not try to overwrite .bak?

No, when the program is launched it will not overwrite your .bak, but will do so after the period of time you've set.

And BM: Watch your memory, StrongDC.exe will (sometime) stay in memory for a few secs/mins after you close it. That's a guarantee. :D

Share this post


Link to post
Share on other sites

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.

I was not complaining about your universe, but about the BM's one. Frankly, I don't have similar issues, but in the way you all describe it and in the way BM refuses to fix this, I will be forced switch my more serious jobs to a more serious client if this happens to me. :D

Share this post


Link to post
Share on other sites

Zlobomir

Argh, my post was pointed to BM, so don't bother about that :D

Share this post


Link to post
Share on other sites

And BM: Watch your memory, StrongDC.exe will (sometime) stay in memory for a few secs/mins after you close it. That's a guarantee. :pinch:

yes, for about 5 - 10 second but I've never lost my settings/favorites/queue, neither if I interrupt the process manually.

there's one thing - when you terminate the process, it can delete your queue.xml. Yes, actual queue is in memory, so it won't be saved, but there exists old queue.xml on your harddisk.

If someone write some nice patch which avoid happening this situation, I will, of course, integrate it into StrongDC++. But I don't respect any post-checking whether current file is correct :D There must exist solution to have this file always correct and avoid damaging.

Share this post


Link to post
Share on other sites

BTW, If I terminate strong through task manager, I never got my queue wiped. All times I got it corrupted, it was closed using standart way.

Share this post


Link to post
Share on other sites

edit:...erm :D i wrote a completly pointless post. totally of topic. :pinch: never mind

Edited by balder

Share this post


Link to post
Share on other sites

But I don't respect any post-checking whether current file is correct :D There must exist solution to have this file always correct and avoid damaging.

Maybe it will be be wise to remove this check when you will find this solution? Unfortunately we are not there yet.

Share this post


Link to post
Share on other sites