Problems with OSC streaming

[samikre]

Hi James,

Thank you for the wonderful mind-monitor app, it has been very helpful.
I am using the app for OSC streaming with a muse headband (model MS-01) and the corresponding script (https://github.com/Enigma644/MindMonito ... eceiver.py).

The script is working and saves the stream to a csv file but I have encountered 3 main issues that I am hopeful you can help me with.

1) As seen in image 1.png

1.png (76.66 KiB) Viewed 1846 times

, I am getting more values than expected (also the Marker are not written in the correct column but I assume this is a simple mistake). Do the first 4 values after the timestamp correspond to the RAW_* inputs and the last 2 extra values correspond to AUXR and AUXL (even though I thought Muse MS-01 only had one AUX input)?

2) I am also receiving some rows with extra columns and other rows with missing columns as seen in 2.png

2.png (209.05 KiB) Viewed 1846 times

.Rows with missing columns do not always come after rows with extra columns, they appear at random from what I can tell and independent of each other.

3) One last issue I encountered is a random difference in time format. I assume the timestamp column is the elapsed time since MindMonitor started streaming. But I aso get a different timestamp format as seen in image 3.png

3.png (234.76 KiB) Viewed 1846 times

.

Any insights on the reason for these issues or work-arounds are much appreciated.

-samikre

[James]

#1 - Sorry about that. I missed a couple of commas.
You'll have to edit the code a bit depending on which Muse version you have. The original MU-01 Muse only has the four RAW channels, The MU-02 and MU-03 (Muse 2) have a single Aux, and the MS-01 & MS-02 Muse S have 2 Aux channels. Hardly anyone has the original MU-01 anymore, so the code just has options showing for the other two and a comment about changing it manually.

#2 - I'm not sure how you're getting multiple lines of data without a line break. I'd say it was a threading issue, but there's no extra timestamp in there, so I honesty have no idea about that one. Are you sure you've not edited the code and introduced a bug? Whitespace indentation is important in python loops, so check for that. The newline character is written after the data on line 27 and I don't see any reason that it wouldn't trigger.

I'm on holiday for the next month and I don't have a Muse with me to test, sorry; but I'm pretty sure I never saw this issue when I wrote the code last year.

#3 - You can see the timestamp format on line 23: "%Y-%m-%d %H:%M:%S.%f". To get it to display correctly in Excel, you'll need to edit the column number display format. Or just load it in notepad and you'll see it as text. For Excel select "number format", "custom", and use this string "yyyy-mm-dd h:mm:ss.000".

[samikre]

Hi,

Thank for the help. I did not know that Muse S has 2 AUX channels, I will modify my script accordingly.

For #2, I also thought that I could have introduced a bug. So I tested it with the exact version on github (unmodified). Sadly this error was consistent. It is writing new lines, but introduces thess error lines occasionally. For now I will skip any lines with extra values, but would very much appreciate if you could get back to me if you find what may be causing the problem.

-samikre

[James]

Re #2 I'm currently on holiday and won't be able to run tests till mid August, sorry. I'd recommend the first debugging step should be to write out the argument count rather than (or in addition to) the values.

[James]

You're correct. There's an issue. The eeg_handler is getting called so often that sometimes it's not done writing the last line before the next line needs writing.. I'll have to make some kind of write buffer and update the code.

[James]

Fixed!
Change Link - https://github.com/Enigma644/MindMonito ... 65c1f3234a
OSC Receiver.py - https://github.com/Enigma644/MindMonito ... eceiver.py

[samikre]

Thanks for the message!

This sadly did not solve the issue for me. I assume that using BlockingOSCUDPServer instead of ThreadingOSCUDPServer would work but that would, of course, cause data loss while the server is idle inbetween handling requests. I also had the same idea of creating a buffer (i.e a string) and then write it to the file once. But I suspect that a thread is still writing to a line while another one starts writing to the same line, which is why the issue persists. So maybe a theoretical fix would be to create threading locks for file writing and have each thread store their data in private buffers until acquiring the lock and then dumping the data to the file. I cannot test this for now, but will try to test this approach in the future.
Please let me know if you find a solution.

[James]

Are you sure you were running my updated code?
I ran a bunch of tests last night and I didn't get any issues, where as before it took only seconds to see overlaps in data.
I just ran another test just now for 10 minutes with no issues.
How long are you recording for before you see an error?
What type of drive are you recording to? NVME SSD, SATA SSD, HDD? I'm wondering if drive speed is compounding the issue. I have SATA SSD.

Last night when I was testing I made a global threadCount int which I incremented at the start of eeg_handler and decremented at the end. I was often seeing two threads, which explained the issue. After changing to a single f.write statement, I was still seeing two threads running concurrently, but no issues in the file itself.. I assumed that means that f.write is locking/blocking internally, so feeding it the entire line fixed the problem.

[samikre]

I even tested it again (making sure to copy and paste the exact updated code from your repository). I recorded for 2 minutes and saw overlaps from the start of the file. I am using a 14-inch MBP (macOS 12.5.1) from 2021 with M1 Pro processor, 16GB of Ram and 1TB SSD (with more than 200 GB of free space). I am running MindMonitor on an iPhone 13 Pro (with iOS 15.6.1).

I have my doubts on if f.write is locking internally but I have not checked this with the documentation of pythonosc.osc_server.ThreadingOSCUDPServer or with the pythonosc.dispatcher.Dispatcher class.

[James]

I'm running on a PC, so maybe it's a Mac issue with f.write not locking. Do you have a PC you can test with?