On LEDE, mpd-mini package plays mp3 streams. (for example http://spoonradio.ice.infomaniak.ch:80/spoonradio-hd.mp3) But on openwrt-18, mpd-mini package does not play mp3 streams (it gives "failed to decode" warning).
To find out the cause of this, I did the following:
git clone git://github.com/openwrt/packages.git openwrt-packages
cd openwrt-packages/
git log -p
But I could not find the relevant commit...
How to make mpd-mini package in openwrt to play MP3 streams again?
Hey there
I have exactly the same problem. I´m using 19.07.0 rc2 X86/Geode. With 18.06.1 everything was working. But @18.06.1 I used mpd-full witch depends on libffmpeg. But now mpd-full is gone and I have to use mpd-mini witch depends on libmpg123.
My local CD-rips in FLAC play nice. But my Playlist with http-streams don´t. For testing I installed mpeg123 console player and played my Playlist on console. This is working. But with mpd only an error in logfile.
Jan 03 13:12 : exception: Failed to decode http://stream.sunshine-live.de/live/mp3-192/stream.sunshine-live.de/#sunshine live Livestream
Jan 03 13:12 : player: played "http://stream.sunshine-live.de/live/mp3-192/stream.sunshine-live.de/#sunshine live Livestream"
I just saw in the faillogs for 19.07 that there are entries for mpd-mini and mpd-full. I don´t understand much of the logs, but the faillog for mpd-full is about not compiling for some reason? And mpd-mini has some problems, but compiled. There ist a faillog for ffmpeg also.
ffmpeg depends on BUILD_PATENTED, which is not enabled (and won't be, for legal reasons), but you can build it from source with the according setting yourself.
Is libffmpeg also affected? I don´t think so, because there is no faillog for it. If not, it´s not a problem for me. I just want to play http-streams with mpd-mini or mpd-full. mpd-full is not available because of compiler problems and mpd-mini has problems playing the stream. Maybe the reason is found in the faillog for it?
Btw, I had to create a new account to answer. There was a problem with my username existing twice!?
Problem still exists. Can anyone help please?
Was it that? Or did you reach the posting daily limit for new user?
Anyway, I'd have advised you to check with the admin instead of creating a new account.
You could tag people like this: @slh if you want to mention someone that they notice your post.
This is for legacy i3866 platform. It's a NASM problem.
On the surface, this error is bizarre. I removed all of the unnecessary BUILD_PATENTED entries when the mp3 patents expired.
edit: This might be a problem with the meson conversion.
edit2: Maybe -Dmpg123=true needs to be added here: https://github.com/openwrt/packages/blob/master/sound/mpd/Makefile#L102
edit3: I see it now. Maybe -Dmad=enabled should be used instead. It's smaller.
No. I created an account with name "marcus", but forum software switched from "marcus" to "Marcus" and back all the time. When I was "Marcus", my full name was shown as Marcus Größer, but that's not my name. I think forum software has mixed two accounts accidently. I was not able to write a post or change anything in the profile settings. After logout, I can't login again, wrong password. Very strange. So I had to create a new account.
@neheb can you fix the problem with mpd?
Thanks for letting us now.
I just did a quick check and can confirm that clicking on "marcus" leads to the user profile of "Marcus".
Seems to be a bug in Discourse -> will be adressed to the discourse team. Resolution might take a while.
FYI - I have changed ownership of your previous two posts from "marcus" -> "marcus2208"
Probably not. I don't have a good way to test.
Testing is no problem. I can do that. I just bought an PC Engines ALIX for spare a few days ago, should arrive next few days. With that, I can play around without breaking anything. But I need someone with skills in debugging and compiling openwrt.
Before I switched to 19.07.0 rc2, I was using 18.06.1 with mpd-full on ALIX. I have connected a "Topping D10" USB DAC to the ALIX. That was working as expected. Played my FLAC rip´s and mp3 radio-streams. With M.A.L.P. MPD client on my android mobile phone, this is best solution ever for listening Music. But it should work with mpd-mini also.
On further analysis, I can't see what's really going wrong. You could try this patch but I doubt it would fix things:
--- a/sound/mpd/Makefile
+++ b/sound/mpd/Makefile
@@ -64,7 +64,7 @@ endef
define Package/mpd-mini
$(call Package/mpd/Default)
TITLE+= (mini)
- DEPENDS+= +libmpg123 +libvorbisidec
+ DEPENDS+= +libmad +libvorbisidec
PROVIDES:=mpd
VARIANT:=mini
endef
@@ -132,7 +132,7 @@ MESON_ARGS += \
-Dflac=enabled \
-Dfluidsynth=disabled \
-Dgme=disabled \
- -Dmad=disabled \
+ -Dmpg123=disabled \
-Dmikmod=disabled \
-Dmodplug=disabled \
-Dmpcdec=disabled \
@@ -174,7 +174,7 @@ ifeq ($(BUILD_VARIANT),full)
-Dsoundcloud=enabled \
-Did3tag=enabled \
-Dffmpeg=enabled \
- -Dmpg123=disabled \
+ -Dmad=disabled \
-Dtremor=disabled \
-Dvorbis=enabled \
-Dfifo=true \
@@ -194,7 +194,7 @@ ifeq ($(BUILD_VARIANT),mini)
-Dsoundcloud=disabled \
-Did3tag=disabled \
-Dffmpeg=disabled \
- -Dmpg123=enabled \
+ -Dmad=enabled \
-Dtremor=enabled \
-Dvorbis=disabled \
-Dfifo=false \
edit: Another possibility would be to fix ffmpeg to compile so that mpd-full can be built. Quick example:
--- a/multimedia/ffmpeg/Makefile
+++ b/multimedia/ffmpeg/Makefile
@@ -482,13 +482,7 @@ ifeq ($(ARCH),x86_64)
FFMPEG_CONFIGURE+= --enable-lto
endif
-ifneq ($(CONFIG_TARGET_x86),)
-ifeq ($(CONFIG_NASM),y)
- FFMPEG_CONFIGURE += --enable-x86asm
-else
- FFMPEG_CONFIGURE += --disable-x86asm
-endif
-endif
+FFMPEG_CONFIGURE += --disable-x86asm
ifeq ($(BUILD_VARIANT),full)
After trying out multiple options, this is what I came up with to fix ffmpeg:
From c9239892a4edab72ab40726dc46ad206be8992cf Mon Sep 17 00:00:00 2001
From: Rosen Penev <rosenp@gmail.com>
Date: Tue, 7 Jan 2020 19:07:51 -0800
Subject: [PATCH] target: switch pentium to pentium2.
With CPU_TYPE set to pentium, NASM fails to create proper compiled files,
which causes ffmpeg to fail compilation. Not even objdump can figure out
what these files are.
This is one way to fix compilation of ffmeg.
Intel's Pentium 2 was released in 1997. I think it's legacy enough.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
include/target.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/target.mk b/include/target.mk
index a813ba2d2d..5e31a536e9 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -177,8 +177,8 @@ ifeq ($(DUMP),1)
CPU_CFLAGS_octeonplus = -march=octeon+ -mabi=64
endif
ifeq ($(ARCH),i386)
- CPU_TYPE ?= pentium
- CPU_CFLAGS_pentium = -march=pentium-mmx
+ CPU_TYPE ?= pentium2
+ CPU_CFLAGS_pentium2 = -march=pentium-mmx
CPU_CFLAGS_pentium4 = -march=pentium4
endif
ifneq ($(findstring arm,$(ARCH)),)
--
2.24.1
I cannot runtime test this as I do not have the equipment.
@neheb Thank you for your investigation. Your suggestion sounds resonable, because ffmpeg has problems to compile on i368_pentium only. At target i386_pentium4 and x86_64 ffmpeg compiled with no error. And also mpd compiled on these targets without any error.
But the big question is, what happens when CPU_TYPE is set to Pentium2? Is ffmpeg still compatible to AMD Geode LX?
Yes.
i386_geode and i386_legacy both use the same toolchain for simplicity. Unfortunately NASM is totally broken.
After discussing on IRC, it seems there are still ancient systems running OpenWrt, so this change would not be merged.
Best option would be to disable NASM in such a case.
I just set up a VMware with Debian 10 Server and openwrt build tools. Cloned openwrt git 10 mins ago. But your last post confused me, sorry. Thats because for me it´s the first time doing this.
What´s the meaning of this. NASM is the assembler, right? I doubt there is anything I (we?) can do.
Yes, my PC Engines WRAP for example. It´s using an very ancient National Semiconductor Geode SC1100 CPU. Even if CPU_TYPE pentium2 is compatible with Geode LX of ALIX, for sure it won´t be compatible with SC1100 CPU of WRAP (and all the other CPU´s like that).
Ok. So no more ffmpeg for i386. And without ffmpeg, no more mpd-full. It should work with mpd-mini also. But sadly its broken somehow also.
Is this something I can do with my fancy new development VMware?
Sorry for all the stupid noob questions. But I want to understand (and help by testing) whats going wrong with mpd.