-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stops After 00:00:01 (and makes CMD's cursor invisible) #36
Comments
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 |
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, To better understand your environment, it'll help to know the following:
|
|
There might be a segmentation fault or a similar error that causes it to crash silently. To investigate, I've enabled Python's It should be possible to run directly using the pipx run --spec git+https://github.com/arkrow/PyMusicLooper.git@debug pymusiclooper -dv play --path test.flac |
The garbled output is the same on my end and might be an issue with how
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 |
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. |
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 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 |
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.
The text was updated successfully, but these errors were encountered: