Frustratingly SLOW startup - up to 1 1/2 mins

[agwd]

I have a valid 'never expire' license for dvdfab, however find the startup wait to be frustrating. It always takes well over a minute, sometime much more, sitting on the splash screen "Logging in...".
I have an OK internet connection (10ms ping, 100Mbs), and no identifiable network issues. The delayed startup exists on other machines if I try them (same network). I have double checked firewall settings. I never had any such problems with v8.
I am in Australia.
The long delay is independent of my physical hardware (ie the exact same delay occurs on a dual E5 xeon machine with 64G ram, and a i73630qm laptop with 16G ram, 10Gb LAN /1G to router, 100Mb to WAN - I really don't think I am bound by hardware limitations.)
I totally understand the need for dvdfab to connect to a licensing server, however I wonder if could be streamlined somewhat. I also wonder if Fengtao Software's servers have reached saturation ? I note that downloading updates from the site is very slow (less than 40kbps). It's all a little bit 1999.
Any ideas?

[dahabes]

Same Here....

My start up times are even worse, over 5 minutes. It was fine a couple of months ago, now it's horrible. Same software level, same PC, same network. Please remediate.

[signals]

All

This is difficult to evaluate, it can be caused by a busy server on the DVDFab end or delays on your end of the network . You can help us evaluate the performance of your link to the registration server through the following procedure.

From the command (DOS) prompt in windows, go to the root directory of your OS drive (typically C:\) and enter the following:

tracert -h 40 -w 5000

The forum software interprets the above as a link, but it is not. It will produce a small text file in the root directory of your OS drive that will show the route from you to us and the delays along the way. Attach it to a new post in this thread. After the test completes and the file is written, the DOS prompt will return (this can take several minutes) and you can type "EXIT" to close the window.

[GregiBoy]

Here are my results from Oz...

[signals]

Hm, looks like something on optusnet. Timeout was set for 5 seconds, so the packets are rattling around somewhere downunda. Thanks mate.

[agwd]

Good idea - I am also on optusnet.
Trace output attached...
if I run it multiple times the hop from 66.198.96.58 to 184.107.1.2 (iweb) times out consistantly:

>tracert -w 5000 -d www.dvdfabstore.com

Tracing route to www.dvdfabstore.com [184.107.48.214]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.11.1
  2    11 ms    11 ms    12 ms  10.86.0.1
  3    12 ms    17 ms     8 ms  198.142.192.65
  4    52 ms    33 ms    24 ms  211.29.126.77
  5   177 ms   179 ms   210 ms  203.208.190.85
  6   179 ms   190 ms   193 ms  203.208.183.38
  7   250 ms   279 ms   253 ms  66.198.127.9
  8   269 ms   305 ms   255 ms  66.198.127.2
  9   254 ms   266 ms   291 ms  66.198.144.58
 10   276 ms   262 ms   265 ms  66.198.96.45
 11   253 ms   254 ms   262 ms  66.198.96.58
 12     *        *        *     Request timed out.
 13   277 ms   255 ms   271 ms  184.107.1.30
 14   253 ms   257 ms   261 ms  184.107.48.214

Trace complete.

I feel the issue lies elsewhere though?

[GregiBoy]

Could this have anything to do with it?

http://www.brisbanetimes.com.au/technology/technology-news/how-asics-attempt-to-block-one-website-took-down-250000-20130605-2np6v.html

[agwd]

@GregiBoy - I am no expert but I don't think the "great firewall of oz" would be the problem - I believe they block the ip ranges on all ports, so we'd not even see the endpoint. (ah... our misguided governments)
The hop timeouts are likely just misconfigured or overloaded routers (set to not decrement ttl or respond to udp).
If I say hello to over port 443 I get "is ok" within 250ms - 800ms.

GET  HTTP/1.1
User-Agent: TEST
Host: www.dvdfabstore.com

Request Count:   1
Bytes Sent:      63		(headers:63; body:0)
Bytes Received:  331		(headers:283; body:48)

ACTUAL PERFORMANCE
--------------
ClientConnected:	12:31:08.709
ClientBeginRequest:	12:31:08.709
GotRequestHeaders:	12:31:08.709
ClientDoneRequest:	12:31:08.709
Determine Gateway:	0ms
DNS Lookup: 		0ms
TCP/IP Connect:	0ms
HTTPS Handshake:	0ms
ServerConnected:	12:31:03.559
FiddlerBeginRequest:	12:31:08.709
ServerGotRequest:	12:31:08.709
ServerBeginResponse:	12:31:08.962
GotResponseHeaders:	12:31:08.962
ServerDoneResponse:	12:31:08.962
ClientBeginResponse:	12:31:08.962
ClientDoneResponse:	12:31:08.962

	Overall Elapsed:	0:00:00.253

RESPONSE BYTES (by Content-Type)
--------------
~headers~: 283
text/html: 48

[signals]

Possibly a timing sensitivity issue in software. We will watch it. It is noticeably slower for me on days with new releases when traffic into our rack is heavier, but still nothing like as slow as has been reported in this thread.

Try a ping with larger packets and let it run for 30-45 econds and see what the packet loss is.

e.g. ping -t -l 1024 www.etc.

[agwd]

Yep, tried that earlier - here's output:

...
Reply from 184.107.48.214: bytes=1024 time=260ms TTL=50
Reply from 184.107.48.214: bytes=1024 time=284ms TTL=50
Reply from 184.107.48.214: bytes=1024 time=276ms TTL=50

Ping statistics for 184.107.48.214:
    Packets: Sent = 72, Received = 72, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 253ms, Maximum = 300ms, Average = 264ms

[agwd]

More info:
I ran a sniffer to see what kind of activity is happening between local network and 184.107.48.214. On Dvdfab startup, it calls home on port 443 ... and gets an immediate response (encrypted of course) - then nothing - as far as I can tell there is no further communication with that IP. Dvdfab remains idle 'logging in' for about 90 secs before finally continuing.
AG

[signals]

That may be helpful. Is it still slow starting up? How about the new v9045?

[agwd]

Installed and tested v9045 and there is no difference.
Is there an official bug report / support channel? I feel this thread might be cluttering things up a bit. Thanks for your help!

[signals]

I have a direct channel to the QA Team in Beijing and their Boss. I will see that they get a link to the thread.

Note that unless you have turned the feature off, it is also checking for updates every time you start it. Try disabling that to see if it improves the speed.

[Fred_Fish]

The only setting I could find was Allow upgrading to Beta version.

There's also a setting for Check for on-the-fly decryptor automatically. Would this be necessary if I'm only doing DVD?

BTW I've had the minute and a half wait for startup since the very first version 9. I just go get a drink while I wait.