DIsplay the announced and the actual sampling rate if it deviates from the information transmitted in the stream header.
This information can be added to the stream name.

This issue will be assigned to Sören once he has a Github account.

The xdf file seems to be not constructed correctly.
The lab recorders writes the xml header for all streams at the beginning of the xdf file.
Receiver interleaves xml headers and data.

#21 forced us to revert back to liblsl 1.15.0. This breaks CI builds. Either find a way to use a more current liblsl version or fix CI (1.16.2 build in CI but exposes #21...)

After finishing and saving a recording the internal state of the app is not reset correctly. The app requires the user to use a
"Close inlets" button. But it does nothing else than the Restart the app.

.. and its streams can be recorded successfully using our app.

This issue will be assigned to Sören once he has a Github account.

Hi,

Can you tell me if there is an equivalent for the lsl_api.cfg file?
Is there a way to configure the devices that can broadcast to the recorder?

Thanks in advance

Error message: 'App not installed'.

• This was only observed, when dragging the apk to the phone, not using the ADB interface
• Idea: set ADB to verbose when installing
• find out which phones
• What is different in the apks?

ListView.getChildAt returns Null when the child is not currently visible.

2023-12-07 15:11:54.287 4139-4139 AndroidRuntime com.uol.neuropsy.LSLReceiver E FATAL EXCEPTION: main Process: com.uol.neuropsy.LSLReceiver, PID: 4139 java.lang.NullPointerException: Attempt to invoke virtual method 'void android.widget.TextView.setBackgroundColor(int)' on a null object reference at de.uol.neuropsy.recorda.MainActivity.setColorBasedOnQuality(MainActivity.java:307) at de.uol.neuropsy.recorda.MainActivity.updateStreamQualityIndicators(MainActivity.java:296) at de.uol.neuropsy.recorda.MainActivity.access$400(MainActivity.java:48) at de.uol.neuropsy.recorda.MainActivity$7$1.run(MainActivity.java:272) at android.os.Handler.handleCallback(Handler.java:942) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loopOnce(Looper.java:226) at android.os.Looper.loop(Looper.java:313) at android.app.ActivityThread.main(ActivityThread.java:8762) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:604) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

The user can select a file name in the settings. This name is not used in the code, though. Previously the file was always "default.xdf", currently the file name is determined automatically and adds time and date to "recording".

The android_manifest still has places where it refers to LSLRecorder, same as some of the GUI code. Search for occurrences and replace with RECORDA.

Documentation on

• how to set up the project in order to contribute features or bug fixes
• how to navigate the code

I will investigate whether we can use a doc generation tool like Doxygen and whether we can integrate that into our CI/CD pipeline.

In the LSLService class, each call of pull_chunk() is performed with an array size of one (1), effectively limiting the pulled chunk to a sample. This can possibly lead to a buffer overflow after some time.

Functional: Save only after finishing the acquisition.

• All stream contents are held in memory until the user stops the recording.
  Data is not written to the file during recording, but only at the end.

• Disadvantage 1: Costs more memory, increases the
  probability of running out of memory out with long recordings. In this case the
  app suddenly crashes during a long recording session and the recording would
  lost without warning. Just as the app is implemented, there are
  no automatic safe shutdown before the memory runs out.

Disadvantage 2: If an error causes the app to crash during recording
or does not work as intended, the recording may be lost.
If the app were to write continuously to a file, the recordings made up to
failure written data can be recovered. "LabRecorder" makes this the
Example better.

Author: Sören Jeserich

Essential parts of the implementation are six times duplicated with only small differences between the copies. This has been fixed largely in in the (native) C code, but not in the Java code.

We need to buffer the current stream quality somewhere and then set the quality in ArrayAdapter::getView. Problem: Views get recycled, so sometimes the wrong stream items also receive the colouring after scrolling.

The current name is 'app-debug'. We could also think about adding the version number for easier bug tracking.

This app is sometimes called LSL_RECORDER, sometimes RECORDA, sometimes record-a.

..and build the recorder on a Github build agent.
Add a deploy stage containing a recent build from the main branch and documentation. Set up build in regular intervals (we don't need nightly builds).

Implement a status indicator for incoming streams which shows the data quality, i.e.: - do the sampling rates announced in the stream and the actual samping rates match

• do we receive any data at all
• does the sampling rate vary greatly in short amounts of time
• did we loose any data recently/during recording

This feature is similar to the status indicator in the desktop LSL Recorder.
This issue will be assigned to Sören once he has a Github account.

Add screenshots to the readme file and a description on how to transfer files from phone to PC.

Functional: recording of all streams.
The app first makes a recording of all detected streams to memory, also those, which were explicitly deselected before.
Only when saving, only those choices are taken into account, and data from the irrelevant streams are discarded.

Disadvantage: Costs more memory, makes a failure more likely.

Author: Sören Jeserich

On some devices only one stream can be resolved if the phone is not connected to a WiFi. The Pocketable Labs release did not exhibit this behaviour. I made a test app https://github.com/pmaanen/HelloResolver. As the bug occurs also in this test app I do not think the bug is on our side. I am currently bisecting and found that this behaviour starts somewhere between liblsl 1.15.2 and 1.16.0. As liblsl 1.15.0 is the last version where this bug does not occur and which works w/ debug builds, we would have to revert to liblsl 1.15.0 if we can not make liblsl's authors fix it on their end soon.

Many names of variables and functions are chosen in a way, that it takes longer to recognize which tasks and contents they represent.
Example: A file name is stored in variables "temp" and "convertedValue". Other identifiers were "arr" and "arr2" and "i" and "i2".

Disadvantage 1: Understanding and changing the code causes more effort, because one has to go on "treasure hunt" again and again to trace back what is actually written into a variable.

Disadvantage 2: Risk of errors: Two not meaningful variables from the same type can be confused. Who knows what is in "i" and what is in "i2" if the variables were described at a remote code location?