mpg123-devel — Mailing list for mpg123 developers

Re: [mpg123-devel] mpg123 1.31.0 released

[Thomas O. <tho...@or...>]

Thanks,

to clarify:

Am Sun, 8 Jan 2023 20:06:11 -0800
schrieb Dave Yeo <dav...@gm...>: 

> OS/2 needs this patch to find getaddrinfo() and friends. No ipv6 support.  

You mean no IPv6 support before or still after this change? Do you have
a complete build failure without libcx/net.h?


Alrighty then,

Thomas

Re: [mpg123-devel] mpg123 1.31.0 released

[Dave Y. <dav...@gm...>]

Hi Thomas, this got lost for a bit :)
On 10/28/22 04:07 AM, Thomas Orgis wrote:
> -- Revert to internal network code for plain HTTP to ensure continued
>    support for original shoutcast servers that do not talk proper HTTP.
>    External backends are built at the same time and can be enforced using
>    --network <backend>.

OS/2 needs this patch to find getaddrinfo() and friends. No ipv6 support.
Thanks,
Dave

[mpg123-devel] mpg123 1.31.1 released (build fix for Illumos)

[Thomas O. <tho...@or...>]

Dear people who take an interest in mpg123,

there is a quick build fix release out now:

1.31.1
------
- Fix largefile aliases for the case of a largefile-insensitive build
  that still does define _FILE_OFFSET_BITS from the outside
  (sys/feature_tests.h on Illumos).

So unless you got a build failure on your setup with 1.30.0, you can
sit that one out.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.31.0 released

[Thomas O. <tho...@or...>]

Dear mpg123-inflicted,

I hereby announce version 1.31.0, which was supposed to be a little
bug-fix release before pondering deeper (actually rather shallow)
API/ABI business, but still brings quite a list of changes:

1.31.0
------

- mpg123:
-- Finally make terminal control work on Windows, for real. Building it
   was broken in 1.30.x.
-- The --control / -C switch will make mpg123 abort now if terminal
   control cannot be enabled.
-- Revert to internal network code for plain HTTP to ensure continued
   support for original shoutcast servers that do not talk proper HTTP.
   External backends are built at the same time and can be enforced using
   --network <backend>.
-- Try-witout-port for internal network code is gone. We do not need to
   keep each ancient hack for specific hosts.
-- Handle redirections independently of the backend behind net123. 
-- Set proxy environment variables when --proxy is specified, for net123
   backends to use.
-- Continue reading for long commands in generic control, avoiding
   unnecessary unfinished command errors.
-- Change error message from 'unknown command' to
   'unknown command with arguments' to avoid confusion why 'help foo'
   is unknown, as opposed to 'help'.
-- Reduce CPU load while just waiting for terminal input
   (thanks to bolshoytoster on github).
-- Condense terminal control help output and excessive vertical whitespace
   in printouts (inspired by Volkmar Klatt).
-- Fix interaction of pause (looping) with buffer, adding --pauseloop
   to set the loop interval.
-- Numeric option arguments are strictly checked now for conversion errors.
   This also catches -devbuffer, which was interpretd as -d 0 before. This
   also applies to out123.
- libout123:
-- Add same interruption handling to out123_write() as to
   unintr_write(), adding EAGAIN to fix bug 342 (thanks to Steffen Nurpmeso)
   for certain ALSA setups.
-- Add --devbuffer support to win32 output and change default to 0.25 seconds.
-- Fix race condition to deadlock on buffer_sync_param() where parameters after
   the command byte got read as more commands. This got triggered easily by
   using the pause key in terminal mode with buffer (which was discouraged
   before because of buffer flushing). Generally, changing parameters with
   active buffer process was dangerous since libout123 entered the scene.
- some build fixes for compiler pickyness
- Disable largefile renames also for non-sensitive POSIX systems
  (in some distant future, the alias symbols could go away, then …
  bug 330).
- Fix Android NDK x86 builds with GLOBAL_VAR_PTR use in assembly (bug 345).

The updated Windows binaries come from a refreshed toolchain and at
least the x86 build has been verified to work on Windows XP with an
Atom CPU in a little netbook from times long gone.

Get it from the usual places indicated on

	http://mpg123.org/download.shtml

and enjoy!


Alrighty then,

Thomas

Re: [mpg123-devel] [PATCH] Use the pkg-config file when detecting sndio

[Brad S. <br...@co...>]

On 10/15/2022 9:07 AM, Thomas Orgis wrote:
> Am Sat, 15 Oct 2022 00:13:42 -0400
> schrieb Brad Smith <br...@co...>:
>
>> We added the pkg-config file 18 months ago. OpenBSD has had 3 releases
>> since then, 7.0, 7.1 and
>> now 7.2. With us being back to -current.
> Finally merged, to appear in 1.31.0 soon.
>
>
> Alrighty then,
>
> Thomas

