Duration in metadata.yaml is wrong when bag is split by time and size (humble)

[andrewbest-tri]

Description

When recording a bag in humble, I expect the metadata.yaml duration field to be equal to last_message_timestamp - first_message_timestamp. However, it is set to whatever the split duration is when splitting by time, and some function of the split duration when splitting by size.

Expected Behavior

Record a bag for 30 seconds split at 5 second intervals. Metadata.yaml duration is 30 * 1e9

command I use ros2 bag record -a -d 5 -b 86016

Actual Behavior

Record a bag for 30 seconds with ros2 bag record -a -d 5 -b 86016

Inspect metadata.yaml. Duration is 5 * 1e9, the length of the split.

To Reproduce

** Steps to reproduce the behavior, e.g.

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. Logs print error '...' **

Terminal 1:

ros2 topic pub /foobar std_msgs/msg/Empty "{}"

Terminal 2:

ros2 bag record -a -d 5 -b 86016

wait 30 seconds. stop the bag. inspect.

System (please complete the following information)

• OS: Ubuntu Jammy
• ROS 2 Distro: Humble
• Version: Latest from APT

Additional context

We use a backport to foxy which shows this behavior in rosbag2, but that isn't a surprise as its the same codebase.

[emersonknapp]

Thanks for the report - this does indeed sound like incorrect behavior. If you have a fix with regression test, PRs are welcome, otherwise this will go on the backlog for when somebody can get to it.

[chaoflow]

I disagree, the fact that no messages were recorded since beginning and until the end of recording is valuable and a bag should contain that information independent of whether split or not.

[andrewbest-tri]

I disagree, the fact that no messages were recorded since beginning and until the end of recording is valuable and a bag should contain that information independent of whether split or not.

Maybe my example wasn't clear. There are two terminals. Every single split in the bag has messages but the duration metadata is still wrong. Does that clarify @chaoflow . I also don't think I understand. What is your expected behavior if the bag is empty? Duration 0? That makes sense to me but isn't what's happening here.

[chaoflow]

@andrewbest-tri I think that the start and end time should reflect the start and end of a recording, not the first and last message:

1. start time
2. first message >= start time
3. last message >= first message
4. end time >= last message

Duration = end time - start time

[MichaelOrlov]

I tend to agree with @chaoflow for the sake of consistency.
Although @andrewbest-tri talking about a bit different issue.
The original problem described in the issue is that the bag split is overwriting the original start time in the final metadata.
The problem is that we aren't keeping the original time start when doing bag split for writing it in the final metada yaml file.

On the rolling, we have implemented saving metadata inside bag for each file for SQLite3 and perhaps after #1423 will be accepted and merged we will have the same for MCAP. It will help to have the ability to store correct start and stop times for each bag after the split.

[l-schilling]

On the rolling, we have implemented saving metadata inside bag for each file for SQLite3 and perhaps after #1423 will be accepted and merged we will have the same for MCAP. It will help to have the ability to store correct start and stop times for each bag after the split.

Could this be backported to humble?

[MichaelOrlov]

@l-schilling See my closing notes at the #1473
It would be possible if would managed to upgrade mcap vendor package to the v1.1.0.
However, to do this we need to prove ABI compatibility in mcap vendor package. I am sorry but I don't have the resources to do this in the near future.

[MichaelOrlov]

• The issue with an incorrect start time in metadata.yaml file after the split was fixed in the [Humble] Fix split by time. (backport #1022) #1616
• Closing as fixed.