The rest of the messages, including the very similar UploadFailed, all use the masked filename. The first step is to get these transfers to explicitly fail when UploadDenied is sent, then see if this odd behavior still exists. I suspect that what is happening is that the remote client is sending a transfer response that indicates we are good to go, but then immediately fails because it can't open the file, sends UploadDenied, and then somehow doesn't clean up the transfer connection, or potentially doesn't cancel the connection or prevent Soulseek.NET from proceeding to establish it. Soulseek.NET improperly handles UploadDenied somehow, and fails to abort the transferĪ bunch of odd stuff happens simultaneously after the connection attempt times out, and the logs suggest that a transfer connection was established and seeked to the starting offset of the file.
#Soulseekqt port closed download
I've been able to reproduce the problem by removing a file from a share configured in Soulseek Qt and trying to download it.
Troubleshooting failed downloads from a user this morning, I stumbled upon some odd behavior that is definitely a bug, but that I also don't understand.
0 kommentar(er)
