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.

[heare2code]

UPDATE I decided to do a complete python wipe and reinstall with 3.12.4 and now it shows an error with the debug flags: C:\Users\<user>\pipx\venvs\pymusiclooper\Lib\site-packages\librosa\core\intervals.py:15: DeprecationWarning: path is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice. I tried both the alternative branches you suggested and they show the same error.

[arkrow]

C:\Users<user>\pipx\venvs\pymusiclooper\Lib\site-packages\librosa\core\intervals.py:15: DeprecationWarning: path is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice.

This is a deprecation warning, not an error, so it wouldn't be the cause for failure here. Is this the only error message? Since I can't reproduce the issue and there is no fault/traceback output, it makes the root cause difficult to identify and resolve.

I'm working on packaging this CLI tool as a standalone executable file for Windows, though it is taking some time. In the meantime; this is a bit of a last resort option, but can you try installing this tool in a WSL environment instead? That way, it'll be installed in a Linux environment, unaffected by whatever is causing the issue on Windows. As long as you launch WSL from a terminal in the folder the tracks are in and use relative paths, it should be relatively painless to use.

[heare2code]

Using WSL does work, it reads it, but it cant play the audio. ERROR module 'sounddevice' has no attribute 'OutputStream'

[arkrow]

Quick update on this issue:

• The root cause is still unknown, but is suspected to be environment-related
• As a potential workaround, I added the ability to build an executable for this package using PyInstaller. The build instructions can be found in the updated README in the pyinstaller_autoversioning experimental branch. The GitHub Action CI workflow for this now just has one issue preventing it from working correctly, though once done, I'll link the built artifact in the issue for testing.

[arkrow]

The latest release as of this comment (v3.4.1) now has a compiled exe binary for Windows, no python or other dependencies needed. Only ffmpeg is optional for certain files. Try it out and let me know if it resolves the issue for you @heare2code.

To use, download the exe, open a command line or powershell in the exe's download directory, and invoke it like so:

.\pymusiclooper.exe

Full example as above:

.\pymusiclooper.exe -dv play --path test.flac

[heare2code]

Sorry that it took so long for me to get back to you, but even this Windows binary doesn't work. Still shows the DeprecationWarning as if it was running from pip(x). I also uninstalled it from pipx just in case it was using that install instead and it still doesn't work. I also ran it in Powershell and still nothing.

[seoarche]

I seem to be having the same error, any updates?

[heare2code]

I decided to go back to using this and it appears to be fixed. I unfortunately do not know what fixed this but I had uninstalled python a few times between then and now, so I could only assume that perhaps that could be a solution.