arkrow
commented
2 weeks ago Hmm, this might be an edge case based on the configured STDOUT terminal. As can be seen below, the logic is very simple and has no wrapping, but the print method provided by the rich library might apply wrapping based on the output terminal.
I'll change the method that writes to the terminal to one that doesn't apply any transformations implicitly, just to be safe. Thanks for reporting @MattEqualsCoder .
Update: this should be fixed in the new v3.4.2 release. Let me know if the issue is fixed for that sample.
MattEqualsCoder
Before continuing with the bug report, does updating to the latest version fix this issue? No
Describe the bug It appears that the results of --alt-export-top can sometimes word wrap.
Debugging Information Copy the command-line arguments used and the error message / stack trace if applicable. For
ERRORmessages, try to re-run the command with debugging enabled using the-d/--debugflag (e.g.pymusiclooper -i --debug play test.mp3) and provide the traceback output if available.Optionally, include some brief information about the file(s) being loaded if relevant (e.g. file type/extension, file size, length, does the audio have an obvious loop point that algorithm failed to find?)
Apparently the song length is 7:41.
Expected behavior A clear and concise description of what you expected to happen.
Each line should have the same number of parts if split around spaces.
Environment Information (please complete the following information):
pymusiclooper --versionin the terminal if unsure): 3.2.2 and 3.4.1ffmpeg --versionin the terminal if unsure): [e.g. Yes/No] YesAdditional context Add any other context about the problem here.