Headphones no longer honoring libraryscan and libraryscan_interval settings

[theguardian]

This seems to be a new bug introduced very recently.

With libraryscan = 0 and libraryscan_interval = 0 in the GUI and config.ini, it appears that library scan is happening automatically on startup and (apparently) every 24 hours.

I only perform library scans manually, so this results in a lot of unwanted CPU cycles.

[basilfx]

Can you confirm if you restart Headphones after saving?

[theguardian]

It's even more insidious. Library scan appears to be running on an infinite loop.

I saved the configuration and restarted - no change. Along with other recent bugs, it seems like the latest push wasn't quite ready for prime time.

[basilfx]

I'm working on a fix.

The other bugs were very specific and I have already committed some fixes :-)

[basilfx]

Just wondering, could it be that you have symlinks pointing to a path in the library scan folder?

See https://docs.python.org/2/library/os.html#os.walk.

[theguardian]

Nope - no symlinks in the library scan folder.

[basilfx]

I just committed ee3ccfa in the develop branch. The only place where I identified potential (infinite) recursion is the directory walking with following symlinks. It's the only thing that has changed since v0.4.

If you have the time, please test the develop branch. I included extra logging to pinpoint any problems:

Interval changes will reschedule the background tasks. It should yield logging like this (I clicked save multiple times in the log below):

13-nov-2014 02:30:25 - INFO :: CP Server Thread-4 : Writing configuration to file
13-nov-2014 02:30:25 - DEBUG :: CP Server Thread-4 : Current number of background tasks: 6
13-nov-2014 02:30:25 - INFO :: CP Server Thread-4 : (Re-)Scheduling background tasks
13-nov-2014 02:30:25 - DEBUG :: CP Server Thread-4 : Using the following server values: MBHost: 144.76.94.239, MBPort: 8181, Sleep Interval: 0
13-nov-2014 02:30:35 - INFO :: CP Server Thread-4 : Writing configuration to file
13-nov-2014 02:30:35 - DEBUG :: CP Server Thread-4 : Current number of background tasks: 6

Potential (infinite) recursion due to symlinks is logged like this:

13-nov-2014 02:22:02 - INFO :: CP Server Thread-4 : Writing configuration to file
13-nov-2014 02:22:02 - INFO :: Thread-12 : Scanning music directory: /Users/basilfx/Projecten/BasilFX/Headphones/music
13-nov-2014 02:22:02 - DEBUG :: Thread-12 : Skipping '/Users/basilfx/Projecten/BasilFX/Headphones/music/Folder' since it is a symlink to '/Users/basilfx/Projecten/BasilFX/Headphones/music', which is already visited.
13-nov-2014 02:22:02 - INFO :: Thread-12 : [/Users/basilfx/Projecten/BasilFX/Headphones/music] Now scanning subdirectory /XXX/AAA
13-nov-2014 02:22:02 - INFO :: Thread-12 : [/Users/basilfx/Projecten/BasilFX/Headphones/music] Now scanning subdirectory /YYY/BBB

The library scan task should start with:

13-nov-2014 02:22:02 - INFO :: Thread-12 : Scanning music directory: /Users/basilfx/Projecten/BasilFX/Headphones/music

and end with:

13-nov-2014 02:22:23 - INFO :: Thread-12 : Library scan complete

Any loop should that I could identify should repeat the Scanning music directory ... and Library scan completed messages, or should identify symlinks.

Please let me know if you can identify the problem with this. Thanks!

[basilfx]

I think I have been sleeping, but the original problem was as expected, since the code would allow one to schedule a library scan every 0 minutes :-P It seems this was always the case, even in < v0.5.

However, I modified the code to allow one to disable all tasks by setting the interval to zero. I think this should give more control. See commit 2601de5 for more information.

[theguardian]

I've been on master for over two years and it hasn't been a problem until the latest master update. I made sure that a libraryscan = 0 config value disabled library scanning back in #1259. Agree that interval values of zero should mean 'disable' across the board. Thanks for the fix!

[theguardian]

Looks good to me in the latest master. Closing.

[AdeHub]

Great work @basilfx getting the (minor!) issues resolved