1. Movesense Avatar Movesense
  2. Movesense-Community
  3. Movesense-mobile-lib
  4. Issues

[ANDROID] Logbook not working

Issue #47 resolved
Philipp Hafner created an issue

Hi!

I'm having trouble getting the logbook to work. Sensor software is V1.1 (G-Variant) and mds lib is version mdslib-1.6.0(1)-release

What I have done so far:

Set the DataLogger config:

01-02 21:16:41.419 27436-27523/at.sportsense.sportsensemanager I/Komposti: [SDS REQUEST] type: PUT uri: suunto://174130000178/Mem/DataLogger/Config contract: {"config":{"dataEntries":{"dataEntry":[{"path":"/Meas/Hr"}]}}}
01-02 21:16:41.422 27436-27447/at.sportsense.sportsensemanager I/art: Enter while loop.
01-02 21:16:41.431 27436-27447/at.sportsense.sportsensemanager I/art: Background sticky concurrent mark sweep GC freed 6945(236KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 16MB/17MB, paused 5.524ms total 18.272ms
01-02 21:16:41.869 27436-27527/at.sportsense.sportsensemanager I/Komposti: [SDS RESPONSE] type: PUT status: OK header: {"Content-Type": "application/json", "Status": 200, "TaskId": 27, "Reason": "OK", "Uri": "suunto://174130000178/Mem/DataLogger/Config", "Content-Length": 67} body: {"Content": {"dataEntries": {"dataEntry": [{"path": "/Meas/Hr"}]}}}

This seems to work. Then, starting the DataLogger:

01-02 21:17:54.178 27436-27523/at.sportsense.sportsensemanager I/Komposti: [SDS REQUEST] type: PUT uri: suunto://174130000178/Mem/DataLogger/State contract: {"newState":3}
01-02 21:17:54.492 27436-27447/at.sportsense.sportsensemanager I/art: Enter while loop.
01-02 21:17:55.321 27436-27526/at.sportsense.sportsensemanager I/Komposti: [SDS RESPONSE] type: PUT status: OK header: {"Content-Type": "application/json", "Status": 200, "TaskId": 28, "Reason": "OK", "Uri": "suunto://174130000178/Mem/DataLogger/State", "Content-Length": 14} body: {"Content": 3}

Again, apparently works.

According to [1], I can retrieve the logs by getting all entries from the logbook. This returns:

01-02 21:18:52.430 27436-27523/at.sportsense.sportsensemanager I/Komposti: [SDS REQUEST] type: GET uri: suunto://174130000178/Mem/Logbook/Entries
01-02 21:18:52.441 27436-27447/at.sportsense.sportsensemanager I/art: Enter while loop.
01-02 21:18:53.349 27436-27447/at.sportsense.sportsensemanager I/art: Enter while loop.
01-02 21:18:54.429 27436-27447/at.sportsense.sportsensemanager I/art: Enter while loop.
01-02 21:18:55.339 27436-27447/at.sportsense.sportsensemanager I/art: Enter while loop.
01-02 21:18:56.772 27436-27525/at.sportsense.sportsensemanager I/Komposti: [SDS RESPONSE] type: GET status: OK header: {"Content-Type": "application/json", "Status": 200, "TaskId": 29, "Reason": "OK", "Uri": "suunto://174130000178/Mem/Logbook/Entries", "Content-Length": 273} body: {"Content": {"elements": [{"Id": 282, "ModificationTimestamp": 536928980, "Size": null}, {"Id": 283, "ModificationTimestamp": 245085, "Size": null}, {"Id": 284, "ModificationTimestamp": 536902312, "Size": null}, {"Id": 287, "ModificationTimestamp": 501219, "Size": null}]}}

Here the returned JSON in a more readable formatting:

{
   "Content":{
      "elements":[
         {
            "Id":282,
            "ModificationTimestamp":536928980,
            "Size":null
         },
         {
            "Id":283,
            "ModificationTimestamp":245085,
            "Size":null
         },
         {
            "Id":284,
            "ModificationTimestamp":536902312,
            "Size":null
         },
         {
            "Id":287,
            "ModificationTimestamp":501219,
            "Size":null
         }
      ]
   }
}

I'm not sure why, but the Size of all Entries is 0, no matter how long I wait or what I do. When updating, the timestamp changes on at least one entry (I'm guessing, thats the HR log) If i proceed to retrieve all descriptors, I only get lots and lots of gibberish (encoded?) data. Same if I try to retrieve the actual data.

