necessary to create .torrent files every time BiglyBT starts?

[as-muncher]

Java 1.8.0_202 (64 bit) Oracle Corporation c:\program files\biglybt\jre

SWT v4942r22, win32, zoom=100, dpi=120 Windows 10 v10.0, amd64 (64 bit) B2.8.0.0/4 az3

Hi, just wondering if it's really necessary to create and re-create the .torrent files every time BiglyBT starts up. Is it to share with others? I figure that if someone wants to download the .torrent file, it could be created on demand. Of course, I haven't coded BiglyBT and I'm happy to use the software. I'm just curious.

[parg]

Where are these torrent files being created?

[as-muncher]

C:\users\\AppData\Roaming\BiglyBT\tmp\AZU.tmp\ where those numbers are different for each torrent

[parg]

Those files are generally nothing to do with torrents, they are things like temporary log files.

[as-muncher]

I tried to edit my post, and then my computer froze.
Plus, with the < and > symbols, this webpage was not showing those symbols and everything I wrote between them, so that must be a bug with this web software. The directories were C:\Users\username\AppData\Roaming\BiglyBT\tmp\AZUand then a whole bunch of numbers, different for each torrent and then .tmp\

I can see in Process Hacker 2 that .torrent files are being created on startup. The .torrent files are maybe the info hash and then an underscore and then 4 digits or letters and then the .torrent extension. I'm not sure why log files would be saved with a .torrent extension.

[as-muncher]

[as-muncher]

This is not a torrent of .torrent files being downloaded. This happens on startup. As a side note, I have BiglyBT set to add the .!qB extension for incomplete files, but for my torrent of .torrent files, the incomplete .torrent files are not being saved with the .!qB extension. I think that's an issue that could be fixed.

[parg]

Not always 4 numbers after the hash... Only place I've found where such .torrent files are created are for subscription downloads. In this case they're supposed to be in %appdata%\subs\temp though

[as-muncher]

Do you need me to upload any logs? Thanks for responding.

[parg]

You could check the Subscriptions_1/2.log files in the "logs" directory - if should say if subscription torrents are being created

[as-muncher]

Before I check it, I will say that those .torrent files are being created even when the computer is not connecting to the web, but is in airplane mode.

[10/21/21 2:12 PM] Log File Opened for BiglyBT 2.8.0.0 [14:30:42] Popularity update: Failed to record selected subscriptions [14:30:42] com.biglybt.core.messenger.PlatformMessengerException: com.biglybt.pif.utils.resourcedownloader.ResourceDownloaderException: https://rpc.biglybt.com/rpc.php?msg=subscription:set-selected: Exception while initializing download of 'https://rpc.biglybt.com/rpc.php': Unknown Host 'rpc.biglybt.com' at com.biglybt.core.messenger.config.PlatformMessengerConfig$1.replyReceived(PlatformMessengerConfig.java:130) at com.biglybt.core.messenger.PlatformMessenger$2.runSupport(PlatformMessenger.java:429) at com.biglybt.core.util.AsyncDispatcher$1.run(AsyncDispatcher.java:168) at com.biglybt.core.util.AEThread2$threadWrapper.run(AEThread2.java:317) Caused by: com.biglybt.pif.utils.resourcedownloader.ResourceDownloaderException: https://rpc.biglybt.com/rpc.php?msg=subscription:set-selected: Exception while initializing download of 'https://rpc.biglybt.com/rpc.php': Unknown Host 'rpc.biglybt.com' at com.biglybt.pifimpl.local.utils.resourcedownloader.ResourceDownloaderURLImpl.download(ResourceDownloaderURLImpl.java:1495) at com.biglybt.pifimpl.local.utils.resourcedownloader.ResourceDownloaderURLImpl$3.run(ResourceDownloaderURLImpl.java:637) ... 1 more Caused by: java.net.UnknownHostException: rpc.biglybt.com at java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.security.ssl.SSLSocketImpl.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.protocol.https.HttpsClient.(Unknown Source) at sun.net.www.protocol.https.HttpsClient.New(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivilegedWithCombiner(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.access$100(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$8.run(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$8.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivilegedWithCombiner(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source) at com.biglybt.pifimpl.local.utils.resourcedownloader.ResourceDownloaderURLImpl.download(ResourceDownloaderURLImpl.java:1015) ... 2 more

Only 1 lightweight torrent created. It's not the 20 or so that I see being created in Process Hacker.

[as-muncher]

Always writing out these .torrent files slows things down quite a bit on startup. I guess I could check the infohashes of the .torrent files and see where they match in my torrent list, if they do.

[as-muncher]

So these .torrent files that are being created are for the magnet link files "metadata download for ....". This happens even when airplane mode is on. I'm using 2.9. In 2.8, the user interface would take a long time to load up, but then the "metadata download for ..." would show up immediately. Now, the .torrent files pop up after a while, but it left me wondering what happened to them all. I figure it's not necessary to write those files every time Bigly starts up. I think just once is enough.

[as-muncher]

Java 1.8.0_202 (64 bit) Oracle Corporation c:\program files\biglybt\jre

