Library Scanner does not detect existing files when new formats are supported.

[Sean M. Pappalardo]

With the SSM4A plugin built, after doing a library (re)scan, M4A files do not show up. They do, however appear in the Browse view just fine.

[Sean M. Pappalardo (pegasus-renegadetech)]

This happens on Windows, 1.8 branch r2450.

[RJ Skerry-Ryan (rryan)]

Linux as well.

On Mon, Jun 28, 2010 at 4:22 AM, Pegasus <email address hidden> wrote:

> This happens on Windows, 1.8 branch r2450.
>
> --
> M4A files don't show up in library with plugin
> https://bugs.launchpad.net/bugs/599267
> You received this bug notification because you are subscribed to Mixxx.
>

[RJ Skerry-Ryan (rryan)]

This doesn't happen for me anymore. I think the problem was I was not enabling the plugin properly. It has to be in ~/.mixxx/plugins/ and doesn't take anything in lin64_build/plugins/lin64_build/ unless you provide the pluginPath commandline parameter.

[Alessandro Bellina (abellina)]

It doesn't work for Mac OS X either. I tried it with the source for 1.8.1 and 1.8.0.

I first built everything with the m4a=1 flag. Running the executable wouldn't do it. Then I copied the m4a plugin folder (osx32_build/plugins/osx32_build/m4a) to ~/.mixxx/plugins/m4a and that didn't do it either. The files here are: libsoundsourcem4a.dylib, soundsource.os and soundsourcem4a.so.

Any ideas?

[Alessandro Bellina (abellina)]

I got it to work by copying the .dylib and .so's to the soundsource folder within the plugins folder. The files shouldn't be within the m4a folder.

[William Good (bkgood)]

I had the plugin working the other day on win32 (7) without issue. The biggest thing (well now that it actually seems to build again), as detailed in this bug, is the plugin either has to be in a path mixxx look for it in (see src/soundsourceproxy.cpp for those paths) or has to be in a path given to mixxx at runtime with --pluginPath dir/to/{dll|dylib|so}.

I'm not well read on the library or its scanner, it may be that if the scanner hits a file it doesn't know, it disregards it in future scans, which would explain why m4a's don't get imported but are there in browse, assuming you've got the plugin loaded one way or another. lp:mixxx/1.9 does have a list of all the plugins it's got loaded in the preferences as of a few revs ago, otherwise building with the debug console enabled does loads to determining if the plugin is being found and properly loaded (not that this is possible with the current build system afaict but *sigh*).

Regardless, I'm not too worried about the bug as the plugin is only slightly better than dead-in-the-water for all intents and purposes.

[Albert Santoni (gamegod)]

On Sat, Jan 1, 2011 at 8:19 PM, Bill Good <email address hidden> wrote:
> I had the plugin working the other day on win32 (7) without issue. The
> biggest thing (well now that it actually seems to build again), as
> detailed in this bug, is the plugin either has to be in a path mixxx
> look for it in (see src/soundsourceproxy.cpp for those paths) or has to
> be in a path given to mixxx at runtime with --pluginPath
> dir/to/{dll|dylib|so}.
>
> I'm not well read on the library or its scanner, it may be that if the
> scanner hits a file it doesn't know, it disregards it in future scans,
> which would explain why m4a's don't get imported but are there in
> browse, assuming you've got the plugin loaded one way or another.
> lp:mixxx/1.9 does have a list of all the plugins it's got loaded in the
> preferences as of a few revs ago, otherwise building with the debug
> console enabled does loads to determining if the plugin is being found
> and properly loaded (not that this is possible with the current build
> system afaict but *sigh*).

The library scanner doesn't remember disregarded files, but it does
remember a hash of the list of files in each directory. Since the list
of files hasn't changed, the hash is the same and so the library
scanner is probably just skipping over every directory because it
doesn't think there's any new files in there.

We should make the library scanner maybe use the supported file
extensions regex when it gets the directory listing. The QFileIterator
created on line 347 in LibraryScanner is where you'd make this change.
(Also see SoundSourceProxy::supportedFileExtensionsRegex(), which is a
static function.)

Thanks,
Albert

>
> Regardless, I'm not too worried about the bug as the plugin is only
> slightly better than dead-in-the-water for all intents and purposes.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/599267
>
> Title:
>  M4A files don't show up in library with plugin
>

[Albert Santoni (gamegod)]

Also, if I'm right, then this means that when we ship a version of
Mixxx that supports M4A, everyone will have this problem. We should
target this for 1.10 and make sure it gets fixed then.

On Sun, Jan 2, 2011 at 1:32 AM, Albert Santoni <email address hidden> wrote:
> On Sat, Jan 1, 2011 at 8:19 PM, Bill Good <email address hidden> wrote:
>> I had the plugin working the other day on win32 (7) without issue. The
>> biggest thing (well now that it actually seems to build again), as
>> detailed in this bug, is the plugin either has to be in a path mixxx
>> look for it in (see src/soundsourceproxy.cpp for those paths) or has to
>> be in a path given to mixxx at runtime with --pluginPath
>> dir/to/{dll|dylib|so}.
>>
>> I'm not well read on the library or its scanner, it may be that if the
>> scanner hits a file it doesn't know, it disregards it in future scans,
>> which would explain why m4a's don't get imported but are there in
>> browse, assuming you've got the plugin loaded one way or another.
>> lp:mixxx/1.9 does have a list of all the plugins it's got loaded in the
>> preferences as of a few revs ago, otherwise building with the debug
>> console enabled does loads to determining if the plugin is being found
>> and properly loaded (not that this is possible with the current build
>> system afaict but *sigh*).
>
> The library scanner doesn't remember disregarded files, but it does
> remember a hash of the list of files in each directory. Since the list
> of files hasn't changed, the hash is the same and so the library
> scanner is probably just skipping over every directory because it
> doesn't think there's any new files in there.
>
> We should make the library scanner maybe use the supported file
> extensions regex when it gets the directory listing. The QFileIterator
> created on line 347 in LibraryScanner is where you'd make this change.
> (Also see SoundSourceProxy::supportedFileExtensionsRegex(), which is a
> static function.)
>
> Thanks,
> Albert
>
>
>>
>> Regardless, I'm not too worried about the bug as the plugin is only
>> slightly better than dead-in-the-water for all intents and purposes.
>>
>> --
>> You received this bug notification because you are a member of Mixxx
>> Development Team, which is subscribed to Mixxx.
>> https://bugs.launchpad.net/bugs/599267
>>
>> Title:
>>  M4A files don't show up in library with plugin
>>
>

[William Good (bkgood)]

fixed in lp:mixxx/1.9 r2747

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5434