Dear All,
Working with real time application, I use the Recorder to store any data that modify my model. When Replay, I just load the model and play the recorded updates.This design involves that the last row of recorded topics table has not the same timestamp in all topic. THe value is corresponding to the last modification, and sometimes, it is very less than the last timestamp.
When I tell the Replayer to go to a specific timestamp, by a global request (ie for all the topic of my unique session defined in the configuration file), everything goes well except when the last timestamp Topic is less than the one required : the replayer display a message for this Topic and remains in instable state!
It seems that when the topic table is empty the replayer is ok, but since there is one row, the last timestamp one must not exceed the one required.
Does this means that I have to choose among these solutions :
1. I need to manually duplicate the last row and update the timestamp to make the goto work
2.Use specific time_control in configuration by settings the stop_time according to the contents ( then the config will depend on the data, how weird)
3.Call a goto time for each Topic, but only for those whose last timestamp is compliant. Then, how the Replayer will manage the sent messages? Is there any way to avoid sequential gotos and force synchronization in replay?
Thanks for any help.
Stephane
Hi Stephane:
I'm not clear exactly what you are attempting, but perhaps I can offer a few observations that might help you to decide how to handle the problem.
When replay retrieves topic data for replay it uses an SQL query with "ORDER BY reception_timestamp". This should isolate Replay from issues about when the data was actually added to the file, since it would all just appear as an ordered list of samples.
However, Replay also assumes the base time for the database is the "creation time" of the database, which it obtains from the SQL query "SELECT MIN(Timestamp) from RTILog". You say in your post that your timestamps are "less than" the last timestamp. I would not be surprised if there was unexpected results if samples are added to the database that have a timestamp less than the "creation time" of the database. If you are adding samples to a database with timestamps that are BEFORE the creation time of the database, you might try adding an entry to the RTILog table with the new, lesser, timestamp, or editing the existing entry. That might help to establish a base time for the database that is before all of its contents (which is what Replay expects).
If that doesn't help your situation, you will probably need to manually update your timestamps in the database, as it appears that you are already doing.
As you have apparently discovered, Replay doesn't have tools to reorder or change the timestamps of samples within a single topic. On the contrary, Replay attempts to adhere to the original timeline as closely as possible. If there are large gaps in the timeline of a single topic, you have to either manually reposition Replay to bridge the gaps, or configure multiple replays of the single topic, each with a different timerange. As you say, the configuration will be dependent on the data, because Replay itself is ignorant of the timeline represented by the data, and cannot take it upon itself to reorder, compress, or otherwise distort the timeline."