Bug 478354

Summary: No decoders found! Fingerprinting will be disabled
Product: [Fedora] Fedora Reporter: Bob Arendt <rda>
Component: picardAssignee: Alex Lancaster <alex>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: alex, benjavalero, jeff
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-02 21:27:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch for setup.py to remove -DUSE_OLD_FFMPEG_LOCATIONS none

Description Bob Arendt 2008-12-28 18:03:34 UTC
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


How reproducible:
Always

Steps to Reproduce:
/usr/bin/picard
  
Actual results:
Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
W: 3087824576 10:45:42 No decoders found! Fingerprinting will be disabled.

Gui comes up, the Lookup features seem to work.

Expected results:
Fingerprinting capability should be enabled.

Additional info:
All the dependencies for ofa appear to be satisfied:
ldd /usr/lib/python2.5/site-packages/picard/musicdns/ofa.so 
        linux-gate.so.1 =>  (0x00110000)
        libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x00113000)
        libofa.so.0 => /usr/lib/libofa.so.0 (0x00264000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x0027a000)
        libc.so.6 => /lib/libc.so.6 (0x00294000)
        libdl.so.2 => /lib/libdl.so.2 (0x00408000)
        libutil.so.1 => /lib/libutil.so.1 (0x0040d000)
        libm.so.6 => /lib/libm.so.6 (0x00411000)
        libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0x0043a000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x004d5000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x005c7000)
        /lib/ld-linux.so.2 (0x006fe000)

ldd /usr/lib/libofa.so.0
        linux-gate.so.1 =>  (0x00110000)
        libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0x05efe000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00cbe000)
        libm.so.6 => /lib/libm.so.6 (0x00899000)
        libc.so.6 => /lib/libc.so.6 (0x00723000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00c8d000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x008cb000)
        /lib/ld-linux.so.2 (0x006fe000)

Comment 1 Alex Lancaster 2008-12-28 22:24:07 UTC
(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.

Comment 2 Bob Arendt 2008-12-29 06:29:17 UTC
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!

Comment 3 Alex Lancaster 2008-12-29 06:51:03 UTC
(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.

Comment 4 Bob Arendt 2008-12-29 07:47:17 UTC
> 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.

Comment 5 Alex Lancaster 2008-12-29 09:27:27 UTC
(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.

Comment 6 Alex Lancaster 2009-01-02 21:27:07 UTC
Can't fix in Fedora, see: http://bugzilla.rpmfusion.org/show_bug.cgi?id=284