Getting the opened state of the logbook (/Mem/Logbook/IsOpen) returns false, so no log is even open. Trying to subscribe to the logbook itself (/Mem/Logbook/Subscription) returns in a TIMEOUT message after which the device disconnects and can only be used again if the battery is reinserted.

So, am I doing anything wrong? Did I miss something? Is the subscription to the log only needed when wanting to get informed about new log entries?

Why are there 4 Entries if I only want to log one resource?

Any help would be appreciated.

[1]: [DataLogger Guide]https://bitbucket.org/suunto/movesense-device-lib/src/887714f3b42496988cce6055b3ccf8b8c99a6846/MovesenseCoreLib/documentation/DataStorage.md?at=master&fileviewer=file-view-default

Comments (59)

  5. Karol Baran Account Deactivated

    Hey,

    Thanks for Your feedback. I can confirm problems with Logbook.

    I'm in contact with team responsible for that feature and I will try to help You.

    Also example Logbook usage will be added into Example Android Application.

    Will inform You about news soon as possible !

  6. Philipp Hafner reporter

    Hi Karol!

    Thanks for your feedback. Im aware of the Logbook example app as it is checked in as a branch of the mobile lib. However, the example logbook app does not work either. The error is somewhat different as the returned data is always empty.

    If someone has a working example of a logging activity/code, I would appreciate some input as logging the data is crucial for our application. Maybe there nothing wrong with the device itself and I am doing it wrong.

    Thanks,

    Philipp

  7. juha tervo Account Deactivated

    Hi,

    I have the same issue. I cannot figure out what is the latest log entry as the timestamps and ids are confusing. below entries before and after logging started.

    01-03 17:56:00.440 23288-23370/com.movesense.mds.sampleapp I/Komposti: [SDS RESPONSE] type: GET status: OK header: {"Content-Type": "application/json", "Status": 200, "TaskId": 26, "Reason": "OK", "Uri": "suunto://174830000687/Mem/Logbook/Entries", "Content-Length": 267} body: {"Content": {"elements": [ {"Id": 6, "ModificationTimestamp": 536928980, "Size": null}, {"Id": 12, "ModificationTimestamp": 188545, "Size": null}, {"Id": 13, "ModificationTimestamp": 536902312, "Size": null}, {"Id": 16, "ModificationTimestamp": 37689, "Size": null}]}}

    [{"Id":6,"ModificationTimestamp":204069,"Size":null}, {"Id":12,"ModificationTimestamp":536888864,"Size":null}, {"Id":13,"ModificationTimestamp":1447368192,"Size":null}, {"Id":16,"ModificationTimestamp":536928692,"Size":null}]

  8. Philipp Hafner reporter

    @Juha, could you try to read the log file state from the device? If the log is open? Or try to subscribe to it?

  9. Karol Baran Account Deactivated

    Hey guys,

    I have short update for You.

    You are doing this in good way but You are using instruction from device side. And downloaded file is encoded. Also looks like file is fine even Size = null;

    So summary I will prepare short instruction for You and maybe even working sample FOR MOBILE before end of this week.

    I need to write it and test before will publish it so can't promise it will be ready for tomorrow but I'm working on this and will update soon ( when will finish ).

  10. Philipp Hafner reporter

    Thank you very much Karol! I'm aware that the downloaded file is encoded in your SBEM format, but I was unable to find anything to decode the data.

    But thanks for the update, I'm looking forward to the instructions.

  11. Karol Baran Account Deactivated

    I'm coming with solution!

    [SDS REQUEST] type: GET uri: suunto://MDS/Logbook/serial/byId/identry/Data

    API : /MDS/Logbook/{serial}/byId/{LogId}/Data

    This is request for reading file and this will return output in JSON.

    So Your start code is good, just after get for Entries You need one more get ( above).

    I tried this and works... but it takes some time after will return JSON .

  14. Philipp Hafner reporter

    Could any of you provide a complete code line with the GET call? "/MDS/Logbook/{serial}/byId/{LogId}/Data" is this really correct?

  15. Philipp Hafner reporter 
    ArrayList<DataLoggerEntries.DataEntry> entrylist =  entries.GetEntries();
        mMovesenseHandle.get("suunto://MDS/Logbook/" + serial + "/byId/" + logID + "/Data",
                null, new MdsResponseListener()
                {
                    @Override
                    public void onSuccess(String data)
                    {
                        Log.e("data", data);
                    }

                    @Override
                    public void onError(MdsException e)
                    {
                        if(callback != null)
                            callback.OnError(device, e.getMessage());
                    }
                });

    This works and gives back all recorded heartrate data!

    Is there any way to get the timestamps as well?

    Thank you Karol!

  16. Philipp Hafner reporter

    As an addition, how can you remove logs on the device? I tried removing it as state in the documentation, however, that does not work:

    01-04 20:19:22.475 18594-18654/at.sportsense.sportsensemanager I/Komposti: [SDS REQUEST] type: GET uri: suunto://174130000178/Mem/Logbook/Log/236/Remove
