Ever since I downloaded (or rather file requested) a nodelist for my "othernet", I get this error message after each poll:
ÚÄ Error ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ ³
³ Datei(en) wurde(n) nicht korrekt entpackt! 00:06 ³
³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
I have disabled the processing for the other nodelist, but it looks
like something wants to "process".
ÚÄ Error ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ ³
³ Datei(en) wurde(n) nicht korrekt entpackt! 00:06 ³
³ ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
I have disabled the processing for the other nodelist, but it looks
like something wants to "process".
Would it help if you recieved that file with a tic?
You could send a message to Filefix with ..
%resend <file> <filearea>
in the message body and Filefix will send you the file along with a .tic
if the file is found.
I'd like to have the FSXNET nodelist handy (for lookups and browsing
with oxp). But seems that oxp expects a DIFF file.
His node is 21:4/101.
(Martin.. are you listening?)
[snip]
(Martin.. are you listening?)
I'm always listening :-))
I've freq'd a copy of FSXNET.Z94 from Alan's system, installed it in
my Linux installation of OpenXP and I cannot reproduce your problem. Everything works as expected with FSXNET.Z94 still in my 'files'
directory and not presenting me with any problems.
However, I've just noticed that the last line of FSXNET.094 comprises
one single extended ascii character which I don't think should be
there. Maybe the Windows version of OpenXP doesn't like that character
for some reason. Might I suggest that you delete that character, save
the file and then try again.
ÚÄ Error ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ ³
³ Datei(en) wurde(n) nicht korrekt entpackt! 00:06 ³
³ ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
I have disabled the processing for the other nodelist, but it looks
like something wants to "process".
Would it help if you recieved that file with a tic?
I dunno. It sounds like oxp might be looking for a DIFF file, but I
don't have that part enabled at all. But maybe the mere existance of FSXNET.Z94 in the /FILES directory triggers something to cause the above message.
But.. if I *just* delete the archive in the /FILES directory, oxp locks
up on the next poll. But.. if I then delete the whole FSXNET nodelist, everything works as normal.
I'd like to have the FSXNET nodelist handy (for lookups and browsing with oxp). But seems that oxp expects a DIFF file.
(Martin.. are you listening?)
Let's hope it doesn't lockup after this poll.
Further to my two previous ramblings, I don't get the error message
that you're getting but I do get the lockup after a poll. Actually,
it's the dreaded endless loop rather than a lockup but I digress.
I'm hoping I've fixed this with a bit of a workaround .....
Even though FSXNet don't distribute diffs, I've added some "dummy"
data in the "Update file" and "Update archive" fields: FSXNET_D.###
and FSXNET_D.Z## respectively and this appears to have fixed it.
To test my workaround, I posted a test shot in FIDOTEST and there was
no lockup after the poll. Let's hope it doesn't lockup after this
poll.
I've freq'd a copy of FSXNET.Z94 from Alan's system, installed it in
my Linux installation of OpenXP and I cannot reproduce your problem.
Everything works as expected with FSXNET.Z94 still in my 'files'
directory and not presenting me with any problems.
However, I've just noticed that the last line of FSXNET.094 comprises
one single extended ascii character which I don't think should be
there. Maybe the Windows version of OpenXP doesn't like that character
for some reason. Might I suggest that you delete that character, save
the file and then try again.
In all the time I've been in fsxNet I have never seen a DIFF, I don't
think they produce one.
Hello Al,
His node is 21:4/101.
Make that 21:1/101.. :)
I've freq'd a copy of FSXNET.Z94 from Alan's system, installed it..
However, I've just noticed that the last line of FSXNET.094 comprises
one single extended ascii character which I don't think should be
there. Maybe the Windows version of OpenXP doesn't like that
character for some reason. Might I suggest that you delete that character, save the file and then try again.
In all the time I've been in fsxNet I have never seen a DIFF, I
don't think they produce one.
It's not critical. This matter just seems specific to how oxp works.
It can "update" a nodelist (manually or automatically), but only if
there is a diff.
Otherwise, an update from an existing full nodelist to newer edition
has to be done manually.
Not many nodes even do freq. Only 3 systems do.
His node is 21:4/101.
Make that 21:1/101.. :)
No problem. With an integrated nodelist, I can just look it up! <G>
And oxp can pre-fill the address for a message.
Apparently, all of these are "Paul Hayton":
I'm going to ask Paul about this. It may be simple for him to do, or not
I'm not sure but I'll ask.
Not many nodes even do freq. Only 3 systems do.
I've found a simple utility to install for windows/linux binkd. I'll see
if I can pass it on to a couple nodes who could use it.
It's an external SRIF utility that's needed for binkd that is not well
known.
It's an external SRIF utility that's needed for binkd that is not
well known.
I don't know what SRIF is. Google tells me it's a somatotropin
release inhibiting factor. LOL
I thought most bbs softwares (especially sychro and mystic, the
majority in fsxnet?) supported freq, built-in.
It's an external SRIF utility that's needed for binkd that is not
well known.
I don't know what SRIF is. Google tells me it's a somatotropin
release inhibiting factor. LOL
I thought most bbs softwares (especially sychro and mystic, the
majority in fsxnet?) supported freq, built-in.
Not many nodes even do freq. Only 3 systems do.
I've found a simple utility to install for windows/linux binkd.
I'll see if I can pass it on to a couple nodes who could use it.
It's an external SRIF utility that's needed for binkd that is not
well known.
The problem/lockup seems to start as soon as it sees another FSXNET.Z**
in the /FILES dir.
I've freq'd a copy of FSXNET.Z94 from Alan's system, installed it..
Try freq'ing it again, but this time from his Zone 21 entry.
When I try to freq to his 21: address, oxp is calling Tommi's system:
WTF?
The problem/lockup seems to start as soon as it sees another FSXNET.Z**
in the /FILES dir.
After f'reqing another copy of FSXNET.Z94 from Alan's system and then
polling Richard, no problems arose with the existance of FSXNET.Z94
sitting in my 'files' directory.
[snip]Try freq'ing it again, but this time from his Zone 21 entry.
OK .....
..... that went perfectly.
When I try to freq to his 21: address, oxp is calling Tommi's system:
How strange ????
However, I've seen a similar problem to this before but under
different circumstances. Go to "Fido", cursor over "Crash", press <F1>
and then have a read of the "IMPORTANT NOTE" near the bottom of the
help text. I suspect that the solution to your problem may be lurking
somewhere amongst that lot. Best of luck ;)
It's an external SRIF utility that's needed for binkd that is not
well known.
Oh, that sounds very interesting and useful, is it available for f'req
from your system?
However, I've seen a similar problem to this before but under different
circumstances. Go to "Fido", cursor over "Crash", press <F1> and then
have a read of the "IMPORTANT NOTE" near the bottom of the help text. I
suspect that the solution to your problem may be lurking somewhere
amongst that lot. Best of luck ;)
It that your writing in the F1 help? <G>
Meanwhile, I discovered a workaround/alternative that does NOT require mucking about with switching the primary server settings.
I'll reveal the aptly named August-Solution a lil'bit later.
I have also used FREQ-U by Fred Riccio in the past with good results. I have the linux version available here as FREQ-U.ZIP and the Windows version as FU_W32.ZIP.
Is that your writing in the F1 help? <G>Whatever makes you think that :-))
I'll reveal the aptly named August-Solution a lil'bit later.Come on then, the suspense is killing :-))
I'll reveal the aptly named August-Solution a lil'bit later.
Come on then, the suspense is killing :-))
You got it wrong. Suspense is *thrilling*. Covid is killing.
I'll work on a proper reply to "the solution" later today.
HERE, as promised is the "August-Solution" or the workaround/alternative that does NOT require mucking about with switching the primary server settings.
I have two servers:
[1] Tommi, fidonet = primary
[2] Alan, fsxnet
When I wanted to freq a file from [1], I never encountered an "issue" because OXP always uses the primary
When I wanted to freq a file from [2], it would always call [1]
When I wanted to freq a files from anyone else, the freq would always
work - because those systems were NOT listed as servers.
SO.. the solution: If I want to freq a file from [2] (and avoid reconfiguring the primary server), simply do this:
(are you ready? here's the answer)
(I promise to stop goofing around and delaying the answer)
After creating the freq to [2], simply allow OXP to do a normal POLL to the [2] server via the N A or N S commands.
Maybe a variation of the last sentence above can make its way into the
OXP Help system?
This strategy would probably apply nomatter how many additional servers are added. Simply allow OXP to POLL the server for which the freq is intended.
This strategy would probably apply nomatter how many additional servers
are added. Simply allow OXP to POLL the server for which the freq is
intended.
Yup, I don't see any reason why it shouldn't.
So, the documentation needs clarity on how Freq's are an exception to the Crash rule.
The problem/lockup seems to start as soon as it sees another FSXNET.Z**
in the /FILES dir.
After f'reqing another copy of FSXNET.Z94 from Alan's system and then
polling Richard, no problems arose with the existance of FSXNET.Z94
sitting in my 'files' directory.
HOWEVER.. (get this..) OXP actually updated the nodelist! The config had the dummy diff config file FSXNET.Z## active at that time:^^^^^^ ^^^^^^ ^^^^^^
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Z2PNT.### 115 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist
³ NODELIST.### 122 NODEDIFF.### NODEDIFF.Z## Diff Nodelist
³ FSXNET.### 122 FSXNET.### FSXNET.Z## Diff Nodelist <====
³ micronet.### 108 MICRONET.### MICRONET.Z## Diff Nodelist
The dummy diff entry was present.
SO.. it looks like I have to either enable this for the FSXNET entry:
[x] Delete update after processing
OR.. run a batch program to check for and delete all FSXNET.Z* files in the /FILES directory every time OXP starts up.
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ^^^^^^ ^^^^^^ ^^^^^^
³ Z2PNT.### 115 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist
³ NODELIST.### 122 NODEDIFF.### NODEDIFF.Z## Diff Nodelist
³ FSXNET.### 122 FSXNET.### FSXNET.Z## Diff Nodelist <====
The nodediff cannot have the same filename as the nodelist.
³ micronet.### 108 MICRONET.### MICRONET.Z## Diff Nodelist
The dummy diff entry was present.
Change the names of the diffs to FSXNET_D.### and FSXNET_D.Z## respectively.
SO.. it looks like I have to either enable this for the FSXNET entry:
[x] Delete update after processing
Nope, shouldn't have to do that.
Anyway.. the dummy diffs are now in place:^^^^^^^^^^^^ ^^^^^^^^^^^^
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Z2PNT.### 115 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist
³ NODELIST.### 122 NODEDIFF.### NODEDIFF.Z## Diff Nodelist
³ FSXNET.### 122 FSXNET_D.### FSXNET_D.Z## Diff Nodelist
³ micronet.### 108 MICRONET_D.# MICRONET.Z## Diff Nodelist
We shall see what this week's files trigger.
Anyway.. the dummy diffs are now in place:
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ^^^^^^^^^^^^ ^^^^^^^^^^^^
³ Z2PNT.### 115 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist
³ NODELIST.### 122 NODEDIFF.### NODEDIFF.Z## Diff Nodelist
³ FSXNET.### 122 FSXNET_D.### FSXNET_D.Z## Diff Nodelist
³ micronet.### 108 MICRONET_D.# MICRONET.Z## Diff Nodelist
Hmmmmm, these *might* cause problems but I could, of course, be wrong.
[snip]
We shall see what this week's files trigger.
Yes, indeed we will :)
::: UPDATE ::::
** On Tuesday 05.05.20 - 20:22, Martin Foster wrote to August Abolins:
Anyway.. the dummy diffs are now in place:
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Z2PNT.### 115 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist
³ NODELIST.### 122 NODEDIFF.### NODEDIFF.Z## Diff Nodelist
³ FSXNET.### 122 FSXNET_D.### FSXNET_D.Z## Diff Nodelist
³ micronet.### 108 MICRONET_D.# MICRONET.Z## Diff Nodelist
^^^^^^^^^^^^ ^^^^^^^^^^^^
Hmmmmm, these *might* cause problems but I could, of course, be wrong.
[snip]
We shall see what this week's files trigger.
Yes, indeed we will :)
Since that last post I now have this:
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Z2PNT.### 136 Z2PNT_D.### Z2PNT_D.Z## Diff FD Pointlist
³ NODELIST.### 136 NODEDIFF.### NODEDIFF.Z## Diff Nodelist
³ FSXNET.### 136 FSXNET_D.### FSXNET_D.Z## Diff Nodelist
³ micronet.### 122 MICRON_D.### MICRON_D.Z## Diff Nodelist
[x] Use internal nodelist processor
[x] Import nodelist updates automatically
[x] Automatic TIC file processing
That means the last few weeks of processing have been error-free and no lockups after a poll.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 376 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 23:40:29 |
| Calls: | 8,034 |
| Calls today: | 4 |
| Files: | 13,034 |
| Messages: | 5,828,974 |