Basecamp 4.1.1 for MAC hangs when Time Machine backing up

Former Member over 12 years ago

I have stumbled across the reason my BaseCamp session seems to hang with just the colour wheel rotating for a few minutes at a time. It's down to the fact that Time Machine is busy updating it's backups. When it does so, it mounts the Time Machine as a volume under Finder. BaseCamp picks up that a new volume has appeared and tries to do something clever like look for maps. The result is BaseCamp hangs until Time Machine is finished and dismounts the volume. This is behaviour is new to v4.1.1.

The work around it to stop Time Machine manually (if displayed, click the Time Machine icon in the menu bar at the top of your screen and select "Stop Backing Up"). If you have the default time machine settings, you'll find yourself doing this once every hour while you are running BaseCamp!

I reported it to Garmin support and they just said:
"Unfortunately the configuration of the hardware of the Time Machine may
conflict with our software as it is a removable/virtual drive.
Unfortunately we have no control over the Time Machine configuration the
only solution we could offer is one you have already tried which would
be to temporarily disable this service while using our software."

Hope this helps someone, and Garmin sort something out to either recognise (and ignore) time machine volumes, or allow users to specify which volumes to ignore.

0 Former Member over 12 years ago

Thanks for posting this I've been experiencing the same issue after the update. Curious Apple would not step in since isn't Basecamp an approved App from the App store?

0 danham_ over 12 years ago

This problem actually dates back to much earlier versions of BC. Another workaround is to designate a Firewire drive for TM backups, not a USB drive.

I had this issue with every version of BC when I used a USB drive on my WiFi network for backups. Now that I use a connected Firewire 800 drive, the device never appears in the BC window even though it appears on the desktop as "green" TM drive.

-dan

0 mgasser over 12 years ago

It's not just a USB issue. It happens to me even though I'm using a TimeMachine volume attached (by USB) to another Mac on my network.

0 danham_ over 12 years ago

It's not just a USB issue. It happens to me even though I'm using a TimeMachine volume attached (by USB) to another Mac on my network.

Not sure what you mean by "not USB," especially when you say it is a USB drive attached to another computer on your network. This is exactly what my post above talks about -- a network-attached USB drive. The workaround I mention is to use Firewire instead.

BC is not able to differentiate between a USB device you don't want included in the list and a GPS or its SD card. You could also un-mount the USB drive while using BC. This may throw an error nag message when Time Machine goes looking for it, but that is less intrusive than BC hanging.

-dan

0 mgasser over 12 years ago

Not sure what you mean by "not USB," especially when you say it is a USB drive attached to another computer on your network. This is exactly what my post above talks about -- a network-attached USB drive.
-dan

Sorry, I read the first post which didn't say anything about the drive being on a network, so I thought it was referring to a directly-attached drive. Disconnecting my other computer's Time Machine drive isn't a very good option, and unfortunately the Firewire connection has proved problematic.

0 danham_ over 12 years ago

Sorry, I read the first post which didn't say anything about the drive being on a network, so I thought it was referring to a directly-attached drive. Disconnecting my other computer's Time Machine drive isn't a very good option, and unfortunately the Firewire connection has proved problematic.

No problem; just trying to help. I agree that disconnecting isn't a very good option, but it may be the only one, given that I also have to wonder how realistic it is to think that BC will ever be able to tell the difference between a mounted USB drive and a GPS. Maybe there is some way to tweak it so BC doesn't hang up while adding a Time Machine drive to the list, but I'm a little skeptical of that. I hope I'm wrong.

-dan

0 mgasser over 12 years ago

I also have to wonder how realistic it is to think that BC will ever be able to tell the difference between a mounted USB drive and a GPS.

Surely it's not rocket science, for BC examine quickly some high level contents of the device to determine it's not a GPS. I have a number of very large USB drives on my system that are not Time Machine, and BC seems able to ignore these just fine. There's something else going on here unique to Time Machine. Also it only fails while Time Machine is actually running, whereas my drive is mounted all the time.

0 Former Member over 12 years ago

This has really been bugging me. My setup is similar to the original poster’s: Mac with Time Machine using a network mounted hard drive.

When a Time Machine Backup runs, two volumes are mounted: 1) the network attached disk, 2) the sparse bundle backup DB disk image located on the network attached disk.

