| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0006002 | WHDLoad | [All Projects] General | public | 2023-01-10 10:05 | 2023-03-12 16:08 | ||||||||
| Reporter | MBry0 | ||||||||||||
| Assigned To | Wepl | Project Info | HD-Installer for OS-Killer http://whdload.de/ | ||||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||||||
| Status | resolved | Resolution | no change required | ||||||||||
| Product Version | 18.8 | ||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0006002: Very long loading times with network connected | ||||||||||||
| Description | Lately 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 Reproduce | Maybe 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 Information | Amiga 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. | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Machine | A1200 | ||||||||||||
| CPU | 68060 | ||||||||||||
| CPUSpeed | 66 | ||||||||||||
| ChipSet | AGA | ||||||||||||
| GFXCard | Other | ||||||||||||
| ChipMem | 2 MB | ||||||||||||
| FastMem | 96 (32+64, blizzard+scsi kit) | ||||||||||||
| Workbench | OS 3.2 | ||||||||||||
| KickROM | 47 - Kick 3.2 | ||||||||||||
| KickSoft | None | ||||||||||||
| WHDLoad | 18.7 | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Paul Head (reporter) 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. |
|
MBry0 (reporter) 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 (reporter) 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? |
|
MBry0 (reporter) 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. |
|
Wepl (manager) 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 (reporter) 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. @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 ;-) |
|
Paul Head (reporter) 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. |
|
MBry0 (reporter) 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. |
|
MBry0 (reporter) 2023-01-16 21:48 |
Log attached. |
|
Wepl (manager) 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. |
|
Afebriwyn (reporter) 2023-02-13 11:17 |
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... |
|
Wepl (manager) 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. |
|
Wepl (manager) 2023-03-12 16:08 |
The website has been moved to different datacenter. This problem doesn't appears anymore. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-01-10 10:05 | MBry0 | New Issue | |
| 2023-01-12 13:52 | Paul Head | Note Added: 0012299 | |
| 2023-01-12 17:39 | MBry0 | Note Added: 0012302 | |
| 2023-01-13 12:53 | Paul Head | Note Added: 0012308 | |
| 2023-01-13 17:10 | MBry0 | Note Added: 0012309 | |
| 2023-01-14 16:00 | administrator | Assigned To | => administrator |
| 2023-01-14 16:00 | administrator | Status | new => assigned |
| 2023-01-14 16:00 | Wepl | Assigned To | administrator => Wepl |
| 2023-01-14 19:16 | Wepl | Note Added: 0012312 | |
| 2023-01-16 20:08 | Paul Head | Note Added: 0012317 | |
| 2023-01-16 20:09 | Paul Head | Note Added: 0012318 | |
| 2023-01-16 21:48 | MBry0 | File Added: .whdl_trace | |
| 2023-01-16 21:48 | MBry0 | Note Added: 0012319 | |
| 2023-01-16 21:48 | MBry0 | Note Added: 0012320 | |
| 2023-01-18 17:57 | Wepl | Note Added: 0012326 | |
| 2023-02-13 11:17 | Afebriwyn | Note Added: 0012449 | |
| 2023-02-23 23:07 | Wepl | Description Updated | View Revisions |
| 2023-02-23 23:11 | Wepl | Steps to Reproduce Updated | View Revisions |
| 2023-03-09 21:50 | Wepl | Note Added: 0012475 | |
| 2023-03-09 21:52 | Wepl | Note Edited: 0012475 | View Revisions |
| 2023-03-12 16:08 | Wepl | Note Added: 0012498 | |
| 2023-03-12 16:08 | Wepl | Status | assigned => resolved |
| 2023-03-12 16:08 | Wepl | Resolution | open => no change required |
| Issue History |