mpg123-devel Mailing List for mpg123 (Page 3)
Brought to you by:
sobukus
You can subscribe to this list here.
2006 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
|
May
|
Jun
(6) |
Jul
(4) |
Aug
(17) |
Sep
(2) |
Oct
(13) |
Nov
|
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(7) |
Dec
(6) |
2008 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(18) |
May
(16) |
Jun
(10) |
Jul
(13) |
Aug
(14) |
Sep
(12) |
Oct
(32) |
Nov
(12) |
Dec
(33) |
2009 |
Jan
(2) |
Feb
(10) |
Mar
(16) |
Apr
(48) |
May
(92) |
Jun
(68) |
Jul
(37) |
Aug
(28) |
Sep
(61) |
Oct
(43) |
Nov
(33) |
Dec
(48) |
2010 |
Jan
(8) |
Feb
(27) |
Mar
(16) |
Apr
(11) |
May
(34) |
Jun
(27) |
Jul
(15) |
Aug
(16) |
Sep
(24) |
Oct
(14) |
Nov
(17) |
Dec
(9) |
2011 |
Jan
(21) |
Feb
(12) |
Mar
(8) |
Apr
(33) |
May
(2) |
Jun
(29) |
Jul
(16) |
Aug
(27) |
Sep
(27) |
Oct
(11) |
Nov
(16) |
Dec
(4) |
2012 |
Jan
(40) |
Feb
(12) |
Mar
(40) |
Apr
(34) |
May
(32) |
Jun
(6) |
Jul
(7) |
Aug
(13) |
Sep
(8) |
Oct
(12) |
Nov
(14) |
Dec
(5) |
2013 |
Jan
(3) |
Feb
(19) |
Mar
(2) |
Apr
(7) |
May
(30) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(23) |
Oct
(8) |
Nov
(3) |
Dec
(1) |
2014 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
(9) |
May
(8) |
Jun
(2) |
Jul
|
Aug
(15) |
Sep
(7) |
Oct
(1) |
Nov
(5) |
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(13) |
Aug
(16) |
Sep
(26) |
Oct
(2) |
Nov
(5) |
Dec
|
2016 |
Jan
(13) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
(16) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2017 |
Jan
(11) |
Feb
(10) |
Mar
(6) |
Apr
(4) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
|
Dec
(11) |
2018 |
Jan
(8) |
Feb
(16) |
Mar
(6) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(5) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(9) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
|
Feb
|
Mar
(3) |
Apr
(12) |
May
(4) |
Jun
(12) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(2) |
Dec
(1) |
2022 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(68) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(9) |
Oct
(7) |
Nov
|
Dec
|
2023 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(11) |
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2024 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: <ano...@gm...> - 2022-09-25 12:34:46
|
A pull request by bolshoytoster was opened at 2022-09-25 12:04:23. Please visit https://github.com/madebr/mpg123/pull/10 to give feedback and review the code. --- Currently, mpg123 isn't idle (~0.7% CPU on my machine) when stopped. This commit makes mpg123 just wait indefinetely for input when stopped, rather than constantly going through a full loop. The CPU usage is now 0% when stopped. <!-- Please write a little about the why and how of this pull request A mail should automatically get sent to the mpg123-devel mailing list. Before submitting, please check the following: - [x] Set target branch to `master` - [x] Write a little text above --> --- patch details: - url: https://github.com/madebr/mpg123/pull/10 - patch: https://github.com/madebr/mpg123/pull/10.patch url details: - user name: bolshoytoster - user url: https://github.com/bolshoytoster |
From: Thomas O. <tho...@or...> - 2022-09-13 08:39:06
|
Am Tue, 6 Sep 2022 11:36:17 +0000 schrieb Jonathan Yong <10...@gm...>: > Am I getting the problem correctly? If REMOTE_BUFFER_SIZE is too small, > the path longer than it will never work. It's two things: 1. too small buffer and 2. read() returning only a piece of the command. The latter case was not handled correctly. I added this change now: Index: src/control_generic.c =================================================================== --- src/control_generic.c (revisión: 5149) +++ src/control_generic.c (revisión: 5150) @@ -907,7 +907,7 @@ // Last character not nulled if we did not use all command text. if(buf[len-1] != 0) { - if(next_comstr == buf) + if(next_comstr == buf && len == REMOTE_BUFFER_SIZE) { generic_sendmsg("E Too long command, cannot parse."); // Just skipping it, provoking furhter parsing erros, but maybe not fatal. This should be all that's required … I tested by limiting the read() to 10 bytes, and also checking the proper error case with a small buffer size. Neil, can you confirm with the current trunk or snapshot? Alrighty then, Thomas PS: Oh, just saw the typo of „furhter“ in the comment. Well … I guess I'm pedantic enough to fix that, too. |
From: Jonathan Y. <10...@gm...> - 2022-09-06 11:36:31
|
On 9/5/22 17:38, Thomas Orgis wrote: > > > Am 5. September 2022 16:28:46 MESZ schrieb Jonathan Yong <10...@gm...>: >> I'm kind of lost in the conversation, and I'm not really familiar with the problem. How should it be tested? > > one term: > mpg123 -R --fifo /dev/shm/mpg123 > > another term: > echo silence > /dev/shm/mpg123 > echo load /long/file/path > /dev/shm/mpg123 > > > Observe error messages in first term. Simulation of short read() by changing the value of requested bytes to something smaller than buffer. > Am I getting the problem correctly? If REMOTE_BUFFER_SIZE is too small, the path longer than it will never work. I changed REMOTE_BUFFER_SIZE to 256 to test, something like: echo silence > /dev/shm/mpg123 && sleep 1 && echo load /tmp/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.mp3 > /dev/shm/mpg123 Seems to work fine for bigger buffers. |
From: Thomas O. <tho...@or...> - 2022-09-05 17:38:24
|
Am 5. September 2022 16:28:46 MESZ schrieb Jonathan Yong <10...@gm...>: >I'm kind of lost in the conversation, and I'm not really familiar with the problem. How should it be tested? one term: mpg123 -R --fifo /dev/shm/mpg123 another term: echo silence > /dev/shm/mpg123 echo load /long/file/path > /dev/shm/mpg123 Observe error messages in first term. Simulation of short read() by changing the value of requested bytes to something smaller than buffer. Alrighty then, Thomas, out of nowhere |
From: Jonathan Y. <10...@gm...> - 2022-09-05 14:28:59
|
On 9/4/22 13:18, Thomas Orgis wrote: > > > Am 4. September 2022 12:31:01 MESZ schrieb Neil Walker <ne...@wy...>: >> The snapshot built, but didn't actually solve the problem: because >> read() is only reading a partial command, I got the new >> "E Too long command, cannot parse" response. This makes sense > > > Ah, sorry. I tested using an artificially small buffer, not an genuine short read. So I messed up the logic again. > > I'm out for the week without commit access ... JonY: are you there an able to check in the proper logic? Otherwise, Ißll do it in a week, also when merging the multinet branch. > I'm kind of lost in the conversation, and I'm not really familiar with the problem. How should it be tested? |
From: Thomas O. <tho...@or...> - 2022-09-04 13:21:34
|
Am 4. September 2022 12:31:01 MESZ schrieb Neil Walker <ne...@wy...>: >The snapshot built, but didn't actually solve the problem: because >read() is only reading a partial command, I got the new >"E Too long command, cannot parse" response. This makes sense Ah, sorry. I tested using an artificially small buffer, not an genuine short read. So I messed up the logic again. I'm out for the week without commit access ... JonY: are you there an able to check in the proper logic? Otherwise, Ißll do it in a week, also when merging the multinet branch. Alrighty then, Thomas |
From: Neil W. <ne...@wy...> - 2022-09-04 10:31:11
|
> On 4 Sep 2022, at 07:13, Thomas Orgis <tho...@or...> wrote: > > Am Sat, 3 Sep 2022 17:07:39 +0100 > schrieb Neil Walker <ne...@wy...>: > >> After banging my head against this for a while, I've bitten the >> bullet and reworked control_generic.c to accumulate commands across >> calls to read(). > > I'm really sorry about this. The issue lay bare there all the time with > a comment that it should be fixed eventually. Well I took your > initiative as motivation to do the minimal change needed to finish > unfinished commands. > > Does revision 5149 or current https://mpg123.org/snapshot do the trick > for you? > > I spared the reorganization with moving the command parsing out into a > separate function, while that might be a good path to follow towards > cleaner code, it's unrelated to the issue. Hi Thomas, Thanks for following up. Completely understand the desire to avoid the unnecessary changes. The snapshot built, but didn't actually solve the problem: because read() is only reading a partial command, I got the new "E Too long command, cannot parse" response. This makes sense because next_comstr will still be pointing at buf when a partial command is received. I've been able to further tweak your latest version with two more updates: 1. Comment out the generic_sendmsg("E Too long command ...") 2. Move the assignment to last_len from line 916 to above the if(next_comstr == buf) test. That allows the command to accumulate over separate calls to read() and the file then starts playing correctly, but removes any error detection/handling for the scenario of a genuinely long command. So, I think something like the following looks plausible: (But, I'm writing this live in email, so it's untested) last_len = len-(short)(next_comstr-buf); if(last_len == REMOTE_BUFFER_SIZE) { generic_sendmsg("E Too long command, cannot parse."); last_len = 0; // Just skipping it, provoking furhter parsing erros, but maybe not fatal. } else { mdebug("keeping %d bytes of old command", last_len); memmove(buf, next_comstr, last_len); } Thanks again Neil |
From: Thomas O. <tho...@or...> - 2022-09-04 06:14:42
|
Am Sat, 3 Sep 2022 17:07:39 +0100 schrieb Neil Walker <ne...@wy...>: > After banging my head against this for a while, I've bitten the > bullet and reworked control_generic.c to accumulate commands across > calls to read(). I'm really sorry about this. The issue lay bare there all the time with a comment that it should be fixed eventually. Well I took your initiative as motivation to do the minimal change needed to finish unfinished commands. Does revision 5149 or current https://mpg123.org/snapshot do the trick for you? I spared the reorganization with moving the command parsing out into a separate function, while that might be a good path to follow towards cleaner code, it's unrelated to the issue. Alrighty then, Thomas |
From: Neil W. <ne...@wy...> - 2022-09-03 16:32:45
|
Hi, I've been using mpg123 in remote mode running on Alpine Linux (v3.15) on a Raspberry Pi. I've been experiencing some files consistently failing to play in remote control mode, yet play fine if the program was launched with that file specified as a command-line parameter. I've eventually tracked this down to a surprising interaction with `read()`: If I ssh to my Pi, and then launch remote control mode (mpg123 -R) and type LOAD filename.mp3 and press return, all works as expected unless strlen("LOAD filename.mp3") == 64. In that scenario, mpg123 was reporting an unfinished command error. Shorter filenames work fine; longer filenames also work fine! Changing LOAD to L would allow that file to play, but then result in other files failing - those with paths 3 characters longer. I assume there's a 64-byte buffer somewhere on that platform. After banging my head against this for a while, I've bitten the bullet and reworked control_generic.c to accumulate commands across calls to read(). I ended up making bigger changes than were essential: I've split the actual command processing out into a separate function when I was trying to grok the existing structure. In case it's useful, I've attached a patch file. I've only been able to check that it compiles and runs on my Mac and the Alpine Linux Raspberry Pi - so fingers crossed for other platforms. Neil |
From: Thomas O. <tho...@or...> - 2022-08-01 22:08:13
|
Hi, a little maintenance release of mpg123 is out: 1.30.2 ------ - Only use EWOULDBLOCK if the macro is defined (FreeBSD misses it for _POSIX_SOURCE, bug 339). No functional changes. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2022-07-12 22:26:08
|
Dear people of mpg123, here comes another little release with some fixups from the last major one: 1.30.1 ------ - mpg123: -- Show stderr of network helpers in -vvv mode. -- Use curl --http0.9, if available, to support shoutcast v1 streams without wget (wget not needing such switch, yet). -- Support file:// URLs for local access as was intended with the last release. -- Give more helpful error message if neither wget nor curl are usable, also allow error messages from curl to appear when not --quiet. -- Update the man page. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2022-06-26 14:47:52
|
Dear all, finally, the next version of mpg123 is out, with quite a number of changes on the frontend side. Notable is the enhanced experience for users of those legacy systems like OS/2 … and Windows;-) This release finally makes the mpg123 console application support HTTPS streaming, by ditching the old internal network implementation in favour of just calling wget or curl (both tried) to do the messy networking things on forking platforms, and even two possible native APIs on Windows (winhttp by default, build-time choice). The second notable addition is terminal control for both Windows and OS/2. Yes. 1.30.0 ------ - build: -- Use dummy as default module when no other outputs are enabled. This also fixes a non-module build with just the dummy (bug 333). -- Use CMAKE_CURRENT_SOURCE_DIR in CMake build to help nested use (bug 335). -- some updates for OS/2 support (fixing up stdin playing, for example) - mpg123: -- new network backend using external tools/libraries to also support HTTPS -- old network backend changed to use h_addr_list[0] instead of h_addr -- terminal control keys now case-sensitive (fixing smal/big pitch controls) -- additional terminal control keys for simple equalizer control (A/a for bass, J/j for mids, N/n for treble, e for reset, E for printout) -- terminal volume control now in decibel steps and bounded to +/- 60 dB -- terminal control now also with audio from stdin (bug 338) via /dev/tty or ctermid() -- terminal control also available for OS/2 and Windows platforms -- re-print tag info on decrease of terminal width for a bit less mess -- always print an empty line after tag info for cleaner appearance -- print lyrics also to stderr -- remote control API v10 with "@P 3" as additonal message on track end -- also added PROGRESS command as opposite of SILENCE -- fix some verbosity, tweak help for --icy-interval -- added --auth-file -- also obscure argument to --auth for others -- Cygwin/MinGW: Provide _win32_utf8_wide and _win32_wide_utf8 unconditionally. It is needed by the WASAPI plugins, the underlying conversion functions should be present since Windows 2000. Fixes WASAPI support on Cygwin. Also needed for new network code. - libout123: -- pulse: initialize more error codes to avoid bogus error messages -- os2: considerable fixup for proper writes of full buffers avoiding nasty effects from the ... special audio system, more cleanup still nice-to-have, but still lacking See http://mpg123.org/download.shtml to get your fix. Alrighty then, Thomas |
From: Dave Y. <dav...@gm...> - 2022-05-23 17:14:38
|
On 05/22/22 11:18 PM, Thomas Orgis wrote: > Good ... but crashes?! I don't tolerate those. Please give us that call stack/trace, best reproduced with the current code. OK, sending privately in case anything important is hiding there. Today I'm not getting as informative reports so also sending an older one. > > The buffer of 4608 is the usual size of one MP3 frame (1152 samples, stereo, 16 bit). So the splitting of writes is broken on some side. Buffer juggling. > > Playing some static noise could be a precursor to the crash, from the same source. Some MP3s only? What do they have in common? Layer I, II, III? MPEG 2, 2, 2.5? Mono/stereo? This also has different block sizes being written to the output. Lower bit rates seems to correspond to more static. > > Please, let's figure out that and fix it. I don't want to ship software with lurking memory corruption. Dave |
From: Thomas O. <tho...@or...> - 2022-05-23 06:19:06
|
Good ... but crashes?! I don't tolerate those. Please give us that call stack/trace, best reproduced with the current code. The buffer of 4608 is the usual size of one MP3 frame (1152 samples, stereo, 16 bit). So the splitting of writes is broken on some side. Buffer juggling. Playing some static noise could be a precursor to the crash, from the same source. Some MP3s only? What do they have in common? Layer I, II, III? MPEG 2, 2, 2.5? Mono/stereo? This also has different block sizes being written to the output. Please, let's figure out that and fix it. I don't want to ship software with lurking memory corruption. Altighty then, Thomas |
From: Dave Y. <dav...@gm...> - 2022-05-23 03:52:45
|
On 05/22/22 02:26 AM, Thomas Orgis wrote: > Am Thu, 19 May 2022 16:47:59 -0700 > schrieb Dave Yeo <dav...@gm...>: > >> It's looking pretty good, see screenshot, even the progress meter is >> working. Not sure if some fine tuning could still be done. > > Nice! It appeared to me that one thing could be tuned: I now have > mpg123 consistently print a blank line below the tag info (svn up). It > should now look consistent for the initial printout and the repeated > ones after shrinking the terminal. What ever you did helped a lot. Last night playing various MP3's I downloaded years back, so various bit rates and encoders, a few MP3's were still scrolling. After updating today, that is fixed and playing around with the console size, even at 30 columns, no scrolling. Looks much better. > > So … we got a rather fully functioning MPEG player and HTTP/HTTPS > streaming application for the OS/2 console window now? The last problem I had was the os2 module would have static on some MP3's. Changing the buffer size generally made it worse and when I tried 4096, mpg123 crashed (call stack available if interested). Anyways, rebuilt with --enable-debug=yes and saw lots of lines like, [../mpg123.svn/src/libout123/libout123.c:out123_play():722] debug: written: 4608 errno: 0 (Error 0), keep_on=16 So adjusting the audiobufsize at line 27 in os2.c to 4608 seems to be the sweet spot, just played a dozen MP3's and they all sounded correct. I don't understand why as the documentation says any buffer size up to 64kb and uses 4kb in the example. Never understood where the 4884 came from either. Anyways if you commit that change, I'd say it is working very well and worth distributing once you do a release. Thanks, Dave |
From: Thomas O. <tho...@or...> - 2022-05-22 09:27:12
|
Am Thu, 19 May 2022 16:47:59 -0700 schrieb Dave Yeo <dav...@gm...>: > It's looking pretty good, see screenshot, even the progress meter is > working. Not sure if some fine tuning could still be done. Nice! It appeared to me that one thing could be tuned: I now have mpg123 consistently print a blank line below the tag info (svn up). It should now look consistent for the initial printout and the repeated ones after shrinking the terminal. So … we got a rather fully functioning MPEG player and HTTP/HTTPS streaming application for the OS/2 console window now? Alrighty then, Thomas |
From: Dave Y. <dav...@gm...> - 2022-05-19 23:48:08
|
On 05/19/22 08:14 AM, Thomas Orgis wrote: > Well, I added a change that just subtracts 1 from the width to use. Dies rev 5094 work properly now? > It's looking pretty good, see screenshot, even the progress meter is working. Not sure if some fine tuning could still be done. Thanks, Dave |
From: Thomas O. <tho...@or...> - 2022-05-19 15:14:37
|
Well, I added a change that just subtracts 1 from the width to use. Dies rev 5094 work properly now? Alrighty then, Thomas |
From: Dave Y. <dav...@gm...> - 2022-05-19 15:01:11
|
On 05/19/22 12:02 AM, Thomas Orgis wrote: > Am Wed, 18 May 2022 18:52:27 -0700 > schrieb Dave Yeo <dav...@gm...>: > >> On 05/18/22 08:12 AM, Thomas Orgis wrote: > >> Ok, operator error previously. It consistently outputs "Note: stderr >> terminal width: 0" no matter the terminal width. > > So … what do we do with that?! Is our code broken? Isn't OS/2 able to > provide a terminal width?! OK, I'd left a stray #ifndef __OS2__ in term_posix.c, deleting it, and doing a svn up fixes that, examples, Note: stderr terminal width: 80 Note: stderr terminal width: 87. > > #ifdef __OS2__ > int s[2]; > _scrsize (s); > if (s[0] >= 0) > return s[0]; > #else > > What is wrong here? Forgetting to clean up after previous testing. > >> What it does is cause an extra blank line below the xxx's before the >> prompt returns. Change the 80 to 79 and that line goes away. >> Seems that there is a CR or such printed at the end of the line so >> effectively it is 79 chars without scrolling. > > A CR shall not trigger advancing a line. That's the point of it. If > this is the case, it's a bug in your terminal. So we need to solve this > second problem. I can do an ifdef(__OS2__) limit = limit - 1; … but > first, we need to be able to get a proper width value! > OK, things have changed with reverting term_posix.c, it always scrolls with v, on the other hand the progress meter is now working and the display of Title: Artist: etc is now correctly formatted. The terminal, or officially a VIO window is more like a DOS display then a regular window, at that running a DOS program in a window has much the same behaviour. I think the cursor just advances to the next character which if at the end of the screen means going to the next line. Sorry about missing the patch in term_posix.c, forgot about SVN ignoring changes. Dave |
From: Thomas O. <tho...@or...> - 2022-05-19 07:03:02
|
Am Wed, 18 May 2022 18:52:27 -0700 schrieb Dave Yeo <dav...@gm...>: > On 05/18/22 08:12 AM, Thomas Orgis wrote: > Ok, operator error previously. It consistently outputs "Note: stderr > terminal width: 0" no matter the terminal width. So … what do we do with that?! Is our code broken? Isn't OS/2 able to provide a terminal width?! #ifdef __OS2__ int s[2]; _scrsize (s); if (s[0] >= 0) return s[0]; #else What is wrong here? > What it does is cause an extra blank line below the xxx's before the > prompt returns. Change the 80 to 79 and that line goes away. > Seems that there is a CR or such printed at the end of the line so > effectively it is 79 chars without scrolling. A CR shall not trigger advancing a line. That's the point of it. If this is the case, it's a bug in your terminal. So we need to solve this second problem. I can do an ifdef(__OS2__) limit = limit - 1; … but first, we need to be able to get a proper width value! You could put the above snippet with printout into a little stand-alone program for easier testing. Do you have different terminal emulators to try? Alrighty then, Thomas |
From: Dave Y. <dav...@gm...> - 2022-05-19 01:52:36
|
On 05/18/22 08:12 AM, Thomas Orgis wrote: > OK, I forgot the playback status. The line without knowledge of terminal width can exceed 80 chars. We should prevent that, assume 80 as default limit... hm. Or even only print stat lines at all if terminal was detected. > > Please check again if you have a current build. There has to be a note about terminal width with verbosity 3 and above (mpg123 -vvv). If you pipe /tee /grep stderr, it should print -1. Ok, operator error previously. It consistently outputs "Note: stderr terminal width: 0" no matter the terminal width. > > I also just checked with term width 80 that this does not give an extra empty line: > > perl -e '$s = "x" x 80; print $s."\n"' > > Does that cause an extra line break with width 80 for you? What it does is cause an extra blank line below the xxx's before the prompt returns. Change the 80 to 79 and that line goes away. Seems that there is a CR or such printed at the end of the line so effectively it is 79 chars without scrolling. Dave |
From: Thomas O. <tho...@or...> - 2022-05-18 15:12:35
|
OK, I forgot the playback status. The line without knowledge of terminal width can exceed 80 chars. We should prevent that, assume 80 as default limit... hm. Or even only print stat lines at all if terminal was detected. Please check again if you have a current build. There has to be a note about terminal width with verbosity 3 and above (mpg123 -vvv). If you pipe /tee /grep stderr, it should print -1. I also just checked with term width 80 that this does not give an extra empty line: perl -e '$s = "x" x 80; print $s."\n"' Does that cause an extra line break with width 80 for you? Alrighty then, Thomas |
From: Dave Y. <dav...@gm...> - 2022-05-18 14:21:36
|
On 05/17/22 10:33 PM, Thomas Orgis wrote: > Am Tue, 17 May 2022 17:30:35 -0700 > schrieb Dave Yeo <dav...@gm...>: > >>> So with widened terminal, the line fits, but it does still scroll? >> >> Had to double check as I previously pressed q too quick. No it doesn't >> scroll and works much as expected, though really I should test on Linux. >> The cut off is 83 chars, so with a 82 char wide terminal it scrolls, at >> 83 char it doesn't unless have -vvvvvvv > > That is wrong. Two points: > > 1. Our OS2 term_width() does not work. > 2. The stat line should be 80 characters long and fit int 82! > > > To the first one, please update to current trunk (r5088), run with > -vvv and check for > > Note: stderr terminal width: 138 > > (right after playlist printout) and I don't see this, after playlist I see, ... f:/sounds/mp3/Three_Dead_Trolls Note: Disabling all formats. Note: default format 44100 Hz, 2 channels, s16 Note: output support for 8000 Hz, 1 channels: 0xd1 Note: Want to enable format 8000/1 for encodings 0xd1. Note: output support for 8000 Hz, 2 channels: 0xd1 Note: Want to enable format 8000/2 for encodings 0xd1. ... > > Note: readjusting for smaller terminal (90 to 89) > > each time when you reduce the terminal width in this verbose mode. Get the same as above with different terminal widths. It's possible that it scrolled off the screen, though I tried piping stderr and stdout through tee and logging it and still don't see it. > > > To the second … is this a full line for you? > > 00104+10114 00:02.71+04:24.20 --- 100=100 112 kb/s 366 B acc 0 clip p+0.000 The output is prefixed with "> " without the quotes. Confusing in an email as most mail programs use the same prefix for quoting in a reply. > > Because that is exactly 80 characters. It should not scroll on 82 char > terminal. The terminal may also scroll after a line exceeds 79 chars. Yes testing echoing exactly 80 chars gives an extra line before returning to the prompt compared to 79 chars. Dave |
From: Thomas O. <tho...@or...> - 2022-05-18 05:33:15
|
Am Tue, 17 May 2022 17:30:35 -0700 schrieb Dave Yeo <dav...@gm...>: > > So with widened terminal, the line fits, but it does still scroll? > > Had to double check as I previously pressed q too quick. No it doesn't > scroll and works much as expected, though really I should test on Linux. > The cut off is 83 chars, so with a 82 char wide terminal it scrolls, at > 83 char it doesn't unless have -vvvvvvv That is wrong. Two points: 1. Our OS2 term_width() does not work. 2. The stat line should be 80 characters long and fit int 82! To the first one, please update to current trunk (r5088), run with -vvv and check for Note: stderr terminal width: 138 (right after playlist printout) and Note: readjusting for smaller terminal (90 to 89) each time when you reduce the terminal width in this verbose mode. To the second … is this a full line for you? 00104+10114 00:02.71+04:24.20 --- 100=100 112 kb/s 366 B acc 0 clip p+0.000 Because that is exactly 80 characters. It should not scroll on 82 char terminal. Alrighty then, Thomas |
From: Dave Y. <dav...@gm...> - 2022-05-18 00:30:50
|
Hi, back home. On 05/17/22 09:05 AM, Thomas Orgis wrote: > Am Tue, 17 May 2022 07:52:41 -0700 > schrieb Dave Yeo <dav...@gm...>: > >> Those were all one line. Widening the terminal to 90 characters gives >> (one line); >> > 00104+10114 00:02.71+04:24.20 --- 100=100 112 kb/s 366 B acc 0 >> clip p+0.000 >> >> Notice that previously the last 00 was cutoff. > > So with widened terminal, the line fits, but it does still scroll? Had to double check as I previously pressed q too quick. No it doesn't scroll and works much as expected, though really I should test on Linux. The cut off is 83 chars, so with a 82 char wide terminal it scrolls, at 83 char it doesn't unless have -vvvvvvv > >>> One possibility is that \r doesn't do carriage return (move cursor back >>> to beginning) but a line end instead. Do we need to do some custom >>> cursor positioning? >> >> I'd assume it gets translated into CR/LF, perhaps needs to be in binary >> mode? > > Hm. Maybe. But this maybe could mess up other parts. You can just try a > > compat_binmode(STDERR_FILENO, TRUE); > > early in main() in mgp123.c. We'd have to insert some \r then, though, > for metadata printout. They won't hurt on other systems. > > But should textmode in OS/2 really translate \r to \r\n? That does not > match my recall that says that it's only about what \n means internally > and externally. > Binary mode makes no difference and you're right about \r. Dave |