Subject: Audacious plugin broken on Audacious 1.4.6

From: shd
Date: Thu Apr 24 16:42:16 2008

To: UADE-Developer-discussion
I just found out that the Audacious plugin is broken for Audacious 1.4.x and 1.5.0. I don't use Audacious, but I would very much like to have this fixed as soon as possible. &lt;hopeful&gt;Anybody able or wanting to fix this?&lt;/hopeful&gt;

---

From: Baldrun
Date: Thu May 15 22:19:58 2008

To: UADE-Developer-discussion
I totally agree. The audacious plugin for 1.4.6 or 1.5.0 doesn't work for me either. And since there is no XMMS in gentoo portage anymore I would prefer using audacious. Unfortunately I am not a developer. Someone please fix this. Thanks a lot in advance.

---

From: alankila
Date: Tue May 20 09:41:41 2008

To: UADE-Developer-discussion
It seems to me that sndfile plugin (wav playback, I suppose) is also broken, as this doesn't work. I guess someone has fucked audacious file format detection up pretty badly.

---

From: alankila
Date: Tue May 20 10:00:54 2008

To: UADE-Developer-discussion
I solved the problem. It seems that the UADE plugin is faultless, but to get this whole thing to work you have to:

- uncheck the checkbox &quot;Detect file type by extension&quot; or whatever you have in your potentially localized audacious. This option is illogically in the &quot;Audio&quot; section. (I think it belongs to the playlist tab.)

- in the plug-in tab, disable &quot;Monkey's Audio&quot; if you have it. Audacious with this plugin enabled is unable to do anything at all in my case; it doesn't play anything, just sits there.

It is a pity that audacious sucks a bit. It would be good player otherwise, but it has these self-destructive habits like bad defaults, and surprisingly messy configuration. I submit that getting rid of bad plugins is to mercilessly expose your users to crashes and related problems, until each and every bad plugin gets fixed.

---

From: alankila
Date: Tue May 20 10:36:17 2008

To: UADE-Developer-discussion
Okay. So I tested around some more and came across this:

% audacious uade:cust.GravityForce

results in audacious sending this URL for the UADE plugin to handle:

Unable to read from file:////home/alankila/Musiikki/mod/chip/cust/GravityForce/uade:cust.GravityForce, giving up.

Sheesh. audacious is really going to hell lately. All the fine code (Actually, it's pretty insane but that's because audacious interface seems to be a moving target.) in the UADE plugin trying to handle these URLs is unable to detect this particular case, because no way in hell are you supposed to look for uade: after the directory name. That's just plain insane, but could be fixed easily enough.

Unfortunately, uade:/foo also &quot;works&quot;, detects the plugin should be uade, but causes opening of file:///$PWD/uade:/foo. This is unpleasant to handle, because you are supposed to throw away the whole path before the &quot;uade:&quot;... Audacious just plainly shouldn't generate this kind of URLs.

What is even worse, uade:///foo is not recognized at all as special syntax. Tries to open a file by this name. A bit questionable interpretation, perhaps, but fair enough. It's just that URL syntax might make someone try uade://$PWD/foo, and expect it to work... I see no reason to limit the number of accepted slashes to just one, really.

The other problem is that the file:// URLs generated by audacious have one extra slash. As far as I know, file:/// is the correct amount. The host name slot between the 2nd and 3rd / is left empty, and the 3rd slash indicates the directory root. However, 4 /s indicate that there is more thoughtless bugs lurking in audacious.

---

From: alankila
Date: Tue May 20 11:16:39 2008

To: UADE-Developer-discussion
Retraction: I wish to retract the contents of the above post. It looks like the UADE plugin system abuses the notion that audacious supports URLs as file syntax. &quot;audacious uade:foo&quot; is never supposed to work.

This was my error, and the confusion resulted from UADE plugin sending nice debug telling that it failed to open that file, when all other plugins silently failed to open the file, although we can rest assured they all tried.

So how it goes is roughly follows:

1) user execs &quot;audacious uade://$whatever&quot; # or xxx://yyy, it doesn't matter

2) all audacious plugins fail to handle this &quot;uade&quot; transport protocol, so they are forced to give up, not finding a file. Most probably try to open a file including that &quot;uade://&quot; path, but this is a guess, I haven't read the souce.

3) uade plugin magically knows about the uade:// prefix and always removes it. By removing it, it obtains a valid path, and can play the file.

This is &quot;uade://&quot; thing is, in other words, pure hack. Maybe audacious has no facility at all to force a particular plugin to eat a file.

---

From: alankila
Date: Wed May 21 07:42:31 2008

To: UADE-Developer-discussion
For some stupid reason I can't get the sources for audacious from the Debian repository at the moment, but it looks like the reason this uade:// thing doesn't work is that it actually doesn't call the uade plugin any more.

I guess it's either because the protocol &quot;uade&quot; can't be figured out, or maybe it stats that no such file exists and doesn't bother with letting plugins to try.

*sigh* I guess I thought UADE plugin was emitting that error because of the stupid reason that there is &quot;uade&quot; on the error string. I should get my head examined. I found a similarly worded warning in UADE but I guess I did not notice that the wording was not the same for some reason.

Now that this is broken, something should be done to the audacious plugin architecture and/or UADE. Many Amiga files seem to incorrectly go to the MAD mpeg plugin because it apparently thinks it can play many a bitstream, yet disabling the whole mpeg plugin probably kills mp3 playback, so that approach is a nonstarter for most people.

The preferences window apparently allows moving plugins up and down in the list. Does this mean that a plugin higher up is tried first? Either way, it doesn't seem to save this ordering, so it's practically a worthless feature until this is fixed.

Here's my idea: Maybe good plugin architectures should include not only &quot;can I play this file&quot; boolean but also &quot;what is my confidence in having detected the format correctly&quot;, so that a large array of plugins would have higher chance of interacting correctly. Plugins are allowed to answer with full confidence only if they detect appropriate magic numbers and other format metadata that unambiguously identifies the file. However, if any random bitstream could still conceivably be decoded by the plugin, then it should respond with less confidence for those files and let others also vote.

This is the sort of change that I should take up with audacious guys. They have had the foresight to declare the &quot;is_our_file&quot; hook as returning an integer, and while the test today is &quot;result &gt; 0&quot; for acceptance, one could extend this rather easily to tristate boolean or some other way.