Reset and Restart Queue Transfer Upon Completion

Is there a way to automatically have flashfxp reset all in the queue and restart transfer upon transfer complete? At this point i type - ctrl - a /ctrl -r / ctrl -z and it does it but this often goes days between the opportunity for me to do so. Any suggestions? If i am missing an obvious solution or missed a posted solution in the forums let me know. I saw that a similar request was made in 2005 but no replies.

I understand the basics of command line and windows scheduling.

Thanks.

Ultimately a new feature could be added so that it could be selected from the dropdown menu in scheduling with flashfxp.

I have posted this in the forums as well and am a registered user.

Christian Biagi
Ketchikan, Alaska

When a queue contains failed transfers, normally they're transfers that experienced a critical error. Having the queue reset and restart could cause an infinite loop of attempting to transfer files that will always fail.

Non critical failures are always retried to the maximum value set in Preferences / Transfer / Retry failed transfers. Increasing this value might reduce the number of files remaining in the queue marked as failed if the errors are non-critical, leaving only critical failures in the queue.

I think a 'Retry Failed Transfers when Queue finished' feature would be quite useful. Obviously it would only reset them and start the queue over once to avoid looping. This could be a global option (default) and integrated into the On Transfer Complete options (a check item seperate from the radio item list of corse, so that it can be modified from the default on a per session basis rather that changing global option and affecting all/future).

Could also include an extention of the retry failed transfers feature that would move failed items to the bottom of the queue (after the first failure) so that other items can be transfered before the x retries are attempted (as per the retry failed transfers feature).

These are both great suggestions.

I'm going to try and get an option to move failed file transfers to the end of the queue into the next release.

Both of these features have been added to build 1280.

Bug: Preferences option does not work correctly. changing this alone does not save the change when hitting ok, nor does it activate the apply button. In order to save any change to this option you must change another option (changing it immediatly back is fine) so that it activates the apply button. Then modify the new option and hit apply and/or ok.

This saving issue also extends to the per-session on transfer complete. The setting here is not at all changable, clicking does nothing and it stays at whatever is set in global preferences. This makes it impossible to fully test the new feature. However from what i can at least try...

With both retry failed transfers and move to bottom of queue disabled, everything functions normally. Failed transfers are retried X times immediatly as per preferences.

With retry failed transfers enabled and move to bottom disabled, flashfxp function exactly as above. Failed transfers are retried X times immediatly as per preferences, then nothing more is done. The queue is not reset at completion and therefor failed transfers are not retried.

With retry failed transfers enabled and move to botton enabled. Upon the first failure the file is moved immediatly to the bottom of the queue as expected, once the other files are transfers (or also failed) and it reaches the previously moved files it then proceeds to try them again until it has satisfied the X retries as per preferences. In this case once somplete the queue is again not reset as would be expected per the retry failed transfers option being enabled, and therefor the queue is not retried (re-run).

Not much else i can try at this stage i think, maybe the option should be a little more informative though, such as including the word reset ie 'Reset and retry failed transfers.' just to help make the function a little clearer.

Same issue here as DC reported

Thats a good point I will rename the option "Reset and retry failed transfers" thank you.

I have fixed the issue where changing the setting doesn't activate "Apply", Since introducing the apply ability I keep forgetting to make sure new controls set the modification flag.

The global preference for "Reset and retry failed transfers" is only applied on startup the same way the On Transfer Complete options are set, Once the session has been started it must be changed per-session.

Also you must make sure you have the session option checked before you start the queue, as this value is stored locally when the queue is started so that it can be updated on reset without actually turning off the feature.

"Reset and retry failed transfers" only applies once to the queue, Otherwise there's a good chance of things being stuck in an endless loop.

Apart from the "apply" button not being activated everything else should work as intended in this release. I've been doing quite a bit of testing and so far I haven't run into any issues.

If there is an issue that I'm not seeing it in my tests please give me more information regarding the transfer failure errors.