01-04 20:19:22.759 18594-18657/at.sportsense.sportsensemanager E/Komposti: [SDS RESPONSE] type: GET status: NOT_FOUND header: {"Status": 404, "TaskId": 26, "Reason": "NOT_FOUND", "Uri": "suunto://174130000178/Mem/Logbook/Log/236/Remove", "Content-Length": 0}
  17. Karol Baran Account Deactivated

    Timestamp is in JSON

    {"Meas":{"Acc":[{"ArrayAcc":[{"x":-0.17707519233226776,"y":-0.64847809076309204,"z":9.9186038970947266}],"Timestamp":158},...

  18. Karol Baran Account Deactivated

    For removing Entries :

             Mds.builder().build(this).delete(MdsRx.SCHEME_PREFIX + MovesenseConnectedDevices.getConnectedDevice(0).getSerial() +
                                "/Mem/Logbook/Entries/",
                        "{\"timeout\":200000}", new MdsResponseListener() {
                            @Override
                            public void onSuccess(String data) {
                                Log.e(TAG, "onSuccess(): " + data);
                            }

                            @Override
                            public void onError(MdsException error) {
                                Log.e(TAG, "onError(): ", error);
                            }
                        });

    It removing entries but throwing REQUEST_TIMEOUT and need to check why.

  19. juha tervo Account Deactivated

    and the ids and timestamps. started logging couple of times, log entries look like below. I cannot figure out the meaning.

    {"Content": {"elements": [{"Id": 1, "ModificationTimestamp": 220417, "Size": null}, {"Id": 2, "ModificationTimestamp": 536888676, "Size": null}, {"Id": 3, "ModificationTimestamp": 22658, "Size": null}, {"Id": 4, "ModificationTimestamp": 536899820, "Size": null}]}}

    {"Content": {"elements": [ {"Id": 1, "ModificationTimestamp": 905969718, "Size": null}, {"Id": 2, "ModificationTimestamp": 1220511334, "Size": null}, {"Id": 3, "ModificationTimestamp": 1908397834, "Size": null}, {"Id": 4, "ModificationTimestamp": 1953063255, "Size": null}]}}

    {"Content": {"elements": [ {"Id": 1, "ModificationTimestamp": 905969718, "Size": null}, {"Id": 2, "ModificationTimestamp": 1908381777, "Size": null}, {"Id": 3, "ModificationTimestamp": 2931794247, "Size": null}, {"Id": 4, "ModificationTimestamp": 544500065, "Size": null}]}}

  20. Karol Baran Account Deactivated

    That's true. I reported this problem because it's outside of my Android part where I can help.

    So when I will have any news I will share with You.

  21. Karol Baran Account Deactivated

    But I think we are talking about different problem.

    Your logs looks fine. You are doing more file / entries with subscription and when You are sending get for Entries You can see all old and new entries. So thats why its repeated.

    And after next start / stop for Logbook You should see id 1-4 and new 5. So looks fine.

  22. Philipp Hafner reporter

    If I want to delete all log entries to free up space on the sensor, deleting all entries as you showed should work, right?

  25. Karol Baran Account Deactivated

    I also have a important question why You want use Logbook.

    Logbook it's not super effective if You want often read data and the size of memory is limited.

    It's not better to maybe save data from subscription in to file or smth ?

  26. juha tervo Account Deactivated

    use case is such where Bluetooth connection to sensor is most probably lost and data is collected when the connection is again restored. So I assume subscription is not right way to do the sensor data recording. Comments or proposals? thank you for the support.

  27. Philipp Hafner reporter

    Yes, thats exactly the case. I have to store the data on the device because the connection might be lost due to the range. The person wearing the sensor might be up to 50m away from the reciever.

    Is there a way to store timestamps with the measured heart rate? (Like with meas/acc)

  28. Karol Baran Account Deactivated

    If You want store data on the device EEPROM memory used by Logbook is the only way probably.

    But about any specific question about device please ask on the movesense-device-lib repository so guys from embedded / hw part can help You.

  29. Philipp Hafner reporter

    Karol, I can confirm that clearing the log entry with your provided code works. I do get the timeout response, but it works. Thank you for your help!!

  30. Karol Baran Account Deactivated

    Thanks for Your response.

    If You need help or You will find issue feel free to create new ticket.

    Cheers.

  31. Philipp Hafner reporter
    • changed status to open

    Hi Karol, unfortunatley, the error is not resolved. Since yesterday, I get this error message:

    01-09 19:57:44.429 4797-5280/ E/Komposti: Logbook::get: Failed to read data.
01-09 19:57:44.429 4797-5280/ E/Komposti: [SDS RESPONSE] type: GET status: REQUEST_TIMEOUT header: {"Status": 408, "TaskId": 26, "Reason": "REQUEST_TIMEOUT", "Uri": "suunto://MDS/Logbook/174130000178/byId/1/Data", "Content-Length": 0}
01-09 19:57:44.488 4797-4797/ E/SensorDetailFragment: Failed status: 408, reason: REQUEST_TIMEOUT
01-09 19:57:44.543 4797-4809/ I/art: Enter while loop.
01-09 19:57:44.656 4797-4874/ W/libEGL: [ANDROID_RECORDABLE] format: 1
01-09 19:57:58.574 4797-5321/ E/BleManager: Error while receiving data
                                                                           com.polidea.rxandroidble.exceptions.BleDisconnectedException: Disconnected from 0C:8C:DC:20:34:26
                                                                               at com.polidea.rxandroidble.internal.connection.RxBleGattCallback$2.onConnectionStateChange(RxBleGattCallback.java:76)
                                                                               at android.bluetooth.BluetoothGatt$1.onClientConnectionState(BluetoothGatt.java:187)
                                                                               at android.bluetooth.IBluetoothGattCallback$Stub.onTransact(IBluetoothGattCallback.java:70)
                                                                               at android.os.Binder.execTransact(Binder.java:570)
01-09 19:57:58.621 4797-4810/ I/Komposti: [SDS REQUEST] type: PUT uri: sds://MDS/Devices/Library/174130000178 contract: {"LastKnownState": 5, "HwVersion": "C", "Serial": "174130000178", "Descriptors": {"SwVersion": "1.1.0"}, "Model": "Avocado", "Name": "Movesense Sensor"}
01-09 19:57:58.622 4797-5286/ E/Komposti: [SDS RESPONSE] type: PUT status: NOT_FOUND header: {"Status": 404, "TaskId": 27, "Reason": "NOT_FOUND", "Uri": "suunto://MDS/Devices/Library/174130000178", "Content-Length": 0}
01-09 19:57:58.622 4797-4810/ I/Komposti: [SDS REQUEST] type: PUT uri: suunto://MDS/ConnectingDevices contract: {"State": "Disconnected", "Serial": "174130000178"}
01-09 19:57:58.623 4797-5281/ I/Komposti: [SDS RESPONSE] type: PUT status: OK header: {"Status": 200, "TaskId": 28, "Reason": "OK", "Uri": "suunto://MDS/ConnectingDevices", "Content-Length": 0}
01-09 19:57:58.623 4797-4810/ I/Komposti: [SDS REQUEST] type: DEL uri: suunto://174130000178/
01-09 19:57:58.624 4797-5279/ I/Komposti: [SDS REQUEST] type: PUT uri: sds://MDS/Devices/Library/174130000178 contract: {"LastKnownState": 5, "HwVersion": "C", "Serial": "174130000178", "Descriptors": {"SwVersion": "1.1.0"}, "Model": "Avocado", "Name": "Movesense Sensor"}
01-09 19:57:58.624 4797-5284/ E/Komposti: [SDS RESPONSE] type: PUT status: NOT_FOUND header: {"Status": 404, "TaskId": 30, "Reason": "NOT_FOUND", "Uri": "suunto://MDS/Devices/Library/174130000178", "Content-Length": 0}
01-09 19:57:58.625 4797-5279/ I/Komposti: [SDS REQUEST] type: POST uri: suunto://MDS/EventListener contract: {"Operation": "Unsubscribe", "Serial": "174130000178"}
01-09 19:57:58.626 4797-5279/ I/Komposti: [SDS RESPONSE] type: DEL status: OK header: {"Status": 200, "TaskId": 29, "Reason": "OK", "Uri": "suunto://174130000178", "Content-Length": 0}
01-09 19:57:58.626 4797-5279/ I/Komposti: [SDS RESPONSE] type: POST status: OK header: {"Status": 200, "TaskId": 31, "Reason": "OK", "Uri": "suunto://MDS/EventListener", "Content-Length": 0}
01-09 19:57:58.627 4797-4797/ I/Mds: MDS connection has beed deleted for device: 174130000178
01-09 19:57:58.646 4797-4797/ I/SensorDetailFragment: Disconnected: 0C:8C:DC:20:34:26

    This happens after correctly starting the log, logging for ~10-15 seconds, stopping and then retrieving the log. The sensor can only be used after reinserting the battery.

  32. Philipp Hafner reporter

    Note, this does not happen every time, but it happens very often (7 out of 10 times)

  33. Philipp Hafner reporter

    This also happens when retrieving the LogEntries:

    01-09 20:13:26.487 6265-6385/ I/Komposti: [SDS REQUEST] type: GET uri: suunto://174130000178/Mem/Logbook/Entries contract: {"timeout":999999}
01-09 20:13:27.939 6265-6276/ I/art: Enter while loop.
01-09 20:13:29.652 6265-6276/ I/art: Enter while loop.
01-09 20:13:35.798 6265-6388/ E/Komposti: [SDS RESPONSE] type: GET status: REQUEST_TIMEOUT header: {"Status": 408, "TaskId": 26, "Reason": "REQUEST_TIMEOUT", "Uri": "suunto://174130000178/Mem/Logbook/Entries", "Content-Length": 0}
01-09 20:13:35.846 6265-6265/ E/SensorDetailFragment: Failed status: 408, reason: REQUEST_TIMEOUT
01-09 20:13:35.986 6265-6270/ I/art: Do full code cache collection, code=110KB, data=124KB
01-09 20:13:35.986 6265-6270/ I/art: After code cache collection, code=96KB, data=102KB
01-09 20:13:35.999 6265-6318/ W/libEGL: [ANDROID_RECORDABLE] format: 1
01-09 20:13:49.880 6265-6425/ E/BleManager: Error while receiving data
                                                                           com.polidea.rxandroidble.exceptions.BleDisconnectedException: Disconnected from 0C:8C:DC:20:34:26
                                                                               at com.polidea.rxandroidble.internal.connection.RxBleGattCallback$2.onConnectionStateChange(RxBleGattCallback.java:76)
                                                                               at android.bluetooth.BluetoothGatt$1.onClientConnectionState(BluetoothGatt.java:187)
                                                                               at android.bluetooth.IBluetoothGattCallback$Stub.onTransact(IBluetoothGattCallback.java:70)
                                                                               at android.os.Binder.execTransact(Binder.java:570)
  34. Philipp Hafner reporter

    Apparently the problem can be forced by letting the logger run for > 4 minutes. I am logging only the Heart rate, and am subscribed to IsLogFull, which does not report a full log.

  35. Philipp Hafner reporter

    I can reproduce the problem realiably by doing the following:

    Setting a log resource (/Meas/Hr) Start the logger .... wait ~1-2 minutes Stop the logger Get the entries Get the data Clear the data

    Again:

    Setting a log resource (/Meas/Hr) Start the logger .... wait ~1-2 minutes Stop the logger Get the entries << Timeout and device disconnect.

  37. Philipp Hafner reporter

    Juha, can you confirm this issue? Can you always retrieve the logbook entries without errors? It happens on both my devices but maybe its still me who causes the error.

  38. Karol Baran Account Deactivated

    Hey.

    I created issue on team responsible for that and will inform You about news.

    I can a bit try to push them and if anything will be new I will add this here.

  39. Philipp Hafner reporter

    Thank you very much Karol! No need to push them, but it would be a great help if you could confirm the problem with one of your sensors?

  40. Karol Baran Account Deactivated

    Can You tell which software version on Movesense are You using?

    I could reproduce REQUEST_TIMEOUT on Entries request after Clear request. But after this I did one more request for Entries and works.

    My device is not disconnecting even REQUEST_TIMEOUT is throwing.

  41. Philipp Hafner reporter

    Sensor software is V1.1 (G-Variant)

    Could you try to repeat this process a few times: Setting a log resource (/Meas/Hr)

    Start the logger

    .... wait ~1-2 minutes

    Stop the logger

    Get the entries

    Get the data

    Clear the data

  43. Karol Baran Account Deactivated

    Could you try to repeat this process a few times: Setting a log resource (/Meas/Hr)

    Start the logger

    .... wait ~1-2 minutes

    Stop the logger

    Get the entries -> Only here I have problem with REQUEST_TIMEOUT but I'm still connected with device and can send request again.

    Get the data

    Clear the data

  44. Philipp Hafner reporter

    Ah good to know. Does retrying work? Do you finally get the entries?

    Does clearing the entries really remove the log? Or do I have to delete the logs manually?

  45. Karol Baran Account Deactivated
    1. Removing entries but there is a know bug with REQUEST_TIMEOUT exception
      Mds.builder().build(this).delete(MdsRx.SCHEME_PREFIX + MovesenseConnectedDevices.getConnectedDevice(0).getSerial() +
                                "/Mem/Logbook/Entries/",
                        null, new MdsResponseListener() {
                            @Override
                            public void onSuccess(String data) {
                                Log.e(TAG, "onSuccess(): " + data);
                            }

                            @Override
                            public void onError(MdsException error) {
                                Log.e(TAG, "onError(): ", error);
                            }
                        });
    1. Get for Entries working fine. I found single problem when You will remove entries and send immediately get for entries there is exception. For some reason we need wait for ex 5s and then get for entries will work fine without exception.

    Both bug reported.

  47. Petri Lipponen

    To clarify: The DELETE on /Mem/Logbook/Entries does clean the whole logbook. However in current sensor software that takes much longer (~30 seconds) than the MDS internal timeout so the TIMEOUT_EXCEPTION is thrown. If you wait about 30 seconds after calling DELETE, the situation should be stable and Logbook/DataLogger ready to use again. I'm working on a fix right now that should make it in sensor release 1.3

    We are also working on a Logbook/DataLogger mobile sample that should clarify the rest of the operation and serve as a simple guide on how to use this feature from the mobile side.

  48. Philipp Hafner reporter

    Thank you very much, I suspected something like this. Could sending a request to start to the logbook while deleting cause a crash?

  49. Petri Lipponen

    I would guess so though I haven't tested it. So wait 30 sec before doing anything if you get the TIMEOUT. When my fix is released the delete is a fast operation (< 100ms)

  50. Philipp Hafner reporter

    Hi Petri. Sorry for not getting back to you sooner, I was rather busy. I updated the Sensor's software to V1.2 today, are your changes in this release? So far, it seems to work properly.

  51. Karol Baran Account Deactivated

    @Hafnernuss

    Petri's fix for is included in 1.4 ( sw verion). Deleting entries should works fine ( also without timeout Exception ).

    Did You have any more problems ?

  52. Philipp Hafner reporter

    When will V 1.3 arrive?

    Not really problems, but an additional question: Why isnt it possible to log and subscribe to the same resource simulationously?

  53. Karol Baran Account Deactivated

    Why You want subscribe to the same resource ?

    Petri doing Logbook part on the device so if he will not response here I can ask him privately.

    Release version is planed for 14 February.

  54. Philipp Hafner reporter

    Following usecase:

    People are running around with the sensor attached. The data is retrieved live via subscription to monitor the activities and give instant feedback (run faster, slower....)

    Since the data will be examined in detail later and to prevent data loss in the case of out-of-range event, I also want to log the data on the device.

  55. Michal Szynkaruk

    Could you please confirm if the original issue reported here is no longer valid with SW 1.3 ?

  58. Philipp Hafner reporter

    The issue is resolved with 1.4, the workaround is no longer necessary. However, logging and subscribing simultaniously is not working.

  59. Karol Baran Account Deactivated

    Good to hear. Thanks for answer.

    Closing the original issue.

    If You want please create seperate issue with reproduction steps / logs / what is the actual and expected result.

    Cheers.

  60. Log in to comment
Assignee
–
Type
bug
Priority
critical
Status
resolved
Votes
0
Watchers
1