There should be a plain text list of all downloads in the queue (like the “downloads.txt” file in eMule) — that would come in handy in a case like this for instance, to identify which downloads have been accidentally cancelled.
And recently, on 2022-12-18 precisely, I noticed that Shareaza had spontaneously removed 186 downloads during startup. I first noticed that many .partial files did not have an associated .sd file, then, as I was occupied with something else entirely, I found out that many .sd files were in the “recycle bin”, with various deletion dates, and in particular 186 deleted on 2022-12-18. I activated the “General.DebugLog” option, so I could check what happened that day at that time, and there is simply a list of “Cleared download...” notifications, with no explanation whatsoever. So I have no clue what happened. The previous session was interrupted by a BSOD, but none of those .sd file appears corrupted. I simply restored them (at the same time as I launched v. 2.7.10.4 2022-12-27 for the first time, coincidentally), and apparently all of the corresponding downloads were loaded with no issue (they all appeared at the top of the queue, since, I suppose, the “DownloadGroups.dat” file, which apparently determines the sorting order of files, no longer had them referenced). And the two downloads I accidentally cancelled were among those 186, so at least that should make it a bit easier to pinpoint which ones are missing.
[20:13:20] Loading skin: Shareaza OS
[20:13:22] Cleared download "E:\TELECHARGEMENTS\Shareaza\fichiers en cours\ed2k_42378b4b8fc47194431d893871c91787.sd".
[...]
[20:15:25] Cleared download "E:\TELECHARGEMENTS\Shareaza\fichiers en cours\ttr_ZZJYBOTPY5IBXMSF54XGLDTAILEBUHPIIPZ3XVA.sd".
[20:17:08] Starting Shareaza network core...
[20:17:08] Accepting incoming TCP connections on 0.0.0.0 port 35683.
And one more thing (I'm starting to sound like lieutenant Columbo !) : it would certainly be more convenient if that log file (which can be quite huge — I set it to the maximum size of 50MB) included the dates... (Either at the start of each line, or at least at the start of a new day.)
As requested by @abolibibelot1980
There should be a plain text list of all downloads in the queue (like the “downloads.txt” file in eMule) — that would come in handy in a case like this for instance, to identify which downloads have been accidentally cancelled. And recently, on 2022-12-18 precisely, I noticed that Shareaza had spontaneously removed 186 downloads during startup. I first noticed that many .partial files did not have an associated .sd file, then, as I was occupied with something else entirely, I found out that many .sd files were in the “recycle bin”, with various deletion dates, and in particular 186 deleted on 2022-12-18. I activated the “General.DebugLog” option, so I could check what happened that day at that time, and there is simply a list of “Cleared download...” notifications, with no explanation whatsoever. So I have no clue what happened. The previous session was interrupted by a BSOD, but none of those .sd file appears corrupted. I simply restored them (at the same time as I launched v. 2.7.10.4 2022-12-27 for the first time, coincidentally), and apparently all of the corresponding downloads were loaded with no issue (they all appeared at the top of the queue, since, I suppose, the “DownloadGroups.dat” file, which apparently determines the sorting order of files, no longer had them referenced). And the two downloads I accidentally cancelled were among those 186, so at least that should make it a bit easier to pinpoint which ones are missing.
[20:13:20] Loading skin: Shareaza OS [20:13:22] Cleared download "E:\TELECHARGEMENTS\Shareaza\fichiers en cours\ed2k_42378b4b8fc47194431d893871c91787.sd". [...] [20:15:25] Cleared download "E:\TELECHARGEMENTS\Shareaza\fichiers en cours\ttr_ZZJYBOTPY5IBXMSF54XGLDTAILEBUHPIIPZ3XVA.sd". [20:17:08] Starting Shareaza network core... [20:17:08] Accepting incoming TCP connections on 0.0.0.0 port 35683.
And one more thing (I'm starting to sound like lieutenant Columbo !) : it would certainly be more convenient if that log file (which can be quite huge — I set it to the maximum size of 50MB) included the dates... (Either at the start of each line, or at least at the start of a new day.)