A red cross appears next to my torrent currently being downloaded in BitComet. What is it? (Icons next to my task)
This red cross basically means that BitComet cannot continue downloading this torrent into your download directory because any of the following reasons:
This is not an exhaustive list of all the causes which might raise this error but of the most frequent. As a thumb rule, this error is related to disk writes mostly, so anything that prevented BitComet from writing to disk would bring up this error.
If the status light on the right hand lower corner of BitComet's window is yellow and the text next to it says “Blocked”, then inbound connections to your computer are being blocked. That means you can initiate and establish connections to other peers but others cannot establish connections to your client (well they can initiate them, but they won't reach you). This is usually caused by a software/hardware firewall or/and a NAT router (or any combination or those) sitting between you and the Internet.
Adding BitComet to your software firewall permits BitComet to send outgoing traffic (and replies to it) through the firewall to the Internet. That's necessary but it's only half of the job. You must also open your designated listen port on all of your firewalls, to permit new INCOMING traffic through. That's what we're concerned with now.
Having a firewall is a good thing since it protects you from the whole plethora of dangers lurking in the dark corners of the world-wide network. In fact you should never connect to the Internet without a working firewall; you'll most likely get infected in a matter of minutes. But in order to make BitComet work (or any BitTorrent client for that matter) you'll need to make some adjustments.
If you're reading this topic, I'm going to assume that you don't know very much about networking so let's get our hands dirty. First of all you have to determine what is blocking your incoming connections. In order to do that, first answer yourself this question: “Do I have a router?” Once you've answered that question you will know which guide(s) you need to read in order to solve your problem.
If you don't know the answer to that question then do this:
The goal of these guides is to help you open the listening port of BitComet for incoming connections. When you succeed in doing that you will get rid of the yellow status light and your client will be able to run at maximum speed. That is, assuming your client is properly configured as described in the BitComet settings guide.
Refer to solution 2 if solution 1 doesn't work.
A: If you use a router, follow the steps below. If you do not use a router, proceed to B.
B: If you use a software firewall, follow the steps below
For Windows Firewall only users:
If after all of this, and your issue still remains we suggest you upgrade to the last BitComet version.
Obviously, the best solution is to change your ISP as soon as possible! You do not want to waste $70 on some 20Mb connection, if you're now only using 2 gigabytes out of your 50 gigabyte download quota. Because simply, there are a lot of other ISPs in the market who care only about the money. You as a consumer pay them $$ and they will in return provide you their service.
Alternatively, if you're stuck on a contract with your ISP or do not wish to switch, try out our encryption technology:
You can enable this encryption protocol within Bitcomet by following these steps:
Our Recommendation is for the use of “Auto-detect” first; if you do not find any change in speed then use “Always”.
It should look like this:
or like this (in older versions):
Before getting into the actual methods of importing a download you need to acknowledge a fact first. Many BitTorrent clients have an option (enabled by default in many of them) to add an extension (specific to that particular client) to all unfinished files. (E.g. BitComet adds the .bc! extension, uTorrent adds the .!ut extension and so on.)
Starting with version 1.20, BitComet is able to automatically import unfinished downloads of the BitComet, uTorrent and Xunlei/Thunder clients, which have their client's specific extensions appended to the unfinished files. If you intend to import any downloads from these clients, which use their specific file extension, then use Method 2 from below.
However, if your files have appended a different extension which is belonging to another unsupported client, then you will have to remove the appended extensions first, before importing the downloads into BitComet.
This operation is not necessary anymore for v.1.23 and above as BitComet can now import unfinished downloads from any client. So, if you use v.1.23 or above, skip directly to "Method 2" below. If you're using a version prior to v.1.23 read further on.
If your torrent contains only 2-3 files you can easily do that manually. But if your torrent contains dozens or hundreds of files, then doing this manually would quickly become a REALLY tedious task and it would drive anyone insane. In order to avoid that you can download one of the many free utilities which allow you to change extensions for multiple files (such as Extension Renamer, Extension Changer, RenameIt, Renamer or use an Internet search to find a lot others) or use a batch script such as the one you can find here.
Once you got rid of the appended extensions or if your unfinished downloads didn't have any extensions appended (i.e. the previous client didn't have enabled the option to append an extension to unfinished files) you can use any of the below methods to import the downloads into BitComet.
You will need the exact same .torrent file in order to complete those unfinished downloaded files.
If you're one of those tidy persons who save all their torrents to some folder before opening them in their client then you shouldn't have much trouble finding the file.
If you were a little lazier but still have the previous client installed, you may still be in luck. Look into the folder where your other client stores the .torrent files and you may still find you .torrent file in there. Especially, if your task is still present in your other client, you should definitely be able to find the .torrent file in your clients settings folder, since no BitTorrent client can run a task without having the .torrent file for it. Due to the great variety of OS/client type combinations we cannot provide for every case the exact location where your client stores the .torrent files. But usually this is somewhere either in the program directory (under XP or earlier) or in the Documents and Settings (in Windows XP) or User folders (in Vista or later) buried somewhere in the %userprofile%\AppData\ folder.
If you're unlucky enough to have lost the .torrent file from your machine, you'll have to go back to the site where you downloaded it the first time, and download it again. But make sure you download the exact same torrent (i.e. the .torrent file with the same info-hash) or you won't be able to pick up your download where it was left.
Double-click the .torrent file (or drag and drop it on BitComet) and in the opening torrent properties dialog, choose the torrent's current download path to be the same as the path to the folder where your unfinished files reside (it's recommended to do a manual hash-check to ensure that BitComet acknowledges the already downloaded data, first). BitComet will start downloading from where the previous client left off.
Method 2: Starting with v.1.20 you are able to do this automatically through the File → Import Unfinished Download… menu for unfinished downloads of BitComet, µTorrent and Xunlei clients, so far. You can read detailed instructions on how to do that, here: Import Unfinished Download.
Note: If your unfinished downloads didn't have any extensions appended (i.e. the previous client wasn't set to append a specific extension to unfinished files) then you won't be able to always successfully import the downloads into BitComet by using Method 2 (i.e. for single-file torrents you won't be able to select the file and for both single and multi file torrents BitComet won't be able to automatically detect the location of the .torrent file). In this case it's recommended that you use Method 1 to import your downloads.
UPDATE: Starting with v.1.23 BitComet is capable of importing downloads from other clients as well (with specific extensions appended or with no extension appended). You'll have to choose All files in the drop-down box where you can choose the extension type, in the Import Unfinished Download dialog. The only difference will be that BitComet will not try to automatically locate the .torrent file, since it doesn't know the previous downloading application and therefore it has no way of knowing where the .torrent files for that application reside. Therefore you'll have to manually point it to the location of the .torrent file, by choosing Use specified .torrent in the importing dialog.
What's happening is that TCP packets are not being acknowledged. TCP is a two-way protocol, and every packet that is sent out into the chancy world of the Internet, requires an acknowledgment (ACK) from the receiver back to the sender, indicating that the packet was received.
If that ACK doesn't make it back, then the assumption is that the packet got lost or timed out, and the sender sends the same packet again (instead of sending the next packet). The sender will repeat this a few times, then eventually give up and close the connection because it thinks its packets aren't getting through.
Why would this happen? It's because those ACK's from your applications are upstream traffic, using your upload (not download) bandwidth. BitComet is also using upload bandwidth, not just for its own ACK's, but also to send pieces you've already received, to others. If all of this upstream traffic exceeds your upstream bandwidth, then packets have to wait in a queue for their turn to be sent.
If the wait is too long, packets begin expiring (all packets have a maximum time-to-live) before they can make it to their destinations. ACK's aren't being received. The servers your applications connect with, are sending the last packet (which you already got), and still not getting the ACK for that packet. To you, this looks like the application slowed down or stalled – it keeps getting packets that it has already received instead of getting the next one.
But I have a 10Mb connection!! BitComet shows my speed is much less than that! How can this happen?!?
Most ISP's only talk about the downstream speed of the connection – they usually don't even mention the upstream speed, or bury it in the fine print. But that oft-forgotten “A” in ADSL means “asymmetric” – it's not as fast upstream, as it is downstream. Fast upstream pipelines are expen$ive. Your upstream speed is usually a lot less than your downstream speed. You may have 10 megabits per second downstream, but only 250 kilobits per second upstream. It's your upstream bandwidth that is the choke point.
Then what can I do about it?
You can and must impose an upper limit on the global upload bandwidth that BitComet is allowed to use. The limit must be large enough to permit good upload speed for each task you are running, yet small enough that other applications have enough bandwidth to get their jobs done.
Practically, this means you must find out what your actual upstream bandwidth is, and then set your Global Maximum Upload Bandwidth in BC to about 80% of that maximum. (Don't rely on what your internet service provider told you your speed was: test it, with nothing else using any part of it, at speedtest.net or a service fairly nearby, and do it at different times of day and night on different days, to get a reliable average value.) You will need to make sure you transform Kb in KB (a division by 8 will pretty much cover it), then multiply it with 0.8 and input the result on the BitComet Options --> Connection page, in the “Global Max Upload Rate” box.
When you aren't using any other applications, you still can't leave your GMUB unlimited, because BitComet will even interfere with itself, dropping packets in the same way. You can increase the rate, but remember to decrease it again when you want to do other things.
Can't I just set my global maximum upload bandwidth to zero and avoid all this?
But try it, don't just take our word for it. This is a useful thing to understand clearly. Set yours to zero. (First make sure that “0” does not mean “unlimited” to your client. If that's the case, just set it to 1, so it's very low.)
Now let the client run for about 15-20 minutes, then check it again. Notice that the your client stopped downloading – your download speed has dropped to zero? The reason for that is that you must give to get, and if you are a slow or unreliable peer, most other peers will chose not to offer you anything since they can't get anything from you. (What you receive, someone must, obviously, have sent to you.)
Setting your global maximum upload bandwidth very low means you effectively won't be downloading anything before next Kwanza. Set your GMUB back to the 80% that we recommend, then shut down and restart BitComet, and your speed will come back to normal. (“Now calmly think about supposed leechers for a few moments, and you will be enlightened, Chinchbug”.)
A little theory first.
All BitTorrent clients, by the design of the BitTorrent protocol, work by opening simultaneous connections to a very high number of peers. BitComet is no exception from this axiom.
This very high number of simultaneous connections to different IP addresses, will have to be handled by your system and your networking equipment (modem, router). That is to say, BitTorrent clients place a higher stress on certain components (software and hardware) both in your system and in the devices connecting you to the Internet.
While this is no bad thing in itself, if often may bring to surface hardware or software limitations, flaws or conflicts which otherwise don't manifest themselves and rest unbeknown to the user.
This is one such example.
The main issue here, is related to a technology employed by your router/modem, called NAT (Network Address Translation). In short, what this does for you is allowing you to use multiple devices in your personal home LAN (Local Area Network), while having/paying only for one single public IP address to connect to the global network known as the Internet.
NAT does this by translating the private IP addresses used by the devices in your LAN (PCs, servers, etc.) to the public IP address (which your ISP assigns to you), for all the outgoing traffic of your network, and vice-verse, translating the public IP to the private IP addresses each device on your LAN uses, for all incoming traffic going to any of your local devices.
It doesn't matter if you have only one PC connected to the router, it doesn't care about that. As long as NAT is enabled it will do it's job and translate addresses.
The NAT process does that by using a NAT session table which keeps tabs of which port is mapped to which local IP address, so that it may forward incoming reply traffic to the proper local device on the LAN.
As you may have guessed, this NAT table is hosted into the router's memory and as we all know, memory is a limited and expensive resource. Depending on the brand and the model of your router/modem, your equipment will be able to hold various maximum numbers of simultaneous entries depending on the amount of memory allotted to it.
While better equipments have no problem in handling the great number of connections initiated by a BitTorrent client, others do. This isn't to say that the respective device is a bad one per se (it will probably work OK in most other situations), it's just not fit for handling BitTorrent traffic.
To make a long story short, when this issue occurs the NAT table becomes filled up with entries, while your BitComet client is running, and can't handle any more new connections.
While some better routers (of the lot of those who can't support too many connections) handle this situation gracefully by dropping outgoing packets for new connections, until such time an entry times out in the NAT table, other worse equipments stutter and crash or entirely freeze into a state where they may need a manual reboot, to get back on feet.
On top of that running BitTorrent client may keep initiating many new connections for a long time (especially when downloading) therefore even if your device doesn't crash, you may experience a total inability to access the Internet with any other application, or from other computers in your LAN (however this effect may have also a different cause; see the previous topic for details on that).
What can you do to fix this?
The first and best option would be to find an equipment which doesn't have this limitation (buy, trade or swap your actual one for it).
If that's is not an option for you at present time, then there are some measures you could try to contain this.
An option in BitComet, that you can use to contain this effect, is network.max_udp_pkt_per_sec which will limit the maximum number of UDP datagrams which BitComet may send per second. Setting this value to a conservative value, such as 5 will limit the max number of new entries which BitComet can create through UDP, in the NAT table of your router, to 300 new entries per minute. Summed with the 200 you set for TCP, this will give a max number of 500 entries BitComet can place any minute in the NAT table, on behalf of outgoing traffic.
If the above settings work for you, then you should start to gradually increase the values until you find some values which make the issue re-appear and then stay below that threshold. For instance, you may try to first increase the number of TCP connections, by a increment of 50 or even lower and then test your router for a while and see how it works. Do this until you get to a value of 500-800 and if nothing goes wrong stop there.
Then, once you found a number of TCP connections where your router is stable you can start increasing the number of UDP packets per second, by small increments of 5 or lower and again test your router. Once you've found a value which makes your router crash/freeze, go back a couple of increments and let the option set at that value, to keep yourself in the safe zone.
If on the contrary, the above said settings don't work for you, you may try even more conservative settings or you may consider even disabling DHT altogether, to alleviate this problem.
There is no built-in, program-imposed limit. BitComet has been tested and will work for over one hundred simultaneous seeding tasks.
There IS a limit imposed by the bandwidth of your connection, particularly the upstream side of it. (See the answer to the question above). If any task is starving for upstream bandwidth, then you will find few or no peers willing to transfer to or from you. (They may CONNECT to you, but this is simply to see what you're offering and is not the same as actually transferring any pieces to/from you.) Generally, all of your tasks should receive a bare minimum of 8 Kilobytes per second of upload bandwidth. Any less, and running that task is essentially a waste of your time. It should be as much above 8 as you can manage. If you have any tasks that routinely drop below this, you are trying to run too many.
For most people, most typical home broadband connections, start with one downloading and one seeding task, and let them stabilize. Most connections can't handle any more than these two. Try adding one more task and let it stabilize. If any tasks drop below the limit you've chosen (remember, higher than 8), then that's one task too many. The more upstream you give to any task, the better the performance is going to be. (It's going to download faster.)
You can change the maximum number of concurrent downloading tasks in the Options → Task → Task Schedule.
Please read the video download instructions for details.
A little introduction:
BitComet writes its Task List (whenever there is a change in the task list or when it exits) into a file named downloads.xml located in one of several places. (Which place, depends on the version of BitComet and your operating system.)
Under versions prior to 1.17, BitComet stored its task list (and all of its settings) in the
directory, under Windows XP and earlier Windows versions, or
folder in Windows Vista or later
(Users\%userprofile%\AppData\Local\VirtualStore\Program Files (x86)\BitComet for 64bit versions).
Please note that for some older versions of BitComet, if you disable the UAC feature and therefore Windows' data virtualization feature, your client will write/read in the actual Program Files folder, which may lead to issues like an empty or old Task List when turning UAC back on.
Windows Vista and later versions deprecate storing information in that tree (i.e. relying on data virtualization feature of Windows), and the storage place preferred by BitComet for configuration data is now (starting with v.1.18):
C:\Documents & Settings\%userprofile%\Application Data\BitComet
under Windows XP or
C:\Users\%userprofile%\AppData\Local\BitComet (depending on the value of the %AppData% environment variable)
under Windows Vista or later.
Therefore, starting with version 1.18 you may also find this file along with all the other configuration files in the Application Data\BitComet (Windows XP) or in the AppData\Roaming\BitComet (Windows Vista or later) folder alternatively to the Program Files folder.
But this should happen only for clean installations of BitComet; for upgrades over an existing version the default behavior of the client is to seek the configuration files and use the previous location for further storing them. For more detailed info on the conditions when this happens see this topic.
Also, starting with v.1.18 BitComet saves up to 7 successive copies of the downloads.xml.bak file (in the form downloads.xml.yyyymmdd.bak, where yyyymmdd = year, month, day when the file was saved) thus making the recovery of a lost tasklist as easy as removing the .yyyymmdd.bak part from any of the backup files present in the same folder.
(Now, be sensible about this. If this is a new installation, yes, of course the files will be in those locations. But if this is an UPGRADE – you've been running BitComet for a long time and your previous operating system was (or still is) XP, then all the configuration files could still be in the OLD location*. When you install a new version of BC over the old version, it keeps all of the old settings including this one. )
When BC starts up again it tries to read this file and loads the tasklist from downloads.xml, using the torrent copies that it keeps in the \Torrents folder, also off of the program directory.
Anything that interferes with any part of the whole write-read sequence, will generate these kinds of problems.
If the file can't be written, then old, deleted tasks will still be in it and also the newly added ones won't be added in it. If it's missing or empty then BC can't read what isn't there. If the file is set to “read-only”, then BC can't update it, so when it reads the file at restart it gets an old version of the list – tasks added since won't be there and old tasks still will be – none of the changes either way, got saved. If your system or BitComet crashes before writing into the file, any changes made to it will be lost or the entire file may become corrupted. Sometimes, even a version update may result in a missing tasks file. Also, a Windows upgrade may often result in problems with the tasks file, due to the data virtualization feature of the newer operating systems.
This is why it's always a good idea to back up your tasklist before performing any upgrades to your client or your Windows installation, especially when using BitComet versions prior to v.1.18. See how to do that, at the end of this topic.
Also, if you've deleted a torrent from the \Torrents folder, BC hasn't got a task to actually start. If BC is running under an account that lacks permission to do any of these things, there can be problems. If the account that BC runs under has CHANGED since last time, there can be permission problems.
Therefore, if you haven't done any upgrades of your client or Windows OS then always first:
Ways to recover the tasklist:
Do not add or delete any tasks. Doing that WILL make method #2 below, useless (for reasons we trust are obvious), and it will interfere with the others;
If you don't fix the file-writing problem, this will happen again next time you restart.
Tip: If this (your permissions on the file change) happens frequently, you are recommended to update your BitComet to the latest version or manually backup the tasklist as a precautionary measure. But as a definitive fix, you should make sure that nothing interferes with BitComet's writing permissions on the file.
In order to avoid further nuisances related to recovering the tasklist in BitComet, it is highly recommended that you upgrade your client to a version later than v.1.17. Since, starting with v.1.18 BitComet saves up to 7 chronologically sequential backup files of downloads.xml, recovering the tasklist in case of loss is much easier for these versions.
*If you're upgrading from an older version to a newer one and all your tasks/settings vanish – if you've been caught by the store-in-programfiles vs store-in-appdata issue that was mentioned above, then you'll need to copy the files from the “program files” location to the “application data” location. Make sure BC is stopped. Copy all of the files of type “.xml” from the one to the other.
(If you don't know what that means, then you should copy all of the contents of one to the other, and then reinstall the version of BitComet that you just installed, again. But you really should learn what it means and do that.)
How to manually backup the tasklist
Go to Main Menu Bar→ File→ Import and Export Download List. Export the tasklist (and optionally, global program settings) into a .bc_bak file (these are back-up files). If your tasklist has disappeared when you restarted your BitComet, then do the following: go to Main Menu Bar→ File→ Import and Export Download List, then import the .bc_bak file you exported previously.
This might be easier observed when you have no tasks running or you have a single task running in BitComet.
The usual places where one can observe this different speeds, are: BitComet's title bar, Floating Window and the Statistics tab. If you have no tasks running and still, you can see some small traffic reported in these areas, then it means that you are seeing numbers which account for the overhead protocol traffic which BitComet uses for operating (i.e. TCP, BitTorrent, HTTP, FTP, DHT).
If you see higher upload speeds and still have no tasks running or you do have something running but the speeds you see for your task(s) in the Task List pane are different from the ones you can see in the other areas, then you should know that the upload speeds reported in the Task List pane are just those used for BitTorrent uploading. In the rest of the areas, BitComet adds to those speeds the LT-Seeding speeds as well (and the overhead traffic). Therefore the total speeds you will see might differ more or less from the sum of the speeds of all tasks in the Task List pane.
This problem has been fixed since version 1.22, if you prefer using an older version but experience this problem, please then read the following instructions:
First of all, go into the options and look at the Advanced tab. Check down near the bottom for a parameter, “system.use_app_data”. If this is set to “True”, then files like downloads.xml will be stored in your %appdata% directory. If it's set to “False”, then they'll be stored in the application directory under Program Files.
So if this switch is set to “False”, you might want to just set it to “True”, then try again and see if the problem's now solved.
If it's not then recheck the %appdata% permissions – often you need to check all the permissions for the entire tree and every node in it. The account you usually run BitComet under - normally your own - should own the directory and files, and have full control of both.
If you wish to move all your tasks (active and/or stopped) to a new computer and hence to a new installation of BitComet you will have to follow a few easy steps: