[HOW TO] force folder.pjg

[Tim Curtis]

@Nutul

The help button, huh? Wish I’d thought of that

lol, me too. 
It's possible that option is causing the odd cover behavior. In my test yesterday it was set to "Default".

[Nutul]

@Nutul

The help button, huh? Wish I’d thought of that

lol, me too. 
It's possible that option is causing the odd cover behavior. In my test yesterday it was set to "Default".

Well, if it could it definitely would (Murphy...) question remains, though... how? I know there is a fallback to an image in the containing folder but, IIRC, it gets fired only if no image is found in the current...

[Tim Curtis]

@Nutul

The help button, huh? Wish I’d thought of that

lol, me too. 
It's possible that option is causing the odd cover behavior. In my test yesterday it was set to "Default".

Well, if it could it definitely would (Murphy...) question remains, though... how? I know there is a fallback to an image in the containing folder but, IIRC, it gets fired only if no image is found in the current...

Look at /var/www/util/list-songfiles.sh

Run the command with "Default+" as the arg and then examine the output list. If there are multiple images in the album folder then there will be multiple occurrences of the album in the output and the thumbnail generator will eventually end up hashing the last one. At least I think thats what might be happening.

[Nutul]

(...) the thumbnail generator will eventually end up hashing the last one. At least I think thats what might be happening.

It sounds logical, but isn't the thumbnail generator create the image ONLY if it isn't already there... that should prevent it to overwrite an already existing one...

[Tim Curtis]

(...) the thumbnail generator will eventually end up hashing the last one. At least I think thats what might be happening.

It sounds logical, but isn't the thumbnail generator create the image ONLY if it isn't already there... that should prevent it to overwrite an already existing one...

Look at how the logic in the while loop would handle the case where there could be multiple same album dirs in the song file list as would only be the case when the Prefs setting was set to one of the + options. 

For example in the list below the directory album2 would only trigger a hash check / thumb creation when the loop advanced to album3 ($dirA != $dirB). When that happens tim.jpg is used as the cover instead of cover.jpg.

album1 cover.jpg
album2 cover.jpg
album2 kent.jpg
album2 tim.jpg
album3 albert.jpg

[Nutul]

(...) the thumbnail generator will eventually end up hashing the last one. At least I think thats what might be happening.

It sounds logical, but isn't the thumbnail generator create the image ONLY if it isn't already there... that should prevent it to overwrite an already existing one...

Look at how the logic in the while loop would handle the case where there could be multiple same album dirs in the song file list as would only be the case when the Prefs setting was set to one of the + options. 

For example in the list below the directory album2 would only trigger a hash check / thumb creation when the loop advanced to album3 ($dirA != $dirB). When that happens tim.jpg is used as the cover instead of cover.jpg.

album1 cover.jpg
album2 cover.jpg
album2 kent.jpg
album2 tim.jpg
album3 albert.jpg

Yes, now that I see it... this also explains why the folder file priority works, as it specifically looks for Cover, cover, Folder, folder... and voilà...

Perhaps we should do a refactoring of the image-detection scheme, based on priority, with cascading fallbacks...

Example:
PRIORITY EMBEDDED:
1. look into the embedded art
2. if not found, look for specific names (again Cover / Folder, as it is now for the folder file)
3. if not found, look for any image (if "+" present)

PRIORITY FILE
1. look for specific names (again Cover / Folder, as it is now for the folder file)
2. if not found, look for EMBEDDED
3. if not found, look for any image (again, if "+" present)

In the latter, maybe 2 and 3 can be swapped, but I'd leave them in this order.

The step 2 of the EMBEDDED case above should fix the OP issue.

What do you think?

P.S.
Today I was testing a file without album-art, and noticed it took the image file I have in the root folder (/USB/Music) of my external drive instead of the "not-found" one...
Now, it is true that I still test my "Hybrid" priority, but there is no image in the file folder to justify it... could it be related, despite the fact I had the thumb scan option on "Default"?

[Tim Curtis]

(...) the thumbnail generator will eventually end up hashing the last one. At least I think thats what might be happening.

It sounds logical, but isn't the thumbnail generator create the image ONLY if it isn't already there... that should prevent it to overwrite an already existing one...

Look at how the logic in the while loop would handle the case where there could be multiple same album dirs in the song file list as would only be the case when the Prefs setting was set to one of the + options. 

