mpg123 Activity
Brought to you by:
sobukus
Activity for mpg123
-
Remilia Scarlet posted a comment on ticket #384
Sure thing, no rush on my end.
-
Thomas Orgis posted a comment on ticket #384
So this is still on the list. I'll get around to it eventually.
-
SIZEOF_OFF_T assertion error with cmake, mingw32, and mpg123 as a subproject
-
got this in 1.33.4
-
Missing error handling of __wgetmainargs()
-
I think we handled this in 1.33.0.
-
error: Unknown mpeg MIME type text/html
-
libmpg123 is not compatible with SHSTK (Intel CET)
-
Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
-
OK, fixes released, closing now. Thanks for bringing attention to this.
-
mpg123 released /mpg123/1.33.5/mpg123-1.33.5.tar.bz2
-
-
-
-
abdelaziz sbaai posted a comment on ticket #385
Yeah, it seems that it's just one of those things that are really hard to get right, I hope this time is gonna be it. I just tested the latest commit on master, it works as expected ! no segfault, and the frames are working fine. let me know when the bugfix is released so I can do some tests on my side. Many thanks for your help !
-
Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
-
Can you test current trunk? I found inconsistent largefile usage in control_generic.c. It switched on large offsets too late, after including headers that defined the types. This is serious breakage and I am appalled that no tooling threw a warning about that. This is another stark highlight on why it is really really really really a bad idea to have the size of off_t depend on a preprocessor macro. I'm working on this for … dunno … 15 years at least now? … and and still get things wrong every single...
-
great that you now have a better understading of the bug. Would you advise i use v1.31.x or v1.33.4 with --disable-largefile ? i'll probably not be playing files larger that 500MB in the worst case scenarios, i'm still wondering if that changes anything in how https streams work let me know if you want me to test any new commits/patches ;) thank you for being this reactive !
-
Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
-
I see the issue with broken position reporting on i686 with largefile: $ LD_LIBRARY_PATH=/usr/i686-linux-gnu/lib src/mpg123 -R @R MPG123 (ThOr) v11 LOAD https://jazzradio.ice.infomaniak.ch/jazzradio-high @I jazzradio-high @I ICY-NAME: JAZZ RADIO NATIONALE @I ICY-URL: https://jazzradio.ice.infomaniak.ch/jazzradio-high.mp3 @P 2 @S 1.0 3 44100 Joint-Stereo 2 627 2 0 0 0 192 0 0 @E Error getting position information, disabling playback status. @I ICY-META: StreamTitle=''; quit No crash, but at least...
-
yes, here it is
-
Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
-
Damn. So you see a corruption issue based on the largefile stuff, which YET AGAIN needs fixing. Hm. Did I break something with the 64 bit API in control_generic.c for 32 bit platforms? Maybe I can reproduce this after all, here. Can you attach the full configure output / config.log from a normal run of current mpg123 without the --disable-largefile?
-
yes, i tested mpg123 1.33.4, and it works just fine isn't this what this doc file describes ? https://github.com/madebr/mpg123/blob/master/doc/LARGEFILE
-
Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
-
So you built all those commits and they ran fine without crashing? Is the current mpg123 also fine with --disable-largefile?
-
new update ! i have succeded to compile and run all the previous commits, and problematic versions usings when i tryed this configure option to avoid compilation problems on some commits: --disable-largefile the hint was this make error ./src/intsym.h:245:23: error: conflicting types for ‘INT123_position_info’ #define position_info INT123_position_info ^~~~~~~~~~~~~~~~~~~~ src/common.c:164:5: note: in expansion of macro ‘position_info’ int position_info( mpg123_handle *fr, long offset, out123_handle...
-
There is something else going on. At least on x86-64, I can build all of those 19 commits just fine. What jumps out is this one: commit 3172d2ef48ec160a1101582ffbb1b47a84c54343 Author: thor <thor@35dc7657-300d-0410-a2e5-dc2837fedb53> Date: Sun May 28 19:26:58 2023 +0000 mpg123: patch up remote control interface esp. with buffer and fix some casing Buffering and generic remote control did not interact nicely before. Now I added some explicit draining and dropping to make sense. This means that, on...
-
Hello again, i tryed to git bisect, but i ended up skipping many commits because of compilation errors i couldn't fix, so this is the "narrowed down" list of commits where the problem could've happened There are only 'skip'ped commits left to test. The first bad commit could be any of: 2b353cb4e049794243ced9213ce59fe7dff6d96d 3172d2ef48ec160a1101582ffbb1b47a84c54343 05d0d723b8726fcb10da92c3660c4d91cdea3202 68f648a58347365dbc34ae9f2c3f497d34f0ceef 2b687d071562c0306b08bf6f066b364ca06cf402 515829134b6e3a7bb980b6ba2b4755f6c93f75f0...
-
Wait, what? The failure to get position information is while playing a local file? That should be super-easy to debug! (Sorry, I'm not fully able to pay attention here.) Does building with -fsanitize=address give anything? Or ubsan? This can be nicely scripted for bisecting the error. Also … valgrind and/or gdb should be able to pin down something.
-
I don't think that failure to get position information is unrelated. The network backend does not matter, apparently. So it is something in the main process, triggered by that stream … but only if it is really live, not read from a dump. Some memory corruption. Also only in remote control mode … Since you have the infra set up for testing differing versions. Can you check the commits/revisions between in a bisecting fashion (always taking the middle revision between the currently known-good and currently...
-
i have tryed to bisect to find where the problme occurs exactly, here are the results of the different versions i have tried Version Works ? 1.33.4 No 1.32.9 No 1.32.3 No 1.32.0 No 1.31.4 Yes 1.31.2 Yes aff67e9a (commit) No ebdd0b62 (commit) Yes So as you guessed, the problem comes from the change from 1.31.x to 1.32.0, I have noticed another non related problem, the frames don't work in remote mode in the impacted versions #commit aff67e9a /home/dev/mpg123.aff67e9a/usr/local/bin/mpg123 -R @R MPG123...
-
i have tryed to bisect to find where the problme occurs exectly, here are the results of the different versions i have tryed Version Works ? 1.33.4 No 1.32.9 No 1.32.3 No 1.32.0 No 1.31.4 Yes 1.31.2 Yes aff67e9a (commit) No ebdd0b62 (commit) Yes So as you guessed, the problem comes from the change from 1.31.x to 1.32.0, I have noticed another non related problem, the frames don't work in remote mode in the impacted versions #commit aff67e9a /home/dev/mpg123.aff67e9a/usr/local/bin/mpg123 -R @R MPG123...
-
Hello again ! yes i have tried ./configure --with-network=internal as well as the other options for --with-network (curl, wget), none of them solved the problem
-
The whole data structure is fishy … (gdb) print *filept $1 = { buf = "\r\nAccess-Control-Allow-Origin: *\r\nAccess-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type, Icy-MetaData\r\nAccess-Control-Allow-Methods: GET, OPTIONS, SOURCE, PUT, HEAD, STATS\r\nicy-"..., bufp = 0xd34f1 "\377\373\262d\017\210\026\021f\315Gi\340\002Z\244\312\f\354\024", fill = 39, fd = -1, htd = { content_type = {p = 0x0, size = 819024, fill = 11}, icy_name = {p = 0xb <error: Cannot access memory at address...
-
Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
-
But that does not make sense: You are using the same helper code with 1.31.x (btw.: 1.31.3 is also fine? Are you able to bisect things? So if it is the change from 1.31.x to 1.32.0, we got broadly revisions 5191 to 5333 to check in trunk. Would be helpful to narrow it down to one of those commits. If you are missing tooling for svn (I'd just do a simple shell script, but some folks are very used to git tools), you could use the github mirror https://github.com/madebr/mpg123 or just the plain git-svn...
-
Can you check if a non-https stream using the old internal http code in mpg123 crashes? ./configure --with-network=internal You got the hunch already, that something in the https helper handling is causing memory corruption.
-
I somehow missed your first response with the streamdump playback check and the gdb logs. I'll have to look at the more closely.
-
Hello again ! new update, just tested mpg123 1.31.2, and it is working better, i tryed to use different versions after i have experienced more problems in remote mode (@JUMP -1, not being able to see the frames @F) i had problems on v1.33.4 and v1.32.10. but using 1.31.2 solves most of them
-
Hello again ! new update, just tested mpg123 1.31.2, and it is working better, i tryed to use different versions after i have experienced more problems in remote mode (@JUMP -1, not being able to see the frames @F)
-
Environment - Platform: armv7l (Raspberry Pi, Raspbian Buster/Debian 10) 1. The problem only occurs in remote mode; plain mode works fine Plain mode plays the stream without issue: mpg123 https://jazzradio.ice.infomaniak.ch/jazzradio-high Remote mode crashes: # Terminal 1 mpg123 -R --fifo /tmp/mpg123-fifo.cmd # Terminal 2 echo "LOAD https://jazzradio.ice.infomaniak.ch/jazzradio-high" > /tmp/mpg123-fifo.cmd Output before crash: @I jazzradio-high Segmentation fault. 2. Stream capture replayed with...
-
Next step would be to check if a stream capture (--streamdump file) that is then opened with correct --icy-interval from disk also crashes. This isolates things from the actual HTTP process. Of course, the history of the corrupted string struct would be good
-
I cannot reproduce on AMD64. Is this specific to remote control mode or does plain mpg123 https://jazzradio.ice.infomaniak.ch/jazzradio-high also crash? It also prints the ICY info for me … though it is not very informative: src/mpg123 https://jazzradio.ice.infomaniak.ch/jazzradio-high High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.33.5-dev; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes Directory: https://jazzradio.ice.infomaniak.ch/...
-
Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
-
Can you test current trunk / snapshot? I followed the original suggestion to copy the aarch64_defs.h approach now. I've seen the sections announcing shadow stack now, but I have not tested this anywhere.
-
Sorry for the late reply! Yeah, keep the whole file if you wish, it's fine with me. I don't think support for every single frame would be necessary if it adds additional symbols to the library. Just ones with substantial use in the wild and strong use cases.
-
Revisiting the ID3v2 spec … there are lots of frames that I never encountered, ideas for specifc uses that did not materialize. As I said, adding text fields should be easy enough, but there is lots of funny binary frames, or things like LINK … I do not think that it is libmpg123's task to provide a full implementation of the standard. It is unfortunate that you got lots of MusicBrainz IDs stored as TXXX frames and only one of them as UFID. I am pondering how to add API for the UFID frames. It needs...
-
Can I keep the leading bits of your file as test data in the mpg123 distro? I guess I'll just add parsing and testing of the dump for the fields it has.
-
Awesome, sounds good.
-
Hm, so id3v2 is not actually displaying the binary data for UFID. I thought I'd let mpg123-id3dump show it in hex. Regarding additional fields: I guess you'd like to see the URL fields (starting with W), too. Then there's TORY. There is a numer that I did not cover. Adding more text-like fields is easy. The binary ID needs some specific bits, but not such a big deal. So far there was no demand for more fields, but sure, I can add more.
-
So I came across this while adding support for MusicBrainz IDs to the music player I wrote, Benben, which uses libmpg123 for MPEG-1 and ID3 support. Support for these IDs was being added because, when you submit to ListenBrainz, adding MusicBrainz IDs (if they exist in the file) help ensure a better match for the user. And it turns out, MusicBrainz Picard uses the UFID frame to store the MusicBrainz Recording ID. I'm not totally sure what other fields aren't getting handled, but I can spend some...
-
So I came across this while adding support for MusicBrainz IDs to the music player I wrote, Benben, which uses libmpg123 for MPEG-1 and ID3 support. Support for these IDs was being added because, when you submit to ListenBrainz, adding MusicBrainz IDs (if they exist in the file) help ensure a better match for the user. And it turns out, MusicBrainz Picard uses the UFID frame to store the MusicBrainz Recording ID. I'm not totally sure what other fields aren't getting handled, but I can spend some...
-
Sure, mpg123's ID3 parsing is not exhaustive. It is mostly about (text) fields useful for player display. Can you give an example file and also show the id3v2 output? Seems like id3v2 doesn't actually create UFID frames. id3v2 --UFID xxx foo.mp3 does not result in anything being added to the file. So I wonder how you populate these and also, since the data is supposed to be unspecific binary, how it is to be displayed. This field seems to be designed for the same purpose that Amazon utilizes a simple...
-
The UFID frame of an ID3v2 tag does not get parsed
-
sunbeachbeforesunset posted a comment on ticket #383
GCC and Clang have a cet.h that you can include that defines the section, eg look at /usr/lib/gcc/x86_64-linux-gnu/13/include/cet.h, you could simply use: #if defined(__has_include) && __has_include(<cet.h>) #include <cet.h> #endif Or, if you don't want an include, you can copy the contents of cet.h into an mpg123 header. Note that cet.h defines support for both SHSTK and IBT, but Linux only supports SHSTK right now, so you may not want to advertise IBT support as there is no way to test it curr...
-
manx posted a comment on ticket #383
Maybe we need to go to inline asm, after all, at least for active architectures. I would suggest also considering to change to intrinsics instead of inline asm. Intrinsics for SSE and AVX on amd64 (or NEON on arm64) are widely supported and compatible between all major compilers, while inline asm requires compiler-specific syntax. We'd keep the files for 32 bit archs unchanged, I presume. Changing all the x86 32bit asm implementations is very likely not worth the effort, totally agreed.
-
Hm. You got a working example that does this in custom assembly files? Is the layout exactly the same on x86-64 as on ARM? What replaces __ARM_FEATURE_BTI_DEFAULT and __ARM_FEATURE_PAC_DEFAULT? I wonder how many of these annoying busywork items will crop up, making it more and more cumbersome to carry stand-alone assembly files. Maybe we need to go to inline asm, after all, at least for active architectures. We'd keep the files for 32 bit archs unchanged, I presume. But for now it is reasonable to...
-
libmpg123 is not compatible with SHSTK (Intel CET)
-
-
-
Ozkan Sezer posted a comment on ticket #382
Anyhow, I imported the most recent patch. Is current revision 5532 fine for you? Looks good to me
-
Isn't this a major bug in cmake and subprojects should just be avoided unless there is some isolation between them, or at least controlled sharing of variables? Anyhow, I imported the most recent patch. Is current revision 5532 fine for you?
-
Discard my big patch above. The following revised version of the Marteen's patch should do the trick: diff --git a/ports/cmake/src/CMakeLists.txt b/ports/cmake/src/CMakeLists.txt index 7861e35..f6a77b9 100644 --- a/ports/cmake/src/CMakeLists.txt +++ b/ports/cmake/src/CMakeLists.txt @@ -74,9 +74,9 @@ check_function_exists(execvp HAVE_EXECVP) check_function_exists(ctermid HAVE_CTERMID) check_function_exists(clock_gettime HAVE_CLOCK_GETTIME) -check_type_size(off_t SIZEOF_OFF_T) +check_type_size(off_t...
-
Maarten posted a comment on ticket #382
As an alternative, I've attached an alternative patch that changes all SIZEOF_OFF_T to MPG123_SIZEOF_OFF_T. This patch was created by @sezero, another member of the SDL project.
-
SIZEOF_OFF_T assertion error with cmake, mingw32, and mpg123 as a subproject
-
Attempting to build results in syntax error
-
mpg123 build failed for the avx assembly files.
-
out123_open uses strtok_r, which is unavailable on MSVC
-
Using libmpg123 to get raw ID3 returns modified data.
-
Building mpg123 using non-legacy CMake toolchain fails
-
-
-
Trunk works :)
-
This is a weird one. When I download the URL via wget, I get an MPEG stream. When I access via mpg123's old internal http code, I get some HTML reply. If I look at what the redirections that wget gets do … $ wget http://nrj.de/pop --2025-09-18 23:25:28-- http://nrj.de/pop Resolviendo nrj.de (nrj.de)... 157.90.170.233 Conectando con nrj.de (nrj.de)[157.90.170.233]:80... conectado. Petición HTTP enviada, esperando respuesta... 301 Moved Permanently Ubicación: https://frontend.streamonkey.net/energy-pop/stream/mp3?aggregator=shorty...
-
Hans Streibel created ticket #381
error: Unknown mpeg MIME type text/html
-
How's the current trunk for both?
-
You suggested using __ANDROID__ there. __ANDROID__ is a built-in macro, whereas ANDROID is added by the CMake toolchain file. Reading the verbose build log, -DANDROID is correctly passed when compiling C sources, but not when assembling S sources.
-
You suggested using __ANDROID__ there. __ANDROID__ is a built-in macro, whereas ANDROID is added by the CMake toolchain file. Reading the build log, Reading the verbose build log, -DANDROID is correctly passed when compiling C sources, but not when assembling S sources.
-
Am Wed, 10 Sep 2025 14:19:19 -0000 schrieb "Maarten" pacha2087@users.sourceforge.net: -.data +#ifndef APPLE + .section .rodata +#else + .data +#endif Yeah … I guess we probably should define a macro #ifndef __APPLE__ #define RODATA .section .rodata #else #define RODATA .data #endif and use that everywhere?
-
Am Wed, 10 Sep 2025 14:18:39 -0000 schrieb "Maarten" pacha2087@users.sourceforge.net: // Apple and Android NDK seem both not to like direct global access. -#if defined(PIC) && (defined(APPLE) || defined(ANDROID)) +#if defined(PIC) && (defined(APPLE) || defined(ANDROID)) #define PIC_GLOBAL_PTR #endif So our resolution of bug #345 was fauly in putting ANDROID in there? Or rather, this used to be defined and now only ANDROID is?
-
Unrelated to the error, but would this patch make sense? diff --git a/src/libmpg123/tabinit_mmx.S b/src/libmpg123/tabinit_mmx.S index 077e19e7..332bcd22 100644 --- a/src/libmpg123/tabinit_mmx.S +++ b/src/libmpg123/tabinit_mmx.S @@ -10,7 +10,11 @@ #include "mangle.h" -.data +#ifndef __APPLE__ + .section .rodata +#else + .data +#endif ALIGN32 .globl ASM_NAME(INT123_costab_mmxsse) ASM_NAME(INT123_costab_mmxsse):
-
Building mpg123 using non-legacy CMake toolchain fails
-
-
-
John Regan posted a comment on ticket #379
Just downloaded the latest snapshot and tested, and I can confirm the fix. Thank you so much!
-
It was a bad idea to begin with, messing with the bytes like that. I now took the step to change the internal parser API to pass the encoding separately, removing the need for the byte abusal. Revision 5520 contains the fix. The snapshot being generated before 03:00 CEST tonight will contain this. Can you confirm the fix?
-
Oh, right, you beat me to it. I even wrote a very explicit comment about abusing a byte.
-
Indeed. I did not spot the line yet, but something in the parser does modify the buffer. If you also set mpg123_param(mh, MPG123_ADD_FLAGS, MPG123_SKIP_ID3V2, 0); to disable the parsing itself (which makes sense if you are interested in the raw frame data), the contents are unchanged. Likely the parser modifying the data only started being a bug once we added the feature of keeping the RAW data
-
I believe the attached patch fixes the issue. There's some areas in id3.c that copy the encoding byte into the raw data when processing comments and usertext, this patch just makes sure to copy the original byte back.
-
Using libmpg123 to get raw ID3 returns modified data.
-
-
-
-
-
-
-
Camille Ribeiro posted a comment on ticket #378
Thank you, but now I can't do it, I was testing it on a friend's computer and they settled for using the pre-built version of mpg123 that came with their distribution of Ubuntu (no idea why apt worked but compiling it ourselves didn't). But again thanks for trying to fix it.
-
Can you try the same with current svn trunk? I added code that should give you a clearer error message (the error being missing pkg-config at autoreconf).
-
This happens whem you don't have JACK development files installed. No issue with running configure, but when generating it. (Edit: This was not supposed to be in bold, stupid sf.net markup) It's an annoyance, yes. Maybe we can change JACK detection not to depend on that macro. But for now, just install libjack-dev, jack-devel or similar package from your distribution. (Edit: removed mail signature … mail responses are a nice feature, but too bad that it's broken here.)
1 >
