similar to: XMMS plugin: string handling bugs

I, like others here, have noticed that the xmms plugin is broken for first use in version 1.1.2. The problem is confusion between dynamically-allocated and statically-allocated strings. A quick, although perhaps not elegant, fix is included below. Note: you would not see this if you already had a [flac] section in your config file, which probably explains how it escaped the notice of

Hi, Here's a patch to add support for streaming HTTP transport to the xmms plugin. Most of the code (in particular, http.c) is taken from the xmms mpg123 input plugin. You'll need to make a three-line change to the xmms mpg123 input plugin to get streaming to work. The mpeg plugin currently handles all http urls itself unless they end in an ogg or real audio extension (which means flac

Yes but can this be exported to an external source like a web-site on my network Richard On Sun, 21 Nov 2004 20:46:48 +0100, Anatol <icecast@recordcaster.de> wrote: > Richman wrote: > > > > Is their anyway that i can ecport the now current playing song into a > > text file iam using ices 0.4 and icecast 2.0 > > > > -- > > Thankyou > > Richard

Hi, the patch below fixes function prototypes/defintions with void argument to shut up the heartful warnings by recent gcc :) It doesn't cover all places, e.g. test directories. The patch is to 1.1.2. Takashi --- src/metaflac/operations.c-dist 2005-05-25 16:20:02.000000000 +0200 +++ src/metaflac/operations.c 2005-05-25 16:20:09.000000000 +0200 @@ -26,7 +26,7 @@ #include <stdlib.h>

On Tue, Jul 08, 2003 at 10:11:49PM +0200, Miroslav Lichvar wrote: > On Tue, Jul 08, 2003 at 11:07:09AM -0400, Matt Zimmerman wrote: > > severity 200435 normal > > thanks > > > > I received this bug report from a Debian user. I can't think of any reason > > offhand why the command line tool would work while the xmms plugin would > > fail. > ... >

Sorry for all the "my plugin don't work" questions... I can't seem to get http streaming of flac files to work in xmms. When I open an m3u with http URLs, the xmms window just says Invalid FLAC file: "http://localhost/foo.flac" This is with flac 1.0.3 and xmms 1.2.7. This is supposed to work, right? Thanks, steven.

Hi, some of my maintenance scripts weren't working as expected and I finally found that this only happens if the user was mapped to a backend server reachable via IPv6: On a director: doveadm mailbox status -u username messages Junk returns Junk messages=203 (if backend is connected via IPv4) or Lookup of host ipv6addr:542 failed: ... (if backend is connected via IPv6)

f0296255 switched to --std=c99 by default, but old glib relies on the pre-C99 extern inline rules. Override G_INLINE_FUNC for it to avoid multiple definition linker errors. --- src/plugin_xmms/charset.c | 4 +--- src/plugin_xmms/configure.c | 4 +--- src/plugin_xmms/fileinfo.c | 4 +--- src/plugin_xmms/http.c | 5 +---- src/plugin_xmms/plugin.c | 4 +--- src/plugin_xmms/plugin.h |

Christian Weisgerber <naddy@mips.inka.de> wrote: > #0 0x0000000040d18810 in FLAC__lpc_compute_residual_from_qlp_coefficients_wide > (data=0x49e4c014, data_len=110, qlp_coeff=0x7f7ffffece70, order=1, > lp_quantization=14, residual=0x4fced000) at lpc.c:745 > 745 residual[i] = > data[i] - (FLAC__int32)((qlp_coeff[0] *

Christian Weisgerber <naddy@mips.inka.de> wrote: > | # nasm build rule: > | %.lo: %.s Even with gmake, this really works only by accident. Automake generates a competing suffix rule, and gmake apparently gives the rule above a higher priority than the suffix rule (or that just happens to be the evaluation order). Matt, since you seem to understand automake, can you come up with

Running the basic (--disable-thorough-tests) test suite, I get these failures round-trip test (rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64

Matt Zimmerman <mdz@debian.org> wrote: > Aha. In FLAC__fixed_restore_signal, the index variable 'i' is declared > unsigned, then used like so: [...] With the following trivial patch applied, > everything works on Alpha, at least with my test sample. Against 0.9 or CVS? While this clearly fixes a bug, 0.9 still dies for me. #0 0x1600692a8 in

severity 200435 normal thanks I received this bug report from a Debian user. I can't think of any reason offhand why the command line tool would work while the xmms plugin would fail. ----- Forwarded message from Stephan Niemz <st.n@gmx.net> ----- Date: Tue, 8 Jul 2003 10:24:57 +0200 From: Stephan Niemz <st.n@gmx.net> Resent-From: Stephan Niemz <st.n@gmx.net> To: Debian

That sounds like the application param is still used as part of the process though? Would allowing the user to specify the application work in the Solokey case? What is stored in the private keyfile? The documentation says no private key is stored there. So is it just information used to reseed the public/private key? Thanks, Kevin ________________________________________ From: openssh-unix-dev

Currently, if IPv6-enabled rsync is run as --daemon, it will perform a wildcard bind(2) on an AF_INET6 socket and expect that IPv4 traffic will be forwarded to the v6 socket (IPv4 mapped address, RFC2553). This has never worked on OpenBSD which disallows IPv4 mapped addresses for security reasons. On FreeBSD 5.0-CURRENT, where the behavior is subject to configuration, the default was switched to

This affects the XMMS plugin. configure.in has this test: AC_CHECK_TYPES(socklen_t, [], []) And src/plugin_xmms/http.c is the only consumer: #ifndef HAVE_SOCKLEN_T typedef unsigned int socklen_t; #endif Together this looks bogus to me. The configure check looks for socklen_t in the default headers. If it isn't found there, socklen_t will be typedef'ed. However, at least on

I'm currently trying to figure out why RC3 oggenc with iconv support will - work, but enter replacement characters into tags instead of converting to UTF-8; - dump core; or - catch an assert(); depending on the locale settings. (On FreeBSD, with Chuguev iconv.) I think I'm getting a handle on the assert(). It's this one: assertion "(!k && !ibl) || (k == (size_t)(-1)

libogg 1.1's included regression tests ("make check") fail at least on alpha: ---------------> ./test_bitwise Small preclipped packing (LSb): ok. Null bit call (LSb): ok. Large preclipped packing (LSb): ok. 32 bit preclipped packing (LSb): ok. Small unclipped packing (LSb): ok. Large unclipped packing (LSb): ok. Single bit unclipped packing (LSb): ok. Testing read past end

Here's the promised Sun audio system plug-in. I have tested this on OpenBSD. It should work without changes on NetBSD, too. Jeremy, could you please verify this? After a few minor tweaks it now also compiles on Solaris 2.7. Alas, I can't verify whether it actually plays anything there. I guess this could also with little effort be made to work on SunOS4. Attached: - Diff to

Problems in FLAC 0.9: - On alpha, flac immediately dumps core for both encoding and decoding (FreeBSD/alpha). - The distribution Makefile.in files haven't been generated with "automake --include-deps". The resulting Makefiles aren't fully portable; in particular they break with BSD make. In the future, care should be taken to use "--include-deps". - What is