Delay on checking for updates

crazyc · 24 February 2023, 10:14

Hi All

All of my a1200s are set to go online when they boot up, which means when I run games it does the update check for the slave and for WHDLOAD itself.

For the first time in a few years I recently set up an a1200 with a B1230MKIV (for the last couple of years I have been using only 060 based machines) and all worked well except for running games via WHDLOAD - after running the game it was taking at least 60 seconds (just hanging there) to bring up the splash screen. I thought I had either messedup the setup or maybe I had just been spoiled by using 060 machines. I went back to my other amigas and found that they now have this same issue - I am sure I would have remembered this if it had been the case previously? (as it is really noticeable). disconnecting from Roadshow and hence the internet before running the game removes the issue (but also removes the update check).

Is anyone else seeing this? Has there been a change on the server side when doing the update check? or am i just going insane.....?

Wepl · 24 February 2023, 12:34

I'm currently investigating this problem.
The problem exists since Dec 21st, 2022 where the shared hosting of whdload.de/net moved to another server. With this move also the http-server changed from apache to ngix.
My current understanding is, that this is a problem of the http-server.
The first connection timeouts. Subsequent connections are working normal.
I have opened a support ticket.
If someone has ideas about the problem please tell...

crazyc · 24 February 2023, 13:27

Cheers - I thought I had broken something (as thats usually the cause).
I shall just wait and hope for an update in due course if you manage to resolve it.

shelter · 24 February 2023, 13:44

Wait, auto update slaves, how?

coldacid · 24 February 2023, 16:43

@shelter it doesn't auto-update slaves, it just checks to see if there's an update available (via a document on the WHDLoad website that contains relevant details for this) and alerts the user if an update for the currently loaded slave is available. It's still on the user to actually download it and replace the old slave, last I noticed.

crazyc · 24 February 2023, 16:52

Although if you have your amiga setup correctly you can click and it will take you to the specific update page for that slave.
You have to download and install etc yourself from there though.

shelter · 24 February 2023, 18:30

Ok. that explains it. I never had networking enabled prior to starting WHDLoad since it locks up the system. So I never got that notification.

Wepl · 28 February 2023, 23:09

Is there something like tcpdump on Amiga?
I'm using Genesis ATM.

shelter · 01 March 2023, 12:05

Quote:

Originally Posted by Wepl

Is there something like tcpdump on Amiga?
I'm using Genesis ATM.

Roadshow got a tcpdump utility. Not sure if it's compatible with anything else tho'

Wepl · 01 March 2023, 21:40

Thx. I have made a dump via the router (FritzBox) which worked fine. So no need to do this on the Amiga.
My idea is now that the webserver doesn't answer when the remote port is 1024.

kriz · 01 March 2023, 22:08

You dont have to disable the tcp/ip client before running Whdload anymore ?

Wepl · 02 March 2023, 23:16

You should let disable the tcpip-stack via options ExecuteStartup/Cleanup.
Nothing changed here.

crazyc · 03 March 2023, 11:50

Quote:

Originally Posted by kriz

You dont have to disable the tcp/ip client before running Whdload anymore ?

As Wepl says - the execute and clean up scripts in WHDLOAD take care of both the network and Poseidon (USB) for me. (Obviously after doing the update check)

Wepl · 09 March 2023, 12:24

So, I got the confirmation from the webhoster that their server doesn't respond to remote ports=1024.
This is stupid broken on their side and not conforming to internet standards (reserved ports are 0..1023).
I still hope that the webhoster may fix this issue, but it is unclear if it will happen soon.

The problem is then if you start WHDLoad as the first application which opens a TCP connection the tcpip-stack will probably use 1024 as local port and the connection will timeout.
To avoid the problem in the meantime you could start one tcp connection before starting whdload (netcat, wget, curl, ...).

Wepl · 11 March 2023, 15:52

The problem is solved now.
Website has been moved to a different datacenter.

crazyc · 17 March 2023, 10:16

Fantastic - cheers.

Confirmed all back to working properly from my end, including clicking the update slave and being taken to the right page.

Wepl · 09 October 2023, 12:11

The problem exists again since a while (due my stupid provider).
I will contact him but it's unclear if this gets fixed soon.

Wepl · 18 October 2023, 23:23

As the damned ISP is unable to fix the problem I have added a workaround in WHDLoad to avoid using local port 1024.
It's included in the latest beta: https://whdload.de/whdload/whd190.lha

crazyc · 21 October 2023, 22:09

Seems to work fine so far, cheers!

tolkien · 30 December 2023, 14:39

Using latest beta works great with no delay but seems It fails to check or ignore for newer slaves.

