The shmem_receiver doesn't properly track the previous gps, which may keep it from handling cycle jumps properly.

While looking at daq restarts on the test stand we got the following log output.

Oct 27 15:17:39 x2daqdc1 daqd[2600]: Dropped data from shmem or received 0 dcus; gps now = 1287865078, 0; was = 1287865077, 3; dcu count = 3
Oct 27 15:17:39 x2daqdc1 daqd[2600]:         expected gps = 1287865077
Oct 27 15:17:39 x2daqdc1 daqd[2600]:         expected cycle = 4
Oct 27 15:17:39 x2daqdc1 daqd[2600]:         expected nano = 4
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 4
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 5
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 6
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 7
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 8
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 9
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 10
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 11
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 12
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 13
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 14
Oct 27 15:17:39 x2daqdc1 daqd[2600]: shmem_receiver looking for gps=1287858805 found 1287865076 on cycle 15

The interesting point is the note of what gps was being looked for 1287858805, not 1287865077. The 1287858805 ended up being the start time of the daqd. The shmem_receiver was not tracking the previous gps, so that when there was a skip it was looking for the wrong next data point. In this specific case there was no recovery, however it had been a case of a long running daqd cycle and the data was actually there the daqd would have failed to recover, even though it could.