Since updating to DD 2.8.5, it interferes with MacOS screen sharing.
With the dashboard open, the whole Mac becomes unresponsive when you try and control it through Screen Sharing. If I access the Mac directly, there is no issue, if I minimise the Drobo Dashboard, the Mac becomes responsive again though ScreenSharing.
Through ScreenSharing with the Dashboard open, the mouse cursor flickers and moves with a delay of about 5 seconds.
if so, it might be worth trying to click on each of the drive bays in dashboard (or to bring up the dropdown/tabs with info about the bays) when you get a moment, just in case there are any more warnings or healed drive messages, which are somehow not popping up as messages, but possibly trying to be brought to the front of the dashboard window, which eats up cpu cycles or something similar?
Thanks for the replying. It’s the same drobo. The drive that was failing has long since been replaced and one of the other drive upgraded.
Everything is green and each drive shows Heath as good.
The mac has also been rebooted a couple of time since the dashboard upgrade.
The fault has no impact on CPU, use of which is negligible. If I access dashboard using the screen and keyboard attached to the mac, there are no issues. If I access the same mac using screeensharing, it is fine when the dashboard is minimised, but as soon as I maximise the dashboard, the mac becomes very unresponsive. CPU usage remains low.
ah thanks leakh, it might be a bug that unfortunately crept in,
am not sure about specific requirements of screensharing on a mac as only have a windows computer but maybe there is a way to fully exit dashboard, and then to try launching it once in screensharing mode?
I had filed a bug report (about 3-4 years ago?) that Drobo Dashboard renders screen sharing pretty much useless if the available bandwidth is too low.
But looking at the overall “quality” of the Dashboard software for Mac…the seem to be happy if it is working (hopefully) at all.
The Dashboard software (Mac) constantly redraws the whole f***ing window all the f***ing time. …and switches to the dedicated GFX if available on mobile macs. This is a bandwidth / CPU / GPU hog and every dev that has worked on that code should be ashamed. This is so sad…
maybe there is a way to set a frame rate limit, like with some games that start out at a fixed 60fps, some can be limited to run at 20 or 30 fps even i think as low as 10 fps. maybe there is a way to control that on a mac too that might help (but am not a programmer).
That’s would certainly explain the behaviour - constantly redrawing the dashboard would be more than Screen Sharing could cope with, even with a good network connection.
There is no other bottleneck - CPU and memory usage are low and if I control the Mac directly through a locally attached mouse and screen, there is no problem.
constantly redrawing it’s window (don’t know - have not done any openGL stuff myself)
requiring the dedicated GPU. This is only a small build flag to enable the integrated GPU for an openGL app. Mobile Macs use the dedicated GPU as a default if the app uses openGL. But since this is no demanding game with sophisticated graphics…this should not be necessary and COULD BE FIXED IN 5 SECONDS.
thansk jemi2,
btw a new version of dashboard just got released recently, version 3. i had a quick look and it looks like some new improvement features got added, though as i couldnt see an entry specifically for screensharing, i created another post here for you in case it helps: http://www.drobospace.com/forums/showthread.php?tid=147583
Well things went from bad to terrible with 3.0 dashboard. The Drobo Dashboard 3.0.0 on my Mac mini refused to find the attached Drobo (4 bay Gen 3) even though the volumes were mounted on the Mac. Also the Drobo drive icons were missing - just the default Mac ones instead. And on top of that, the Mac was very unresponsive (direct access, not using screen sharing) and the Drobo backup volume was showing errors that the Mac Disk Utility could not fix.
I tried installing the 3.0.0 dashboard on my MacBook Pro and connecting the Drobo to the Mackbook Pro. Same issue.
I then tried the same connecting the Drobo to a Windows 10 laptop with the 3.0.0 dashboard. On windows, the 3.0.0 dashboard was able to discover the Drobo but as the volumes are formatted for Mac, is was not, of course, able to mount them.
So I have reverted to 2.8.1 - all my problems go away with that version.
If I had to guess - The part of the 3.0.0 dashboard that probes to find an attached Drobo was the cause of the issue, that would explain both the fact the dashboard could not find the Drobo, and, perhaps how the dashboard could cause disk issues?
cool for jemi (at least on one front)
but oh no for leakh… ill hold off more advice for now then
one thing though… .another user just recently mentioned that they were not able to see the drobo in dashboard after updating it to v3, but a restart of the drobo, mentioned here, got things working again (at least from the visibility point of view) http://www.drobospace.com/forums/showthread.php?tid=147598
(you probably did restart but just to mention)
Update - I eventually braved the 3.0.0. update again after reading other threads with similar problems, where it was determined that a reboot of the Drobo was needed after the 3.0.0 dashboard update.
Since then I have not had a problem with the new dashboard (3.0.0) and it seems to have cured the issue I was having with the 2.8.5 version.
