You are here: Home » Topic » CPU Usage Spike During File Scan

CPU Usage Spike During File Scan

This topic contains 4 replies, has 3 voices, and was last updated by  Anonymous 9 years, 6 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #2371

    Anonymous

    Hi,

    I’ve been running Firefly Server without any problems until this week. The music folder is located on a NAS disk, which I use as a back up to my main iTunes library, which is on an external drive.

    The problem started after I did my last back up. When Firefly goes through the file scan it reaches a certain point and the CPU usage goes through the roof. Usually during a file scan it stays around 5 – 10%, but when it hits this certain point it goes to 80% and above. The file scan doesn’t get all the way through, it appears to stall when the problem starts.

    Is it possible that some of the files added are causing the problem? I’ve tried removing some of the files added from the last back up, but with no luck so far. I’ve also tried reinstalling Firefly from scratch.

    I’m using OSX 10.4.11 and Firefly Server svn-1586. Here’s the message I get in the log: Thread 0: Entering ws_returnerror (302: Moved)

    Thanks for any help.

    #16801

    stretch
    Participant

    If you´ve been running a *scan* try running a full scan instead.
    If that doesn´t work.
    Stop Firefly, delete (or move) the database file and then restart Firefly.

    #16802

    Anonymous

    I’ve already had to try a full scan. When the error occurs, the only way I can stop Firefly is to kill the process in the Activity Monitor. When I restart Firefly, the database is empty so it starts a full scan.

    I’ve tried deleting all the files in the Application Support folder (conf, log, db, db-journal), but the same thing happens. Out of a library of 12323 songs, the problem occurs around the 10700 songs mark.

    #16803

    fizze
    Participant

    Ok, here’s how to fix this:
    Set the debuglevel of firefly to 9 in the web interface.
    Then trigger a rescan. And when firefly goes to bitbucket land, check the logfile for the file it was currently scanning, or the last sucessful before that.
    That should give you enough pointers to remove or fix the defective file.

    #16804

    Anonymous

    Thanks fizze. I shall give that a go.

    Edit: That found the problem, although I don’t know what the problem was. The album causing the issue was one that has been there all the time I’ve been using Firefly.

    Thanks for your help.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.