IPB

Welcome Guest ( Log In | Register )

> foobar2000 Tech Support Forum Rules

Please read foobar2000 Tech Support Forum Rules before posting and comply with all the points.
Failure to provide all the information pointed out in the above document in your post is considered wasting other people's time and in extreme cases will lead to your topic getting locked without a reply.


See also: Hydrogenaudio Terms of Service.

 
Reply to this topicStart new topic
Full tag info not refreshing, even after "reload info from file(s
Chinch
post Mar 27 2012, 12:40
Post #1





Group: Members
Posts: 98
Joined: 22-July 09
Member No.: 71664



I am not sure whether this is a bug, or just a misunderstanding on my part, but it is a simple enough issue to describe and recreate:

If I have a file or album loaded in a playlist... say I select all 10 tracks on this album, and then embed the Front Cover album art into the said tag...

Using Columns UI, I have it showing a thumbnail of the album art next to each grouping of files (put into order by something natural, say... %album artist% %artist% %album% %discnumber% %tracknumber%

That's just for example, but similar to how an "album" would be made to group together.

Regardless of that, though... even if it is a single file, ungrouped, in either circumstance --

If I embed the Front Cover art using foobar2000... it of course doesn't show the album art (as expected)... but then I even go to the "Reload info from file(s)", which I was under the impression that this function basically re-read all of the tag info, etc... and updated the display elements accordingly (did something like a forced refresh on the display of those data fields...


But I can't get it to show the album or track's cover art, even after reloading the info from the file. The ONLY way that I can get it to show the embedded Front Cover is to remove the file from the playback/playlist queue, and re-add it freshly. Am I mistaken in thinking that the "Reload info..." should make it show the newly embedded cover art? If I am, is there any easier or quicker way to force it to re-read the embedded cover art and get it to update in the Columns UI display, showing a cover where there was previously none... other than the solution just mentioned (a full remove/re-add to queue)?


Or is the issue possibly that it only reloads the tag info that EXISTED PREVIOUSLY, e.g. when the file was first loaded into the queue? Therefore, now that I added a brand new tag that didn't exist at that point, it's only reloading the original tag info, and not any newly added ones?

Don't mean to be so repetative and elementary... I just want to make sure I am explaining my viewpoint of what is or isn't going on, and then if I need to be corrected in my understanding of something, then you can pinpoint exactly where I'm failing in my assumptions...

Thank you! It's just something that I have been "working around" for a long time, and I want to find out what I am possibly doing wrong and how to best accomplish the refresh!
Go to the top of the page
+Quote Post
TurnTwo
post Apr 10 2012, 18:00
Post #2





Group: Members
Posts: 1
Joined: 20-March 12
Member No.: 97945



@Chinch:

Saw this post and just wanted to let you and the forum know, "me too". My experience began to occur on random artists within my playlists. I associated my music files through discogs but I didn't always need the full details so I would just grab the appropriate front cover, save it to disk, then from the columnsUI write tags > front cover, I associated the front cover to the correct artist album.

Everything was fine in my case until about 3 weeks ago when random files, for lack of a better description, became corrupt displaying random cover art from other albums in my library. I've tried the "reload" option and a few other restore options, without any luck. Since I'm using fb2k to manage an iPod, I'm not sure what the best approach is. I'm also wondering if WMP (which I use to manage my Sony MP3 player) may have fouled something up.

So, if someone is monitoring this thread, there's more than one occurrence. More details can be provided if asked. Thanks.
Go to the top of the page
+Quote Post
Chinch
post Apr 22 2012, 13:18
Post #3





Group: Members
Posts: 98
Joined: 22-July 09
Member No.: 71664



I think your assumption about the evil WMP may have something to do with it, in fact, I bet I can tell what may have happened.

WMP has this horrible, nasty, terrible... inexcusable habit of going through your album art (external, not embedded) and resizing your folder.jpg files to 280x280 (hi-res, right? great looking when you expand that to a size that you can actually see)... then it gives the folder.jpg file both hidden and system attributes (or was it read-only) -- either way, it butchers any folder.jpg art, which foobar can and does use (at least for me, all the time)...

What likely has happened is you've opened WMP (and that's all it takes... even if you explicitly set the options that say DONT F**K WITH MY FILES, it disregards that)... so it basically does this without asking the user, and once it's done, the damage is done. It also creates a smaller thumbnail version called AlbumArtSmall or something similar which is again, like a massive 70x70 (who in 2012 is looking at album art the size of an icon?? And what made them decide, once again... in 2012, 2011, whatever it may be... that 280x280 is the optimal resolution for the LARGE version of the cover art? Totally asinine.

Anyway... possibility-- what foobar was once using to show your album art, the folder.jpg file inside each album's folder.... is now a hidden file, and it may not be able to see it, so it assumes the file is missing... and therefore doesn't display artwork for that album or set of files. To prove or disprove this, go into your explorer options and Show all file types; hidden, system and show hidden files blah blah... you wanna see it all... then navigate into several of your album folders or mp3 folders that used to have artwork showing... see if you find the hidden folder.jpg AlbumArt.jpg AlbumArt_small.jpg (or whatever) hiding in there. If so... I would say mystery is solved.

You can do a 1 command, recursive pass through each of your folders unsetting the hidden and system attributes, and (in my case, I also set it to delete the newly created 2 AlbumArt files as well) and restore folder.jpg back to a usable state -- but the sad, sorry part is... it's forever 280x280; and this is the very reason why:

a) I refuse to even OPEN WMP, because like I said, it starts this militant takeover immediately... no waiting around for WMP!
b) Now make sure to always EMBED my album art into the file... and on top of that, since I like having the album art preview on folders in explorer, once I get my decent good sized artwork back, I set folder.jpg to read-only and I make a second copy of it, named like 00-whateverblahblah.jpg -- a file that WMP won't go seek and destroy in case my folder.jpg happens to be molested again, I always have a backup of the external file.


Sound like a possibility? I'm interested in what you find.

Unless you also did B and EVERY file/album had embedded artwork... then totally exclude everything I said. LOL. As far as the randomness thing, I don't know... but I've had that happen if there happens to be Album A's artwork in a hidden "folder.jpg" file in a folder, even if files in the folder had embedded artwork, it would default to the hidden folder.jpg, to which my only response was: "Why the HELL is the Teenage Mutant Ninja Turtles soundtrack cover art showing up as the front cover of my CANNIBAL CORPSE CD?!" (Exaggerated for contrast/effect but circumstance was similar).

So even with embedded art, look for stray folder.jpg's. Lemme know. I still got no help here... nobody knows.... or maybe it's just a well-guarded secret of the foo crew... Hope to hear back from you again.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st September 2014 - 19:46