Uncertain behavior of rosbag play when restoring corrupted bag files

Question

When a rosbag file is restored from a backup, the goal is to confirm that all original messages are present and unmodified. The standard workflow relies on rosbag check to flag internal index or CRC errors, followed by rosbag play to replay the data. However, the tool offers no automated comparison between the replayed stream and the source bag, and it is unclear whether rosbag play emits any warning or log entry when it encounters corrupted or truncated segments.
Additionally, the documented behavior for handling a partially corrupted file—such as a missing CRC or an incomplete index—is not fully defined. The tool may silently skip messages, potentially leaving the restored bag incomplete without notifying the user.
Given this ambiguity, the following questions arise:

Does rosbag play provide any notification or log output when it skips messages due to corruption?
Is there a documented method to automatically compare the replayed stream against the original bag to verify fidelity?
How does the handling of truncated indexes or missing CRC differ between ROS 1 (Melodic, Noetic) and ROS 2 (Foxy, Humble) when restoring a corrupted bag?

Tasadduq Burney · Answer

Answer
Does rosbag play notify when it skips messages due to corruption?

Confirmed fact (ROS 1): When a read error (CRC mismatch, missing index) occurs, rosbag play prints an error to stderr and stops playback unless --quiet is used.
Confirmed fact (ROS 2): ros2 bag play continues after a deserialization error, logs a WARN such as [WARN] [bag_play]: Failed to deserialize message on topic X, skipping, and increments a dropped‑message counter shown in the final summary.

Is there a built‑in automated comparison between the replayed stream and the original bag?
Likely explanation: Neither ROS 1 nor ROS 2 provides a direct diff mechanism; users must record the playback output to a temporary bag and then compare message counts or topics manually.
How does handling of a truncated index or missing CRC differ between ROS 1 and ROS 2?

ROS 1: If the index is missing or corrupted, rosbag play falls back to sequential byte‑by‑byte reading. This can cause silent message loss; rosbag check will flag the index problem beforehand.
ROS 2: The bag format stores a separate SQLite index. When that index is absent or corrupt, ros2 bag play refuses to open the bag and returns an error, preventing silent data loss.

Verification steps for this case

Run rosbag check 'bagfile' (ROS 1) or ros2 bag info 'bagfile' (ROS 2) to confirm the index/CRC status.
Play the bag with increased verbosity:
  
    ROS 1: rosbag play --verbose 'bagfile' 2> play.log
    ROS 2: ros2 bag play --log-level debug 'bagfile' 2> play.log

Inspect play.log for:
  
    ROS 1: error messages that cause termination.
    ROS 2: WARN lines about skipped messages and the final dropped‑message count.

Record the output to a temporary bag:
  
    ROS 1: rosbag record -O /tmp/replayed.bag /tf /your_topics while playing, or use rosbag play --output /tmp/replayed.bag if available.
    ROS 2: ros2 bag play 'bagfile' --output /tmp/replayed.bag

Compare the original and replayed bags:
  
    Check message counts with rosbag info / ros2 bag info.
    Optionally diff specific topics using rostopic echo -p or ros2 topic echo -p and a diff tool.

If you did not see any WARN messages or a dropped‑message count in the ROS 2 summary, please let me know; that detail would change the recommendation to rely solely on rosbag check for integrity verification.

Uncertain behavior of rosbag play when restoring corrupted bag files

1 answer

Answer

Verification steps for this case

Your perspective belongs here.

0 question comments