Provide info about the next bag file in the current bag file.

[ianstarz]

Description

When splitting bag files on max size and/or duration, it would be helpful to know when the following bag file begins. You cannot infer this based on the end time of a bag file, because the start time of the next bag file does not coincide. This is because the following bag file sets it start time based on the first message it contains, and not when the previous bag ended.

This would be helpful in downstream processing, where we want to publish the availability of logs for any given time segment, continuously as we upload individual bag files.

We are on Humble so we would like to introduce the change there and propagate.

Related Issues

This work might encounter #1413

Completion Criteria

Inside the metadata for a bag file add a new field struct:

next_bag_file:

• start_time

Other fields like name, first message time, etc could be added in follow up feature requests if needed.

Implementation Notes / Suggestions

Modify the previous bag file when the next bag file begins writing.

Testing Notes / Suggestions

I would need help with this.

[ianstarz]

I should note, that this information can be derived from the metadata.yaml file for a bag. In our case, we don't want to wait for this file if possible. This way we can publish availability statelessly on each file received by our downstream processing.

[emersonknapp]

We are on Humble so we would like to introduce the change there and propagate.

The intention is good but this is the opposite of the correct development workflow. Within ROS, at least in the core, we follow a gitflow-style development process, introducing new features and fixes first to the main branch (rolling), then port those as appropriate to active releases.

Back to the feature request - my understanding is that it's for a differentiation between "start of recording" vs "timestamp of first message". I think that's pretty reasonable but it does have nuances in implementation that I'm not 100% sure of at first glance. That could come out in code review though.

[ianstarz]

then port those as appropriate to active releases.

Sounds good, thanks.

I'll take a look at what is involved.

[chaoflow]

I think independent of whether split bags are in action, each bag file (not only the metadata.yaml) should contain the start time of recording and the end time of recording as it is valuable information whether messages have been published since the beginning of recording, pushed to the extreme by a recording without messages. In case of split bags the end time of previous should be equal to start time of subsequent.