The problem with BaseCamp hanging doesn’t appear to be a conflict with the Time Machine back-up process per se, but with the sparse bundle disk image. If I turn off Time Machine automatic backups and manually mount the network attached drive and then the sparse bundle disk image then BaseCamp hangs and the beach ball starts spinning. If just the network attached drive is mounted then BaseCamp doesn’t have a problem. The issue has something to do with the disk image being mounted.

It looks like BaseCamp is doing a fairly exhaustive scan of all the directories in the "Time Machine Backups" volume contained in the sparse bundle. I can see this by running /Applications/Utilities/Console.app, searching for the BaseCamp process, clicking "Inspect" and then watching the "Open Files and Ports" tab. Every few seconds BaseCamp accesses a folder somewhere deep within the "Time Machine Backups" volume.

At this point I have two questions. 1) Why is BaseCamp traversing terabytes worth of backup directories if all of Garmin's data is supposed to be stored in a "Garmin" folder at the root of any attached device (in mass storage mode anyway)? 2) Why is it so slow in doing this scan?

I’ve tested this by mounting another Time Machine Backups sparse bundle over the network (one that was created by another mac in the house) with the same result. So I don’t think it is a problem of a corrupt disk image volume. (Also, I ran a Disk Utility repair on both the physical disk and the disk image and no problems were reported).

BaseCamp also freaks out if I attach the Time Machine drive directly to my computer via USB and then mount the sparse bundle backup DB disk image. Again it starts opening all the directories in the backup, one by one, looking for something. The only difference is that when attached locally, the data read per second is between 4 and 7 megabytes, versus between 200 and 400 kb when connected remotely.

There is obviously a design flaw in BaseCamp 4.1.1 that needs to be fixed.

Sample of BaseCamp open directories on Time Machine Backups volume when attached over the network (2012-10-01-171030 is the oldest backup):

[FONT=Courier New]/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/External 1TB A/Applications/Toast 10 Titanium Pro/Toast 10 Titanium/Toast Titanium.app/Contents/Resources
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/External 1TB A/Data/.../.../.../.../.../.../Raw
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/External 1TB A/Documents/.../.../.../.../.svn/text-base
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/External 1TB A/Documents/.../.../.../.../.../Portraits Edit/Hi-Res
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/Macintosh HD/Applications/Adobe/Adobe Help.app/Contents/Resources/HelpIcons
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/Macintosh HD/Applications/Adobe Media Encoder CS5/Adobe Media Encoder CS5.app/Contents/Frameworks/MediaUtils.framework/Versions/A/Resources
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/Macintosh HD/Applications/Adobe Media Encoder CS5/Adobe Media Encoder CS5.app/Contents/Frameworks/SettingsUI.framework/Versions/A/Resources/png
[/FONT]

Ditto when the Time Machine Backups volume is attached locally:

[FONT=Courier New]/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/Macintosh HD/Applications/Address Book.app/Contents/Resources/AddressBook.help/Contents/Resources/Spanish.lproj
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/Macintosh HD/Applications/Address Book.app/Contents/Resources/ca.lproj
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/Macintosh HD/Applications/Adobe Media Encoder CS5/Adobe Media Encoder CS5.app/Contents/Frameworks/dvaui.framework/Versions/A/Resources/png
/Volumes/Time Machine Backups/Backups.backupdb/[my computer name]/2012-10-01-171030/Macintosh HD/Applications/Adobe Reader.app/Contents/Built-in/Multimedia.acroplugin/Contents/Resources/exv
[/FONT]

0 danham_ over 12 years ago

Very nice bit of detective work. Thank you!

This explains fully why my FW 800 Time Machine drive does not cause the problem; no sparse bundle needed because it is plugged right into my iMac.

The whole sparse bundle deal has always been a source of problems with TM using NAS.

-dan

0 Leursism over 12 years ago

Thanks a lot for sharing your insights! I just upgraded Basecamp to the latest version (4.1.1.0) and immediately encountered the problem with the spinning wheel. Thanks to the replies I solved the problem by disabling my back up routines, although I am not planning to do that everytime I use Basecamp. I think the Garmin software developers did a crappy job. Why did it work fine in the previous version? I still cannot understand why such lousy software is written in the year 2013.