.. _troubleshooting:

=================
 Troubleshooting
=================

.. seealso::

   :ref:`support`
     If this page doesn't help

.. _troubleshooting-unknown-wire-schema:

Wire-schema is not Known
========================

.. seealso::

   :ref:`idl-options`
     Commandline Options for loading Data Type Definitions

Problem

  I tried to record :term:`events <event>` with :term:`wire schema`
  ``rst.kinematics.JointAngles`` using :ref:`bag-record`. This does
  not seem to work - at least :ref:`bag-record` reports:

  .. parsed-literal::

     WARNING:
         :term:`Payload` serialization format for :term:`wire schema` ``:|.rst.kinematics.JointAngles|``
         is not known. :term:`Channel` format will only describe outer :term:`event` serialization;
         not inner :term:`payload` serialization.

Solution

  :ref:`bag-record` should record all :term:`events <event>` despite
  the warning but the resulting :term:`log file` will not contain
  information about the :term:`types <data type>` of the recorded
  :term:`event payloads <payload>` and will thus not be
  self-describing. :ref:`bag-record` usually tries to make all
  recorded :term:`log files <log file>` self-describing. That is the
  reason for the warning.

  For recording and replaying :term:`events <event>`,
  :ref:`bag-record` and :ref:`bag-play` do not require this additional
  information. Did you try to :ref:`replay <replay>` the recorded
  data?

  If you want to avoid the warning and/or store the type information
  in the :term:`log file` to make it self-describing, you can add
  :ref:`commandline options to load the respective data type
  definitions <idl-options>`:

  .. parsed-literal::

     bag record -I\ :file:`{PATH-TO-RST}/proto/stable/` -l\ :file:`{PATH-TO-RST}/proto/stable/rst/kinematics/JointAngles.proto` …

.. _troubleshooting-missing-spread-library:

Missing Spread Library
======================

Problem

  Calling any of the ``bag *`` :ref:`tools <tools>`, the following
  happens:

  .. code-block:: sh

     $ bag cat my-log-file.tide
     WARNING:
       Failed to load Spread library: Unable to load any of the alternatives:
       ("libspread-without-signal-blocking.so" "libspread.so" "libspread.so.2"
        "libspread.so.2.0" "libspread.so.1").
       Did you set LD_LIBRARY_PATH?
       Spread transport will now be disabled.
     [execution continues, but Spread transport does not work]

Solution

  Place one of the mentioned :term:`Spread` libraries (typically
  :file:`libspread.so.2.0`) on the system library search path or set
  :envvar:`LD_LIBRARY_PATH` appropriately.

.. _troubleshooting-illegal-spread:

Illegal Spread
==============

Problem

  We would like also to know how to record with :ref:`bag-record`. We
  have tried:

  .. code-block:: sh

     $ bag record -o test.tide                         \
                  'spread://remote:4803/nao/vision/0'  \
                  'spread://remote:4803/nao/vision/1'  \
                  'spread://remote:4803/nao/audio/all'

  with no success: ``ILLEGAL SPREAD``.

Solution

  Most likely, there is no :term:`Spread daemon` running on host
  ``remote`` (or not on port ``4803``).

.. _troubleshooting-bag-records-exits:

bag-record Exits during Recording
=================================

Problem

  When recording with :ref:`bag-record` using the :term:`Spread`
  transport, :ref:`bag-record` exist after a short amount of time with
  an error like::

    Error receiving: CONNECTION-CLOSED

Solution

  This problem occurs because more data is sent to :ref:`bag-record`
  than it can receive and/or write to disk. Although this problem
  should be much less common in recent versions (>= 0.9) of
  :ref:`bag-record`, it can still happen with large volumes of data or
  problematic :term:`Spread` configurations.

  There several options to mitigate the problem:

  #. When the data which should be recorded is sent to several
     :term:`scopes <scope>`, separate :ref:`bag-record` processes can
     be created for these :term:`scopes <scope>` - maybe even on
     different machines.

  #. The :ref:`socket-based transport <specification-socket>` is
     sometimes faster than the :term:`Spread` :term:`transport`.

  #. An unmodified :term:`Spread daemon` sometimes delivers
     :term:`events <event>` slower than necessary, which can lead to the
     problem described above. We provide a patched :term:`Spread` Debian
     package in the  `CoR-Lab package repository
     <http://packages.cor-lab.de/>`_.

.. _troubleshooting-empty-log-files:

Empty Log-files after Recording
===============================

Problem

  After recording with :ref:`bag-record`, there are no :term:`events
  <event>` in my :term:`log files <log file>` (according to
  :ref:`bag-info`).

Solution

  We suggest the following procedure to investigate the problem:

  .. digraph:: empty_file

     fontname=Arial
     fontsize=11
     node [fontsize=11,fontname=Arial]
     edge [fontsize=11,fontname=Arial]

     info [label="bag info broken.tide",shape=box]
     info_decision [label="displays events?",shape="diamond"]
     noevents [label="no events (according to bag info)",shape=box]
     filesize [label="check filesize",shape=diamond]
     forgetit [label="forget it; nothing has been recorded",shape=box]
     forgetit_decision [label="want to fix it?",shape=diamond]
     info_reindex [label="bag info --on-error continue",shape=box]
     info_reindex_decision [label="displays events?",shape=diamond]
     merge_reindex [label="bag merge --on-error continue -o repaired.tide broken.tide",shape=box]
     contactus [label="contact us",shape=box]

     info -> info_decision
     info_decision -> noevents [label="no"]
     info_decision -> contactus [label="yes (what is the problem, then?)"]
     noevents -> filesize
     filesize -> forgetit [label="<= 22 byte"]
     forgetit -> forgetit_decision
     forgetit_decision -> contactus [label="yes"]
     forgetit_decision -> forgetit [label="no"]
     filesize -> info_reindex [label="> 22 byte"]
     info_reindex -> info_reindex_decision
     info_reindex_decision -> contactus [label="still no events"]
     info_reindex_decision -> merge_reindex [label="yes, displays events"]

.. _troubleshooting-adjusting-timestamps-during-replay:

Adjust Timestamps during Replay
===============================

.. seealso::

   :ref:`bag-play-adjusting-timestamps`
     Description in the :ref:`bag-play` manual page

Problem

  Is it possible to have :ref:`bag-play` use a :ref:`playback strategy
  <bag-play-playback-timing>` like ``recorded-timing`` but to adapt
  the ``create`` timestamps of the data to correspond to the current
  system time and not the recorded original creation time?

Solution

  This can be achieved by calling :ref:`bag-play` like this:

  .. code-block:: sh

     $ bag-play --replay-strategy 'recorded-timing :adjustments ((:create :now))' ...

.. _troubleshooting-replay-without-gaps:

Replay without Gaps
===================

Problem

  Replaying a :term:`log file` with "gaps" (i.e. periods of time
  during which no :term:`events <event>` were sent) for testing
  purposes is inconvenient and takes longer than necessary because of
  the gaps. Is it possible to skip over these gaps while otherwise
  retaining the original timing?

Solution

  This can be achieved by calling :ref:`bag-play` like this:

  .. code-block:: sh

     $ bag-play --replay-strategy 'recorded-timing :max-delay .1' ...

  ``:max-delay .1`` limits the maximum delay between adjacent
  :term:`events <event>` to 100 milliseconds without changing the
  playback timing for shorter delays.