I mentioned in my last post that I am continually requesting a set of directory holes that never seem to be filled. Specifically there are 29 holes in the directory. I have given the directory an "age" of "10 days" which means that holes older than 10 days are ignored. To understand this post you may need a reminder of how we determine which files are new based on old and new dates.
The request looks like this:
From:AC2CZ to PFS3-11 Ctrl: 3 Type: UI Cmd PID: bd FLG: 10 BLK_SIZE: f4
Hole 1: 09 Jan 19 11:41 19 Jan 38 03:14
Hole 2: 09 Jan 19 07:42 09 Jan 19 09:22
Hole 3: 09 Jan 19 00:08 09 Jan 19 02:26
Hole 4: 08 Jan 19 03:34 08 Jan 19 04:08
Hole 5: 08 Jan 19 01:56 08 Jan 19 03:18
Hole 6: 08 Jan 19 00:39 08 Jan 19 00:59
Hole 7: 07 Jan 19 00:41 07 Jan 19 01:49
Hole 8: 06 Jan 19 05:19 06 Jan 19 06:40
Hole 9: 06 Jan 19 03:40 06 Jan 19 05:01
Hole 10: 05 Jan 19 00:07 05 Jan 19 01:16
Hole 11: 04 Jan 19 08:11 04 Jan 19 09:03
Hole 12: 04 Jan 19 00:03 04 Jan 19 02:07
Hole 13: 03 Jan 19 10:26 03 Jan 19 12:13
Hole 14: 03 Jan 19 09:39 03 Jan 19 09:53
Hole 15: 03 Jan 19 08:39 03 Jan 19 08:50
Hole 16: 03 Jan 19 00:39 03 Jan 19 02:57
Hole 17: 03 Jan 19 00:09 03 Jan 19 00:37
Hole 18: 02 Jan 19 19:48 02 Jan 19 19:59
Hole 19: 02 Jan 19 10:43 02 Jan 19 13:03
Hole 20: 02 Jan 19 08:39 02 Jan 19 10:43
Hole 21: 02 Jan 19 06:07 02 Jan 19 07:40
Hole 22: 01 Jan 19 23:42 02 Jan 19 01:27
Hole 23: 01 Jan 19 09:15 01 Jan 19 11:33
Hole 24: 01 Jan 19 00:38 01 Jan 19 01:52
Hole 25: 01 Jan 19 00:00 01 Jan 19 00:00
Hole 26: 31 Dec 18 08:43 31 Dec 18 10:02
Hole 27: 31 Dec 18 08:00 31 Dec 18 08:43
Hole 28: 31 Dec 18 02:31 31 Dec 18 03:05
We then receive a Broadcast Directory entry for file 161a like this:
From:PFS3-11 to QST-1 Ctrl: 3 Type: UI Res PID: bd FLG: 20 FILE: 161a TYPE: 0 OFF: 0 E OLD: Thu Jan 10 10:25:50 EST 2019 NEW: Thu Jan 10 12:44:32 EST 2019 CRC: 179
FRAG: 161a 10 Jan 19 15:25 - 10 Jan 19 17:44 ->
MADE HOLE1: Frm: 09 Jan 19 11:41 To: 10 Jan 19 15:25
MADE HOLE2: Frm: 10 Jan 19 17:44 To: 19 Jan 38 03:14
We get another even newer file and it is processed the same way.
From:PFS3-11 to QST-1 Ctrl: 3 Type: UI Res PID: bd FLG: 20 FILE: 1614 TYPE: 0 OFF: 0 E OLD: Thu Jan 10 19:42:42 EST 2019 NEW: Thu Jan 10 20:42:42 EST 2019 CRC: ffbc
From:PFS3-11 to QST-1 Ctrl: 3 Type: UI Res PID: bd FLG: 20 FILE: 15fa TYPE: 0 OFF: 0 E OLD: Mon Jan 07 22:34:03 EST 2019 NEW: Tue Jan 08 02:20:37 EST 2019 CRC: 8a4c
It was uploaded 08 Jan at 05:37 according to our directory. With an old date of 08 Jan 05:37 and a new date of 08 Jan 06:41. But hold on. That is not what is in this Directory Broadcast Packet. It has an old date of Jan 7 22:34 and a new date of Jan 8 02:20. It is quite different. No wonder we can't fill out the holes! They seem to be shifting.
The "fix" for this bug is likely that we need to read and process all directory broadcasts that we receive and use it to update the map of the holes that we have. I presume the holes I am requesting are not real, but FS-3 is sending me the pieces to complete the map if I process it.
73 Chris g0kla/ac2Cz
Enter Comments Here:
| On: 01/17/19 11:11 Chris / g0kla said: |
More on this: The directory holes are stored in a separate data structure. It is updated based on the dates in the Directory Broadcast. But that update was not being called if the Pacsat File Header was already stored in the directory. That is now fixed and I update the PFH in the directory too, so the latest is stored. |
Copyright 2001-2021 Chris Thompson
Send me an email