Unable to run Audacity 2.1.0 with Os X network account

[kozikowski]

only the user data ("~/username" to clarify), like the Audacity preferences, is stored and accessed through the network

Without getting down to the fine details, Audacity doesn't understand network delays and management (yet). If it needs to access any part of the application over the network then that portion becomes subject to critical timing. It's possible you got lucky with the other version.

Koz

[Leland]

Leland, I will check this out after the Easter holidays, but I have no memory at all seeing an .audacity.sock file in "application support/audacity" on my regular (working) mobile account, which is configured to show hidden files.
A quick google shows no sign that SL-Server wouldn't support sock files. My knowledge about them is very limited though, this is the first time I'm made aware that they exist.

You would search for Unix domain sockets. They are for IPC between processes running on the same machine. I'll also poke around to see if I can get a definitive answer.

Enjoy the holiday.

Leland

[Leland]

Leland, I will check this out after the Easter holidays, but I have no memory at all seeing an .audacity.sock file in "application support/audacity" on my regular (working) mobile account, which is configured to show hidden files.
A quick google shows no sign that SL-Server wouldn't support sock files. My knowledge about them is very limited though, this is the first time I'm made aware that they exist.

I couldn't find a definitive answer, so I tested it myself. While I don't have OSX Server, what I try to pass off for a brain kicked in and I realized that I can do AFP sharing between two clients...DOH!

Anyway, as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory. I assume that would be on the local filesystem???

Leland

[Gale Andrews]

Thanks for looking into this, Leland.

as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

[Leland]

Thanks for looking into this, Leland.

as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there's a more concrete reason to put the socket file in the user specific temp directory.

Leland

[Gale Andrews]

Thanks for looking into this, Leland.

as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there's a more concrete reason to put the socket file in the user specific temp directory.

Leland

So if we don't need the socket file to be in the same directory as the lock file, it seems we should actually go back to putting the socket file in the user specific temp directory.

I "think" TwinOak is saying that the chosen Audacity temp folder is actually on the local computer and not being read over the network. But if it was chosen to put the Audacity temp folder where the ~/username is (on the network, as I understand it) then it would presumably still fail.


Gale

[Leland]

Thanks for looking into this, Leland.

as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there's a more concrete reason to put the socket file in the user specific temp directory.

Leland

So if we don't need the socket file to be in the same directory as the lock file, it seems we should actually go back to putting the socket file in the user specific temp directory.

Yepper, that's my take on it as well.

Leland

I "think" TwinOak is saying that the chosen Audacity temp folder is actually on the local computer and not being read over the network. But if it was chosen to put the Audacity temp folder where the ~/username is (on the network, as I understand it) then it would presumably still fail.

[TwinOak]

Thanks for looking into this, Leland.

as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there's a more concrete reason to put the socket file in the user specific temp directory.

Leland

So if we don't need the socket file to be in the same directory as the lock file, it seems we should actually go back to putting the socket file in the user specific temp directory.

I "think" TwinOak is saying that the chosen Audacity temp folder is actually on the local computer and not being read over the network. But if it was chosen to put the Audacity temp folder where the ~/username is (on the network, as I understand it) then it would presumably still fail.


Gale

To answer the question and clarify: we do not change the setting for the temp folder so it gets created in the default location on the local drive in all scenarios above.

I'm very impressed and grateful that you're taking the time, thanks a bunch!
Alexander

[Gale Andrews]

Leland has moved the socket file to the temp dir https://github.com/audacity/audacity/commit/44900e1.

If you want to try it, it should be in the latest nightly build from the top of http://www.audacity.homerow.net/index.p ... order=desc.


Gale

[TwinOak]

Nice! Can hopefully test this tomorrow, thanks!

/A