hi nick, I would like to try to reproduce this on my side. Is your RPi connected via cable or wifi? Is your Windows 8.1 connected via cable or wifi? If one of them are connected via wifi, whats your Brand/Model from your Access Point? Heinz
I did have similar networking issues on earlier versions of recalbox, and later I found out that the problem was caused by the default extreme overclock settings. So when I want to transfer files I set it to High or Turbo, when I want to play I switch it back to extreme. hope that may help.
Thanks for your responses. I'm using a RPi2 which is not overclocked. The issue happens no matter if I use an Ethernet cable or WiFi on the RPi2. The PC (Windows 8.1 Pro x64) is connected via Ethernet to my router (Virgin Media Superhub) which is set to default settings. The only thing I have not tried is: 1) My other computer with Windows 7 x32 2) Use Wireless on my Windows 8.1 It would be great to have the ability to FTP files to the shared folder but this only happens with large files. Is the default option to 'extreme overclock' on the RPi2? How do I change or check this?
I would be cool if you could try under Win7. I tried to change the samba config in last release, but i didn't change anything if you still have this issue.
Tried under Windows 7 x32 and it's actually worse in my case. http://www.mediafire.com/view/f2c72sbugm2cfc1/Capture3.PNG Does the same thing but clicking on retry doesn't do anything and cancel then deletes the file. I suspect therefore the reason why the file doesn't play with when transferred with Windows 8 is because it's incomplete somehow. I dragged out my ancient Powerbook G4 and tried that and it works fine. My conclusion so far is that the issue is specifically with transferring large files from Windows to Linux. I'm wondering if there is some kind of file checking setting in Windows that needs disabling. 
I see this also on my infrastructure. but it looks more that it has a timeout before it begins to transfer.... I first thought it was not working, but after some "time" it was copied. Could also be that the client tries to do something that's not implemented on the other side and after an amount of time it uses an kind of backward compatiblity mode to do this transfer.
It turns out that a faster memory card works a lot better. My older memory card transfers less than 10MBs so appears to be saturated somehow so Windows thinks it's not responding. Not sure why I get different results when using Linux/Android/Mac. Recommendation: Don't use older cards if you are wanting to transfer large files.
Sorry to hijack an old thread, but I'm also exhibiting this issue, Windows 8.1 Enterprise. Also a mate of mine has reported the same thing. Small files are fine, but once they get large, say 500mb plus, they stall. Both of us are using RPI2+ with brand new class 10 cards. I recall seeing this on Linux before, something to do with SMB2 and perhaps signing. I'll report back if I can dig up the info I'm thinking of.
have you tried to transfer using winscp?
Well, I've been mucking with smb config files and windows registry time out settings, with no luck. Looks like scp is the way to go for now. Heaps of reported cases with it being solved with disabling signing (windows) or disabling oplocks (Linux) but nothing works for me
I think this should be added as a bug too.
It works for me with richcopy. https://technet.microsoft.com/de-de/magazine/2009.04.utilityspotlight(en-us).aspx
It turns out that a faster memory card works a lot better. My older memory card transfers less than 10MBs so appears to be saturated somehow so Windows thinks it's not responding. Not sure why I get different results when using Linux/Android/Mac. Recommendation: Don't use older cards if you are wanting to transfer large files.