Thank you.

Re: [mpg123-devel] [PATCH] Use the pkg-config file when detecting sndio

[Thomas O. <tho...@or...>]

Am Sat, 15 Oct 2022 00:13:42 -0400
schrieb Brad Smith <br...@co...>: 

> We added the pkg-config file 18 months ago. OpenBSD has had 3 releases 
> since then, 7.0, 7.1 and
> now 7.2. With us being back to -current.

Finally merged, to appear in 1.31.0 soon.


Alrighty then,

Thomas

Re: [mpg123-devel] [PATCH] Use the pkg-config file when detecting sndio

[Brad S. <br...@co...>]

On 10/2/2022 3:20 AM, Thomas Orgis wrote:
> Am Sat, 1 Oct 2022 20:52:47 -0400
> schrieb Brad Smith<br...@co...>:
>
>> Use the pkg-config file when detecting sndio
> Yes, this looks nicer. I wonder: Did the pkg-config file for sndio come
> late and is only available in recent installs?


We added the pkg-config file 18 months ago. OpenBSD has had 3 releases 
since then, 7.0, 7.1 and
now 7.2. With us being back to -current.

Re: [mpg123-devel] [PATCH] Use the pkg-config file when detecting sndio

[Thomas O. <tho...@or...>]

Am Sat, 1 Oct 2022 20:52:47 -0400
schrieb Brad Smith <br...@co...>: 

> Use the pkg-config file when detecting sndio

Yes, this looks nicer. I wonder: Did the pkg-config file for sndio come
late and is only available in recent installs?


Alrighty then,

Thomas

[mpg123-devel] [PATCH] Use the pkg-config file when detecting sndio

[Brad S. <br...@co...>]

Use the pkg-config file when detecting sndio


Index: configure.ac
===================================================================
--- configure.ac	(revision 5165)
+++ configure.ac	(working copy)
@@ -1882,15 +1882,7 @@
 			fi
 		;;
 		sndio)
-			SNDIO_LIBS=-lsndio
-			AC_CHECK_LIB([sndio], [sio_open],
-				[AC_CHECK_HEADERS([sndio.h],
-					[output_modules="$output_modules sndio" HAVE_SNDIO="yes"])
-				]
-			)
-			if test "x$HAVE_SNDIO" != xyes; then
-				check_failed=yes
-			fi
+			PKG_CHECK_MODULES(SNDIO, sndio, output_modules="$output_modules sndio" HAVE_SNDIO="yes", HAVE_SNDIO="no" check_failed=yes)
 		;;
 		sun)
 			AC_CHECK_HEADERS([sun/audioio.h sys/audioio.h asm/audioio.h sys/audio.h])

[mpg123-devel] Opened GH-#10: Removes CPU usage when stopped. [bolshoytoster]

[<ano...@gm...>]

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

Re: [mpg123-devel] 'Unfinished command' when operating in remote mode

[Thomas O. <tho...@or...>]

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.

Re: [mpg123-devel] 'Unfinished command' when operating in remote mode

[Jonathan Y. <10...@gm...>]

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.

Re: [mpg123-devel] 'Unfinished command' when operating in remote mode

[Thomas O. <tho...@or...>]

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

Re: [mpg123-devel] 'Unfinished command' when operating in remote mode

[Jonathan Y. <10...@gm...>]

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?

Re: [mpg123-devel] 'Unfinished command' when operating in remote mode

[Thomas O. <tho...@or...>]

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

Re: [mpg123-devel] 'Unfinished command' when operating in remote mode

[Neil W. <ne...@wy...>]

> 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

Re: [mpg123-devel] 'Unfinished command' when operating in remote mode

[Thomas O. <tho...@or...>]

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

[mpg123-devel] 'Unfinished command' when operating in remote mode

[Neil W. <ne...@wy...>]

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

[mpg123-devel] mpg123 1.30.2 released (just a build fix)

[Thomas O. <tho...@or...>]

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

[mpg123-devel] mpg123 1.30.1 released

[Thomas O. <tho...@or...>]

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

[mpg123-devel] mpg123 1.30.0 released

[Thomas O. <tho...@or...>]

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

Re: [mpg123-devel] Please test new network code in/out of mpg123 (now with HTTPS support)!

[Dave Y. <dav...@gm...>]

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

Re: [mpg123-devel] Please test new network code in/out of mpg123 (now with HTTPS support)!

[Thomas O. <tho...@or...>]

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

Re: [mpg123-devel] Please test new network code in/out of mpg123 (now with HTTPS support)!

[Dave Y. <dav...@gm...>]

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

Re: [mpg123-devel] Please test new network code in/out of mpg123 (now with HTTPS support)!

[Thomas O. <tho...@or...>]

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