DP 4.6: problem saving

[mindswerve]

i save like a maniac. an "itchy save finger". using dp 4.6 on a dual 800 g4, os x 10.3.9- i'll do a routine save and i get "can't save to disk- try using another disc, another folder or another name". NONE of these work, and i have 5 disks to choose from. my ONLY option is force quitting and not saving anything (sometimes i take a screen snapshot of where i am JUST to re-do something of where i was)

anyone else getting this problem?
know the culprit?
a workaround?
(i was using almost no 3rd party plug-ins too)

[studiodog]

I get that occasionally in 4.6.
This version DOES NOT like it if you make a lot of fast moves.
Most, if not everytime, if the program hasn't gone into the permanent beachball, it will still let me save if I give it a few seconds and try again.

[Shooshie]

You may also be experiencing a kind of corruption that we've beend discussing in some other threads. It's possible that you could have this corruption going on without knowing it. Until you do certain things, it's not likely to reveal itself. Check the following threads and see if any of this might apply to you. After my corruption started, I also had the save problem. But I had never had it prior to that.

UnicorNation Bulletin Board: Report on 4.6 problem

UnicorNation Bulletin Board: AU softsynths gone AWOL in DP 4.6

UnicorNation Bulletin Board: Switching Chunks DP 4.6

UnicorNation Bulletin Board: mixing board layout

UnicorNation Bulletin Board: Crackling audio? Try CoreAudio Aggregate Devices. (this thread isn't about corruption. It's about a fix for audio which a number of us tried recently. It may be related to the corruption, so I'm including it here for reference. But, it may be totally unrelated. This is just here to help find clues to what's been affecting a lot of people all of a sudden.)

Good luck finding it, and if you come up with any corroborating clues, please drop us a note and let us know! Version 4.6 is too good to have to drop. I don't want to go back to 5.2.

Shooshie

[dix]

I'm getting this too. When this happens, "Save A Copy As" works 90% of the time. Then a quit and restart of DP makes things right again. ...only seems to happen on files w VIs present.

[larrytheo]

I, too am having the same problem, but it didn't start with 4.6. I know for certain I had it with 4.5.2 and I believe I had it before that. This indicates that it is almost certainly session corruption, especially since it is only the one session that has the problem.

However, my session is different than some of the others discussed here in that it is pretty much all audio, no VIs. I had two tracks of Mach5 on some chunks, though not the chunk I'm currently working on. Perhaps that has something to do with it.

In any event, I have about 30-something tracks of audio (only a dozen or so of which play continuously through the whole tune) and at least that number of chunks, plus lots and lots of takes (most of which are unused).

Save As doesn't work, Save a Copy As doesn't work. As with others, I've tried saving to different volumes, different disks, different names, the whole deal. Nothing works.

Trashing the session and starting over is simply not an option, there is WAY too much work in this session to be able to recover without many weeks of full-time work.

I'm thinking of either deleting all chunks other than those that absolutely must be kept (and there's more than one of those), or making a new session and trying to copy the key sequences over to it. I guess it depends on where the corruption lies, but I fear it's in the header or wherever the basic session definition is stored.

