It can be triggered easilly:. You can see from the screenshot that this has happened a few times before. Once I did not notice, so it downloaded another GB before I stopped it. Rechecking shows all data is there. I'm using BiglyBT v2. The torrent file is stored on a NAS Samba network share. The text was updated successfully, but these errors were encountered:.
Have you changed any settings that might be causing it to take a while in your setup? Sorry, something went wrong. As you see the file is GB. It contains about individual files.
During startup, the allocation phase can take several minutes. There are some other files that big too, so it does happen that it takes too long to load before I need to reboot or something like that. It looks like that BiglyBT somehow forgets the file is downloaded if BiglyBT is restarted or killed during this allocation phase. There is an option to move the data files in the right-click menu under Content make sure you are running the latest beta if you use this as there was a performance issues with moving files in 1.
An alternative approach would be to close BiglyBT, manually move the files, then use the 'find existing files' option to match them back up. Unfortunately this will result in them all being rehashed so I'm not sure it is advisable for Sorry, something went wrong. First, thank you very much parg for all you have done over the years, and for this reply! Yes, I want to move.
And yes, when I messed it up previously I was thankful I had a fresh backup Ah, I didn't see "option to move the data files in the right-click menu under Content"! The 'move torrent file' you tried before should work - I jut tested with 3 torrents and it seemed to do the expected - what went wrong? I'm going to move the 'Move Torrent File Thanks for the response. To give some details, I have two torrents in my library 0 done, 2 downloading.
They were showing queued. Thanks for the help. I have this same issue except I am running BiglyBt on Mac. Upon switching to BiglyBT from Vuze, only one torrent will download at a time and the others are queued even if I stop all active seeds , whereas in Vuze I would have up to four downloading at once according to the same settings. What are your settings for 'minimum simultaneous downloads' and 'max active torrents'? Thanks for your fast response. I had minimum simultaneous downloads set to 1 and max active torrents set to 6 this is the configuration that worked without any issue in Vuze , but after your response I experimented with the settings and found that if I made the value for minimum simultaneous downloads the same as the max simultaneous downloads, which is set at 4, the desired number of torrents would begin to download.
The same effect could be achieved by setting max simultaneous downloads to 0 or some much higher value and selecting only four torrents but this is obviously undesirable for the sake of good settings and automation. Only finishing the real first file, did it stop downloading two at once. Well this maddening behavior is rarer still and usually it either sequentially downloads or ignores the setting. But it does demonstrate how error prone the logic behind is. Automatic settings regarding 'auto sequential for selected file extensions' also do so.
Sequential downloading is achieved at the piece level by setting the piece priorities so that the desired sequence is preferred.
Various other things also mess with priorities e. When things go wrong perhaps you can take a look at the 'pieces' ot 'piece map' sub-tabs and check out the piece priorities. Well I started another torrent which was marked as sequential download when it was added to the queue a few days back. It exhibits the same issue again:. The pieces being downloaded have priorities all under and I couldn't find a way to get priorities of pieces currently not downloading.
Also not through the piece map. So started another torrent with same issue. This time it is downloading many files sequentially All pieces being downloaded have priority ranging in , ,
0コメント