RapidQueuer 2.4.4

[ILLBeBack]

hi, i actually changed the code twice..i scrapped the processwaitclose idea. I hoped you weren't fast enough to download the first

If $ExtPID <> "" Then
    ProgressSet(0, "DHCP:" & @CRLF & " Waiting for "&$ExtIPResetName&" to close.", "-")
    TraySetToolTip("RapidQueuer" & @CRLF & "DHCP: Waiting for "&$ExtIPResetName&" to close.")
    Do
        Sleep(1000)
    Until TimerDiff($TimerTimeout) > 30000 OR ProcessExists($ExtPID) = 0
    Endif

Yep, I was too "fast" and the last test I reported was based upon "ProcessWaitClose($ExtPID, 10)".

Your latest version, using "Until TimerDiff($TimerTimeout) > 30000 Or ProcessExists($ExtPID) = 0" will work for me, (it’s along the lines that I initially recommended), and when you change the timeout to obtain the value from the INI file, the timeout will no longer be an issue.

[Datenshi]

http://www.fetgrek.com/RapidQueuer_2.4_RC1.exe

This is not the official v2.4, its a release candidate version as in "beta".

# ILLBeBack check if its good now with dhcp_refresh_exec_timeout=

Edited December 13, 2009 by Datenshi

[ILLBeBack]

http://www.fetgrek.com/RapidQueuer_2.4_RC1.exe

This is not the official v2.4, its a release candidate version as in "beta".

# ILLBeBack check if its good now with dhcp_refresh_exec_timeout=

Datensi,

I'm testing this version at this moment and RQ is waiting for RS to open a slot with the progress window saying:

Non-Critical Error

Too many users/Waiting for slot

Trying again in 2min

But, the progress bar is moving extremely slowly. It appears to be waiting 20 minute instead of 2 minutes. Please check it out as it will take forever to complete testing.

ILLBeBack

[yehia]

v 2.3 is crashing with the object error for me

[Datenshi]

ILLBeBack, hahaha you're right, all these numbers! quick fixed

Yehia, Yeah i know, try the http://www.fetgrek.com/RapidQueuer_2.4_RC1.exe beta version if you really need it. 2.4 will be released soon i think.

[ILLBeBack]

ILLBeBack, hahaha you're right, all these numbers! quick fixed

That's MUCH better (one too many zeros I suspect )!

Results will probably be slow coming as this time of day is the worst time of day to get a free user slot, and since it's the weekend it's even worse than that. I'll let RQ run, and I'll Be Back when I have something to report...

ILLBeBack

[ILLBeBack]

SUCCESS!

It took over 90 minutes to get an RS slot. RQ then called my script and waited for it to close, which took the normal 40 seconds or so (I have dhcp_refresh_exec_timeout set to 900).

Incredibly, RQ immediately caught another free slot, and downloaded my 2nd test file, and repeated the process without any problems. In my opinion, this issue is resolved!

I noticed that the description of the dhcp_refresh_external_exec key in the INI needs to be updated to state that RQ will wait up to the value in dhcp_refresh_exec_timeout for the program/script to exit.

Here are a few things I would eventually like to see in RQ, but definitely do not hold up version 2.4 for them:

1. An INI option to play a short audio file when each download completes.

2. An INI option to play a short audio file when all downloads are complete, or RS shuts down for any other reason.

3. An INI option to automatically open the progress window when RQ starts downloading.

4. An INI option for the initial state of the progress window's "always on top" option.

5. Open the progress window in the same location as it was last positioned, provided part of it is on screen (considering the window resolution when it opens). This location could be stored in the INI file.

ILLBeBack

[Datenshi]

Excellent news! This method would probably allow for scripts which are a bit more unusual as well, but that stuff would have to be implemented by whoever wants it, else I'll never get this version out

I'll look into suggestion 3 and 4 for 2.4, they both should be quite easy to include. The rest I'll keep in mind for later. All very good suggestions thank you very much for the help, so hard to properly test stuff when i can't or usually don't use the features myself. I'll add you to credits

[ILLBeBack]

Datenshi,

I agree, this method of supporting External DHCP Refreshing is quite flexible and I suspect will work quite well for everyone.

FYI, I'm continuing testing of beta 2.4. It's gone through a few more complete download cycles, including one where my IP refused to change and RQ patiently waited for my script to cycle several times until a new IP was awarded. Works great, that's very much!

ILLBeBack

[yehia]

man i guess i said it before somewhere at this topic, but again your tool is awesome it saved me lots of my life time

thanks for the gr8 tool

[Phil Viton]

This is a note on the Unexpected Filesize error when trying to download from Rapidshare. I'm not convinced that it's RapidQueuer's fault. I have two boxes, side-by-side: one is running XP-Pro, and downloads perfectly; the other is running Vista Enterprise, and persistently has this problem. I've no idea why.

One thing that the OP could do is try to download a large-ish (say 100MB) RS file directly using a browser. On my Vista system, using the latest Firefox, the download starts normally, but then grinds to a halt after a while. The same sort of thing happens when I try to download part of the Lyx system using anonymous ftp.

If anyone has any idea what might be causing this, I'd very much like to know - I'm completely stymied!

Edited December 14, 2009 by Phil Viton