Any suggestions? I am VERY frustrated. (I still love DP, but I'm *very angry with it* right now.)

Larry the O

[qo]

This, I'm almost certain, is a DP bug rather than session corruption. Someone else mentioned it earlier and provided specific output. The output included an OSX file system error code -50. This corresponds to:

paramErr -50 Invalid value passed in a parameter. Your application passed an invalid parameter for dialog options

What specific error are you guys getting (you may want to look in /Library/Logs/Console/XXX/console.log

Where XXX is a number (on my system, it's 501).

In Terminal you could do:

tail -f /Library/Logs/Console/501/console.log

This will display all new lines that are added to console.log in realtime.

Now, try to save in DP. You should see some output in Terminal corresponding to the error.

Copy/paste that here, and we can debug further.

[dix]

Larry. If you quit DP w/out saving changes and open the file again are you still getting the error? This has not been the case for me. After relaunching DP I'm able to save normally.

...Have you tried starting a new Project and then Loading the Chunk into it? Loading often seems to fix problem Chunks.

<small>[ August 10, 2005, 11:41 AM: Message edited by: dix ]</small>

[danworks]

Hi guys,

I wrote about this replying on a similar topic.

Keep your Background Processing window open with the option of viewing 'every'task. I believe that when you're trying to save your project DP is probably doing something else on background like analyzing or beat detecting. I saw this error too, after having recorded some audio, couple of minutes or more.

When you get that warning, if you try to wait a little and then save on the same location with the same name, you'll see that it'll save the file no problem.

On your BGP pref, set the processing "only when needed" and you shouldn't see that message anymore.

Having said that, it's a DP bug.

[dix]

A good theory, but I can't seem to get the error to occur this way. I am able to save normally while BG processing is going on. Since this problem is intermittent for me I'll have to wait for the 'unable to save' error to come up again and *then* try this out.

Does anyone have a file that the error is occurring on 100% of the time?

[magicd]

Deja vu?

I spent some time a month or so ago working with a customer who had problems where he couldn't save a file. He sent me copies of files and I found that the file permissions had been changed to read-only. That would certainly disable DP from saving the file.

If you get an error when trying to save, get info and check permissions on the file.

You can also send me rougue files and I'll take a look at them. If you are going to do that, please archive the file first and do not send me anything other than the DP session file. My email server will strip off any attachment larger than 2mb.

Magic Dave
magicd@motu.com

[qo]

Hi magicd,

Thanks for the reply. File permissions don't change on their own though. What other people are describing, and what I have also experienced, is that sometimes a file that is normally savable, becomes unsavable. It's intermittent. If you quit DP, reopen the file, and save, it works most of the time. This wouldn't be the case unless the file's permissions are changed randomly. I don't see how this could possibly happen unless DP, or some other process, is changing permissions behind our backs.

As a test, I just changed the permissions on a DP project file to Read Only and the error message is not the same as what we are experiencing. Rather, the error message when intentionally changing permissions to read only says:

An error occurred while writing to the disk. The file TestProject was not saved.

You do not have the right privileges or the file is read only. Try to save your file to another disk or folder, or with a different name.

In contrast, the error I've seen involves ID = -50, similar to this thread, only I'm not using an external drive that's FAT32 formatted.

Thanks again.

<small>[ August 11, 2005, 09:21 PM: Message edited by: qo ]</small>

[dix]

Thanks for the reply. File permissions don't change on their own though.<snip>

Apparently they do. If not then why are we always having to constantly Repair Permissions? ...I'm sorry, but after two years of OSX only computing I still can't answer that question. Clearly the answer to this issue has something to do with OSX's Permissions silliness, but what is it? Has anyone other than Magic Dave been able to fix an open DP file by changing it's Read/Write status?

[qo]

Apparently they do. If not then why are we always having to constantly Repair Permissions?

Hi dix,

Repairing Permissions involves only files that are accounted for in the BOM (Bill of Materials) files that exist in /Library/Receipts/*.pkg (yes, I know you're talking generically i.e. about ANY file's permissions mysteriously changing, and that you likely already know this about Repair Permissions, but go with me for a second...)

The permissions of these (mostly system and application) files could get changed by, for example, the Installer for an application, or some maintenance script running under cron, or even because Apple decides the permissions should be different between OSX versions (perhaps based on security issues). The point being that something changes the permissions. They don't just up and change on their own. An OS's file system is probably the most tested part of the OS. It has to be since so much is riding on it. If you issue the following in Terminal, as root (or as a user with Admin privileges), (but, don't...):

chmod -R 755 * /

and then Repair Permissions, I can guarantee that hundreds or thousands of files will be listed as fixed. Many hundreds of others will be changed, but not fixed, because they aren't listed in a BOM file.

An Installer could do the same thing if the app's developer goofed.

Our beloved DP session files are (IMHO) less likely to be "in the line of fire" of errant Installers or cron scripts (especially in cases where folks are saving them on external disks, or non-system disks) since these Installers/scripts are typically changing things on the system volume only.

For removable media, permissions are even more strange since that media can be moved between multiple OS's and multiple machines, where e.g. UID/GID (user ID / group ID) are different. Ownerships can change and, in fact, are pretty tenuous with this sort of disk anyway. This is why the "Ignore ownership on this volume" option is available for for all volumes (whether physical disks, or partitions) except the system disk/partition.

Anyway, when we moved from OS9 to OSX, we also moved from a single-user environment to a multi-user environment (where some of the "users" are created for OS background processes to run as). So, in addition to simple permissions, we have permissions for user, group, and other; which further complicates things.

But, files outside of the system volume, except for removable media, shouldn't be randomly changing characteristics unless an application, or user, changes them. That would be a serious OS bug indeed. Not to say it couldn't happen. But, I've just got to believe that Apple has really sophisticated automated file system test suites.

<small>[ August 11, 2005, 11:25 PM: Message edited by: qo ]</small>

[mindswerve]

thank you all for your effort in trying to figure this out-
since my initial/first post i've gone back to using dp 4.52 and *so far* the unable to save problem hasn't happened....

is there a 4.61 "fix" on the horizon? hope so....
(a bug this heavy should warrant a maintenance fix)

the last thing i want to do is fiddle with file permissions and start guessing while i have a client in the room with me

thanx

[pcm]

I am having a similar yet different "permissions" problem. Ever since 4.5, I occasional have files that repeatedly put up error 61 when I try to save. The dialog box suggests I save to a different drive or use a different name. I dismiss it, and it always takes the save command the second time. But it keeps cropping up for the remainder of the session. This happens on LOTS of projects. It never existed before 4.5, and I have never seen it with any other application. I have seen other users bring this exact scenario up as well.

It's an interesting idea that perhaps it is related to moving projects to and from different drives. I have two machines, one at my studio, one at my home. I wonder if there is a pattern here relating to the projects being opened and saved on different machines. Both machines have the same user name (mine). I sure would like to see this gone.....