24 February 2023, 10:14	#1
crazyc Registered User Join Date: May 2012 Location: Gravesend - UK Posts: 927	Delay on checking for updates Hi All All of my a1200s are set to go online when they boot up, which means when I run games it does the update check for the slave and for WHDLOAD itself. For the first time in a few years I recently set up an a1200 with a B1230MKIV (for the last couple of years I have been using only 060 based machines) and all worked well except for running games via WHDLOAD - after running the game it was taking at least 60 seconds (just hanging there) to bring up the splash screen. I thought I had either messedup the setup or maybe I had just been spoiled by using 060 machines. I went back to my other amigas and found that they now have this same issue - I am sure I would have remembered this if it had been the case previously? (as it is really noticeable). disconnecting from Roadshow and hence the internet before running the game removes the issue (but also removes the update check). Is anyone else seeing this? Has there been a change on the server side when doing the update check? or am i just going insane.....?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Checking to see if an ADF is FFS	jasonver2.0	Coders. General	5	01 October 2021 12:42
Checking for undesireable contents	rare_j	project.Amiga File Server	15	30 June 2020 00:41
Checking for a colour before blitting.	gazj82	Coders. Blitz Basic	6	01 January 2018 02:03
Checking my Religion	Axxy	request.Modules	0	04 July 2005 19:22

24 February 2023, 12:34	#2
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	I'm currently investigating this problem. The problem exists since Dec 21st, 2022 where the shared hosting of whdload.de/net moved to another server. With this move also the http-server changed from apache to ngix. My current understanding is, that this is a problem of the http-server. The first connection timeouts. Subsequent connections are working normal. I have opened a support ticket. If someone has ideas about the problem please tell...

24 February 2023, 13:27	#3
crazyc Registered User Join Date: May 2012 Location: Gravesend - UK Posts: 927	Cheers - I thought I had broken something (as thats usually the cause). I shall just wait and hope for an update in due course if you manage to resolve it.

24 February 2023, 13:44	#4
shelter Registered User Join Date: Nov 2022 Location: #Amigaland Posts: 156	Wait, auto update slaves, how?

24 February 2023, 16:43	#5
coldacid WinUAE 4000/40, V4SA Join Date: Apr 2020 Location: East of Oshawa Posts: 538	@shelter it doesn't auto-update slaves, it just checks to see if there's an update available (via a document on the WHDLoad website that contains relevant details for this) and alerts the user if an update for the currently loaded slave is available. It's still on the user to actually download it and replace the old slave, last I noticed.

24 February 2023, 16:52	#6
crazyc Registered User Join Date: May 2012 Location: Gravesend - UK Posts: 927	Although if you have your amiga setup correctly you can click and it will take you to the specific update page for that slave. You have to download and install etc yourself from there though.

24 February 2023, 18:30	#7
shelter Registered User Join Date: Nov 2022 Location: #Amigaland Posts: 156	Ok. that explains it. I never had networking enabled prior to starting WHDLoad since it locks up the system. So I never got that notification.

28 February 2023, 23:09	#8
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	Is there something like tcpdump on Amiga? I'm using Genesis ATM.

01 March 2023, 21:40	#10
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	Thx. I have made a dump via the router (FritzBox) which worked fine. So no need to do this on the Amiga. My idea is now that the webserver doesn't answer when the remote port is 1024.

01 March 2023, 22:08	#11
kriz Junior Member Join Date: Sep 2001 Location: No(R)Way Age: 41 Posts: 3,195	You dont have to disable the tcp/ip client before running Whdload anymore ?

02 March 2023, 23:16	#12
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	You should let disable the tcpip-stack via options ExecuteStartup/Cleanup. Nothing changed here.

09 March 2023, 12:24	#14
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	So, I got the confirmation from the webhoster that their server doesn't respond to remote ports=1024. This is stupid broken on their side and not conforming to internet standards (reserved ports are 0..1023). I still hope that the webhoster may fix this issue, but it is unclear if it will happen soon. The problem is then if you start WHDLoad as the first application which opens a TCP connection the tcpip-stack will probably use 1024 as local port and the connection will timeout. To avoid the problem in the meantime you could start one tcp connection before starting whdload (netcat, wget, curl, ...).

11 March 2023, 15:52	#15
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	The problem is solved now. Website has been moved to a different datacenter.

17 March 2023, 10:16	#16
crazyc Registered User Join Date: May 2012 Location: Gravesend - UK Posts: 927	Fantastic - cheers. Confirmed all back to working properly from my end, including clicking the update slave and being taken to the right page.

09 October 2023, 12:11	#17
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	The problem exists again since a while (due my stupid provider). I will contact him but it's unclear if this gets fixed soon.

18 October 2023, 23:23	#18
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	As the damned ISP is unable to fix the problem I have added a workaround in WHDLoad to avoid using local port 1024. It's included in the latest beta: https://whdload.de/whdload/whd190.lha

21 October 2023, 22:09	#19
crazyc Registered User Join Date: May 2012 Location: Gravesend - UK Posts: 927	Seems to work fine so far, cheers!

30 December 2023, 14:39	#20
tolkien AmigaMan Join Date: Oct 2012 Location: Castro Urdiales/Spain Posts: 761	Using latest beta works great with no delay but seems It fails to check or ignore for newer slaves.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)