First, remember that any cipher must be functionally correct, that is for any valid plaintext $$\operatorname{Dec}_k(\operatorname{Enc}_k(m))=m$$
This effectively means you must be able to properly decrypt any properly encrypted message. This also means that it cannot happen that $m_1\neq m_2$ with $\operatorname{Enc}_k(m_1)=\operatorname{Enc}_k(m_2)$ can happen. After all, how would you decrypt the result deterministically? To $m_1$ or to $m_2$? You can't decide, thus such a scheme would violate funtional correctness and thus this situation can't happen. Now Blowfish is functionally correct and as per the above argument you'll never see any collisions under the same key. Also you're using ECB where each block is encrypted individually meaning the above argument also applies to longer messages.
With CBC the situation is different, you encrypt as $c_{n}=\operatorname{Enc}(m_n\oplus c_{n-1})$ (where $\oplus$ denotes bitwise XOR). Which means if you find any two $(m_1,c_0),(m_2,c_1)$ such that $m_1\oplus c_0=m_2\oplus c_1$ you've got two resulting cipher texts looking the same (ie a "collision"). Note that $c_0,c_1$ are essentially random, and they're being combined with an unrelated value meaning the result will be essentially random again and you expect a collision among two random strings of length $l$ after $2^{l/2}$ samples.
One final note: If you're trying to use ECB for production, chances are you have the wrong mode. If you need something with random-access and no overhead, use AES-XTS, if you need something with random-access and authentication, chunk it with AES-GCM and in any other case just use (chunked) AES-GCM because it also takes care of authentication for you and will be much faster than Blowfish-ECB if your CPU supports AES-NI.