A free C++ BitTorrent/HTTP/FTP Download Client

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:

1. You are trying to download a file over 4G to a FAT32 disk drive.
2. There is insufficient space on the drive where your Download Directory resides, to save the file(s) you are trying to download.
3. The .torrent file you are trying to download from “Torrent Collection” is not available now. (If the client which shared this torrent has disconnected, and no other sharer has this torrent.)
4. The .torrent file for the task was deleted from the Torrents folder of BitComet.
5. BitComet can't find the download path (e.g. the download folder was on an external drive).
6. The path to the torrent task's file(s) contains illegal characters (i.e the torrent was created under Macintosh or *nix).
7. You have two or more torrent tasks running, which are trying to write in the same directory a file with the same filename.
8. BitComet can't write to the download folder (e.g. it's running under an account without writing permissions or permissions have been changed).
9. The file(s)/folder BitComet is trying to write into, is read-only.
10. The file is locked by another application/process.
11. The Download Directory for your BitComet client may be corrupt or your hard disk has suffered a hardware failure resulting in bad sectors which cause write-check to fail.

Solution:

1. This is due to FAT32 limitations (the largest single file can only be 4G), you can convert to NTFS disk format and then re-download or change destination to another NTFS disk drive.
2. Increase the free space available for BitComet's Download directory by deleting files/folders you no longer require. Or change your Download location to a disk drive/partition with more free space.
3. Read about Torrent Exchange.
4. Switch to Torrent History (Torrent Archive in v.1.16 or older) and look in the list for the torrent with the same name as your task. If you find it, delete the task from the tasklist without deleting the files, too. Double click the torrent and re-add the task into the tasklist. If you don't find it in the Torrent History (Torrent Archive in v.1.16 or older) you'll still have to delete the task (without deleting files) but you'll have to go to the source where you got the .torrent file in the first place and re-download it (make sure it's the exact same file not one with a similar name). Add it into BitComet and make sure that you select the same folder where your unfinished files are; you'll get a prompt warning you that there are already some unfinished files in there. Confirm the choice; it will hash-check and pick up where it has left.
5. If you use an external drive for the download folder, make sure it's connected and that it's got assigned the same drive letter. Make sure that Windows recognizes and assigns a drive letter to the hard drive partition where the download folder resides. Make sure the partition was not hidden by some other application. If it was a mounted partition make sure it is still mounted. If it was a mapped network drive make sure the mapping is permanent.
6. Use an application for invalid filenames renaming, such as MacNames, to rename the file/folder.
7. Stop the running tasks and change the download directory for any of the tasks, to another folder.
8. Make sure BitComet has writing permissions on the download folder.
9. Make sure the torrent's folder/file(s) is not read-only before starting the task again.
10. Close the application/process that is using the file. If you don't know which one is that, you can use a tool like Unlocker or Process Explorer to find out the locking process and close the handle for that file or kill the locking process.
11. Change download directory to another folder, run a file system check and make sure your hardware works fine.

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:

• press the “Start” button on the Windows taskbar and choose the “Run” command. Alternatively, you can press: .
• type cmd in the box and hit Enter;
• at the command prompt type ipconfig; you will get a result like the following:

• if the IP Address and the Default Gateway are identical then you do not use a router and you can go to the Create Firewall Rules guide;
• if the IP Address and Default Gateway are not identical then you may have a router standing between you and your ISP and therefore besides the guide for creating firewall rules you'll also have to follow the instructions of the Add Port Mapping in NAT Router guide.

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.

What is DHT and how can I enable DHT network?

Solution 1

• Open BitComet, click Options → Advanced → Connection → UNCHECK Enable DHT Network → Click OK
• Close BitComet to allow saved changes to take place.
• Reboot PC if possible.
• Open BitComet, click Options → Advanced → Connection → CHECK Enable DHT Network → Click OK
• Look at the status of the DHT network at the bottom right hand corner.

Refer to solution 2 if solution 1 doesn't work.

Solution 2

A: If you use a router, follow the steps below. If you do not use a router, proceed to B.

