Also add some debug messages to FV3 parsing. It's clear the current
approach is wrong. This looks a lot like the slices seen earlier,
since hbdata values appear more than once in a given file.
Also turn off summary YAML since the next bit of work will focus on
parsing.
It turns out the session end time was intentionally not being set in ParseSummary,
probably due to its unreliability. This may be revisited once things are more
stable, but for now the old behavior is retained.
This doesn't have much observable effect, other than reducing a
day's total usage time if there are periods with no breathing
detected. Most of the shortcomings were obscured by information
gleaned from the events and waveform files.
A PB event obviously can't start so late that its duration ends in the future!
The fix hasn't been applied to F0V4 or F0V6 yet, since those haven't been
tested yet.
Also fix a sign bug in EventList::AddEvent when there *is* unordered data.
Remarkably, this resulted in nearly no changes to the test output.
Only one session with 0 duration had its start/end times reset to 0,
since it will no longer get imported.
This doesn't fix the bigger bug where files are skipped based on
their filename rather than the actual chunk session IDs. That's
a trickier challenge for another day.
This introduces a very slight change UI behavior, where the user
will receive an alert if their machine has a supported family/version
but is a model number for which we don't have any test data.
Also, the user alert for an unsupported machine has been updated
to align with the actual underlying parsing limitations. It's
possible this will create some new warnings, but it doesn't seem
like any such machines would have worked anyway, in which case
an explanatory message is an improvement.
The "untested" alert will happen on import once per launch of OSCAR.
Ideally this would only happen the first time an untested machine is
imported, but that will require figuring out how to serialize an
additional value in the user's machine profile.
Only PRS1Import::ParseSummaryF0V23 has disappeared, being merged into
ImportSummary. The only change it needed to subsume the functionality of
all other variants was the addition of one extra setting.
The rest of the now-unused variants will be removed next.
Also move an extra unsupported check out of PRSImport::ImportSummary
into CreateMachineFromProperties, where it should intervene before
reaching PRS1Import. Leave a warning debug message in its place.
This isn't fully tested yet, since I don't currently have fileVersion 2 samples.
It has been tested with 200X devices and doesn't change behavior there,
but the slice parsing immediately bails, so it's not really being exercised.
It seems very weird that "slices", whatever they are, would only show
up on bricks, the least capable devices. This needs more investigation.
This looks discouragingly redundant at first glance, but eventually
the import stage will probably be unified across all families, leaving
the parsers the only difference. That'll happen after all summary
importers have been split.
This looks even uglier than the F5V3 event split for now,
since portions of the fileVersion 3 parsing are still stuck in
PRS1Import, and can't be reasonably moved until all the parsers
are split into PRS1DataChunk.
Also, PRS1ParsedSettingEvent may be the wrong abstraction. That's
a first attempt, so that it can inherit PRS1ParsedEvent's notion
of gain and unit, and because m_parsedData is currently a list
of PRS1ParsedEvent pointers. But it has no notion of time (start=0)
and requires yet another enum to specify which setting it
represents.
This should be revisited once all the parsers have been split
and the summary parsing can be examined in more detail.
This doesn't look much prettier yet, since it requires double the
switch statements, but the expectation is that once all event
parsers are split out from import, the import routines will be
identical among all machines, and can then be consolidated.
Regardless, it's important to drive a wedge between file parsing
and the internal database structure.
Now that we check header checksums, it uncovered a problem parsing 1160P event
headers. It turns out that the 1160P uses a "waveform" header for its .002
events files. So we can't use the file extension to decide which header to
parse, but there's a flag in the standard header that seems to reliably indicate
a waveform header. The 1160P events are listed at fixed intervals, as are
waveforms, so the flag has been named "interval" rather than "waveform."
The 1160P event headers have more than 2 signals in the header and an interval
longer than 1sec. This clarified the meaning of multiple waveform header fields
that were previously being parsed incorrectly.
