seems like updating to 2.8 hasn’t resolved the issue, I have however recorded a screencap showing the behaviour that I mentioned before. In the video attached you can see me navigate to a highly detailed part of the sample, only for the stream to cut out. Opening and closing the application doesn’t fix anything, however if the sample is moved back to a less detailed region the stream regains functionality. It is important to note that while the stream is cut out it is still possible to take captures, it just doesn’t show up as a live preview in the software.
Very strange. Do you know the IP address of your microscope? When it next cuts out, could you please go to http://{{your microscopes IP}}:5000/api/v2/streams/mjpeg
That’s the source for the stream and I’m curious to know if it works from another client.
Additionally, when it next cuts out could you go to the new Logs tab, use the download button at the top, and send the log file to me (either upload here or email j.collins@bath.ac.uk if you don’t want it public).
If the stream doesn’t work in your web browser, please close the OpenFlexure Connect window with the broken stream and then refresh that address.
The reason I think it’s client side is that if the stream stops, it will just forever display the last working frame. However what I could believe is that for some reason the client is reloading the stream and hitting some kind of connection or bandwidth limit.
Alright so I tried that, it seems like even in the browser the stream cuts out when it happens in the openflexure client. I’ve attached the log file, hope that helps somehow
Ok thanks. Have you tried closing the client app and refreshing in the browser?
Okay yeah this is truly bizarre.
Can you let me know which model of Raspberry Pi you’re using, and how you’re connecting to the microscope? Thanks
Also, this may sound odd but can you try moving the sample by hand to one of the regions that causes problems? As in move the slide on top of the stage (not the stage itself).
I just want to rule out a mechanical failure where the stage moving around might somehow be causing issues with the camera connection. Though the fact you can still capture images would suggest that’s not the case,
If this is only happening locally on a pi (not sure if it is) is it the GPU overlay failing? Do we still do that?
1 Like
Yeah good shout. @mmgoessens in your OpenFlexure Connect window, can you go into Settings, Display, and ensure that “Enable GPU preview”, “Track window”, and “Disable live stream” are all enabled, then see if the same issue occurs.
These settings will disable the MJPEG stream but replace it with a direct camera overlay which works differently and may give us a clue as to the cause of this issue.
I suppose and then compare it to the opposite way, because perhaps they are on and the GPU preview is failing. Which is default?
I’ve tried this before, but yes even movement by hand causes the issue, I’ll try to replicate the issue again in a bit and turn off all the options you mentioned
1 Like
okay so, the default options were set to:
Disable live stream: Off
Enable GPU preview: Off
Track window: On
Changing around either the Track window or the GPU preview setting didn’t help in any combination.
When I checked “disable live stream”, the OF client displays “stream preview disabled”, but the feed in the browser would still cut out and show the square, so I couldn’t find any change in behaviour depending on which options were checked
Sorry Enable GPU Preview should be On.
This will verify if the issue is with our stream or deeper into the camera.
I’m sorry I phrased it unclearly, I already tried enabling GPU preview and that results in the same thing, the stream cutting out
Thanks. Sorry for all the extra requests but could you take a video on your phone or something of this happening with the GPU preview on (and live stream disabled)?
If the GPU preview also cuts out then this is something lower level than our software and will need much deeper investigation.
I’ll try in a moment, just for clarity, when you say I should disable the live stream, does that mean you would like to see the preview in the browser? because as far as I can tell, when I disable the live stream option I can not view anything from the OF client
I need to clarify this in the interface. So there’s two types of camera preview: The live stream, which is an MJPEG stream over the network, and the GPU preview, which is builtin to the Raspberry Pi and directly draws the camera feed to the GPU.
If you’re working on the microscope itself, then if you disable the Live Stream and enable the GPU Preview you should see a camera preview that uses way lower level code than our software, which will help us figure out at which point the problem is being introduced.
If you don’t see the GPU preview on the display connected to your microscope then that’s a separate issue that I can quickly fix up.
aah that explains, I was connecting to the Rpi over VNC viewer, once I attached a monitor directly to it I managed to see the GPU preview!
With the GPU preview enabled I was unable to replicate the bug (though I did notice that the GPU preview seemed to stick around on my screen when the client closed, requiring a reboot to fix)
I think it may indeed be something like a bandwidth problem with the stream, the GPU preview also appears to move more smoothly (higher framerate perhaps?)
Ah I see! Sorry I saw the screenshot and assumed it was taken from the Pi directly.
Just so I’m clear, you’re connecting to the Pi over VNC, and then running OpenFlexure Connect within that VNC session? If that’s the case then I can believe that the combined VNC stream and MJPEG stream would cause bandwidth issues.
We usually suggest that if you’re connecting from another machine, you install OpenFlexure Connect on the device you’re actually using. If it’s on the same LAN then it should find your microscope automatically, but otherwise you just need to know the IP address of the Pi.
If you do this, it might help with the bandwidth issues.
Can I also ask how you’re actually networking the devices?
The Raspberry pi is on the same wifi network as my PC, but my PC is hooked up to the router with an ethernet cable.
It seemed very logical that perhaps the VNC was using up too much bandwidth, I hadn’t thought of that!
unfortunately, even with VNC disabled on the Pi and using the windows OF connect client, the issue seems to persist…