This saving issue also extends to the per-session on transfer complete. The setting here is not at all changable, clicking does nothing and it stays at whatever is set in global preferences. This makes it impossible to fully test the new feature.

The global preference for "Reset and retry failed transfers" is only applied on startup the same way the On Transfer Complete options are set, Once the session has been started it must be changed per-session.

What i meant here is that the per session setting was not at all changable, even when queue is empty the per session setting stays stuck at whatever the global setting is. ie If global is off per-session can not be turned on. This is regardless of if there are any items in queue and if its actively transfering or not.

"Reset and retry failed transfers" only applies once to the queue, Otherwise there's a good chance of things being stuck in an endless loop.

As stated above, in my tests no reset and retry occured. It functioned exactly as if the option was disabled. Should it not continue through the queue until nothing is left (aside from the failed transfers), then reset the failed items and retry the queue once more (obviously only doing this once)?

With retry failed transfers enabled and move to botton enabled. Upon the first failure the file is moved immediatly to the bottom of the queue as expected, once the other files are transfers (or also failed) and it reaches the previously moved files it then proceeds to try them again until it has satisfied the X retries as per preferences. In this case once somplete the queue is again not reset as would be expected per the retry failed transfers option being enabled, and therefor the queue is not retried (re-run).

For the most part this functions as i would expect, except that (as above) when the queue is done and left with only failed items, i would expect this to be the time when the 'reset and retry failed transfers' would kick in, resetting the files and running the queue one last time. (when it does this is should function exactly as it usually would if it was a new queue, except that once done it would NOT repeat the reset and retry action). I am assuming the best way to avoid a loop in this case would be to use a flag in memory to is increased from 0 to 1 the first time is resets and retries the queue, then stays at 1 (disallowing the action to re-occur) until the queue is found to be completely empty then is clears or resets the flag back to 0 ready for any new queue.

In my tests i used a DrFPTd site and kicked a slave offline, this allowed me to control exactly which files would be failing and to accurately run the tests watching the way flashfxp functioned.

After further testing I discovered a small issue with the resetting the queue.

I will be posting a new build shorty.

Bug: When site manager is opened the SSH over FTP>Advanced tab is visible and on top (the tab botton is not visable, just the controls) even though the highlighted site is not of that type. It stays like this until you select a tab for yourself to force it to clear.

New features..

Global setting is fixed, this also seems to have resolved the inability to change the per session on transfer complete setting.

global off, session off, bottom of queue off
Flashfxp functions normally, retrying X times per preferences then marking failed, as expected.

global on, session off, bottom of queue off
Flashfxp functions normally, retrying X times per preferences then marking failed, as expected.

global off, session on, bottom of queue off
Flashfxp functions as expected, retrying X times per preferences then marking failed, continuing until the queue has finished, resetting the queue and retrying the failed transfers X times per preferences then ending.

global on, session on, bottom of queue off
Flashfxp function as expected, exactly as above.

global and/or session on, bottom of queue on
Flashfxp moves a failed item to the bottom after the first failure, then moves it to the bottom of the queue each time it failes cycling all failed transfer over and over until satisfying the X retries per preferences. I assume this is the desired behavior. (seems logicaly correct). Once complete the queue is reset and retried once as expected before ending.

global off, session on / global on, session off / global off, session off / etc... with bottom of queue on
All seem to function as would be expected, exactly as the first set of tests except that the files are moved around in the queue per the move failed transfers to the bottom of queue option.

Everything seems to be functioning correctly in this build as far as i can tell, except the site manager bug of corse.

Thanks for taking the time to test the new features, I appreciate it very much.

Regarding the site manager, sometimes if the design time layout isn't exactly the way it should be laid out this can occur, in my haste to get the new build out I left the wrong tab active during compile.

Typically this isn't a problem because when the site manager dialog is created I set the active tab, however it would appear that in your situation this doesn't remedy the problem.