(In reply to comment #0)
> Description of problem:
> On startup, the following message is displayed:
> W: 3087824576 10:45:42 No decoders found! Fingerprinting will be disabled.
>
> It sounds like this major is nonfunctional, though all the libraries seem to be
> in place
>
> Version-Release number of selected component (if applicable):
> picard-0.11-2.fc10.i386
> libofa-0.9.3-13.fc9.i386
> fftw-3.1.2-7.fc10.i386
> libdiscid-0.2.2-1.fc10.i386
> python-mutagen-1.13-2.fc9.noarch
> python-2.5.2-1.fc10.i386
Fingerprinting relies on the ffmpeg library which can't be included in Fedora because of patent reasons associated with the mp3 decoder (amongst others), see:
https://fedoraproject.org/wiki/ForbiddenItems#MP3_Support
picard used to provide a gstreamer backend that enabled the various gstreamer-plugins-{bad,ugly} to be used to read the audio data, which could be easily gotten from livna/freshrpms (now RPM Fusion). Unfortunately upstream decided to remove the gstreamer support and rely on ffmpeg completely. I filed a bug on this upstream:
http://bugs.musicbrainz.org/ticket/3428
but upstream is unwilling to support gstreamer anymore and the ffmpeg developers have a monolithic library that isn't amenable to splitting up like gstreamer.
One solution is to move picard entirely to RPM Fusion, which I'm reluctant to do, since picard under Fedora is functional in every other respect, the other is to create a picard-ffmpeg only RPM Fusion that supplies the missing binary component. The annoying part of that would be creating an SRPM that compiles the optiona ffmpeg bits on Fedora and RPM Fusion and keeping them sychronised (assuming this would actually work!). Anyone willing to volunteer their time to help co-maintain picard, especially maintain the RPM Fusion subpackage would be welcome.

Created attachment 327912[details]
Patch for setup.py to remove -DUSE_OLD_FFMPEG_LOCATIONS
Thanks for the info Alex. I'd already had ffmpeg-devel (from atrpms.net) installed, so I just needed to rebuild picard from the src.rpm. It's now fingerprinting and tagging like gangbusters.
I created the attached patch to remove the hardcoded "-DUSE_OLD_FFMPEG_LOCATIONS" in setup.py. It would be nice if upstream imported that behaviour from the environment so packagers could dynamically set rather than patching. Then I hacked picard.spec in the obvious way:
--- picard.spec_old 2008-12-28 22:33:53.000000000 -0700
+++ picard.spec 2008-12-28 22:05:12.000000000 -0700
@@ -3,7 +3,7 @@
Name: picard
Version: 0.11
-Release: 2%{?dist}
+Release: 3rda%{?dist}
Summary: MusicBrainz-based audio tagger
Group: Applications/Multimedia
@@ -30,6 +30,8 @@
#Source18: http://users.musicbrainz.org/~brianfreud/SearchSoundtrackCollector3.py
#Source19: http://users.musicbrainz.org/~brianfreud/SearchSoundtrackINFO3.py
+Patch0: %{name}-0.11-avsetup.patch
+
License: GPLv2+
Url: http://musicbrainz.org/doc/PicardTagger
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -51,6 +53,7 @@
%prep
%setup -q -n picard-%{version}
+%patch0 -p0
%build
env %{__python} setup.py config
-----------------------------------------
Comparing the sizes of all the files for the pure vs. ffmpeg builds, and the only difference is that the ffmpeg build creates:
/usr/lib/python2.5/site-packages/picard/musicdns/avcodec.so
It would be easy to build on a system with ffmpeg and generate two different packages. Purists could just pull picard and not picard-ffmpeg. Is this a possibility, or would you submit separate builds to fedora and rpm-fusion?
Another option is to have users pull the src.rpm and rebuild it with ffmpeg-devel installed on their system. Messy, if they don't already have a system configured for development.
Thanks for your help, Alex!

(In reply to comment #2)
> Created an attachment (id=327912) [details]
> Patch for setup.py to remove -DUSE_OLD_FFMPEG_LOCATIONS
>
> Thanks for the info Alex. I'd already had ffmpeg-devel (from atrpms.net)
> installed, so I just needed to rebuild picard from the src.rpm. It's now
> fingerprinting and tagging like gangbusters.
>
> I created the attached patch to remove the hardcoded
> "-DUSE_OLD_FFMPEG_LOCATIONS" in setup.py. It would be nice if upstream
> imported that behaviour from the environment so packagers could dynamically set
> rather than patching. Then I hacked picard.spec in the obvious way:
Thanks for the patch, although I'm still not 100% clear as to why it is necessary, can you explain a bit?
> Comparing the sizes of all the files for the pure vs. ffmpeg builds, and the
> only difference is that the ffmpeg build creates:
> /usr/lib/python2.5/site-packages/picard/musicdns/avcodec.so
Right, and I figured that it would probably be a single library that would be necessary, although I hadn't got around to trying it.
> It would be easy to build on a system with ffmpeg and generate two different
> packages. Purists could just pull picard and not picard-ffmpeg. Is this a
> possibility, or would you submit separate builds to fedora and rpm-fusion?
The latter as ffmpeg is only in RPM Fusion and (by design) unavailable to the Fedora build system. Basically how I see it working is that I would have to commit a single spec file to both Fedora and RPM Fusion build systems with a %define statement that would toggle whether building for Fedora or RPM Fusion. On the Fedora side, I would set the define for Fedora, recommit and kick off a build which would generate the picard package, then on the RPM Fusion side, change the %define kick off a build that would generate only picard-ffmpeg. The co-ordinate the simultaneous release of the new package via bodhi on Fedora and plague on RPM Fusion.
Messy, but do-able in principle. If you were willing to work on a conditionalised spec file (don't have time right now), I could look into the RPM Fusion angle (although we should probably move that discussion to the RPM Fusion bug tracker).
> Another option is to have users pull the src.rpm and rebuild it with
> ffmpeg-devel installed on their system. Messy, if they don't already have a
> system configured for development.
Right, but a flag could be used to supply directly to rpmbuild, although I favour the above option, if it can be done without too much hassle.

> Thanks for the patch, although I'm still not 100% clear as to why it is
> necessary, can you explain a bit?
Apparently the ffmpeg library now installs the includes at:
/usr/include/libavformat/avformat.h
/usr/include/libavcodec/avcodec.h
They used to be lumped into /usr/include. I'm using (atrpms.net):
ffmpeg-devel-0.4.9-28_r15845.fc10.i386
ffmpeg-0.4.9-28_r15845.fc10.i386
There's a bit of code in picard/musicdns/avcodec.c
27 #ifdef USE_OLD_FFMPEG_LOCATIONS
28 #include <avcodec.h>
29 #include <avformat.h>
30 #else
31 #include <libavcodec/avcodec.h>
32 #include <libavformat/avformat.h>
33 #endif
Nice, looks like I should just be able to not define this, but setup.py has:
cfg.set('avcodec', 'cflags', cfg.get('avcodec', 'cflags') +
' -DUSE_OLD_FFMPEG_LOCATIONS')
That sort of hard-codes in the flag. So I hard-coded it out. I believe there is (or could be) a way to re-assert it externally without a patch if needed. This may no longer be an issue for f10 packages .. I don't know when ffmpeg changed the install locations of the include files.
> On the Fedora side, I would set the define for Fedora, recommit and kick off a
> build which would generate the picard package, then on the RPM Fusion side,
> change the %define kick off a build that would generate only picard-ffmpeg.
It almost seems like it should be possible to have single src.rpm "just work". Toss it at fedora, you just get picard. Toss it at rpmfusion enabled with ffmpeg and you get both packages. Like the way a library src.rpm generates both the primary and devel package, the same type of trick might work here. The main thing is to ensure that non-generation of the -ffmpeg package isn't construed as an error by the fedora build system.
I could probably take a look at this in a week or so; It would be a learning experience. But don't feel that you have to wait on me.

(In reply to comment #4)
> That sort of hard-codes in the flag. So I hard-coded it out. I believe there
> is (or could be) a way to re-assert it externally without a patch if needed.
> This may no longer be an issue for f10 packages .. I don't know when ffmpeg
> changed the install locations of the include files.
OK.
> > On the Fedora side, I would set the define for Fedora, recommit and kick off a
> > build which would generate the picard package, then on the RPM Fusion side,
> > change the %define kick off a build that would generate only picard-ffmpeg. > It almost seems like it should be possible to have single src.rpm "just work".
> Toss it at fedora, you just get picard. Toss it at rpmfusion enabled with
> ffmpeg and you get both packages. Like the way a library src.rpm generates
> both the primary and devel package, the same type of trick might work here.
> The main thing is to ensure that non-generation of the -ffmpeg package isn't
> construed as an error by the fedora build system.
That's the basic idea to have a primary "picard" and a subpackage "picard-ffmpeg" but only one on each build system. However, since the .spec file generates the SRPM, and Fedora and RPM Fusion both work off .spec files checked into CVS not SRPMs, the same .spec file would be checked in on both. If there is a reliable variable available on the build systems distinguishing itself, then the .spec file can take advantage of that, otherwise you would have to set the variable separately in each .spec.