For example in the list below the directory album2 would only trigger a hash check / thumb creation when the loop advanced to album3 ($dirA != $dirB). When that happens tim.jpg is used as the cover instead of cover.jpg.

album1 cover.jpg
album2 cover.jpg
album2 kent.jpg
album2 tim.jpg
album3 albert.jpg

Yes, now that I see it... this also explains why the folder file priority works, as it specifically looks for Cover, cover, Folder, folder... and voilà...

Perhaps we should do a refactoring of the image-detection scheme, based on priority, with cascading fallbacks...

Example:
PRIORITY EMBEDDED:
1. look into the embedded art
2. if not found, look for specific names (again Cover / Folder, as it is now for the folder file)
3. if not found, look for any image (if "+" present)

PRIORITY FILE
1. look for specific names (again Cover / Folder, as it is now for the folder file)
2. if not found, look for EMBEDDED
3. if not found, look for any image (again, if "+" present)

In the latter, maybe 2 and 3 can be swapped, but I'd leave them in this order.

The step 2 of the EMBEDDED case above should fix the OP issue.

What do you think?

P.S.
Today I was testing a file without album-art, and noticed it took the image file I have in the root folder (/USB/Music) of my external drive instead of the "not-found" one...
Now, it is true that I still test my "Hybrid" priority, but there is no image in the file folder to justify it... could it be related, despite the fact I had the thumb scan option on "Default"?

I think the OP might be using the plus option to get parent folder covers but as the help for the "Thumbgen scan" setting mentions:

"NOTE: Incorrect thumbnails may appear in the Library if the Album folder also contains image files and "Cover search priority" is set to Embedded."

Basically the OP needs to either (1) embed a cover in the albums that are causing the issue or (2) have just one image file (the cover) in the Album folder.

ETA: or (3) switch "Cover search priority" to "Cover file" from "Embedded". The side effect is that if most of the collection contains embedded covers then "Cover file" priority will cause the thumbnail scan to take longer.

No need to code for this corner case.

[TheOldPresbyope]

Hey, guys, the + option doesn't exist yet for Joe User. It wasn't committed to the git repo until the week after the release of 8.3.3. Hence, that's not germane to the OP's issue.

Fact is, I can reproduce the OP's issue with the two albums I downloaded. One album has FLAC files with well-formed metadata including an embedded image in each and one album has FLAC files with well-formed metadata and not including an embedded image. Each album contains a number of jpg files including folder.jpg (and also Cover.jpg in one of them).

For me, the problem arises because list-songfiles.sh was modified for r8.3.3 to return image files as well as music files. To my way of thinking, the logic in thumb-gen.php doesn't match up right. As a test, I commented out the added image types in the regen pattern in list-songfiles.sh after which the OP's albums "just work" with Cover search priority either Embedded or Cover file.

I'm comfortable telling a user that the cover image file in an album directory should have the generic name [Cc]over or [Ff]older but not comfortable saying that an album directory should not contain any other image files.

Not sure what to suggest for a solution since I don't know what else you have in mind for this code. As an aside, I'm feeling squiggy about searching up-directory to find an image. Seems to me there be dragons.

As another aside, I was surprised to see the copyright statement in list-songfiles.sh. It took me a minute to remember I submitted its predecessor listall.sh. Given how much has been done to the code beyond simply renaming the script, I think the copyright statement needs to be adjusted but I'm not sure how it should read. 

Regards,
Kent

[Nutul]

Hey, guys, the + option doesn't exist yet for Joe User. It wasn't committed to the git repo until the week after the release of 8.3.3. Hence, that's not germane to the OP's issue.

This makes things even weirder...

As another aside, I was surprised to see the copyright statement in list-songfiles.sh. It took me a minute to remember I submitted its predecessor  listall.sh. Given how much has been done to the code beyond simply renaming the script, I think the copyright statement needs to be adjusted but I'm not sure how it should read. 

IMO some files should not hold the copyright notice; especially this shell script, as it does nothing more than invoking find with some file-pattern; which is almost the only thing to do when invoking find... ;-)

Reminds me when, a few years back in time, a certain company claimed copyright to the graphical slider (among other things...) to unlock / answer the phone...

[TheOldPresbyope]

Re: CR, I don't disagree but the subject is a mine field.