"Support" in this instance means that it will quietly ignore the events, since there's really
nothing to import. But this means that parsing will correctly continue past the events, even
though so far they're the only events in a session. There are diagnostics to log if that
assumption turns out not to be correct.
Still trying to figure out timestamp event.
Other summary parsers will need review, since there was an initial
filter that was dropping sessions that began with event 5 or 6,
now commented out.
Based on the F0V23 loop and F0V6 switch statement, along with manual review of
several sample files to determine record length.
Split ParseHumidifierSettingF0V4 out from ParseSettingsF0V4.
These are events that are in the PRS1 files but which OSCAR doesn't know how to present:
- An F0V6 event with duration that looks like PB or LL but doesn't appear on any official reports
- The Auto-CPAP pressure to use at the beginning of a session
- A report of the snores detected at each pressure/EPAP/IPAP
- Apnea alarms on F3V6
Rather than bury the understanding in commented-out sections of the parser, these events
will now be parsed and added to the internal event stream, which allows them to be dumped
to YAML. Whenever OSCAR eventually supports these data, the importer will have ready
access to them.
Again, no change to external behavior.
This only affects the parser at this point, and the importer has been updated so that
there is no externally visible change to the imported data.
Eventually we'll need to figure out how to display the two differing kinds of
pressures, at which point we'll need to fix the importer to use the right channels,
instead of the inconsistent treatment now.
The next step will be to split parsing from mode interpretation, so that
we can at least accurately identify all of PRS1's modes. Then we can
work on mapping that to OSCAR's notion of modes, which probably then needs
to be augmented.
to act differently from profiles after a subsequent application launch.
It was only getting set at the end of Profile::OpenMachines, which was only
called by the Profile constructor, and which wouldn't succeed on a newly created
profile, having no files to open. Therefore, the only way for the flag to be set
was to quit and re-launch the application after creating the profile.
The flag's only remaining use was to make sure that OpenMachines() wasn't
getting called twice and trampling an existing list of machines, so the check
there was changed from looking at a brittle flag to looking at the actual list
of machines.
A critical warning was also added to the check, since OpenMachines() is
only getting called from the Profile constructor and therefore can't
be invoked twice unless a new bug has been introduced.
duplicate sessions being added when making preference changes to a brand new
profile with existing data.
Preference changes trigger a reload, see PreferencesDialog::Save and
needs_reload, leading to MainWindow::reloadProfile -> MainWindow::CloseProfile
-> Profile::UnloadMachineData.
This is the root cause of the duplicate sessions, but the fact that it only
happened with newly created profiles, rather than on subsequent launches,
demonstrates an inconsistency in state of Profile. It should be identical when
initially created and when loaded via subsequent application launch.
This prevents duplicate sessions from being added to Day during a rebuild, but is still not
the root cause. The next step will be to address the attempted duplication in Machine.