SWT v4942r22, win32, zoom=100, dpi=120 Windows 10 v10.0, amd64 (64 bit) B2.9.0.0/4 az3

[parg]

Ah yes, that would make sense. Not easy to change I'm afraid.

[parg]

Actually might not be that hard, I'll see

[as-muncher]

I saw something related to this issue - did you fix it? Thanks for looking at it. Using an encrypted non-SSD hard drive, with a lot of magnet links, it takes a while for BiglyBT to start up.

[parg]

try the latest beta

[as-muncher]

Java 1.8.0_202 (64 bit) Oracle Corporation c:\program files\biglybt\jre

SWT v4942r22, win32, zoom=100, dpi=120 Windows 10 v10.0, amd64 (64 bit) B2.9.0.1_B05/4 az3

It's still happening. It's still the metadata download links still writing out the .torrent files every time BiglyBT starts up. I noticed that Bigly starts up a lot faster than 2.9, but I still see this .torrent file problem. Looking in the DiskOps_1.log file, I see that it says that "metadata download for ... is not persistent, auto-move disabled." is what I saw for 2.9, but for 2.9.0.1 B 05, I don't see that in the log file, but still see these .torrent files being created. I see a

[16:10:07] DEBUG::Sun Nov 28 16:10:07 MST 2021 URL Group map changed for Metadata download for .torrent: old=, new=http://tracker.opentrackr.org:1337=1, udp://tracker.opentrackr.org:1337=1 [16:12:55] [stderr] DEBUG::Sun Nov 28 16:12:55 MST 2021::com.biglybt.core.util.ThreadPool::checkWarning::368: [16:12:55] [stderr] Thread pool 'Simple Timer' is full (busy=LazyHaveSender,SimpleTimer:ticker,CacheFile:stats+cleaner) [16:12:55] [stderr] run (ThreadPool.java:246), run (ThreadPool.java:213), runSupport (Timer.java:322), AERunnable.run, run (null:-1)

[as-muncher]

I've also noticed that when the .torrent file is finally downloaded, and the torrent starts, that all the files are being allocated even though I had unchecked the box to allocate all files.

[parg]

what's that got to do with the metadata download?

[as-muncher]

@parg, I guess nothing, so it sounds like you would want me to start a new issue for that, which I can do.

[as-muncher]

I guess I just figured I'd kill two birds with one stone instead of having to open another issue.

[parg]

Unchecked which "box to allocate all files" ?

[as-muncher]

Yes, for sure, just checked again, in Options under Files. "Allocate and zero files upon creation" and the checkbox under it are both unchecked. Also, when I start up BiglyBT, I see under "Status" for many of the torrents, that they are Allocating and then the percentage. Maybe that's BiglyBT's way of doing fast resume? I didn't think so though. Maybe allocating happens on a per torrent basis, and so then when you change the options in BiglyBT to not allocate, the torrents that were created that had allocation turned on at the time still keep doing the same thing, even though you've turned allocating off.

[as-muncher]

Java 1.8.0_202 (64 bit) Oracle Corporation c:\program files\biglybt\jre

SWT v4942r22, win32, zoom=100, dpi=120 Windows 10 v10.0, amd64 (64 bit) B2.9.0.1_B08/4 az3

It looks now like the .torrent files don't keep writing anymore every time BiglyBT starts. Thank you! Allocating is still happening, though, when that torrent starts, even though allocation is turned off.

[parg]

"allocate and zero" means BiglyBT will sequentially write zeros to the entire file during the allocation phase to reserve the space and try and minimise fragmentation.

If you really don't want the files to be created when you add a torrent then use the "add in a stopped state" option.

If you want the file to grow as it is downloaded then enable "incremental file creation". Be aware though that as the file is generally downloaded in random blocks it will grow quickly (e.g. when the last block of a file is written that will grow the file to its entire size even if intermediate blocks haven't been downloaded)

If you want the file to grow as it is downloaded in a more sensible fashion, and your file system supports it, use "spare files".

As an alternative to sparse files use "append data and reorder" although I generally wouldn't recommend this.

[as-muncher]

Java 1.8.0_202 (64 bit) Oracle Corporation c:\program files\biglybt\jre

SWT v4942r22, win32, zoom=100, dpi=120 Windows 10 v10.0, amd64 (64 bit) B2.9.0.1_B09/4 az3

"Allocate and zero" is greyed out, unchecked. "Use sparse files" is checked. "Enable incremental file creation" is unchecked. "By default add torrents is a stopped state" is checked.

I will keep an eye on it, though.

[as-muncher]

I got to thinking about this last post, and I think it may throw some confusion. I had done all the steps that you mentioned @parg such as turning off allocation, using sparse files, all that. But the allocation was still happening when I wrote it. But I will continue to keep an eye on it.

[as-muncher]

Yes, files still being allocated even though that is turned off in the settings.

Java 1.8.0_202 (64 bit) Oracle Corporation c:\program files\biglybt\jre

SWT v4942r22, win32, zoom=100, dpi=120 Windows 10 v10.0, amd64 (64 bit) B2.9.0.1_B10/4 az3