Bug 9424 - Scanner hangs on semi-random file
: Scanner hangs on semi-random file
Status: RESOLVED DUPLICATE of bug 9432
Product: Logitech Media Server
Classification: Unclassified
Component: Scanner
: 7.2
: PC Windows XP
: -- major (vote)
: ---
Assigned To: Squeezebox QA Team email alias
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-07 01:10 UTC by sasu.tikkanen@gmail.com
Modified: 2008-09-18 08:52 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sasu.tikkanen@gmail.com 2008-09-07 01:10:50 UTC
I added a new directory under the root directory of music to be scanned to SqueezeCenter 7.2. When starting to scan the directories by clicking "Basic Settings" - "Look for new and changed music" - "Rescan" the scan process hangs after about 30 seconds. 

The Status page says:

------------------------------
Directory Scan   (1  of  20298)   Running  00:05:42

E:\Music\ShareMusic\Download-MP3s\_Pop\ABBA\Gold Greatest Hits\11 Chiquitita.wma
SqueezeCenter has finished scanning your music collection. Total Time: 00:05:42
------------------------------

The file where it hangs changes sometimes. First I thought it's maybe a too long filename, but this doesn't seem to be the case with the above mentioned file. The scanner log has the following output:

------------------------------
[08-09-07 10:02:07.8156] main::main (219) Error: Failed when running main scan: [Can't call method "content_type" on an undefined value at /<C:\PROGRA~1\SQUEEZ~1\server\scanner.exe>Slim/Schema.pm line 1155.
]
[08-09-07 10:02:07.8162] main::main (220) Error: Skipping post-process & Not updating lastRescanTime!
------------------------------

The bug can be reproduced every time by me.
Comment 1 James Richardson 2008-09-08 14:20:42 UTC
Please turn DEBUG on for:
(scan.import) - File & Playlist Metadata Import Logging 
(scan.scanner) - Music & Playlist Folder Scanning

then attach the log file to this bug 
Comment 2 KDF 2008-09-09 11:17:38 UTC
This seems to be a result of the merge into 7.2, change 22939.  I can't lookup where it was done in the branch.

For me, I can reproduce this whenever a file doesn't exist.  Either referenced from a playlist or from iTunes or MusicIP libraries.

a simple check on the status of $track should do it. Change Schema.pm line 115 like so:

		if (blessed($track)) {
			$attributeHash->{'CONTENT_TYPE'} = $track->content_type;
		}
Comment 3 KDF 2008-09-09 12:07:15 UTC
also applies to bug 9442 which was marked as a dupe but is actually a match for this one instead of what it was duped with.
Comment 4 James Richardson 2008-09-10 16:22:31 UTC

*** This bug has been marked as a duplicate of bug 9434 ***
Comment 5 Spies Steven 2008-09-18 08:52:50 UTC
I believe this is actually a dupe of bug 9432 that has been fixed in the nightly.  If you still see this behavior with the nightly please reopen and add additional comments.

*** This bug has been marked as a duplicate of bug 9432 ***