#45 Artwork status always "Not Present" for networkdrive folders

closed
AlexVallat
None
5
2014-04-05
2010-03-04
Steffen Poulsen
No

I just stumbled into this this fine program today, and I'm happily adding covers to my collection as I'm writing - I must admit that I'm very impressed with the success-rate of this utility :-)

However, I stumbled over an "interesting" :-) behaviour when accessing mp3 folders over network shares, that I hope you will help me fix.

The bug appears to be, that the File Browser in Album Art Downloader will always return "Artwork Status" as "Not Present" if the folder searched is placed on a network drive. This is even though that the folder both holds a "Folder.jpg" and a "Cover.jpg".

I have used the program "Process Monitor" from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx to gather some debug information of the file access level:

First of all, it seems like the directory is queried for all of its files first, and the complete list of files appears to be returned OK:

6:53:04.2038580 PM AlbumArt.exe 5708 QueryDirectory \media\mp3\Zebrahead - Panty Raid (2009)* SUCCESS Filter: *, 1: .
6:53:04.2049989 PM AlbumArt.exe 5708 QueryDirectory \media\mp3\Zebrahead - Panty Raid (2009) SUCCESS 0: .., 1: 18 - Hidden Track.mp3, 2: front_600.jpg, 3: Folder.jpg, 4: Cover.jpg, 5: 01 - Survivor.mp3, 6: 02 - Girls Just Want To Have Fun.mp3, 7: 03 - Underneath It All.mp3, 8: 04 - Trouble.mp3, 9: 05 - London Bridge.mp3, 10: 06 - Beautiful.mp3, 11: 07 - Girlfriend.mp3, 12: 08 - The Sweet Escape.mp3, 13: 09 - Intro.mp3, 14: 10 - Jenny From The Block.mp3, 15: 11 - Rehab.mp3, 16: 12 - Spice Up Your Life.mp3, 17: 13 - Intro.mp3, 18: 14 - Oops!...I Did It Again.mp3, 19: 15 - Get The Party Started.mp3, 20: 16 - Mickey.mp3, 21: 17 - All I Want For Christmas Is You (Bonus Track).mp3

But the subsequent request for Folder. unfortunately fails with "NO SUCH FILE":

6:53:04.3088693 PM AlbumArt.exe 5708 QueryDirectory \media\mp3\Zebrahead - Panty Raid (2009)\Folder. NO SUCH FILE Filter: Folder.

And the same goes for the subsequent request for Cover. - it also fails with "NO SUCH FILE":

6:53:04.3962505 PM AlbumArt.exe 5708 QueryDirectory \media\mp3\Zebrahead - Panty Raid (2009)\Cover. NO SUCH FILE Filter: Cover.

However, if I copy the folder 1:1 to the local harddrive QueryDirectory returns OK, and "Artwork Status" shows up as green as expected - and the request also turns up as a "SUCCESS" request in the Process Monitor log:

6:54:57.2111917 PM AlbumArt.exe 5708 QueryDirectory C:\mp3\Zebrahead - Panty Raid (2009)\Folder. SUCCESS Filter: Folder., 1: Folder.jpg

I will be happy to provide more debug info, if needed.

I wonder, perhaps there is a known workaround for this behaviour? - I.e. a a setting I can change in the smb.conf file that will change the samba daemon behaviour into returning SUCCESS for the "QueryDirectory Folder." request?

If not, I hope it is possible to fix this behaviour in Album Art Downloader. As can be seen, the complete list of files appears to be returned OK as one of the first requests, so the necessary information should be available to Album Art Downloader in some way already I think.


I am running Album Art Downloader in a 64 bit Windows 7 Ultima environment.

The mp3 share is shared from a standard CentOS install:

[root@media mp3]# smbd -V
Version 3.0.33-3.7.el5

[root@monster mp3]# cat /etc/redhat-release
CentOS release 5.3 (Final)


  • Thanks again for an excellent program! :-)

Discussion

  • AlexVallat
    AlexVallat
    2010-03-04

    Thank you for your detailed bug report. I will test this out locally as soon as I can get a server with a network share set up. Hopefully it won't be specific to CentOS.

    Could you do a quick check for me and in the File Browser, replace the "Specify path to find images" text with just "Folder", or even just "" - that might narrow down whether it is multiple wildcards that are causing the problem, or if it's some difference in how the filesystem query is being made.

     
  • Thanks for the quick reply!

    I have now tried changing the wildcard pattern into:

    Folder.jpg|Cover.jpg

    But still, same result. Further, I tried to "strace" the smbd processes at the CentOS installation, and as it happens, the output comes out like this:

    stat("/some/media/path/FOLDER<.JPG", 0x7fff2039f4a0) = -1 ENOENT (No such file or directory)
    stat("/some/media/path/COVER<.JPG", 0x7fff2039f4a0) = -1 ENOENT (No such file or directory)

    So, to me it appears that two things happen "magically":

    1) the "*" is changed into a "<"
    2) the filename casing is changed to UPPER

    and for these reasons, I guess the match fails.

    However, if I change the "Specify path to find images" to exact names ("Folder.jpg|Front.jpg" etc) I have green lights all over (yay!).

    I'm not really convinced that this particular error lies with Album Art Downloader, it might just as easily be a problem with my samba installation. But at least now I can move on, as I don't need to make use of the wildcard option for my exact purposes - the direct matching is more than good enough :-)

    I can see that I do have two options set in my smb.cnf that might (?) affect this matching behaviour, these are:

        preserve case = yes
        case sensitive = yes
    

    But for other reasons I need these options enabled, so turning them off is not a solution in my case.

    As stated, I am now able to continue with the altered match pattern with no wildcards. If this behaviour happens to be reproducible my idea of a solution would probably be in the direction of doing the matching locally, against the complete list of files in the directory, as it appears to be retrieved OK. But I am happy to leave that train of though entirely up to you.

    Btw: I wondered if there is a source for http://albumart.org/ available - or has this site perhaps been left out on purpose?

    Again, thanks for an amazing program!

     
  • AlexVallat
    AlexVallat
    2010-03-05

    I'm glad to hear you found a workaround. I'm going to leave this open until I can do some more testing, but if it turns out to be just a CentOS or Samba thing then I'll close it.

    albumart.org has been left out because it is simply a front-end to amazon images, which are already searched directly by the amazon scripts.

     
  • AlexVallat
    AlexVallat
    2013-04-22

    • status: pending --> closed