Open heare2code opened 4 months ago
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
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)
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:
pipx
environment or using a normal pip
install?pipx
, does doing pipx upgrade pymusiclooper
help resolve the issue?python -VV
would be useful to know.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
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.
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
It only does the same, but weirdly, the length was like normal: 3 the first time, 1 the second time.
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.
C:\Users\
\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.
Using WSL does work, it reads it, but it cant play the audio. ERROR module 'sounddevice' has no attribute 'OutputStream'
Quick update on this issue:
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
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.
I seem to be having the same error, any updates?
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):
pymusiclooper --version
in the terminal if unsure): yes: 3.4.1ffmpeg --version
in the terminal if unsure): yes: ffmpeg version 4.4-essentials_build-www.gyan.devAdditional 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.