xfer queue fails

Version 2 RC2 (build 862) on intel platform running XP Pro

the error displayed is "Error: "xxx.xxx.xxx.xxx" not found in Site Manager

Of course a valid IP is displayed.

This happens during an existing queue xfer and the remaining xfers are aborted.

That particular FlashFXP session will not reconnect to the given IP, EVER! If you open another instance of FlashFXP you can reconnect to that IP.

Sorry if this is a repeat bug.

[DYN_DaTa]

Before reporting a bug make sure that you're using the latest version (actually it's build 869).

[bigstar]

Please keep in mind only registered users can upgrade to the latest release. Non-registered users are stuck using the last public release. which in this case is build 862.

This is very unusual starting with RC2, FlashFXP only validates the first item in a series of files from the same site.

Once the site information is cached it can always access it via memory and it doesn't have to validate that it still exists. Even if it doesn't exist it can still read it from memory.

That being said I have no explaination for your problem, I have double and triple checked the code and I performed several tests, I was unable to reproduce the problem.

If there is anymore information you can provide that might be useful please do.

well yes...there is more inform, but mostly speculation...

It seems as if the IP for the queue is placed in a memory stack somewhere with the IPs for the Site Manager and each time another file from the queue needs to be transferred the IP is retrieved from the stack space.
However, the stack space is very limited AND shared with any other instances (open sessions) of FlashFXP. Further...it seems as if it's position in the stack is static (chronilogical), meaning it's use does NOT refresh it's position in the stack. Other (manually entered) IP entries (from other FlashFXP sessions) simply push it out the bottom of the stack. Once gone the IP pointer and THE QUEUE become invalid.

Just a guess, but thats what seems like is happening?!

[bigstar]

The quick connect history will keep track of the last 50 connections, If a queue is made and then later restored there is no guarantee that the site information will still be available. In order to permanently keep a site you need to specifically add it to the site manager.

50 is the default value which can be changed via an INI setting, for details please refer to the FAQ section of the msg board.

are you saying that if 50 'other' attempt to login to sites occur before a queue has completed, the queue will fail?

should not the IP be refreshed back to a higher position in the list when re-accessed?

[bigstar]

I am not quite sure I understand your terminology.

If the queue is already in progress then it's irrelevant because the host information is already known.

When you connect via the quick connect the new entry is added and if the total number of sites in history is greater than 50 then the oldest one is removed.

If you reconnect to a site in your quick connect history it's position updated.

Yes, you are mis-understanding.

Let me use an example.
And let us assume your 'last 50 connections' suspections are correct.

to simplify the example let reduce the '50' count to '5'

I will connect to 100.100.100.1 and queue 10 files.
each file will take 10 minutes to xfer.

I open another instance of FlashFXP and connect to 100.100.100.2

Meanwhile file 2 begins it's xfer from 100.100.100.1

I disconnect from 100.100.100.2 and connect to 100.100.100.3 and queue 10 different files with the second instance of FlashFXP. Same size and xfer rate.

Meanwhile file 3 begins it's xfer from 100.100.100.1

I open a third instance of FlashFXP and connect to 100.100.100.4, disconnect and connect to 100.100.100.5
I queue up 3 more files (same size and xfer rate).

I open a forth instance and connect to 100.100.100.6.
As I am browsing the directory of this site, third file completes it's xfer from 100.100.100.1 and here is what appears in the status window of the first FlashFXP instance.......

226 Transfer complete.
Transferred: 1. File03.rar 15,000,000 bytes in 10:01 (24.97 KBps)
Error: "100.100.100.1 " not found in Site Manager
Error: "100.100.100.1 " not found in Site Manager
Error: "100.100.100.1 " not found in Site Manager
Error: "100.100.100.1 " not found in Site Manager
Error: "100.100.100.1 " not found in Site Manager
Error: "100.100.100.1 " not found in Site Manager
Error: "100.100.100.1 " not found in Site Manager
Transfer queue completed

The remain seven files are now mark failed.

The following anomolies occur...
1. If you reset failed queue entries and restart the xfer, you will immediately receive the 'not found' error above for the remain entries.
2. If you manually connect back to the site with 'Quick Connect' and then reset failed queue entries and restart the xfer, you will immediately receive the 'not found' error above for the remain entries.
3. If you manually connect back to the site with 'Quick Connect' and then clear the queue and 're-tag' the previously untransfered files and start the xfer, you will immediately receive the 'not found' error above for all entries.


You can connect and xfer to any other site from this FlashFXP instance but this instance FlashFXP will not xfer any file from 100.100.100.1

But now that the first instance of FlashFXP has connected to 100.100.100.8 (after briefly connecting to 100.100.100.7) the second instance of FlashFXP is finishing the xfer of file 4 and fails when attempting begin the xfer of file 5 with the same failure.....

226 Transfer complete.
Transferred: 1. File04.rar 15,000,000 bytes in 9:57 (25.17 KBps)
Error: "100.100.100.3" not found in Site Manager
Error: "100.100.100.3" not found in Site Manager
Error: "100.100.100.3" not found in Site Manager
Error: "100.100.100.3" not found in Site Manager
Error: "100.100.100.3" not found in Site Manager
Transfer queue completed

Now here's a neat anomoly....
If I clear the queue on the second instance of FlashFXP (the one that just failed file xfer from 100.100.100.3) and have it connect to 100.100.100.1 (that's the IP that the first instance of FlashFXP won't xfer files from) I can queue up and xfer files from it?!
NOW
If I return to first instance of FlashFXP, I will be able to xfer the previously failed files. But only after refreshing the IP from another instance of FlashFXP.

This is a hard bug (repeatable) and 'will' happen every time.

Although, I am not sure of the 'count'. If you say it is 50, then maybe it is fifty. It does take a while!

I hope this zeroes you in on the problem

[bigstar]

I did some research and your build functions differently then the latest build. I was under the impression that the changes I made were in the public RC2 release and I was wrong. In your RC2 build the information is not cached and that is why it causes such a big problem. However

1. If you reset failed queue entries and restart the xfer, you will immediately receive the 'not found' error above for the remain entries.
2. If you manually connect back to the site with 'Quick Connect' and then reset failed queue entries and restart the xfer, you will immediately receive the 'not found' error above for the remain entries.
3. If you manually connect back to the site with 'Quick Connect' and then clear the queue and 're-tag' the previously untransfered files and start the xfer, you will immediately receive the 'not found' error above for all entries.

1. Even with the information being cached you will still encounter this type of problem on reconnect. cache is only valid while connected.

2. It fails because the magic number association is different, the newly recreated quick connect entry doesn't match the previously queued files.

3. This seems a bit unusual and I will need to look into this situation.


As for the over-all big picture, It sounds like the Quick Connect simply doesn't meet your needs. I highly recommend you use the Site Manager for these type of situations.

I don't know if this would be a true statement??

As for the over-all big picture, It sounds like the Quick Connect simply doesn't meet your needs.

Since a quick look at the properties for each of the queued items ('EDIT') does show that all of the necessary information to process the xfer is available (except 'maybe' the port#).

I would simply expect it to work? (using the info available!)

I mean if your going to take the time to write code to cache the information (and make it editable), USE IT. Don't make it's validity denpendent upon some 'magic number' that can and will disappear.

Please don't take this the wrong way. Your product is great.

[bigstar]

The site information you are referring to is not cached and is not part of the queue, it is loaded directly from the Quick Connect History.