11.4. What’s Fixed in 6.1.1¶
11.4.1. Recording Service unable to create directory on Windows Systems¶
When starting Recording Service, an error creating a directory caused the service to shut down. This was due to Recording Service using the time format “HH:MM:SS”, which cannot be used on Windows systems to create directories. This problem has been resolved by changing the time format to “THHMMSS”.
[RTI Issue ID RECORD-1059]
11.4.2. Replay Service and Converter did not shutdown when data streams had missing type information¶
Replay Service and Converter did not properly handle the case in which a data stream did not include its type information (it wasn’t recorded or provided in XML). This resulted in the service being unable to shutdown automatically, because it was waiting for type information that was not available.
This problem has been resolved. Now when the type cannot be found, a new message is logged, stating that the stream reader was not created, and the replay/conversion for that stream will not occur.
[RTI Issue ID RECORD-1118]
11.4.3. Storage of duplicate Discovery information affected database replay¶
Recording Service may have stored duplicate discovery information if more than one DataWriter is created for the same topic at a different time.
Consequently, Replay Service could not detect the end of the replay. Due to this issue, users could not loop over the database or shut down the service automatically. This issue has been resolved.
[RTI Issue ID RECORD-1198]
11.4.4. Output from ‘-help’ was missing some updates¶
The output of the -help command-line option for Recording Service, Replay Service, and
Converter, was out of date.
The option
-ignoreXsdValidationwas not described.The description of
-verbosityshould have shown its new syntax, which allows you to set the verbosity for Service and DDS log messages: (<service level>[:<dds level>]).The description of
-logFormatwas missing the VERBOSE option.
This issue has been resolved, -help has been updated.
[RTI Issue IDs RECORD-1224, RECORD-1258]
11.4.5. DataReader created after a pause was not affected by the pause¶
If a DataReader was created after replay was paused, that DataReader did not pause. Instead it used the elapsed pause time as part of the elapsed replay time. This caused the DataReaders to become out of sync. This issue has been resolved.
[RTI Issue ID RECORD-1259]
11.4.6. DataReader created after rate change did not use new rate¶
A DataReader created after a replay rate change did not have its rate updated accordingly. The new DataReader continued using the initial rate. This caused the DataReaders to become out of sync. This issue has been resolved.
[RTI Issue ID RECORD-1260]
11.4.7. Remotely updating replay rate caused error in time calculation¶
If the replay rate was remotely updated in the middle of a replay, the elapsed replay time moved forward or backward in time due to a calculation issue. This caused a complete loss of fidelity. This issue has been resolved.
[RTI Issue ID RECORD-1261]
11.4.8. Incorrect example in Service API documentation¶
The documentation for the Service API includes an example of how to
use the API. In this example, the ServiceProperty used cfg_name, when
it should have used service_name. The documentation has been corrected.
[RTI Issue ID RECORD-1262]
11.4.9. Recording Service became stuck while creating recording directory in some cases¶
When creating a directory for the output of a recording, the service may have
gotten stuck in a loop if you provided a directory name using the format %F%
to express the current date. It caused Recording Service to loop indefinitely until the
end of the day, when %F% changed. This issue only occurred if this scenario
happened twice on the same day, without removing the recorded directory.
This issue has been resolved.
[RTI Issue ID RECORD-1265]
11.4.10. Decimal playback rates truncated by Remote Administration¶
Setting the playback rate to a decimal value through Remote Administration did not work as expected. The rate was truncated, or if less than 1, the service did not change the rate and logged an error. This problem has been resolved.
[RTI Issue ID RECORD-1276]
11.4.11. Replay Service’s Monitoring ServicePeriodic topic showed wrong timestamp¶
During Replay, the Monitoring ServicePeriodic topic published the wrong
timestamp. The field current_timestamp_nanos was incorrectly set to
the current system time. Instead, it should have been set to the
timestamp at which the data was replayed, relative to the recorded time.
This issue has been resolved, now current_timestamp_nanos shows the
correct timestamp, so you can understand where you are in the replay.
[RTI Issue ID RECORD-1277]
11.4.12. Debug operations ‘next_slice’ and ‘continue’ did not work as expected¶
The Debug mode operations “next_slice” and “continue” had some issues creating their own breakpoint. First, they used the wrong timestamp to set their breakpoint. Therefore you may have resumed the replay for longer than expected. Also, concatenating the next_slice and continue operations caused a delay in receiving new samples after resuming the replay. This caused a loss of replay fidelity. Both issues have been resolved.
[RTI Issue ID RECORD-1283]
11.4.13. Recording Service crashed when XML configuration had duplicate names¶
Duplicate names in an XML configuration caused Recording Service to crash.
For example, consider this configuration:
...
<session name="A">
...
<topic_group name="A">
...
Recording Service could not properly create the topic group and crashed when it started receiving samples. This problem has been resolved; duplicate names will no longer cause a crash.
[RTI Issue ID RECORD-1311]