Here is the actual call I'm making:īitcomet -url=NAME.torrent -silent -tray It will check my email account reguarly for an email with a certain subject and download the torrents whose URLs I've embedded in the email body.įor the downloading part, I've decided to programmatically call windows' cmd.exe (the command prompt) and execute BitComet.exe with certain parameters. I'm attempting to create a Windows service which will essentially allow me to start torrent downloads on my home PC remotely. It could well be giving you a false report as in my case. In light of this it is my opinion that the code change to bitcomet such that the green light comes on once a single remote connection is established was a bad idea. It seems that Mcafee was blocking the majority of inbound connections but the "odd" one would get through thus triggering the green light. I then contacted Mcafee support whom I found to be excellent via online chat but it took them over 2 hours (many reinstalls reboots etc) but eventually they came up trumps and all is 100% Investigation proved this to be my firewall (Mcafee in my case) simply proved by complete removal of Mcafee, just turning the firewall off was not effective. Then, after a random time interval (could be a few seconds or several hours) the green light would turn on but I was still seeing poor speeds and very few remote connections. upon starting bitcomet I would have a blocked port indication and only local connections. If I remember correctly, Bitcomet code was adjusted such that once a remote connection was established the green light would be turned on. The problem was that users were reporting a blocked listen port indication yet were still achieving remote connections. This relates to a change made to bitcomet some time ago.
0 kommentar(er)
