Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time in status line is not updated every seconds #443

Closed
jps2000 opened this issue Feb 19, 2019 · 9 comments
Closed

Time in status line is not updated every seconds #443

jps2000 opened this issue Feb 19, 2019 · 9 comments

Comments

@jps2000
Copy link

jps2000 commented Feb 19, 2019

Problem

The status line shows absolute time and relative time in seconds in playback
In playback of longer recordings ( 20 min or so) the absolute time is not updated every second. However the relative time changes every second correctly.

Expected

Update absolute time also every second

Operating System and Version

Win

GUI Version

4.1.0 beta

Running standalone app

downloaded app

Type of OpenBCI Board

Ganglion

Are you using a WiFi Shield?

No

@retiutut
Copy link
Member

@jps2000 Making a 20+ minute recording now to test this...

@retiutut
Copy link
Member

@jps2000 I have reproduced this issue!

insta

@retiutut
Copy link
Member

findTimesToDisplay() in W_TimeSeries.pde can probably be updated to use the actual timestamps that appear!

@retiutut
Copy link
Member

retiutut commented Feb 22, 2019

I'm going to try pulling from the regular time column:

127, 0.00, 0.00, 0.00, 0.00, 0.000, 0.000, 0.000, 10:05:14.214, 1550851514214
0, 17.02, 14.61, 8.28, 23.24, 0.000, 0.000, 0.000, 10:05:14.227, 1550851514227

And drop the milliseconds by using split(time, '.')

@retiutut
Copy link
Member

retiutut commented Feb 22, 2019

Fixed! 🔥 💻
insta

I think I like it better with milliseconds 😄

retiutut added a commit to retiutut/OpenBCI_GUI that referenced this issue Feb 22, 2019
…nBCI#443

Now displaying milliseconds!!! Huge improvement with less code. This is 
possible because of updated timestamps in playback files.
@retiutut retiutut mentioned this issue Feb 22, 2019
8 tasks
@jps2000
Copy link
Author

jps2000 commented Feb 22, 2019

Absolute time is important to trace back events with videos for example. Hence there is no need for milliseconds as long as there is no slow motion playback .
But when you have ms now then leave it.

@retiutut
By the way: Do you see any chance to speed up loading/handling of long playback files?
For example sleep studies etc need analysis of recordings in the magnitude of hours.
Such long files can not be handled now
An "easy to realize" (nothing is easy) remedy may be a recording scheduler to limit length of recordings
(start a new recording (file) after x minutes)
This would solve #400 as then there is no need to start a new recording manually

@retiutut
Copy link
Member

retiutut commented Feb 22, 2019

Changed my mind, I'm just going to go with second accuracy everywhere. Was able to update the elapsed time algorithm to be very accurate with long playback files.

@jps2000 Let's keep #400 by itself. The solution to that issue should resolve any problems users should have resulting from working with long playback files.

@retiutut
Copy link
Member

@jps2000 I applied a fix to for this issue in a recent update. I think this issue can be closed.

@jps2000
Copy link
Author

jps2000 commented Mar 20, 2019

Thank you

@jps2000 jps2000 closed this as completed Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants