(Note: I wrote the FTP server software here and have access to the raw server logs of what happened)
The issue here is rather simple, when you attempted the SIZE command in Filezilla, you were in binary transfer mode. When you attempted to run this command via your client (or after Filezilla reconnected), you were in ASCII transfer mode.
Looking at the actual access logs, it seems that on the initial connection, Filezilla executes 'TYPE I' followed by 'MLSD'. When it reconnects afterwards, it doesn't attempt the MLSD command again, so it doesn't bother to execute 'TYPE I'.
Computing the actual file size in ASCII mode is fairly resource intensive (especially considering that your code by nature is going to attempt this command quite frequently). It requires that we parse the entire file and replace all the line ending characters. This not something that we'd want to do all the time on a busy FTP server.
This behavior is actually accounted for by the RFC:
The presence of the 550 error response to a SIZE command MUST NOT be taken by the client as an indication that the file cannot be transferred in the current MODE and TYPE. A server may generate this error for other reasons -- for instance if the processing overhead is considered too great.
In ASCII mode:
ncftp / > quote size games_mp.log
> quote size games_mp.log
Cmd: size games_mp.log
550: SIZE not allowed in ASCII mode.
SIZE not allowed in ASCII mode.
In BINARY mode:
ncftp / > quote size games_mp.log
> quote size games_mp.log
Cmd: size games_mp.log
213: 134901
134901
So, your actual fix here would be to switch to binary mode before you try and get the file size.
We'd also greatly prefer that you change the password on your account. We've seen significant abuse from open FTP accounts in the past (some people feel the need to fill up any FTP account they find with various types of pirated content).