• Open your Router Webpage (e.g. 192.168.2.1)
• Open the Router Page which controls all the forwarding of Ports.
• Next, create a new rule, for a UDP Virtual Server type entry. (In other words, in addition to the TCP Portforwarding done for BitComet, you will need to create an EXACT replica of that rule, except it isn't TCP, but UDP)
• Ensure that the UDP Port is exactly the same as your TCP Port. (TCP & UDP Ports should be exactly identical to BitComet's Listening Port.
• Continue on to B if you use a Firewall in addition to your Router.

B: If you use a software firewall, follow the steps below

• Open your firewall's Program Configuration/Control. This is where your firewall controls which applications are allowed to access your network and/or Internet.
• Locate BitComet.exe (by default: C: Program Files/Bitcomet/bitcomet.exe).
• Add it into your firewall's exception rules. Also, if your firewall also controls the 'ports' used by a program, locate UDP type.
• Add in exactly the same port used as in your listening port. (Once again, this should also be the same as your TCP Port).
• Make sure your firewall rule updates for use with new versions when you update BitComet. Better firewalls such as McAfee do this automatically.

For Windows Firewall only users:

• People who use Windows XP SP-2 firewall need to make sure exceptions are allowed.
• BitComet will add the ports for you when the following setting “Enable NAT/Firewall Configuration in ICS/ICF (XP only)” is turned on in Options > Connections.
• Windows Vista users need too, the above rule turned on as well as the “Remove Port on NAT/Firewall (XP only)” rule located two settings below.

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:

• Open BitComet (ensure that its not an old version like 0.60 or below) and go to: Options → Task → BitTorrent (or Options → Advanced → Connection in older versions);
• Locate “Protocol Encryption” Here you can choose between “Auto-detect” or “Always”. “Always” is a safer option for users who are fully aware that their under ISP throttling. For those who aren't sure, use “Auto-detect” first, this allows your client to receive more connections, but may lead to lower encryption.

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.
<html><span style=color:teal;font-weight:bold>Note:</span></html>

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.

Method 1: 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.

<html><span style=color:teal;font-weight:bold>Note:</span></html> 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.
<html><span style=color:teal;font-weight:bold>UPDATE:</span></html> 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.
<html><br /></html>

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.
<html><br /></html>

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.
<html><br /></html>

Can't I just set my global maximum upload bandwidth to zero and avoid all this?

No.

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.

1. If you have LT-Seeding enabled in your client, make sure that you go to Options-->Advanced and change the value of the bittorrent.connection_ltseed_protocol_selection option to 0 instead of the default 2. This will force BitComet to use only TCP as a transport protocol for LT-Seeding connections.
   
2. Next, set the network.max_connections option to a conservative value such as 200, for starters. This will limit the number of simultaneous TCP connections maintained by BitComet, to whatever value you set for this option, and in turn reduce the number of entries which BitComet may place in the NAT table, by the use of TCP connections.
3. (Optional) If you're using Windows XP, you may also want to set the number of maximum embryonic connections allowed by Windows to something a little higher than the default 10 (by using the TCP/IP Limit option in BitComet to set it at something like 20) and then make sure that the network.max_connecting_connections option is set to something lower than that (the default 10 should be OK).
4. Another thing you might want to watch out for is the number of simultaneous running tasks BitComet has, since incoming TCP connections and UDP traffic for each additional task cannot be stopped before reaching the router so each different IP source will create a new entry in the NAT table. Starting out with 1-2 running tasks in total (both downloading and seeding) might be a good place to begin, along with all the above measures if you encounter this type of issue.
5. If after doing all the above your problem still isn't solved, then it means that the culprit here is probably the UDP transport protocol. BitComet may communicate with very large number of different IPs using UDP, on account of DHT and Torrent Exchange messages which use UDP as a transport protocol. Each UDP datagram outgoing towards a different IP address will create a new entry in the NAT table of your router as well as each new IP address sending a datagram towards you, so your router's NAT table can easily become cluttered simply on account of UDP traffic even though the traffic volume in itself may not be very high, necessarily.
   

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.

However,

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 <html><span style=“color:navy; font-weight:bold”>writes</span></html> 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

C:\Program Files\BitComet

directory, under Windows XP and earlier Windows versions, or

C:\Users\%userprofile%\AppData\Local\VirtualStore\Program Files\BitComet

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\Roaming\BitComet 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 <html><span style=“color:navy; font-weight:bold”>read</span></html> 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:

• Make sure you have full permission for this file and BitComet folder (in some cases you might need to also take ownership of the folder);
• Make sure the downloads.xml is not read-only;

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;

1. If your version is v.1.18 or above (or in case you upgraded, if your previous version was v.1.18 or above), then recovering your tasklist is just a matter of deleting the current downloads.xml file and renaming one of the .bak files (you can start with the most recent one) to downloads.xml (they should be present in the same folder as downloads.xml).
2. If your version is v.1.07 or above but below v.1.18 (or in case you upgraded, if your previous version was v.1.07 or above), try the backup file: see if there is a downloads.xml.bak file in the program directory described in the above sections. Delete the downloads.xml file and rename downloads.xml.bak to downloads.xml. Now start Bitcomet and see if the task list is correct or more nearly correct.
3. Check the Torrent History (or Torrent Archive in BitComet v.1.16 or the older). The Torrent History may have all of your previously downloaded torrents, unless you disabled this feature or deleted that torrent from the history list… Select the torrents that existed as tasks before your BitComet shutdown, one by one (starting with v.1.23 you can select multiple torrents and add them with one single command from the right-click context menu: Add to TaskList…). Double-click the selected torrent and a popup dialog will warn: “The task you want to view is removed, do you want to download again? ” Click “Yes” and choose the same destination for the download as the one where the files for that torrent reside, and click “Download now” to continue. BitComet will do a hash-check automatically then and after the hash-check is finished, it will start downloading those unfinished tasks or seeding if they were finished.
4. Try recreating the task list from the \Torrents subfolder. BitComet keeps copies of the torrents for current tasks, in this folder. Copy the entire folder somewhere else for backup. Try to re-add each torrent as a new task, making sure to hash-check it after you add it but before you start it. You *should* be able to recover your entire task list this way.
5. If none of the above applies to you and all you have is the unfinished downloaded files, then you'll have to go about it the hard way. Head to the index sites where you downloaded the torrents the first time, and download the exact same .torrent files (they need to be the ones with the same info-hash) and add them to your Task List again. Upon adding make sure that you point each task's download path to the folder where its unfinished files reside. It should automatically hash-check and pick up where it left. If that doesn't happen, then stop the task, perform a manual hash-check and restart it again.
6. If all you have is the unfinished downloaded files and your client version is v.1.20 or later you could also try the Import Unfinished Downloads option of the File menu.

 If you don't fix the file-writing problem, this will happen again next time you restart.

<html><span style=color:RoyalBlue>Tip:</span></html> 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.

Also

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:

1. Copy the current BitComet download folder (the folder which holds the files for each task) onto the new computer and make sure that it resides in a partition which has the same letter as the previous one (i.e. if your current download folder is D:\BitComet Downloads then make sure you move BitComet Downloads on the D:\ partition of the new computer.
   If you don't have a partition with the same letter on the new computer then you'll have to move all the tasks from within BitComet (select the tasks, right-click and choose File Move To) into a folder on the current computer whose path can be replicated on the new one and you'll have to do this prior to moving the files to the new computer or exporting the tasklist. (E.g. if your download folder on the current computer is D:\BC_Downloads but you'll only have a C:\ partition on the new computer (bad idea by the way) then you'll have to move all your tasks into C:\BC_Downloads on the current computer prior to moving the folder on the new computer. This ensures that each task points toward the right path, not towards an inexistent one, on the new PC.
2. Go to the File menu and choose Import and Export Download List…. In the lower section named “Export” click on the ellipsis button and choose a filename and location for the backup file. Make sure that the “Export all tasks” radio button is selected before hitting the Export button. This will create a backup copy of the tasklist and BitComet settings into a backup file.
3. Select all the tasks in the Task List of BitComet and then right click and choose Save Torrent As and save all the .torrent files into a location of your choice.
4. Make sure that in your new installation of BitComet the variable system.use_app_data is set to TRUE into Options–>Advanced.
5. Open a new Explorer window and type in the address bar %appdata%\BitComet\torrents then hit Enter. You should find yourself into the \torrents folder of the new BitComet installation. Copy in here all the .torrent files that you saved in Step 3.
6. Go into the File–>Import and Export Download List… and into the upper section called Import choose the backup file which you saved in Step 2. After BitComet finishes importing the list, you should be done and have an identical completely functional list of tasks as on the old computer.

-Previous Page -Next Page
-Main Index