0008423: File Monitor doesn't use same logic as Add/Rescan

ID	Project	Category	View Status	Date Submitted	Last Update

0008423	MMW v4	Tracklist	public	2011-09-27 05:31	2011-10-02 22:27

Reporter	rusty	Assigned To
Priority	immediate	Severity	minor	Reproducibility	always
Status	closed	Resolution	unable to reproduce
Product Version	4.0
Target Version	4.0

Summary	0008423: File Monitor doesn't use same logic as Add/Rescan
Description	There have been numerous reports of scanning failures in which tracks are represented incorrectly in the library (missing an Album even though Artist and Album Artist exist and are identical). It turns out that the problem is specific to the file monitor. The issue was discovered in the course of testing scanning of ACDC albums which seemed to display in the tree, but not at the expected location in the tracklist (Art View / Art and Details view). See attached images and video. In contrast, when manually scanning the files, this bug doesn't occur. Could there be other differences in scanning logic between the File Monitor and Manual Scanning (e.g. could it explain some Album Art problems re. multiple art being addde)?
Additional Information	Video of the bug: https://rapidshare.com/files/4199297609/MediaMonkey_AlbumArtWithDetails2011-09-26_1301.swf http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=59636&start=30#p312690
Tags	No tags attached.
Attached Files	failed_album_recognition.jpg (254,308 bytes) failed_album_recognition.jpg (254,308 bytes)

Fixed in build

jiri 2011-09-27 09:47 administrator ~0027957	Well, yes, File Monitor doesn't work exactly as Add/Rescan, but it also never did. The thing is that since Add/Rescan works on (presumably) fixed folder content, it can decide whether Album Artist could be assigned based on the fact that the folder seems to contain single album only. On the other hand, File Monitor works on ever changing folder content and so implementing something similar is pretty much impossible. I don't have the exact tracks used for creation of the attached screenshot, but it doesn't seem to be a regression, but rather as something that has always been this way. We can try to do something about it in the future (but as explained above, I'm not sure what exactly to do), but definitely not for 4.0.

rusty 2011-09-27 15:14 administrator ~0027967	This is a regression from MM3. i.e. MM3 scans the files and inserts them into the DB correctly, and renders them properly in the Art/A&D views. MM4 doesn't. This bug is likely the root cause of some of the reports re. bug 0008361 The full folder that triggers the bug in MM4 and not MM3 is posted to the ftp server.

rusty 2011-09-27 17:31 administrator ~0027968	I can't replicate this in 1436/37 (tested with various views/nodes, playback, etc.).

peke 2011-10-02 22:27 developer ~0028007	Verified 1439