The support forum

GUI Appearance Slowness After Program's Start

Doequer :

Jun 17, 2019

Hi, some days ago I noted it would take ~ 1' to the program's main window to be shown up after being started, although it gets loaded in memory right away. So, I thought it might be due to one or more of the jobs being somehow the culprit of such delay, but after trying it with a "fresh" configuration (no jobs), the program kept behaving the same way. So, I went to the program's log and found out what "seems to be" the reason of this issue:

2019.06.16 02:04:52.218 (UTC-3) 3 50:3C en | Enumerating storage devices, volumes and drives...
2019.06.16 02:05:52.465 (UTC-3) 3 50:3C en | Storage scanned in 60240 ms, dev 60220 ms, vol 16 ms, drv 03FFFFFF, in full

Currently I have 12 drives, most of them fixed ones, with no labels neither serial numbers changes at all.

So, not that it is a big of an issue, but I'm wondering if is there a way of getting rid of such a delay or, at least, mitigate it?

Alex Pankratov :

Jun 17, 2019

You are probably correct regarding the source of the delay, but this particular log entry is not the correct one. The engine does a shallow device scan when the program starts up, avoiding queries that would cause devices to spin up and some such. Once the engine is up, it will then re-scan the storage stack in full, which is done asynchronously, and it may in fact take a while to complete. This is what the log entry is for.

In terms of working around this delay - no, there's no way to do it.

Doequer :

Jun 19, 2019

I was thinking of somehow make the program omit certain fixed drives, since they aren't part on any backup jobs, and thus gaining sometime. But as you explained before, since the general scanning can't be avoided, I will just leave it at that.

Thanks.

Alex Pankratov :

Jun 19, 2019

I was thinking of somehow make the program omit certain fixed drives, since they aren't part on any backup jobs, and thus gaining sometime.


That's a reasonable request, but this will require populating "ignore" list with storage device IDs rather than drive letters... hmm, let me see what I can do though. It is a good feature to have.

Doequer :

Oct 24, 2019

OK, look at this:

2019.10.23 20:20:13.596 (UTC-3) 3 24:80 en | Enumerating storage devices, volumes and drives...
2019.10.23 20:20:14.331 (UTC-3) 3 24:80 en | Storage scanned in 728 ms, dev 712 ms, vol 12 ms, drv 03FFFFFF, in full

In the past days I've been struggling with a USB "micro SD" cards reader (with a 2GB card) which was giving me some general system's slowdowns and related problems, so I decided to change it from the USB hub where it was connected, to a direct port at the PC's back panel. It worked rightly, but some days after that I started getting some weird BSODs, all of the sudden; and since I didn't realized of which one could be the reason, I just thought of that last change I made respect the reader, so I decided to just disconnect it. The results were kind of surprising to me:

1- No more BSODs so far.

2- Bvckup2 takes less than 1 second to get loaded.

So, as it turns out, it was that shitty generic "micro SD cards" reader the real cause of the problem.

I don't really know what could be the exact problem, since I don't get any kind of warning messages or similar ones about the drive itself, and it works right, at least right after connecting it. But it seems it gets problematic if I just left it connected in a permanent way (it doesn't matter the "quick removal" policy I apply), since after a while it will affect the other USB drives recognition and cause system's unstability as well.

I think I will just ditch it, and replace it for a decent flash drive.

Alex Pankratov :

Oct 24, 2019

Thanks for the follow-up. It's likely to be an issue at the driver level rather than the reader itself, but I agree that replacing it is probably the right thing to do.

New topic

Create
Made by IO Bureau in Switzerland
Support

Updates
Blog / RSS
Follow Twitter
Reddit
Miscellanea Press kit
Testimonials
Company Imprint

Legal Terms
Privacy