search

mixxxdj / mixxx

Mixxx is Free DJ software that gives you everything you need to perform live mixes.
http://mixxx.org
Other
4.41k stars 1.26k forks source link

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

Closed mixxxbot closed 2 years ago

mixxxbot commented 2 years ago

Reported by: Pegasus-RPG Date: 2010-06-28T08:21:42Z Status: Fix Released Importance: Critical Launchpad Issue: lp599267 Tags: library, m4a

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.

mixxxbot commented 2 years ago

Commented by: Pegasus-RPG Date: 2010-06-28T08:22:44Z

This happens on Windows, 1.8 branch r2450.

mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-06-28T08:34:40Z

Linux as well.

On Mon, Jun 28, 2010 at 4:22 AM, Pegasus

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.

mixxxbot commented 2 years ago

Commented by: rryan Date: 2010-09-09T06:33:20Z

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.

mixxxbot commented 2 years ago

Commented by: abellina Date: 2010-11-29T03:33:11Z

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?

mixxxbot commented 2 years ago

Commented by: abellina Date: 2010-11-29T13:02:34Z

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.

mixxxbot commented 2 years ago

Commented by: bkgood Date: 2011-01-02T01:19:46Z

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.

mixxxbot commented 2 years ago

Commented by: asantoni Date: 2011-01-02T06:32:18Z

On Sat, Jan 1, 2011 at 8:19 PM, Bill Good

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

mixxxbot commented 2 years ago

Commented by: asantoni Date: 2011-01-02T06:34:35Z

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

On Sat, Jan 1, 2011 at 8:19 PM, Bill Good

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

mixxxbot commented 2 years ago

Commented by: bkgood Date: 2011-03-05T07:57:57Z

fixed in lp:mixxx/1.9 r2747

mixxxbot commented 2 years ago

Issue closed with status Fix Released.