Sync makes system alert beep sound

Help and Support
1

Putting this in off topic as it's probably low priority and not something that bothers anyone.

So I've discovered that on Windows, while running a sync command, every time the stats update and refresh the command prompt window, the Windows system sound plays a beep sound.

Anyone else have this happen to them? Any way to stop it?

2

I've not heard of this before!

Which Windows version and which Terminal (cmd / powershell / etc) are you using?

3

Sorry for the delay in replying ... got stuck in work stuff.

I've just done a clean install of Windows 11 Pro, and my scripts (which normally run in a compiled scripting language) started making system beeping sounds.

So I tried manually running an rclone sync from a non-admin windows CMD prompt and the same system beeps can be heard. And, they exactly beep when the stats refresh and update the CMD window (every 15 seconds), so it's definitely something to do with the CMD window refreshing.

My test code is:

rclone.exe sync "<source_path>" "<destination_path>" --drive-stop-on-upload-limit=true --multi-thread-streams=16 --progress --progress-terminal-title --retries 99 --transfers=16 --checkers=16 --create-empty-src-dirs --stats=15s --fast-list --exclude-from Rclone-exclude-file.txt --log-level DEBUG --log-file="<log_file>"

I used to also get unexplained system beeps on my previous Windows 10 Pro build ... I wonder if this was the same root cause.

4

have you tested without --progress-terminal-title

5

Yes, that was the problem. Once I removed --progress-terminal-title, all beep sounds went away (tested with rclone sync and rclone dedupe ... both issued beep sounds).

@ncw might be worth checking the underlying code associated with that option?

Note: observing the behaviour more closely, I'm fairly sure that this was also happening under Windows 10 Pro.

6

Here is the code which writes the terminal title

And yes, it has a BEL on the end which is what will be making the beep!

Here are the definitions

That BEL character is how you terminate the terminal string.

So I guess Windows terminal just doesn't understand setting the title.

7

image
image1500×506 21.7 KB

Under Windows 11, there is an option under Command Prompt settings to change how BEL characters are handled. Not sure if a similar option is available under Windows 10.

So either someone can adjust the BEL handling under Windows 11, or as I did, just not use --progress-terminal-title.

Thanks folks.

8

The terminal shouldn't be playing a BEL at all, it should be using that as the end of the title string for the terminal. So I'd say windows terminal doesn't understand that escape sequence so don't use --progress-terminal-title with it. (There may be Windows terminals which do understand it though).

9

@ncw Just curious - what is the origin/significance of that particular escape sequence (\033]0; + title + BEL)? I'm just interested to know more as I've never heard of it before. Cheers.

Update: after some googling, it seems that escape sequence originates from bash.
Reference:

Windows Terminal Tab Title Setup | Microsoft Learn

10

See also ANSI escape code - Wikipedia

11

According to this post on StackExchange there is an alternative to BEL for terminating the string; ESC\ (ST, String terminator), but for all I know BEL could still be the more compatible alternative...

Using BEL (\007) to end an escape sequence is an anomaly. It does not follow the standard (ECMA-48). Operating system controls should begin with either ESC ] or 0x9d, and end with ESC \ or 0x9c.

Long ago, the developer(s) of xterm added an escape sequence for setting the title. In X11R1 (1987), the program simply read the sequence until it got a nonprinting character. Later, in X11R4 (1989), someone improved this by terminating on a BEL character. The standard had been around longer than that, but the reason for choosing BEL rather than ST is not known. Ultimately that was addressed in the late 1990s, by recognizing either (but keeping BEL as an alternative since many users relied on hardcoded behavior with BEL).

From a PowerShell prompt both works:

"$([char]27)]0;This is my title with BEL`a"

"$([char]27)]0;This is my title with ESC\$([char]27)\"

image

@toby9999, you used Command Prompt originally? Does my examples (and your rclone command with --progress-terminal-title) work as expected if you use PowerShell?

12

That did seem to work when I tried it on Linux

$ unset PROMPT_COMMAND
$ printf '\033]0;%s\007' "works OK 1"
$ printf '\033]0;%s\033\\' "works OK 2"
$ printf '\033]0;%s\001' "doesn't work 1"
$ printf '\033]0;%s\n' "doesn't work 2"

IIRC in rclone the VT100 emulation in CMD is being provided by GitHub - mattn/go-colorable so its probably a bug in that rather than anything else

13

After further digging (thanks to @albertony for your info relating to ANSI support), I've gotten to the root cause of the beeping sounds on my particular setup:

  • Windows 11 introduced a unified, tab-based terminal ("Windows Terminal") which manages both PowerShell and Windows Command Prompt (aka CMD):

    image
    image982×186 12.4 KB

  • Windows Terminal supports ANSI control sequences by default;

  • There is another command shell, "Console Window Host (conhost.exe)" which is used to run batch files etc:

    image
    image888×158 6.99 KB

  • conhost.exe does not support ANSI control sequences by default (see solution below);

  • When my .exe (which calls rclone) runs, conhost.exe is used automatically by Windows to execute it;

  • conhost.exe does not handle ANSI control sequences by default.

Aligning with the above notes, I can confirm:

  • running rclone.exe or my .exe (both with --progress-terminal-title) within Windows Terminal (I have tried both PowerShell and CMD): ANSI control sequences are handled correctly and therefore the BEL character doesn't cause a system beep;
  • running my .exe (with --progress-terminal-title) within conhost.exe does not handle the ANSI control sequences correctly, and does cause a system beep.

Solution:
Microsoft provide a registry setting to enable conhost.exe to handle ANSI control sequences correctly.

Modify or Create: HKEY_CURRENT_USER\Console\VirtualTerminalLevel and set the value to DWORD:1

image
image772×50 3.07 KB

I have tested this registry key change, and can confirm that my .exe, running under conhost.exe, now handles the ANSI control sequences correctly, and no longer causes system beep sounds.

Additional references:

14

Hmm.. Actually we've been through this "swamp" not too long ago, with confusion as to whether VirtualTerminalLevel is default or not in different versions of Windows. What we ended up doing was ensuring console mode ENABLE_VIRTUAL_TERMINAL_PROCESSING is enabled on the rclone process, by using GetConsoleMode /SetConsoleMode functions from Windows API. This means it should work by default, without having to set the registry entry.

The was done in pull request Enable console virtual terminal sequences processing (ANSI/VT100 colors) by albertony · Pull Request #6760 · rclone/rclone (github.com), which was part of release 1.62, mentioned in release notes:

  • lib/terminal: Enable windows console virtual terminal sequences processing (ANSI/VT100 colors) (albertony)

Which version of rclone are you using?

15

rclone version
rclone v1.55.1

  • os/type: windows
  • os/arch: amd64

Haven't updated it in quite some time.

16

Ah, good. Then I think we have the explanation.

1 Like
17

I have just tested with the latest version of rclone (and disabled the registry key), and I can confirm that ANSI is being handled correctly now.

As I've seen in my research, there are two options:

  • Registry key to enable ANSI handling, or;
  • App Developer updates their code to explicitly enable ANSI support.

Cheers

1 Like
18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.