[gentoo-dev] Xmms needs to die.
Luis Medinas
I'm the current maintainer for xmms and all plugins. As you all know
xmms is writen over GTK+-1. This toolkit is not supported by the
upstream like xmms. We have lot's of dead upstream plugins on portage
and this is a pain to maintain like xmms itself. You might want to look
at our patchset that contains fixes for 'millions' of bugs.
We have a few alternatives like audacious, gstreamer based players and
xine-lib players (did i forget anything ?). The problem is that this
players doesn't support a few audiotypes or plugins that xmms currently
does.
So i'm asking for a solution either remove xmms, move the maintainer for
anyone who volunteer or the sound herd.
My plans now is replace xmms for xmms2 (that i would like to take the
maintainership). Opinions ? Ideas ?
--
Gentoo Linux Developer
http://dev.gentoo.org/~metalgod
--
gento...@gentoo.org mailing list
Ioannis Aslanidis
Luis Medinas wrote:
> Hi everyone.
>
> I'm the current maintainer for xmms and all plugins. As you all know
> xmms is writen over GTK+-1. This toolkit is not supported by the
> upstream like xmms. We have lot's of dead upstream plugins on portage
> and this is a pain to maintain like xmms itself. You might want to look
> at our patchset that contains fixes for 'millions' of bugs.
> We have a few alternatives like audacious, gstreamer based players and
> xine-lib players (did i forget anything ?). The problem is that this
> players doesn't support a few audiotypes or plugins that xmms currently
> does.
> So i'm asking for a solution either remove xmms, move the maintainer for
> anyone who volunteer or the sound herd.
> My plans now is replace xmms for xmms2 (that i would like to take the
> maintainership). Opinions ? Ideas ?
>
--
gento...@gentoo.org mailing list
Mike Frysinger
> So i'm asking for a solution either remove xmms, move the maintainer for
> anyone who volunteer or the sound herd.
no one has answered the previous problems ... xmms is the only audioplayer
that actually works on some platforms ...
plus, has the audacious/gcc-4.1 issues been worked out ?
> My plans now is replace xmms for xmms2 (that i would like to take the
> maintainership). Opinions ? Ideas ?
even if you were to do that right now, xmms2 isnt even close to being ready to
replace xmms
-mike
Alec Warner
> On Wed, 2006-08-23 at 20:07 -0400, Mike Frysinger wrote:
>> On Wednesday 23 August 2006 16:30, Luis Medinas wrote:
>>> So i'm asking for a solution either remove xmms, move the maintainer for
>>> anyone who volunteer or the sound herd.
>> no one has answered the previous problems ... xmms is the only audioplayer
>> that actually works on some platforms ...
>>
I'm going to make an uncharacteristic statement here.
Who Cares.
If you want an audio player on your arch; help maintain this, or help
fix an alternative so it does work.
--
gento...@gentoo.org mailing list
Luis Medinas
> > So i'm asking for a solution either remove xmms, move the maintainer for
> > anyone who volunteer or the sound herd.
>
> no one has answered the previous problems ... xmms is the only audioplayer
> that actually works on some platforms ...
>
> plus, has the audacious/gcc-4.1 issues been worked out ?
>
> > My plans now is replace xmms for xmms2 (that i would like to take the
> > maintainership). Opinions ? Ideas ?
>
> even if you were to do that right now, xmms2 isnt even close to being ready to
> replace xmms
Yes you are right but atm xmms is obsolete and there is place for
another player. Xmms2 is a good player that needs of course ages of
development to be able to be like xmms.
Neither i or sound herd want to maintain xmms anymore. If there is
anyone that will take it we won't mind. But we won't waste more time on
a player that is obsolete with a dead upstream. So we would like to move
xmms to overlays.gentoo.org soon with another maintainer to take care of
it.
Josh Saddler
Hash: SHA1
Luis Medinas wrote:
> On Wed, 2006-08-23 at 20:07 -0400, Mike Frysinger wrote:
>> On Wednesday 23 August 2006 16:30, Luis Medinas wrote:
>>> So i'm asking for a solution either remove xmms, move the maintainer for
>>> anyone who volunteer or the sound herd.
>> no one has answered the previous problems ... xmms is the only audioplayer
>> that actually works on some platforms ...
>>
> Most of the gstreamer audio players works just like xine-lib based.
>
>> plus, has the audacious/gcc-4.1 issues been worked out ?
>>
>>> My plans now is replace xmms for xmms2 (that i would like to take the
>>> maintainership). Opinions ? Ideas ?
>> even if you were to do that right now, xmms2 isnt even close to being ready to
>> replace xmms
>
> Yes you are right but atm xmms is obsolete and there is place for
> another player. Xmms2 is a good player that needs of course ages of
> development to be able to be like xmms.
Please don't remove it, and don't replace it with xmms2. There are far too many
media type plugins that work for xmms that audacious and similar players can't
handle. Also, will xmms plugins even work in xmms2? And isn't xmms2 still a
command line-only application? Not what users need or want. Perhaps the most
compelling reason to keep xmms around and *not* use xmms2 is the one you just made:
> Xmms2 is a good player that needs of course ages of
> development to be able to be like xmms.
So, don't dump a product that's not even near alpha status on users. If we want
to keep using software that's old, but works just fine, why force a really
stupid switch?
Can you provide a list of open fairly important bugs for xmms that provide good
examples of why you don't want to maintain it? Just so we can see your reasoning.
You may think xmms is obsolete, but it has a pretty decent niche among the
available player choices; I know I'm not alone in my affinity for it. Please
keep it. At the very least, if it has to go, don't dump a half-assed alternative
like xmms2 on the users -- sure, xmm2 shows a lot of promise, but it's simply
not ready. xmms is stable; might as well keep it around until we're so far into
future gcc versions that it (and gtk-1) just won't compile any longer on any
arch. ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
iD8DBQFE7RjhrsJQqN81j74RAj6DAKCbAM79wAE1JI42q6+L8Vaak9LPKwCfQ2bB
vVoxumBcHPZbVmE0dMtsto8=
=qVNx
-----END PGP SIGNATURE-----
--
gento...@gentoo.org mailing list
Luis Medinas
> Please don't remove it, and don't replace it with xmms2. There are far too many
> media type plugins that work for xmms that audacious and similar players can't
> handle. Also, will xmms plugins even work in xmms2? And isn't xmms2 still a
> command line-only application? Not what users need or want. Perhaps the most
> compelling reason to keep xmms around and *not* use xmms2 is the one you just made:
>
But it contains a modern design and it will be able to support almost
every type of plugins that the current xmms supports.
> > Xmms2 is a good player that needs of course ages of
> > development to be able to be like xmms.
>
> So, don't dump a product that's not even near alpha status on users. If we want
> to keep using software that's old, but works just fine, why force a really
> stupid switch?
>
It's not alpha status... it's very close to a final product afaik. It's
working fine(apart from scons crap :P) and the design provides very easy
maintainence compared to the old xmms.
> Can you provide a list of open fairly important bugs for xmms that provide good
> examples of why you don't want to maintain it? Just so we can see your reasoning.
>
You can just look at bugs.g.o and those bugs are not easy to fix. Most
of them require lot's of time to dive into the sources and fix it on a
repository (upstream job). For a distro maintainer like us it's a pain
to maintain it.
> You may think xmms is obsolete, but it has a pretty decent niche among the
> available player choices; I know I'm not alone in my affinity for it. Please
> keep it. At the very least, if it has to go, don't dump a half-assed alternative
> like xmms2 on the users -- sure, xmm2 shows a lot of promise, but it's simply
> not ready. xmms is stable; might as well keep it around until we're so far into
> future gcc versions that it (and gtk-1) just won't compile any longer on any
> arch. ;)
If noone takes it will be saved on overlays.gentoo.org. Everyone needs
to know that xmms is old and tired (obsolete). A few developers on
redhat, mandriva and suse marked xmms as obsolete. Now it's our turn to
move it to our darkness repository. If you want to be sure it's obsolete
just read xmms's website.
Luca Barbato
> If noone takes it will be saved on overlays.gentoo.org. Everyone needs
> to know that xmms is old and tired (obsolete). A few developers on
> redhat, mandriva and suse marked xmms as obsolete. Now it's our turn to
> move it to our darkness repository. If you want to be sure it's obsolete
> just read xmms's website.
>
fine for me
(please add xmms2)
People could just use mplayer o xine to play any audio sample aud doesn't.
lu
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gento...@gentoo.org mailing list
Mike Frysinger
> If noone takes it will be saved on overlays.gentoo.org. Everyone needs
> to know that xmms is old and tired (obsolete). A few developers on
> redhat, mandriva and suse marked xmms as obsolete. Now it's our turn to
> move it to our darkness repository. If you want to be sure it's obsolete
> just read xmms's website.
that isnt what i meant
you can push whatever audio player you want as the default and mark xmms
unsupported, it just has to be kept around until the newer audio players can
actually fill the gap left by xmms
as for those distros, who cares ... they cant even play mp3s out of the box :p
-mike
Richard Fish
> So, don't dump a product that's not even near alpha status on users. If we want
> to keep using software that's old, but works just fine, why force a really
> stupid switch?
Saying xmms works "just fine" is a bit of stretch IMO. My most hated
xmms bug was this one:
http://bugs.xmms.org/show_bug.cgi?id=149
This bug is more than 5 years (!!) old. I've since moved on to amarok.
-Richard
--
gento...@gentoo.org mailing list
Christian 'Opfer' Faulhammer
Luis Medinas schrieb:
> If noone takes it will be saved on overlays.gentoo.org. Everyone needs
> to know that xmms is old and tired (obsolete).
Having discussed Gentoo Status in this list: Maybe you should announce
that in GWN to prepare the last users (quite a lot I fear, we need Gentoo
stats) that xmms will be removed and they should think about switching if
possible or watch out for overlays.
V-Li
--
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
--
gento...@gentoo.org mailing list
Jakub Moc
> Please don't remove it, and don't replace it with xmms2. There are far too many
> media type plugins that work for xmms that audacious and similar players can't
> handle. Also, will xmms plugins even work in xmms2? And isn't xmms2 still a
> command line-only application? Not what users need or want. Perhaps the most
> compelling reason to keep xmms around and *not* use xmms2 is the one you just made:
> Can you provide a list of open fairly important bugs for xmms that provide good
> examples of why you don't want to maintain it? Just so we can see your reasoning.
So go maintain it - a quick list of bugs awaiting your love:
Even if you do, I'd still love this to go away from the main tree to
some overlay.
> You may think xmms is obsolete, but it has a pretty decent niche among the
> available player choices;
It's broken like hell (see above) and it's a huge PITA to maintain a
thing that's completely dead upstream.
--
Best regards,
Jakub Moc
mailto:ja...@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
Luis Medinas
> Tach Luis, 0x2B859DE3 (PGP-PK-ID)
>
> Luis Medinas schrieb:
> > If noone takes it will be saved on overlays.gentoo.org. Everyone needs
> > to know that xmms is old and tired (obsolete).
>
> Having discussed Gentoo Status in this list: Maybe you should announce
> that in GWN to prepare the last users (quite a lot I fear, we need Gentoo
> stats) that xmms will be removed and they should think about switching if
> possible or watch out for overlays.
>
to -dev ML. Then i'll ask someone to write something for GWN. I don't
want users to be surprised like they were when libexpat2 was unmasked.
Robin H. Johnson
> I'm the current maintainer for xmms and all plugins. As you all know
> xmms is writen over GTK+-1. This toolkit is not supported by the
> upstream like xmms. We have lot's of dead upstream plugins on portage
> and this is a pain to maintain like xmms itself. You might want to look
> at our patchset that contains fixes for 'millions' of bugs.
> We have a few alternatives like audacious, gstreamer based players and
> xine-lib players (did i forget anything ?). The problem is that this
> players doesn't support a few audiotypes or plugins that xmms currently
> does.
> So i'm asking for a solution either remove xmms, move the maintainer for
> anyone who volunteer or the sound herd.
> My plans now is replace xmms for xmms2 (that i would like to take the
> maintainership). Opinions ? Ideas ?
blog, I made an effort to look at both bmpx and audacious.
Both used significantly more CPU, and one of them was completely
unusable with the size of my playlist (~24000 items, mostly legal MP3) -
it sucked up ~4Gb of memory, and then the OOM killer smote it.
The plugins I used are xosd, songchange, realrandom - none of which
seemed to be trivially recompilable when I looked, but I do see that at
least one other distro has managed to port xosd.
One thing that XMMS does have going for it compared to the newer GTK2
variants is that it's much more light-weight. I'm not sure if it's just
because of the usage of GTK2 instead of GTK1, but the added size of the
alternatives isn't suitable for the moment.
As noted by other folk, I have no objections with the default changing
away from xmms, to discourage new users, but don't take XMMS away from
those of us already using it without any issues.
--
Robin Hugh Johnson
E-Mail : rob...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Luis Medinas
> The last time this came up, a few months ago, mentioned in somebodies
> blog, I made an effort to look at both bmpx and audacious.
>
> Both used significantly more CPU, and one of them was completely
> unusable with the size of my playlist (~24000 items, mostly legal MP3) -
> it sucked up ~4Gb of memory, and then the OOM killer smote it.
>
that's true they eat too much mem compared to xmms.
> The plugins I used are xosd, songchange, realrandom - none of which
> seemed to be trivially recompilable when I looked, but I do see that at
> least one other distro has managed to port xosd.
>
We can port it too.
> One thing that XMMS does have going for it compared to the newer GTK2
> variants is that it's much more light-weight. I'm not sure if it's just
> because of the usage of GTK2 instead of GTK1, but the added size of the
> alternatives isn't suitable for the moment.
>
Yes but you need to remember that GTK1 is not supported by upstream
anymore.
> As noted by other folk, I have no objections with the default changing
> away from xmms, to discourage new users, but don't take XMMS away from
> those of us already using it without any issues.
>
Yes discourage new users is the way and move the current users to
another player is necessary too. We can move xmms for overlays with no
support from us or maybe anyone else take it apart from sound herd.
Jonathan Adamczewski
> don't take XMMS away from those of us already using it without any issues.
>
It can disappear from portage without affecting your ability to keep
using it.
j.
--
gento...@gentoo.org mailing list
Robert Cernansky
> We have a few alternatives like audacious, gstreamer based players
> and xine-lib players (did i forget anything ?). The problem is that
[...]
> So i'm asking for a solution either remove xmms, move the maintainer
> for anyone who volunteer or the sound herd. My plans now is replace
> xmms for xmms2 (that i would like to take the
> maintainership). Opinions ? Ideas ?
Just pure user point of view: I search for alternatives and closest
that I found in amd64 stable portage tree is audacious. But it have
less functionality than xmms (even than xmms_with_bugs).
Most missing is gapless output, so when playing continuous tracks
I get ugly spaces between them, brr. Other missing is very usefull
xosd support and great xmms-pipe (which does not work for me
currently, I reported it yesterday - this was probably last drop for
you Luis :-( ) so xmms can be widely controlled by external commands.
This is disadvantages that I have remembered now. I'm sure I'll find
others in the future (as always when swithching software). Also there
are for sure more, that affect other users.
In general, after removing xmms we, users, only get less
functionality. Notthing will be better. So it sounds not logical to
remove functional, widely used piece of software which is better (even
with current bugs) then alternatives.
Kind regards
Robert
--
Robert Cernansky
E-mail: hsli...@zoznam.sk
Jabber: H...@jabber.sk
--
gento...@gentoo.org mailing list
Robert Cernansky
> Robin H. Johnson wrote:
> > don't take XMMS away from those of us already using it without any
> > issues.
>
> It can disappear from portage without affecting your ability to keep
> using it.
Not true, when upgrading world I'll always get message like:
!!! Ebuilds for the following packages are either all
!!! masked or don't exist:
media-sound/xmms
And --depclean will be broken because it will want to remove all xmms
dependencies. Maybe there are other issues with
installed¬_in_portage packages.
Pierre Guinoiseau
> On Wed, 23 Aug 2006 21:30:20 +0100 Luis Medinas <meta...@gentoo.org> wrote:
>
>
> Most missing is gapless output, so when playing continuous tracks
> I get ugly spaces between them, brr. Other missing is very usefull
> xosd support and great xmms-pipe (which does not work for me
> currently, I reported it yesterday - this was probably last drop for
> you Luis :-( ) so xmms can be widely controlled by external commands.
>
* media-plugins/audacious-xosd
Available versions: 0.3
Installed: none
Homepage: http://www.netswarm.net/
Description: Audacious plugin for overlaying text/glyphs in
X-On-Screen-Display
And regarding xmms-pipe, maybe this can replace it :
* net-irc/audacious-show
Available versions: 1.2.0
Installed: none
Homepage: http://nedudu.hu/?page_id=11
Description: XChat plugin to control audacious and to show
whatever you're currently playing to others
--
Pierre Guinoiseau
Email: song...@gmail.com
M$N: song...@gmail.com
Jabber: l...@jabber.fr
WWW: http://akoya.homelinux.net
--
gento...@gentoo.org mailing list
Stephen P. Becker
> Luis Medinas wrote:
>
>> If noone takes it will be saved on overlays.gentoo.org. Everyone needs
>> to know that xmms is old and tired (obsolete). A few developers on
>> redhat, mandriva and suse marked xmms as obsolete. Now it's our turn to
>> move it to our darkness repository. If you want to be sure it's obsolete
>> just read xmms's website.
>>
>
> fine for me
>
> (please add xmms2)
>
> People could just use mplayer o xine to play any audio sample aud doesn't.
>
> lu
>
Note that neither mplayer or xine work on mips particularly well. Xine
is especially screwed. And if anybody mentions gstreamer, it flat out
doesn't work at all.
-Steve
--
gento...@gentoo.org mailing list
Anders Hellgren
Hash: SHA1
On Thu, 24 Aug 2006, Jakub Moc wrote:
> It's broken like hell (see above) and it's a huge PITA to maintain a
> thing that's completely dead upstream.
>
For something that's dead, it's been kicking quite a lot this summer:
http://cvs.xmms.org/cvsweb.cgi/xmms/ChangeLog
/Anders
- --
Anders Hellgren (kallamej)
Gentoo Forums Administrator
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE7asQFX025WX+RG4RAiH7AKCzZyaUiVcTvd0sRsuUYlKFXiYY6ACfeSUo
UFgmWFB+bFDqqkVKoxD5mYw=
=4Euv
Krzysiek Pawlik
> Unfortunatelly this is something different. xmm-pipe lets you control
> running xmms from commandline (thus binding these commands to
> keys). It allows control volume, skipping in current track (fast
> forward), do some playlist actions and lot more.
This helps:
nelchael@nelchael ~$ audacious --help
Usage: audacious [options] [files] ...
Options:
--------
-h, --help Display this text and exit
-n, --session Select Audacious/BMP/XMMS session (Default: 0)
-r, --rew Skip backwards in playlist
-p, --play Start playing current playlist
-u, --pause Pause current song
-s, --stop Stop current song
-t, --play-pause Pause if playing, play otherwise
-f, --fwd Skip forward in playlist
-e, --enqueue Don't clear the playlist
-m, --show-main-window Show the main window
-a, --activate Activate Audacious
-i, --sm-client-id Previous session ID
-H, --headless Headless operation [experimental]
-N, --no-log Disable error/warning interception (logging)
-v, --version Print version number and exit
--
Krzysiek Pawlik <nelchael at gentoo.org> key id: 0xBC555551
desktop-misc, desktop-dock, desktop-wm, x86, java, apache...
Robert Cernansky
> Robert Cernansky a écrit :
> > On Wed, 23 Aug 2006 21:30:20 +0100 Luis Medinas <meta...@gentoo.org> wrote:
> >
> > Most missing is gapless output, so when playing continuous tracks
> > I get ugly spaces between them, brr. Other missing is very usefull
> > xosd support and great xmms-pipe (which does not work for me
> > currently, I reported it yesterday - this was probably last drop
> > for you Luis :-( ) so xmms can be widely controlled by external
> > commands.
> >
> Audacious has xosd support :
> * media-plugins/audacious-xosd
Thanks, I mentioned only stable stuff before. This one is not stable.
> And regarding xmms-pipe, maybe this can replace it :
> * net-irc/audacious-show
Unfortunatelly this is something different. xmm-pipe lets you control
running xmms from commandline (thus binding these commands to
keys). It allows control volume, skipping in current track (fast
forward), do some playlist actions and lot more.
Robert
--
gento...@gentoo.org mailing list
Dominique Michel
It is aqualung that is a very good player with nice features such as
oss, alsa, jack and LADSPA support. It have a database support to help
to organise yours audio files.
http://aqualung.sourceforge.net/
But I don't know if it will work on any architecture. It is still a beta
software, but I know users very happy with it. And the development seam
to be very fast and active.
Dominique
--
gento...@gentoo.org mailing list
Robert Cernansky
Yes, looked at this. It's similar to stadard xmms
posibilites. xmms-pipe have much wider posibilites.
I use mainly skipping within a track (not to next track) so I can
rewind without touching a mouse and switching to third workspace where
xmms is sitting.
Another frequently used xmms-pipe functionality is volume control
(with software mixing enabled you can control volume of xmms
independently from Main/PCM volume).
Useful is also reporting info (e.g. about played track) to output
pipe.
Andrej Kacian
On Thu, 24 Aug 2006 16:22:06 +0200
Robert Cernansky <hsli...@zoznam.sk> wrote:
> Yes, looked at this. It's similar to stadard xmms
> posibilites. xmms-pipe have much wider posibilites.
>
> I use mainly skipping within a track (not to next track) so I can
> rewind without touching a mouse and switching to third workspace where
> xmms is sitting.
>
> Another frequently used xmms-pipe functionality is volume control
> (with software mixing enabled you can control volume of xmms
> independently from Main/PCM volume).
>
> Useful is also reporting info (e.g. about played track) to output
> pipe.
Hello Robert,
sounds like you might want to have a look at http://musicpd.org - in
portage as media-sound/mpd or media-sound/mpd-svn.
It does all you mention above (and more), and is nearing a major
release (rc3 came out just today, I will be adding an ebuild for it
tonight after I'm back from work).
Kind regards,
--
Andrej Kacian
--
gento...@gentoo.org mailing list
Robert Cernansky
> sounds like you might want to have a look at http://musicpd.org - in
> portage as media-sound/mpd or media-sound/mpd-svn.
Thank You for the tip. I looked at mpd also (only on web page). It
have probably good posibility to control it via command line. But what
about xosd support? (Which I mention in my previous post.) I do not
see any info on page about it.
What bothers me also, is that it has not plugin design like
xmms. Support for plugins is very good because lot of people can write
plugins for lot of things. This is why people do not want to switch
from xmms because thanks to plugins it have so many features that
currently no player is able to overcome it.
Also I read that it is not possible to play file without addind it to
mpd's database.(?) It seems to be clumsy.
Can it play streams from internet? Maybe I should install it and look
at it more closely.
Adriaan Leijnse
Greets,
Aidy
2006/8/24, Robert Cernansky <hsli...@zoznam.sk>:
--
gento...@gentoo.org mailing list
Andrej Kacian
On Thu, 24 Aug 2006 18:42:27 +0200
Robert Cernansky <hsli...@zoznam.sk> wrote:
> Thank You for the tip. I looked at mpd also (only on web page). It
> have probably good posibility to control it via command line. But what
> about xosd support? (Which I mention in my previous post.) I do not
> see any info on page about it.
mpd (and xmms2) is just a server that is responsible for music playback,
functionality such as xosd notification can be provided by clients, one
such example is here[1]. Perhaps there are more.
> What bothers me also, is that it has not plugin design like
> xmms. Support for plugins is very good because lot of people can write
> plugins for lot of things. This is why people do not want to switch
> from xmms because thanks to plugins it have so many features that
> currently no player is able to overcome it.
That is true, but if you split the media player functionality between
server and client, server doesn't need many plugins - it only needs to
support as many media types as possible.
Many xmms plugins I saw are frontend-related. This can be handled by
MPD clients. One of main clients, gmpc, recently added plugin support,
and already plugins for album covers or song lyrics are available.
> Also I read that it is not possible to play file without addind it to
> mpd's database.(?) It seems to be clumsy.
This is mainly because mpd is designed to run remotely, i.e. not on
your desktop - clients connect via TCP, so they have no idea about the
filesystem on box where mpd runs.
There are plans to allow this exact functionality via URIs in
format: "file://".
> Can it play streams from internet? Maybe I should install it and look
> at it more closely.
Yes, and what's more, the development version (release candidates too)
is also able to act as an icecast source, thus mpd+icecast2 can act as
a streaming server. I'm usually listening to music streamed from my
home box via an openvpn tunnel at work. :)
Also, mpd has gapless output by default, iirc.
1. http://www.musicpd.org/forum/index.php?topic=1189
--
Andrej
--
gento...@gentoo.org mailing list
Alec Warner
>
> What bothers me also, is that it has not plugin design like
> xmms. Support for plugins is very good because lot of people can write
> plugins for lot of things. This is why people do not want to switch
> from xmms because thanks to plugins it have so many features that
> currently no player is able to overcome it.
So port the plugins from xmms to $NEW_CLIENT, since xmms is an old piece
of crap.
>
> Also I read that it is not possible to play file without addind it to
> mpd's database.(?) It seems to be clumsy.
>
> Can it play streams from internet? Maybe I should install it and look
> at it more closely.
>
> Robert
>
>
--
gento...@gentoo.org mailing list
Stephen P. Becker
>
> there is work in improving ffmp3 in order to ditch mad, that has issues
> with mips iirc)
Well, it depends on your definition of help. I'd be perfectly happy to
provide some hardware for interested developers (I have a couple indys
that I'm willing to donate to anyone willing to help with sound
development). As for writing any code to try and fix these issues, I'm
not capable of providing that sort of help.
Luca Barbato
> Luca Barbato wrote:
>> Luis Medinas wrote:
>>
>>> If noone takes it will be saved on overlays.gentoo.org. Everyone needs
>>> to know that xmms is old and tired (obsolete). A few developers on
>>> redhat, mandriva and suse marked xmms as obsolete. Now it's our turn to
>>> move it to our darkness repository. If you want to be sure it's obsolete
>>> just read xmms's website.
>>>
>>
>> fine for me
>>
>> (please add xmms2)
>>
>> People could just use mplayer o xine to play any audio sample aud
>> doesn't.
>>
>> lu
>>
>
> Note that neither mplayer or xine work on mips particularly well. Xine
Could you please help us fixing it on mips? (in particular currently
there is work in improving ffmp3 in order to ditch mad, that has issues
with mips iirc)
lu
Ciaran McCreesh
<geo...@gentoo.org> wrote:
| I have a couple indys that I'm willing to donate to anyone willing to
| help with sound development
What happened to the one you sent to Jeremy? Wasn't he supposed to be
doing sound things for mips?
--
Ciaran McCreesh
Mail : ciaran dot mccreesh at blueyonder.co.uk
--
gento...@gentoo.org mailing list
Luca Barbato
>
> It is aqualung that is a very good player with nice features such as
> oss, alsa, jack and LADSPA support. It have a database support to help
> to organise yours audio files.
>
> http://aqualung.sourceforge.net/
>
Uses libmad -> no go =/
Luca Barbato
> Well, it depends on your definition of help.
Testing recent snapshots or providing shells would be perfectly fine.
Duncan
Mahogany-0.67.0-1067...@kihnet.sk, excerpted below, on
Thu, 24 Aug 2006 14:31:25 +0200:
> On Thu, 24 Aug 2006 20:39:10 +1000 Jonathan Adamczewski
> <jada...@utas.edu.au> wrote:
>
>> Robin H. Johnson wrote:
>> > don't take XMMS away from those of us already using it without any
>> > issues.
>>
>> It can disappear from portage without affecting your ability to keep
>> using it.
>
> Not true, when upgrading world I'll always get message like:
>
> !!! Ebuilds for the following packages are either all !!! masked or don't
> exist:
> media-sound/xmms
>
> And --depclean will be broken because it will want to remove all xmms
> dependencies. Maybe there are other issues with installed¬_in_portage
> packages.
That's what overlays (local or public/general) are for. There's normally
a 30-day period the ebuild is masked, during which that warning will
appear with the 30-day explanation from profiles/package.mask, giving you
the chance to act accordingly and move it to your overlay, listing it in
package.unmask. When the 30 days is over and it's removed from portage,
you still have it in your overlay.
Even if you don't sync and update during those 30 days and the ebuild is
removed from the tree, given that it's installed, you'll still have an
ebuild for it in /var/db/pkg/, and if you use FEATURES=buildpkg (as I do)
for backup purposes, you'll also have the ebuild attached to the end of
the binpkg tarball. (I used that a couple times before I realized the
ebuild was already in /var/db/pkg.)
Even if you lose your local copies, the ebuild will still be available
from Gentoo's viewCVS for some time, where it can be retrieved from the
attic.
All that said, I too use xmms as I've yet to find anything else as simple
and reliable that continues to "just work". It's very possibly the only
thing I have merged here still using gtk1, but while that means getting
rid of it would mean I'd be able to unmerge gtk1, it also means there's
little else that could break it or that it could break, thru the common
gtk1 dependencies, now. I'd very much like it to continue working for
years yet.
/That/ said, there remains the reality of a now unmaintained gtk1, making
it harder and harder for Gentoo to continue to support thru successive
toolchain update iterations. If no one's willing to continue to maintain
xmms /and/ ultimately gtk1... it will of necessity eventually die.
When it dies in Gentoo, while users can maintain it in their overlays for
months, the clock is seriously ticking, as more and more incompatibilities
between it and a kept-current system pile up.
... Personally, I'm hoping xmms will remain at least until KDE4 comes
around, with hopefully something there more workable than the KDE3 and
other solutions I've tried -- but kept returning to xmms, because it "just
worked", and didn't require undue resources to do it. Getting arts out of
the way as the main KDE audio framework will be a big part of that.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
gento...@gentoo.org mailing list
Stephen P. Becker
> On Thu, 24 Aug 2006 15:48:41 -0400 "Stephen P. Becker"
> <geo...@gentoo.org> wrote:
> | I have a couple indys that I'm willing to donate to anyone willing to
> | help with sound development
>
> What happened to the one you sent to Jeremy? Wasn't he supposed to be
> doing sound things for mips?
>
Apparently a 50 pin scsi hard disk was "too hard" to find and nfsroot
was too much bother.
Robert Cernansky
> On Thu, 24 Aug 2006 18:42:27 +0200
> Robert Cernansky <hsli...@zoznam.sk> wrote:
[...]
> mpd (and xmms2) is just a server that is responsible for music playback,
> functionality such as xosd notification can be provided by clients, one
[...]
> Many xmms plugins I saw are frontend-related. This can be handled by
> MPD clients. One of main clients, gmpc, recently added plugin support,
> and already plugins for album covers or song lyrics are available.
[...]
> > Also I read that it is not possible to play file without addind it to
> > mpd's database.(?) It seems to be clumsy.
>
> This is mainly because mpd is designed to run remotely, i.e. not on
> your desktop - clients connect via TCP, so they have no idea about the
> filesystem on box where mpd runs.
>
> There are plans to allow this exact functionality via URIs in
> format: "file://".
So, I've tried mpd plus mpc, gmpc, glurp and kmp clients. I must say
I don't like it. _Mainly_ because that database thing - sorry but the
playlist management is worse than I expected. I want simply _freely_
browse my filesystem, pickup an .m3u file and play it.
I find it very limiting that I cannot play file from any
location. That I have to copy it to "music" directory and rebuild the
database. What about removable media?
Another big disadvantage is that it cannot play Audio CD's.
Behavior in multi-user environment is also bad. There is only one
daemon, so imagine that I'll take a break from my work, pause the
player, lock my screen and go to pub for an hour. Another user can log
in and work, and listen the music. But he will have loaded same
playlist, paused as I left it. So he loads its own and listen, but it
will break also my player status and when I return, I'll find his
playlist in my player.
Sure, it can be solved by running separate instance of mpd by user but
then it is too complicated way just to play music.
In general, I thing there is no really good client for mpd. I can
imagine that it is possible to start mpd by client, transparently for
user. That this database disadvantages can be hidden by a client so
work with files will be easy and straightforward like in xmms. That it
will have plugin support and more features so things like xosd, handy
disk-writer plugin, effect plugins, tag editing,... will not be
missed.
Many features are planned, but it takes time to get into real life.
Btw, something like effect plugin (for example voice removal) belongs
to server or client?
> Also, mpd has gapless output by default, iirc.
It does not wor for me, gaps are there. I only found Crossfade option
in kmp client.
Robert Cernansky
> Robert Cernansky wrote:
> >
> > What bothers me also, is that it has not plugin design like
> > xmms. Support for plugins is very good because lot of people can
> > write plugins for lot of things. This is why people do not want to
> > switch from xmms because thanks to plugins it have so many
> > features that currently no player is able to overcome it.
>
> So port the plugins from xmms to $NEW_CLIENT, since xmms is an old
> piece of crap.
This would be too time consumig player switch. ;-)
Christian Birchinger
> Unfortunatelly this is something different. xmm-pipe lets you control
> running xmms from commandline (thus binding these commands to
> keys). It allows control volume, skipping in current track (fast
> forward), do some playlist actions and lot more.
Isn't this what the included "audtool" command is for? I use it
for windowmanager hotkeys. "audtool help" shows that it has lots
of options.
Christian
--
gento...@gentoo.org mailing list
Steve Dibb
matter? The list traffic seems to be dying down. Maybe I just missed
the final decision email.
Not that it really matters, but here's my 2 cents:
If its a pita to maintain, hard mask everything and just say "sorry, no
bugs fixie unless you want to maintain it. See
http://dev.g.o/~foo/xmms.html for reasons" At least that way it will
still be in the tree for those that want to use it.
The second thing is, why does it even matter if its out of the tree or
not? Those who are currently using it will still have it installed on
their system, anyway. I'm still using audacious 0.2.3 even though it's
been taken out, and I won't upgrade until my favorite plugin is ported.
I'm fine with that.
Anyway, whatever. Do what works best. :)
Steve
--
gento...@gentoo.org mailing list
Duncan
below, on Fri, 25 Aug 2006 11:20:52 -0600:
> So, I'm curious -- did anyone ever come to a decision what to do on the
> matter? The list traffic seems to be dying down. Maybe I just missed
> the final decision email.
Well, no one has volunteered to take over maintainership, so it would
appear to be heading toward orphaned package status. While that doesn't
mean immediate removal from the tree, it will eventually as bugs begin to
build up, and with a package such as this, they will probably build up to
the point they get the attention of tree cleaners relatively fast...
Overlay was suggested. I imagine if no one takes over maintainership and
it gets pulled from the tree, sunrise might end up with it. It's fairly
likely some user would be interested in it enough to try it there, altho
as complex and old as it is, how successful they might be is open to
question.
Alec Warner
++
I don't see how whining about a package you don't maintain, nor helping
out with it helps anyone. Either it stays in pmask, or it stays in
sunrise (since I would bet 5 bucks it ends up in sunrise after getting
punted). The sound team has been very courteous in informing the
community on the matters pertaining to xmms, so either someone picks up
the slack for it, or the affected users (developers and arch teams
included) find another player.
I don't see why sound should break their backs just so everyone can have
their cake.
It reminds me of the whole "why isn't X,Y,Z stable!". You are an
empowered smart user, I think you can figure out how to keep a package
that is not in the tree installed on your systems.
-Alec Warner
--
gento...@gentoo.org mailing list
Luis Medinas
> I don't see how whining about a package you don't maintain, nor helping
> out with it helps anyone. Either it stays in pmask, or it stays in
> sunrise (since I would bet 5 bucks it ends up in sunrise after getting
> punted). The sound team has been very courteous in informing the
> community on the matters pertaining to xmms, so either someone picks up
> the slack for it, or the affected users (developers and arch teams
> included) find another player.
>
> I don't see why sound should break their backs just so everyone can have
> their cake.
>
> It reminds me of the whole "why isn't X,Y,Z stable!". You are an
> empowered smart user, I think you can figure out how to keep a package
> that is not in the tree installed on your systems.
>
xmms there. This is a solution that prevents users to turn their back
from us. So xmms will only be used in special cases when someone looks
to play something other players don't play.
We will keep the future in mind like "we need to inovate" and put xmms2
in the tree.
--
Gentoo Linux Developer
http://dev.gentoo.org/~metalgod
--
gento...@gentoo.org mailing list
Paul de Vrieze
> Robert Cernansky wrote:
> > What bothers me also, is that it has not plugin design like
> > xmms. Support for plugins is very good because lot of people can write
> > plugins for lot of things. This is why people do not want to switch
> > from xmms because thanks to plugins it have so many features that
> > currently no player is able to overcome it.
>
> So port the plugins from xmms to $NEW_CLIENT, since xmms is an old piece
> of crap.
Who cares. It works (mostly), it is lightweight, and there are enough people
using it to keep it in the tree. As long as things don't break beyond repair
I see no reason whatsoever to remove xmms (or any other largely unmaintained
package in the tree).
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: pau...@gentoo.org
Homepage: http://www.devrieze.net
Alec Warner
> On Thursday 24 August 2006 20:46, Alec Warner wrote:
>> Robert Cernansky wrote:
>>> What bothers me also, is that it has not plugin design like
>>> xmms. Support for plugins is very good because lot of people can write
>>> plugins for lot of things. This is why people do not want to switch
>>> from xmms because thanks to plugins it have so many features that
>>> currently no player is able to overcome it.
>> So port the plugins from xmms to $NEW_CLIENT, since xmms is an old piece
>> of crap.
>
> Who cares. It works (mostly), it is lightweight, and there are enough people
> using it to keep it in the tree. As long as things don't break beyond repair
> I see no reason whatsoever to remove xmms (or any other largely unmaintained
> package in the tree).
>
> Paul
>
This is one of those things (along with qa and security) that the
community needs to decide. Does stuff that works but has terrible qa
stay in the tree? Does security stuff stay in the tree, but masked?
Should xmms be masked? We have no real way of "deprecating" a package,
aside from leaving it in the tree with a masking reason saying
"deprecated and unsupported." at which point not everything in the tree
becomes supported.
The Treecleaner project that I run is based on the assumption that
broken stuff in the tree is bad, and I try to remove the really old stuf
broken stuff first. However I aspire to eventually "catch up" and get
to the currently broken packages. So which way will you have it? Or is
this more of a pragmatic stance on the tree?
--
gento...@gentoo.org mailing list