Skip to content

command line tool: Catch a LivelogTimeout

There may be regular situations where the rss2i command line tool debug command is used but where no livelog messages are sent by the device, e.g. when the "debug proxy", i.e. the device that is connected via USB, is outside the radio range of the other devices for some time or when the synchronization got lost completely. Although, the current behaviour of the command line tool in such situations is to print some awkward error message, i.e. traceback and the thrown exception rss2ipy.LivelogTimeout. Additionally, the program blocks afterwards until the user hits Ctrl+C.

Reproduce

Assuming device 3 is connected to a USB port and there is no ongoing measurement session, just execute

rss2i -a debug -d 3

Actual Behaviour

An exception is thrown after some timeout. The program hangs up afterwards until the user enters Ctrl+C.

rss2i: Detecting connected devices... [3]
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/home/gerrit/bin/rss2i", line 1715, in _debug_livelog
    response = device.read_livelog(bufferLen * bufferScale)
  File "/home/gerrit/bin/python-packages/rss2ipy/__init__.py", line 485, in read_livelog
    raise LivelogTimeout;
rss2ipy.LivelogTimeout

^Crss2i: Signal to abort
rss2i: Disconnecting devices...ok

Desired Behaviour

The rss2ipy.LivelogTimeout should be catched in any case as should be every other exception. The livelog should be kept listening to afterwards. This way, the debug command can be used to check the state of a measurement session without the need of repeated re-execution of the debug command.

A possible behaviour may therefore look like this:

rss2i: Detecting connected devices... [3]
c:00042683 f:004 l:058.27 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:005 l:055.38 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:006 l:058.27 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:097 l:056.50 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:098 l:057.20 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:099 l:056.59 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:100 l:056.91 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:101 l:056.47 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
rss2i: No livelog data available. Are there any received packets?
rss2i: No livelog data available. Are there any received packets?
rss2i: No livelog data available. Are there any received packets?
c:00042683 f:004 l:058.27 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:005 l:055.38 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:006 l:058.27 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:097 l:056.50 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
rss2i: No livelog data available. Are there any received packets?
rss2i: No livelog data available. Are there any received packets?
c:00042683 f:005 l:055.38 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:006 l:058.27 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:097 l:056.50 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:098 l:057.20 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:099 l:056.59 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:100 l:056.91 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:101 l:056.47 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
^Crss2i: Signal to abort
rss2i: Disconnecting devices...ok

Additional Remarks

In order to optimize the user experience, it may be necessary to decrease the livelog timeout. This will reduce the time that the user waits for a feedback. In a worst-case scenario, there will be 250 frames per cycle and the connected device listens for measurement packets within a single one only. This results in 20 livelog entries per second. Hence, it would be possible to set the timeout to just a second without affecting the livelog functionality. Of course, the used timeout settings have to be harmonised with the timeout requirements of other commands.

The monitor command is affected by this bug/feature request in the same way.