Arch Linux

Output from the console seems fairly normal, but I don't know how to monitor what's happening behind the scenes when I execute it via Streamtuner:


Failed to load plugin (/usr/lib/audacious/Visualization/projectm.so): libprojectM.so.0: cannot open shared object file: No such file or directory
amidi-plug(amidi-plug.c:amidiplug_init:97): init, read configuration
amidi-plug(i_backend.c:i_backend_load:107): loading backend '/usr/lib/audacious/Input/amidi-plug/ap-alsa.so'
amidi-plug(i_backend.c:i_backend_load:145): backend /usr/lib/audacious/Input/amidi-plug/ap-alsa.so (name 'alsa') successfully loaded

Upon closing, it simply says:

amidi-plug(i_backend.c:i_backend_unload:164): unloading backend 'alsa'
amidi-plug(i_backend.c:i_backend_unload:167): backend 'alsa' unloaded

I encounter the same problem with audacious.

The only way of getting Audacious to work if a stream is executed by Streamtuner is to first start Audacious and only after that select a stream in Streamtuner. Otherwise Audacious might just flicker for less than a second, or not show any GUI at all, but in both cases cause a 100 % CPU load (interestingly enough it loads both cores of a dual-core). Usually there's no other way to kill the audacious process but to reboot the whole system.

I use XFCE. I've enabled core, extra and community. All packages are updated to the latest. Only application showing errors at the moment is Audacious.

This applies to the same versions of audacious-player and audacious-plugins as described by Thayer.

If executed from command I've get the following:

[kimolee@kimtjik ~]$ streamtuner
Failed to load plugin (/usr/lib/audacious/Visualization/projectm.so): libprojectM.so.0: kan inte öppna delad objektfil: Filen eller katalogen finns inte (in english: No such file or directory)
amidi-plug(amidi-plug.c:amidiplug_init:97): init, read configuration
amidi-plug(i_backend.c:i_backend_load:107): loading backend '/usr/lib/audacious/Input/amidi-plug/ap-alsa.so'
amidi-plug(i_backend.c:i_backend_load:145): backend /usr/lib/audacious/Input/amidi-plug/ap-alsa.so (name 'alsa') successfully loaded

(audacious:10974): GLib-CRITICAL **: g_hash_table_foreach: assertion `hash_table != NULL' failed

Hence my experience it very similar to Thayer's.

I've attached some screenshots showing what happens to my player nearly every time I open it via streamtuner. Even though I have set the skin to the stock "Classic" skin, it reverts to this weird "default" skin when it opens. The preferences window colours are all borked too. I've tried deleting my personal configs for audacious, but it always comes back to this.

Interesting. I thought it was me doing something wrong, because audacious does the same on my system.

I think this may be an upstream issue. I've been testing some things and checking out the Audacious forums for similar cases.

I rebuilt both audacious packages myself to see if it made a difference (it doesn't). I also figured out that whenever audacious crashes, it wipes ~/.config/audacious/config at the same time, which is why it always reverts to the new Default skin.

FYI... to prevent the player from losing all its settings after a crash, do the following:

1. launch audacious and configure it to your liking
2. close audacious
3. remove write permissions to ~/.config/audacious/config

Now when it crashes you won't lose your skin and plugins preferences.

Not sure why it's doing this - I'm looking around trying to find a fix. If anyone sees any similar bug reports or threads elsewhere, please post links here - if anyone finds a patch, even better. ;)

Just uploaded the new audacious-player (1.4.2-1) and audacious-plugins (1.4.1-1) packages - can you check these to see if it's fixed?

Unfortunately not, at least on my system. I've set Streamtuner to load beep-media-player instead, which works flawlessly. I haven't found any clues or links yet.

Dang. Thanks for the test

I'm not seeing any better results, Travis. I removed ~/.config/audacious again just to be sure that nothing lingered from the previous version. It now locks up 100% of the time, whether launched from Streamtuner or on its own.

I'm running a pretty basic setup, all from the official repos: Openbox, networkmanager, gnome-keyring-daemon, glipper-old, trayer, conky, and xscreensaver. I can't figure out what this could be.

Thanks for the report Thayer - are you saying that Audacious now _never_ works for you, no matter how you try to launch it? That blows.

Unfortunately, yes that's what I'm saying... I don't know if the output is much help to you, but when I run audacious through strace I get an endless amount of data. I've pasted the truncated results here:

http://pastebin.archlinux.org/19931

In the meantime, I'm using Sonata =)

It seems determined to make a liar out of me. For kicks, I completely removed audacious (pacman -Rns), deleted all traces of it in /home, rebooted and then reinstalled the package. I launched it and it actually worked. It's even playing nice with streamtuner--crashing only once out of 10 or so tests. I don't know what to say.

Heh - software loves to make a liar out of everybody, especially when bugs appear.

New version uploaded shortly - let me know if it's still an issue please.

Hey Thayer - can you check with -player 1.4.6 and -plugins 1.4.5? Thanks

It seems to work okay for the most part. It still gets glitchy if you try to load a stream while another stream is establishing a connection with an already-open audacious. That may be an upstream issue though.

I haven't been using audacious or streamtuner for a while now as I've switched to ncmpc, so I can't say I've tested it thoroughly. I did a fresh install, opened streamtuner and started clicking on some SHOUTcast feeds. Everything seemed to work fine until I opened audacious for a stream that wasn't live anymore; trying to open any other stream after that caused the hang.

I'm going to say that this might not be a problem with the way we've packaged things, and close it as an upstream issue.