Stops After 00:00:01 (and makes CMD's cursor invisible)

[heare2code]

Before continuing with the bug report, does updating to the latest version fix this issue?
I've checked for updates for both pymusiclooper and ffmpeg.

Describe the bug
The process stops after a second without outputting any file, text, or errors. It also causes the CMD cursor to become invisible and requires a restart of CMD to fix.

Debugging Information
Nothing gets outputted, it just stops as if it closed. No errors or files.

The file I used is a 2 minute and 53 second 44.1 kHz 16bit stereo FLAC encoded file. I believe the algorithm should be able to find a loop, as the start and end are the exact same.

Expected behavior
Give me a correct output or a error.

Environment Information (please complete the following information):

• OS: Windows 11
• PyMusicLooper version being used (execute pymusiclooper --version in the terminal if unsure): yes: 3.4.1
• Is FFmpeg installed and working? (execute ffmpeg --version in the terminal if unsure): yes: ffmpeg version 4.4-essentials_build-www.gyan.dev

Additional context
After a restart of Windows and instantly doing a command, it goes up to 00:00:03, but then stops and all future commands stop at 00:00:01 again.

[arkrow]

Can you rerun the same command with the debug and verbose flags enabled and post the output here? e.g.

pymusiclooper -dv play --path test.flac

[heare2code]

Oh, I forgot to mention that any other flags doesn't show or output anything either. (I thought I wrote it in but I think I deleted it)

[arkrow]

Strange. I tried reproducing this in a new environment as well as in a fresh Windows install, and I can't reproduce this issue. For processing FLAC files, ffmpeg is not required. In fact, in a completely fresh Windows installation, all you need is Python and Microsoft Visual C++ Redistributable (typically available since it's a common dependency).

To better understand your environment, it'll help to know the following:

• Did you install in a pipx environment or using a normal pip install?
• If using pipx, does doing pipx upgrade pymusiclooper help resolve the issue?
• Is the issue present using "Powershell"?
• What version of python are you using? Providing the output of python -VV would be useful to know.
• Does this issue occur with all audio files you tried (MP3, OGG, WAV, etc.), all FLAC files, or just this file?
• Does the issue still occur with the WAV-converted version of the file?

[heare2code]

• I installed in pip because I didn't know pipx was a thing and I assumed to use pip install to install it.
• I uninstalled the version I got from pip and installed it though pipx again but it still happens.
• Yes, it still exits without output both with the pip and pipx installation.
• Python 3.10.11 (tags/v3.10.11:7d4cc5a, Apr 5 2023, 00:38:17) [MSC v.1929 64 bit (AMD64)]
• Using MP3 or WAV doesn't work either.

[arkrow]

There might be a segmentation fault or a similar error that causes it to crash silently. To investigate, I've enabled Python's faulthandler to catch and print any potential faults in a temporary debug branch. Can you test it out and report what you get?

It should be possible to run directly using the pipx run command, without uninstalling the previous version, since it uses a temporary environment to run it from.

pipx run --spec git+https://github.com/arkrow/PyMusicLooper.git@debug pymusiclooper -dv play --path test.flac

[heare2code]

All it did was... This:

It seems to be going further though, getting to 10 seconds instead of 3 at first but only 4 seconds after running again.

[arkrow]

The garbled output is the same on my end and might be an issue with how pipx run writes to the terminal on Windows (works fine on Linux/WSL).

It seems to be going further though, getting to 10 seconds instead of 3 at first but only 4 seconds after running again.

It's normally longer on the initial run since some functions get compiled by Numba JIT to speed up the loop analysis time, which is then cached and reused afterwards.

In any case, since it seems that it doesn't even reach audio loading step, I'm suspecting it might be an issue with Numba's JIT compilation/execution on your system. To verify, I've made another branch disabling the JIT compilation for testing. It'll be potentially much slower, but should help us better pinpoint the issue.

pipx run --spec git+https://github.com/arkrow/PyMusicLooper.git@njit_disabled pymusiclooper -dv play --path test.flac

[heare2code]

It only does the same, but weirdly, the length was like normal: 3 the first time, 1 the second time.