WHDLoad MantisBT - WHDLoad
View Issue Details
0006002WHDLoad[All Projects] Generalpublic2023-01-10 10:052024-02-03 18:39
Assigned ToWepl 
PlatformOSOS Version
Product Version18.8 
Target Version19.0Fixed in Version19.0beta 
ChipMem2 MB
FastMem96 (32+64, blizzard+scsi kit)
WorkbenchOS 3.2
KickROM47 - Kick 3.2
Summary0006002: Very long loading times with network connected
DescriptionLately I'm using roadshow, enabled at startup.
I've resolved the crash/freeze/recoverable alerts problems using 0004091 advices.
Now it work fine, no crash or freeze, but very long loading times, and for long I mean something like 2 minutes and more, then whdload splash screen comes up and everything works as expected, no crash during the game, no crash on exit.

During loading time, I can browse the net without problems, everything works as expected. The connection stops as soon as the whdload splash screen comes up.
Steps To ReproduceMaybe configuring whdload.prefs, WHDLoad-Cleanup and WHDLoad-Startup as Paul Head did in the 0004091 (except for the wireless part, i'm using an ethernet card).
Additional InformationAmiga 1200 with blizzard 1260+scsi module, ateobus bridgeboard, rtg pixel64 with 2mb ram, nic ateonet. Rom 3.2.1, Wb 3.2.1.

The very same issue occurs on my friend's Amiga 3000 with network card.
TagsNo tags attached.
Attached Files? .whdl_trace (5,536) 2023-01-16 21:48
jpg IMG_20231228_202423.jpg (189,152) 2023-12-28 20:35

jpg IMG_20231228_202538.jpg (178,765) 2023-12-28 20:35

? -2.whdl_trace (6,211) 2024-01-03 11:22
? wildcard_bind_test (6,656) 2024-01-15 12:04
? wildcard_bind_test2 (10,832) 2024-01-27 23:27
? WHDLoad (151,932) 2024-01-29 12:22

Paul Head   
2023-01-12 13:52   
To help Wepl, how are you loading the game?
Are you clicking on the game icon from Workbench or are you using a game launcher?
Is the delay with all games?
Whilst the delay is ongoing is there any hard drive activity on that drive (Drive LED or SnoopDOS)?
I'll be honest though it does sound like it's to do with the network checking of slave updates. From memory, I turned off that feature because I had a problem with it loading my web browser after there was little memory left (because of preload) and hence my machine was starved of ram and it was pointless trying to browse the slave update page etc...So it's 'NoNetwork' for me in my WHDLoad.prefs file.
2023-01-12 17:39   
I'm using latest igame, but there's no differences between loading through the frontend or directly from the slave.

The delay is the same with every game (i tried at least 20). In very rare occasions everything works as expected, but only after a cold boot.

No drive activity.

I have 96mb of fast ram, so the memory quantity surely is not the problem here.
While the game is "loading" i can browse the net or exchange files with my pc through FTP, so I think that the network is working properly.

Thanks Paul.
Paul Head   
2023-01-13 12:53   
Been a while since I read that old 0004091 issue. I think Wepl was correct, PoolMem with Roadshow issue. I don't go on that Amiga very much now, but I am kind of intrigued myself as to whether that fault still exists or not without the Wait command (with new WHDLoad versions and Roadshow etc). I'll revisit it one of these days and add another post if it's fixed.

Anyway, onto your issue again...have you tried the NoNetwork option which turns off the slave update check?

I remember now the reason I use NoNetwork was because of Chip RAM starvation (consumed by heftier slaves (AGA for example) and then IBrowse was loaded...not a great combo). This may seem a childish question, but you do have plenty of free Chip RAM right? When this '2 min delay' is occurring, do you have plenty of free Chip RAM (graphics memory in Workbench). I say this because your RTG browsing doesn't need Chip RAM, but WHDLoad certainly does.

Also, you say crash/freeze/alert problems in your original report. What was causing this issue and how did you solve it? Do you use either Roadshow or PoolMem like me, or both?
2023-01-13 17:10   
Nonetwork works as it should, no problems at all. Instant loading after whdload info window.

The os uses very little chip ram (there's 2.009.296 graphics mem free after wb loading), and it goes down to 1.993.776 in the "loading" part, then it takes what needed to launch the game.

I do not use poolmem.

It's hard for me and my little knowledge to give the dev some detailed report, so I'm giving up. Of course it's not a problem running whdload without the version check at start, but I'm very curious on the origin of the problem...

Anyway, thanks for your kind support.
2023-01-14 19:16   
The delay is probably caused by WHDLoad waiting for an answer to his network access. Maybe it cannot resolve the address or there is another problem with your network setup.
You can use option TRACE for further diagnostics. WHDLoad will then write a file called .whdl_trace. Look into this to see if there is a network error reported.
Paul Head   
2023-01-16 20:08   
This must be a new feature then as it had previously escaped my attention!
I have tried it out and it doesn't appear to create the trace file unless I specify a CoreDumps path.

You're very welcome! Now fire up your Amiga and use this TRACE option.
It's easy, just select a game which has the long delay going (any game I believe), select the game icon once with left mouse click and go into the Icon Information in the Icons Menu in Workbench...what we'll do here is just add a ToolType called TRACE. Once entered, select save and load the game up with a double-click. Wait for the game to appear and then quit it and examine the file created which is stored in your "CoreDumpsPath=...." (editable in S:WHDLoad.prefs). The trace file is called ".whdl_trace". I just tried it out here and it works fine. It's only a few KB in size so easy to upload here. Well, when you have a spare few minutes of course ;-)
Paul Head   
2023-01-16 20:09   
When I say "wait for the game to appear" I do mean the actual game, and not the Splash Window. I just thought I'd mention that.
2023-01-16 21:48   
There you go. It seems that it "couldn't connect to remote host". But as I said, the network is fully functional while the game is "loading". I tried to browse the whdload.de while loading, and everything works as expected.
2023-01-16 21:48   
Log attached.
2023-01-18 17:57   
Try if you can open http://cgi.whdload.net/suc.cgi in your browser. That is what WHDLoad tries to load.
2023-02-13 11:17   
I have the same problem:
A500 / ACA 500+ / ACA1234 / X-Surf500 (AmiTCP).

In fact, even the first call of the update URL via a browser leads to time-out, but a reload of the URL then works.
At the same time, however, a ping to the host is possible, i.e. name resolution and route are correct.
I do not have an explanation for this behavior...
2023-03-09 21:50   
(Last edited: 2023-03-09 21:52)
There is a problem since the website has moved to a new server in Dec 2022.
Since then the webserver does not support http-connections with a remote port of 1024. These connections will timeout. A subsequent connection using port 1025 then works. If you start WHDLoad, as the first application opening a tcp connection, the tcpip-stack usually uses the first non reserved port which is 1024. Then WHDLoad will hang because of this tcp-timeout.
I'm in the process to relocate the website to another datacenter without this problem, as the current webhoster seems to be unable to fix this problem.
In the meantime you may try to start anything, which opens a tcp-connection, prior to start WHDLoad, to avoid the problem.

2023-03-12 16:08   
The website has been moved to different datacenter. This problem doesn't appears anymore.
2023-12-27 19:38   
Seems that the problem is still there.
If I load a game without start anything which opens a tcp-connection, it takes a couple of minutes to load, because of the connection timeout to the server.
If I load a game after opening a web page, it will start promptly.
I've tried to open http://cgi.whdload.net/suc.cgi ( in IBrowse 2.5.5, and I get the expected conection timeout after a couple of minutes.
2023-12-28 13:14   
There has been a workaround added in the last WHDLoad beta.
Please try https://whdload.de/whdload/whd190.lha
2023-12-28 20:33   
Updated to 19 beta, but it seems that simply doesn't check for updated slave anymore.
For instance:
-WHDLoad 18.9.6601 - ProjectX SE slave ver 1.5 by Psygore - I get the "Newer Slave exists!" warning;
- WHDLoad 19.0.6626 - same slave - No warning.
2023-12-28 20:35   
Screenshots added
2023-12-29 00:31   
please set option TRACE with the beta whdload 19.0 and attach the created file .whdl_trace
2024-01-03 11:22   
[03-Jan-24 11:18:20.98 6626] performing Slave Update Check for 'ProjectXSE.Slave', Stack='Roadshow 4.347 (29.11.2019)'
[03-Jan-24 11:18:21.06 6626] connecting to host 'cgi.whdload.net' ip=$5CCDC25C port=80
[03-Jan-24 11:18:21.06 6626] Can't bind TCP socket: Cannot assign requested address

Trace added
2024-01-03 13:33   
So this seems to be a RoadShow problem.
I'm checking...
2024-01-03 13:58   
ticket opened: https://www.amigafuture.de/viewtopic.php?t=51522
2024-01-14 20:07   
I use Roadshow and have same problem.
Have tryed version 19.0 whit no luck.
But whit 18.2 it seems to work, can’t upload a picture.
I hope it can help to solve this probem.
2024-01-15 12:05   
@lumby, @MBry0
please run the attached program 'wildcard_bind_test' and quote the output here
2024-01-15 13:41   
please also check if attached WHDLoad fixes the problem
2024-01-15 16:21   

was successful.
socket addresser =

WHDLoad 19.0 [build 6722]
Tryed “Karting Grand Prix (Anco)” and no popup with info abort a slave update.
But with 18.2 popup came up with a warming.
2024-01-16 21:43   
can you please retry the attached whdload?
2024-01-18 13:25   
Tested but unfortunately still no popup.
Same with WinUAE with “Expansions” bsdsocket.library
2024-01-20 18:57   
bind() was succesful.
socket address =

The attached WHDLoad doesn't check for the slave, as the 19beta.
2024-01-21 14:34   
Ok, thanks for the info.
It seems that there is now a normal time for loading.
So hope this is resolved and everything works when you publish verion 19.
2024-01-27 23:28   
Can you please test wildcard_bind_test2 and quote the result?
2024-01-28 16:54   
Ok here is the test with wildcard_bind_test2:
Cannot bind adress to socket (49, ).
2024-01-29 12:22   
Thanks, please try attached WHDLoad. It should fix the issue.
2024-01-29 16:13   
Sorry same error code.

WHDLoad 19.0 [build 6725]
Cannot bind adress to socket (49, )
2024-01-29 17:01   
please attach trace of WHDLoad 19.0 [build 6725]
2024-01-30 16:55   
Can you please explain to me, how I make a trace of WHDLoad.
2024-01-30 21:25   
set option TRACE and attach the created file .whdl_trace
2024-01-31 17:20   
Hooray I just tried "Dylan Dog: The Murderers" and the splash screen came up with "Update slave" and iBrowse opens the page.
But couldn't get TRACE to work.
2024-02-03 10:24   
Just tried whdload 19.06725, and everything works as expected.
Thanks for the support.
2024-02-03 18:39   
Thanks for testing. New beta 19.0 released.

Issue History
2023-01-10 10:05MBry0New Issue
2023-01-12 13:52Paul HeadNote Added: 0012299
2023-01-12 17:39MBry0Note Added: 0012302
2023-01-13 12:53Paul HeadNote Added: 0012308
2023-01-13 17:10MBry0Note Added: 0012309
2023-01-14 16:00administratorAssigned To => administrator
2023-01-14 16:00administratorStatusnew => assigned
2023-01-14 16:00WeplAssigned Toadministrator => Wepl
2023-01-14 19:16WeplNote Added: 0012312
2023-01-16 20:08Paul HeadNote Added: 0012317
2023-01-16 20:09Paul HeadNote Added: 0012318
2023-01-16 21:48MBry0File Added: .whdl_trace
2023-01-16 21:48MBry0Note Added: 0012319
2023-01-16 21:48MBry0Note Added: 0012320
2023-01-18 17:57WeplNote Added: 0012326
2023-02-13 11:17AfebriwynNote Added: 0012449
2023-02-23 23:07WeplDescription Updatedbug_revision_view_page.php?rev_id=1585#r1585
2023-02-23 23:11WeplSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=1587#r1587
2023-03-09 21:50WeplNote Added: 0012475
2023-03-09 21:52WeplNote Edited: 0012475bug_revision_view_page.php?bugnote_id=12475#r1591
2023-03-12 16:08WeplNote Added: 0012498
2023-03-12 16:08WeplStatusassigned => resolved
2023-03-12 16:08WeplResolutionopen => no change required
2023-10-14 23:27WeplStatusresolved => closed
2023-12-27 19:38MBry0Statusclosed => feedback
2023-12-27 19:38MBry0Resolutionno change required => reopened
2023-12-27 19:38MBry0Note Added: 0013463
2023-12-28 13:14WeplNote Added: 0013464
2023-12-28 13:15WeplStatusfeedback => resolved
2023-12-28 13:15WeplResolutionreopened => fixed
2023-12-28 13:15WeplFixed in Version => 19.0beta
2023-12-28 13:15WeplTarget Version => 19.0
2023-12-28 20:33MBry0Statusresolved => feedback
2023-12-28 20:33MBry0Resolutionfixed => reopened
2023-12-28 20:33MBry0Note Added: 0013465
2023-12-28 20:35MBry0File Added: IMG_20231228_202423.jpg
2023-12-28 20:35MBry0File Added: IMG_20231228_202538.jpg
2023-12-28 20:35MBry0Note Added: 0013466
2023-12-28 20:35MBry0Statusfeedback => assigned
2023-12-29 00:31WeplNote Added: 0013467
2024-01-03 11:22MBry0File Added: -2.whdl_trace
2024-01-03 11:22MBry0Note Added: 0013482
2024-01-03 13:33WeplNote Added: 0013483
2024-01-03 13:58WeplNote Added: 0013484
2024-01-14 20:07LumbyNote Added: 0013507
2024-01-15 12:04WeplFile Added: wildcard_bind_test
2024-01-15 12:05WeplNote Added: 0013508
2024-01-15 13:40WeplFile Added: WHDLoad
2024-01-15 13:41WeplNote Added: 0013509
2024-01-15 16:21LumbyNote Added: 0013510
2024-01-16 21:43WeplFile Deleted: WHDLoad
2024-01-16 21:43WeplFile Added: WHDLoad
2024-01-16 21:43WeplNote Added: 0013512
2024-01-18 13:25LumbyNote Added: 0013518
2024-01-20 18:57MBry0Note Added: 0013523
2024-01-21 14:34LumbyNote Added: 0013530
2024-01-27 23:27WeplFile Added: wildcard_bind_test2
2024-01-27 23:28WeplNote Added: 0013551
2024-01-28 16:54LumbyNote Added: 0013556
2024-01-29 12:21WeplFile Deleted: WHDLoad
2024-01-29 12:22WeplFile Added: WHDLoad
2024-01-29 12:22WeplNote Added: 0013557
2024-01-29 16:13LumbyNote Added: 0013558
2024-01-29 17:01WeplNote Added: 0013559
2024-01-30 16:55LumbyNote Added: 0013564
2024-01-30 21:25WeplNote Added: 0013566
2024-01-31 17:20LumbyNote Added: 0013568
2024-02-03 10:24MBry0Note Added: 0013577
2024-02-03 18:39WeplStatusassigned => resolved
2024-02-03 18:39WeplResolutionreopened => fixed
2024-02-03 18:39WeplNote Added: 0013578