|
Notes |
|
|
|
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. |
|
|
|
(0012302)
|
|
MBry0
|
|
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. |
|
|
|
|
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? |
|
|
|
(0012309)
|
|
MBry0
|
|
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. |
|
|
|
(0012312)
|
|
Wepl
|
|
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. |
|
|
|
|
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.
@MBry0
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 ;-) |
|
|
|
|
|
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. |
|
|
|
(0012319)
|
|
MBry0
|
|
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. |
|
|
|
(0012320)
|
|
MBry0
|
|
2023-01-16 21:48
|
|
|
|
|
(0012326)
|
|
Wepl
|
|
2023-01-18 17:57
|
|
|
|
|
|
Hello,
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... |
|
|
|
(0012475)
|
|
Wepl
|
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.
|
|
|
|
(0012498)
|
|
Wepl
|
|
2023-03-12 16:08
|
|
|
The website has been moved to different datacenter. This problem doesn't appears anymore. |
|
|
|
(0013463)
|
|
MBry0
|
|
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 (92.205.194.92) in IBrowse 2.5.5, and I get the expected conection timeout after a couple of minutes. |
|
|
|
(0013464)
|
|
Wepl
|
|
2023-12-28 13:14
|
|
|
|
|
(0013465)
|
|
MBry0
|
|
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. |
|
|
|
(0013466)
|
|
MBry0
|
|
2023-12-28 20:35
|
|
|
|
|
(0013467)
|
|
Wepl
|
|
2023-12-29 00:31
|
|
|
please set option TRACE with the beta whdload 19.0 and attach the created file .whdl_trace |
|
|
|
(0013482)
|
|
MBry0
|
|
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 |
|
|
|
(0013483)
|
|
Wepl
|
|
2024-01-03 13:33
|
|
So this seems to be a RoadShow problem.
I'm checking... |
|
|
|
(0013484)
|
|
Wepl
|
|
2024-01-03 13:58
|
|
|
|
|
(0013507)
|
|
Lumby
|
|
2024-01-14 20:07
|
|
Hi,
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. |
|
|
|
(0013508)
|
|
Wepl
|
|
2024-01-15 12:05
|
|
@lumby, @MBry0
please run the attached program 'wildcard_bind_test' and quote the output here |
|
|
|
(0013509)
|
|
Wepl
|
|
2024-01-15 13:41
|
|
|
please also check if attached WHDLoad fixes the problem |
|
|
|
(0013510)
|
|
Lumby
|
|
2024-01-15 16:21
|
|
Hi,
wildcard_bind_test
was successful.
socket addresser = 0.0.0.0:1033
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. |
|
|
|
(0013512)
|
|
Wepl
|
|
2024-01-16 21:43
|
|
|
can you please retry the attached whdload? |
|
|
|
(0013518)
|
|
Lumby
|
|
2024-01-18 13:25
|
|
Hi,
Tested but unfortunately still no popup.
Same with WinUAE with “Expansions” bsdsocket.library |
|
|
|
(0013523)
|
|
MBry0
|
|
2024-01-20 18:57
|
|
bind() was succesful.
socket address = 0.0.0.0:1028
The attached WHDLoad doesn't check for the slave, as the 19beta. |
|
|
|
(0013530)
|
|
Lumby
|
|
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. |
|
|
|
(0013551)
|
|
Wepl
|
|
2024-01-27 23:28
|
|
|
Can you please test wildcard_bind_test2 and quote the result? |
|
|
|
(0013556)
|
|
Lumby
|
|
2024-01-28 16:54
|
|
Ok here is the test with wildcard_bind_test2:
Cannot bind adress to socket (49, ). |
|
|
|
(0013557)
|
|
Wepl
|
|
2024-01-29 12:22
|
|
|
Thanks, please try attached WHDLoad. It should fix the issue. |
|
|
|
(0013558)
|
|
Lumby
|
|
2024-01-29 16:13
|
|
Sorry same error code.
WHDLoad 19.0 [build 6725]
Cannot bind adress to socket (49, ) |
|
|
|
(0013559)
|
|
Wepl
|
|
2024-01-29 17:01
|
|
|
please attach trace of WHDLoad 19.0 [build 6725] |
|
|
|
(0013564)
|
|
Lumby
|
|
2024-01-30 16:55
|
|
|
Can you please explain to me, how I make a trace of WHDLoad. |
|
|
|
(0013566)
|
|
Wepl
|
|
2024-01-30 21:25
|
|
|
set option TRACE and attach the created file .whdl_trace |
|
|
|
(0013568)
|
|
Lumby
|
|
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. |
|
|
|
(0013577)
|
|
MBry0
|
|
2024-02-03 10:24
|
|
Just tried whdload 19.06725, and everything works as expected.
Thanks for the support. |
|
|
|
(0013578)
|
|
Wepl
|
|
2024-02-03 18:39
|
|
|
Thanks for testing. New beta 19.0 released. |
|
.whdl_trace (5,536) 2023-01-16 21:48
IMG_20231228_202423.jpg (189,152) 2023-12-28 20:35