Different Errors running pipe test

Programming and Development Macros and Scripting
21

I rarely use Windows, but if I recall correctly, the default “capacity” of a named pipe on Windows is rather small. I have an unproven theory that mod-script-pipe can break if either of the pipes become full, so Python should attempt to read back from Audacity after each command that is sent so as to receive any data that Audacity may have sent.

This is not generally a problem on Linux because named pipes have a much larger default capacity.
(Name pipes are basically special kinds of “files” on Linux. They’re a bit more “magical” on Windows, and are not even part of the normal filesystem.)

22

No, because the pipe_test.py code was only intended as a quick and dirty test to confirm that mod-script-pipe (the module in Audacity that handles external scripting commands) is working.

The “pipeclient.py” module on the other hand illustrates a much better approach for practical use.

23

Maybe something here to help? What are reasons for local Windows named-pipes to fail? - Super User

24

I’m seeing failures with zero messages going in or out of the named pipes other than whatever Audacity might be doing. So while your theory may or may not be valid, it doesn’t seem to have anything to do with the problem I’m seeing.

25

Short answer: No. (but I’m on Linux)

26

Let me rephrase my question: Have you tried testing the named pipe functionality on Windows 11 to see if it works reliably for you?

I’m not particular on what Python code to use to access the named pipes so long as it works. I only used the pipe_test.py since it was put out there as the example of using named pipes to Audacity.

The irony is that based on my experience, the pipe_test.py code was does not confirm that mod-script-pipe is working.

27

Yes, scripting is an officially supported feature at present. However, mod-script-pipe hasn’t been touched by the new development team (https://github.com/audacity/audacity/tree/master/modules/mod-script-pipe) and just one small change to mod-script-pipe.py (Pass encoding for pipe open · audacity/audacity@cf0acbd · GitHub) about a year ago.
You may see a trend in the current development direction from these videos: https://www.youtube.com/@audacity/videos?view=0&sort=dd&shelf_id=0

28

I’ll have to wait until I I get back to better bandwidth to watch the videos…

29

If I recall correctly, Process Explorer from sysinternals allows you to inspect named pipes on Windows. Maybe you could get some clues / insight about the problem from that.

30

Process Explorer does not allow you to inspect named pipes Windows. PipeList seems like it does but I can’t seem to get it working on my computer.

31

This code seems to consistently reproduce the problem I’m having with the Audacity 3.3.3 named pipes closing on Windows 11:

import os
import time
import sys

PIPE_TO_AUDACITY = '\\\\.\\pipe\\ToSrvPipe'
PIPE_FROM_AUDACITY = '\\\\.\\pipe\\FromSrvPipe'

def pipe_exists(pipe_path):
    return os.path.exists(pipe_path)


def check_pipes():
    print(f'Loop\tTo\tFrom')
    for loop in range(0,500): 
        if pipe_exists(PIPE_TO_AUDACITY):
             to_status = 'open'
        else:
             to_status = 'CLOSED'
        if pipe_exists(PIPE_FROM_AUDACITY):
             from_status = 'open'
        else:
             from_status = 'CLOSED'
        print(f'{loop}\t{to_status}\t{from_status}')
        if to_status == 'CLOSED' and from_status == 'CLOSED':
            sys.exit()
        time.sleep(1)


print('Opening Audacity')
os.startfile('C:\\Program Files\\Audacity\\Audacity.exe')
print('Waiting 5 seconds...')
time.sleep(5)
check_pipes()

When I run it, I get the following output:

Opening Audacity
Waiting 5 seconds…
Loop To From
0 open open
1 open CLOSED
2 CLOSED CLOSED

As you can see, it isn’t even a matter of using the named pipes causing any sort of problem.

Audacity often produces a crash log when I close Audacity after running the test.

My project is kind of dead in the water until I can get the Audacity named pipe issue resolved. What can we do to get this problem resolved?

32

I can’t test that script as it is Windows specific and I’m on Linux.

The last version that I tested extensively with Python scripting on Windows was Audacity 2.4.2.
If that version has the same problem for you, then the issue is probably not in Audacity.
On the other hand, if pipes work reliably for you with 2.4.2 (and not with recent versions of Audacity, then that’s a strong indication that there’s a regression bug that needs to be logged and fixed.

Audacity 2.4.2 is available here if you want to try it: Old Audacity versions download

33

I tested with Audacity 3.3.3 because that was the version you said to test with:

See if you can identify reliable steps in 3.3.3 that trigger the problem.

I have already spent a fair amount of time reproducing the problem. I have provided code that reliably trigger the problem for me.

At what point does someone familiar with the current codebase and can test it on Windows get involved with chasing down problems like this?

34

I’ve seen multiple reports of problems with macros in Audacity 3.4.0 and 3.4.1. (Macros and scripting share a lot of common code). Trouble shooting an issue in scripting would be near impossible when there are know bugs in the way.

Audacity 3.3.3 is a reasonably recent version of Audacity, but has been around long enough that I would have expected this issue to have been reported before it the problem was in Audacity. I haven’t heard of such bugs, but it’s a small minority of Audacity users that use the scripting feature.

Audacity 2.4.2 is the last version that I’ve tested personally on Windows, and have not seen the issue that you are describing.

As I said in my previous post, If that version has the same problem for you, then the issue is probably not in Audacity. On the other hand, if pipes work reliably for you with 2.4.2 (and not with recent versions of Audacity, then that’s a strong indication that there’s a regression bug that needs to be logged and fixed.

You can log the issue yourself on GitHub (Issues · audacity/audacity · GitHub registration required), but it’s more likely to get the developer’s attention if we could be sure that it’s a regression against a previous version.

35

I’ve done a clean install of Audacity 2.4.2. I modified my test code to find Audacity in “Program Files (x86)” instead of “Program Files” since that is where 2.4.2 installed into by default.

I’m seeing the same sort of results. Sometimes it take a few more loop than other times:

Opening Audacity
Waiting 5 seconds…
Loop To From
0 open open
1 open open
2 open open
3 open open
4 open open
5 open open
6 CLOSED CLOSED

Opening Audacity
Waiting 5 seconds…
Loop To From
0 open open
1 open open
2 CLOSED CLOSED

Opening Audacity
Waiting 5 seconds…
Loop To From
0 open open
1 open CLOSED
2 CLOSED CLOSED

I’m guessing that you tested Audacity 2.4.2 before Windows 11 came out and that 2.4.2 hasn’t been tested on Windows 11 and therefore this could be an issue with Audacity on Windows 11.

36

According to this article [What are reasons for local Windows named-pipes to fail? - Super User] it is possible for pipes to be blocked by a firewall. It’s a very old article, so details may be different in Windows 11, but perhaps worth checking.

37

If that was the case then the named pipes should never work versus intermittently working.

38

Sure, but we got here because something is not working the way that it “should”.

You could try asking the developers on discord if they can reproduce the problem on Windows 11.
The discord channel is here: Audacity dev (time limited link)

39

That article is over a decade old and some of the linked in it are long since dead.

40

Yes. As I said

To be clear,

  • I don’t have Windows 11
  • I can’t reproduce the problem on my computer
  • I’m no longer involved in developing Audacity
  • I posted an invitation link to the Audacity developer’s discord channel so that you can ask them directly