MOTUnation.com

"Trash Prefs" "Repair Permissions"

These are the top fixes for everyday problems. It solves so much of our crashes. What if MOTU could develop some method in which these two items (or especially trashing prefs) wasn't necessary? Is that even possible? So many troubleshooting posts are wasted on "Help, DP crashed" only to find that trashing prefs solved it. Imagine how much less time would be wasted, by users, tech support, and our forum, if this wasn't needed.

Any ideas?

Plists are saved when you close a program, retaining settings when you last left the app. To stop them from getting corrupted they'd have to be locked, but if you check them with GETINFO they are locked. At least, that is my understanding. Technically, they are called a Property List (not a preference list, as often referred to). Same thing to guys like us.

How and why they go south is above my pay grade. Preventing such corruption is apparently beyond many pay grades, maybe all pay grades at this point in computing history.

Trashing prefs and repairing permissions are guesses. When I started out in tech support (long before there was such a thing as "permissions"), I was taught that trashing prefs was an absolute last ditch guess at solving a problem. It's far better to not guess, and to find out exactly what is going on.

For example, in the DP View Filter, it is possible to hide some or all of your sequence data. The View Filter settings are stored in preference files. If you can't figure out why all your data is invisible, trashing the DP prefs will cause DP to make new default prefs which include the settings to show all data (which fixes the problem). So in that example, the prefs were not corrupted. However, by trashing the prefs, all the other user preferences were lost. Also, the user doesn't know what went wrong or how it got fixed. Instead they blame a "corrupt preference".

Any file on a computer can get corrupted, however actual preference file corruption is relatively rare. As part of my troubleshooting, if I can't find the cause of the problem, I may ask the customer to move their preference files to the desktop to see if that makes any difference. I never tell a customer to trash their prefs unless I have solid evidence that a pref file is somehow broken.

An easier way to test for preference related problems is to create a new user account in the computer and launch from there. The new user account won't have the old user account prefs, so that's a quick way to check without disassembling the original user account prefs.

Some preferences are file specific. Some preferences are global to all DP files. There are also other preferences that affect DP, such as preferences for Audio MIDI Setup or the audio interface. Again, launching from a new user account allows for testing with all new default preferences.

In DP8, there is a button in the Preferences window to restore factory default preferences.


File and folder permissions govern whether the file or folder can be modified or read, and by whom. For example, if a presets folder does not have read permission for the current user account, any enclosed presets will not be available. If the preset folder does not have correct write permissions, new presets can not be stored to that folder. I've seen that specific behavior when a presets folder was copied from one computer to another. The presets folder had correct permissions for the original computer, but did not work on the new computer.

The Apple Disk Utility has a Repair Permissions function, but it's effectiveness is limited. The Apple Disk Utility only looks at specific folders in the OS. It doesn't look at any custom installed folders or files, so there could be a permissions problem that doesn't get fixed by the utility.

Typically, permissions problems result in software not installing correctly, files not being able to save correctly, or files not being available. In my experience, the first symptoms of a permissions problem have to do with not being able to open or save, or some other symptom involving missing files. Permissions problems are relatively rare, and you have to hunt them down based on context. For example, if I see a problem saving presets, I go and look at the preset folder and enclosing folders.

Dave

magicd wrote: For example, in the DP View Filter, it is possible to hide some or all of your sequence data.

Having that key command default to cdm-f is a cruel joke, IMO. I can't tell you how many times people (including myself) have "lost" data only to later discover we invoked what is usually a "find" command in virtually every other program, but in DP hitting that key opens the View Filter. Then, on top of that, the usual "dismiss" box location (bottom right of the dialogue) "sets all" in the view filter. You think you're clicking a dismiss box (if you do it instinctively as some do...) but in effect you are making all your stuff invisible! I'm sure we're fielded at least a few dozen issues like that in this board due to the "cmd-f surprise." The first time it happened to me a client had driven 90 miles from Santa Barbara to LA to work with me only to find all the data "gone" and had to return the following week to finish the session. That was not fun.

A cruel, cruel, joke...

But we still love you, man. Thanks for detailing the plist thing. Ride on!

Very lucid, Magic D.

Thanks!


Sent from my iPhone using Tapatalk

Here’s a trick that may get you close to your dream of automatic prefs fixing.
Make your DP prefs how you like them, all the way down to the smallest detail.
Then, QUIT DP.

Go to the prefs files and drag a copy to the desktop and name the folder “safety prefs”.

This way you have a PRISTINE, perfect prefs file with all your favorite settings.
You’ll notice you did NOT do any work in DP after you created this file, you just quit.
That ensures no corruption could occur.
Now, every time you think you need to trash DP prefs, replace it by option dragging the “safety” prefs file into the appropriate prefs folder in your user account.
It’s not quite “automatic”, but it saves a lot of time and takes away the reluctance of making a new prefs file should DP start acting screwy, because you don;t have to MANUALLY re set all your favorite settings...it’s just a drag and drop from the safety file!

toodamnhip wrote:...
You’ll notice you did NOT do any work in DP after you created this file, you just quit.
That ensures no corruption could occur...

... unless the corruption happens during the save process?

Not to hijack this thread, but I think this is relevant. While we have MDave on the line I'd like to ask the question, "Are there other preferences other than MOTU's or DP's that can be deleted as a diagnostic tool?"- This in response to this thread regarding an active TechLink where I have been advised that some pref other than MOTU's may be affecting my ability to use Broadcast Wave files:

http://www.motunation.com/forum/viewtop ... =1&t=54354

OMG, c/t don't take my quicktime suggestion as an authoritative response. As stated in that thread, I was basically throwing ideas at the wall. But it does have me thinking (always dangerous).

Does the timestamp aspect have anything to do, for example, with the clocking from one's audio device? Again, I'm ignorant in that regard or I wouldn't be asking, but if there was a correlation, then the audio device (as well as the driver, and plists) providing the clock might also be a factor. It can't be just a DP thing since other programs also access and process those files. I guess what I am getting at in relation to your question is which other programs and files impact the use of timestamped audio? My best guess is Quicktime which is why I thought that deleting that plist might be something to try. Clearly, it was not.

MIDI Life Crisis wrote:OMG, c/t don't take my quicktime suggestion as an authoritative response. As stated in that thread, I was basically throwing ideas at the wall. But it does have me thinking (always dangerous).

.

No MLC, please relax. It was a tech from MOTU who suggested the very same thing.

Whew! That was a close one... ha ha ha!

MIDI Life Crisis wrote:Whew! That was a close one... ha ha ha!

No problem, but can I interest you in a butt-ugly kitchen in the UK?

Frodo wrote:

toodamnhip wrote:...
You’ll notice you did NOT do any work in DP after you created this file, you just quit.
That ensures no corruption could occur...

... unless the corruption happens during the save process?

Well,
If you create a NEW pref file and then crash on save immediately, it is NOT the pref file that is the culprit then is it?
Therefore, one would need to fix something else.
But once DP works at all in any DECENT manner, this is a cool trick.
If DP is so screwed up as to crash upon the creation of a new pref file, there are bigger problems.

toodamnhip wrote:Here’s a trick that may get you close to your dream of automatic prefs fixing.
Make your DP prefs how you like them, all the way down to the smallest detail.
Then, QUIT DP.

Go to the prefs files and drag a copy to the desktop and name the folder “safety prefs”.

Or, simply grab the file from a TM backup as needed. This way one can even choose the desired date.