[Datenshi]

yehia, thanks glad you like it

Phil Viton, Hm..I'm running XP and i had the same problem with RQ 2.3. RapidQueuer doesn't use any browser, it sends its own TCP packets. I think you got a whole different problem on you hands. If the download was interrupted for some reason, RQ would have written it to the error log and the file would not pass the filesize check either.

Anyway, to both of you i would update to 2.4 as i just released it.

Edited December 14, 2009 by Datenshi

[ILLBeBack]

Thanks Datenshi! It's good to see you have issued version 2.4 . I, for one, appreciate it very much.

ILLBeBack

[rahulwithu]

Hello Friends,

Good to see the new update with RapidQueuer.

But the issue with me is errorlinks.dat shows

The Filesize did not match with Rapidshare, download seem damaged.

This error seems to continue even with RapidQueuer 2.4

[Datenshi]

What OS are u running? You're the only one who i have heard that has this issue, there's gotta be something unique with your setup.

In 2.4, filesizes are not even compared, except when Rapidshare don't have an MD5 hash for the file, which I've yet to see happen.

Edited December 18, 2009 by Datenshi

[ILLBeBack]

Datenshi,

Not to detract from rahulwithu issue, but I haven't had any problems with v2.4, although I've only downloaded a few files. I'll try do more soon.

A friend has downloaded about 60 files using it, and hasn't had any problems, although I did revise his copy so that the INI Key "dhcp_refresh_external_exec" would support command line options for his script. Maybe that's something you can think about adding in the future.

ILLBeBack

[ILLBeBack]

Datenshi,

I made a few more downloads, and all were okay.

Here are some things I have found that I would like to bring to your attention:

1. For the 1st download, if a long wait period is detected, RQ does not attempt to run function DHCP_IPRefresh in order to avoid the long wait period. This can occur, for example, if RQ is instructed to stop after a download, and then RQ is restarted before the 15 minute period expires.

2. When URLs are added to the LinkList using the "Add More Links" option while RQ is downloading, the added links do not appear in the .dat file at that time, and I do not see a way to later check what has been added to the list until RQ is exited, upon which the .dat file is updated and can be inspected.

3. Other than exiting RQ to update the .dat file, I do not see a way to check what remains to be downloaded while RQ is downloading.

ILLBeBack

[Datenshi]

Hi ILLBeBack,

1. RQ currently doesn't run DHCP_Refresh on the first download loop, that's because i didn't want people to blow their first IP "charge" for nothing. While writing a huge answer to this question i had an idea of changing DHCP_Refresh to be run as an "answer" for 15min wait detection in errorchk(), IF DHCP_Refresh is enabled that it. It probably would work but I'll have to look into it. It doesn't make a decision whether to run it or not atm, because the dhcp_refresh function is run prior to any communication with RS.

2 and 3. The way this feature works is a bit of a workaround, For loops don't check if its array increased in size each time it loops, the current method which i called "inject method" works by "redim:ing" the $downloadlinks array to 500, and knowing how many actual links are in there we can add new links to it as we go along, the FOR loop will loop 500 times but skipping any element that is empty. There's no reason the imported links can't be written to Linklist.dat, i just didn't think about it when i wrote it, or i decided not to as i didn't see a reason for it back then. It's probably as simple as putting

FileWriteLine($LinklistFilePath,Array[$x])

in the FOR loop of both TrayFileImport and ClipboardImport(0) functions. I guess its a simple solution but in the end, the method of using Linklist.dat to view what files are in the array it not very elegant, its a feature that should be properly implemented.

Linklist.dat works in this way,
Clicked Start
Read its content and search for links, add them to array
Redim array to 500
Start download loop
If any links added during download loop just replace the empty elements with the links.
When done or exit, dump nonempty elements in array to linklist.dat.

Edited December 18, 2009 by Datenshi

[ILLBeBack]

because i didn't want people to blow their first IP "charge" for nothing.

Datenshi,

The thing is, RS issues a long wait only when an IP would be beneficial. That is, when the waiting period is greater that say 4 minutes, why not obtain a new IP. I believe the longest "short" wait period for a download ticket is 250 seconds (I just checked a 200 MB file).

BTW, The RS message when no slots are available no longer specifies how long to wait before trying again. Here's a guote:

There are no more download slots available for free users right now. If you don't want to become a premium member, you might want to try again later.

ILLBeBack

Edited December 18, 2009 by ILLBeBack

[Datenshi]

The thing is, RS issues a long wait only when an IP would be beneficial. That is, when the waiting period is greater that say 4 minutes, why not obtain a new IP. I believe the longest "short" wait period for a download ticket is 250 seconds (I just checked a 200 MB file).

BTW, The RS message when no slots are available no longer specifies how long to wait before trying again. Here's a guote:

Yeah i know, there's no real reason why it should remain that way. It's because the dhcp_refresh feature as u know, wasn't very "complex" prior to 2.4, kinda "set and forget". It is a great idea to change the code so it can make a "smarter" decision whether to get a new IP, I agree.

About the RS message, I'll check if there's any benefit to refreshing every 30s, but they're probably keeping their old system and just not notify the user about it.

Edited December 18, 2009 by Datenshi