Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

Auto-Import ignores those files if the relevant "ignore special files" option is checked.  You can uncheck it though and then it'll import them.

I'll have to check the behavior of Add from File when I get home.  It could be entirely that I'm just not waiting long enough.  I know that a week and a half ago or so I did a lot of tag maintenance including adding a lot of cover art from files.  Each and every time it worked the way I described.  I'd add the cover art via Cover Art --> Add from File.  MC would update the thumbnails one by one and say "Done saving tag changes" and then I'd scroll over to my Image File column and it'd say M:\Music Art\blah\blah - blah.jpg" or whatever.  I'd then finish tagging and select the files and do Update Tags from Library and it'd fix that column to say "Inside File" as expected.

I probably did this with at least 200 files in that sitting, so I'm pretty sure of the steps.  However:

(a) The files were all on a network drive, and not my big fast RAID, but my temporary "import" drive (which is on a slower machine which is often pretty heavily bogged down with Bittorrent traffic).
(b) I was doing the operations fast.  As soon as the thumbs finished redrawing and showed the cover art, they'd get the Update Tags from Library action almost immediately.  I'd guess that I was slower on a few, but I just thought (from previous experience) that it was necessary so I was going along and doing it quickly.  So... It is entirely possible that MC would have switched these all to "Inside File" on it's own a little while later.  If it was going to take 20 - 60 seconds I'd have missed it.  If it was nearly instantaneous I think I'd have caught it.

[Alex B]

Auto-Import ignores those files if the relevant "ignore special files" option is checked.  You can uncheck it though and then it'll import them.

Hmm... I wasn't speaking about importing the actual image files to the library (at least not this time... )

[Matt]

Doing "Update Library (from tags)" (not Update Tags) will switch the "Image File" column to "Inside File" if MC can read an image from the tag.

If you have a file that MC can't read or write an image into the tag, perhaps you could share it.  The files from earlier today did have art in them.

Thanks.

[cwilliams222]

Maybe you've said, but what program do you use for a virus checker?

JimH - I am using Symantec Anti-Virus 10.1.6.6010, Corporate edition

[cwilliams222]

Did you also try this (it is a separate tool):

Not really sure what you are referring to here..  Are you asking did I try Update tags from library (versus update tags from library)?

If so, then, nope, not tried it yet, but will shortly to see what that does.

The cover art filename is supposed to be stored without a path whenever the linked image file is in the audio file folder. In this case the link is always correct if the image file is moved together with the audio files.

MC has an option for the default storing behavior (in a specific folder or in the audio file folder), but I think that during import it automatically links the first folder.jpg or [Album Artist (auto)] - [Album].jpg file it finds.

However, I don't normally use the Auto-Importer and I have not specifically tested if the cover art behavior is different when the Auto-Importer is used. (I did my mass importing years ago and currenty I import only a few files at a time.)

Really not sure what to say here as I don't think I totally get it above, I must be having a slow "processing" day...... I don't normally use the auto-important feature as well.  I have MC configured to save all coverart in a specific folder, one that is on the same usb drive as the actual library, and to also store the cover art inside the file.

Not sure I really addressed the second part, but not sure how I could....

thanks

[cwilliams222]

Doing "Update Library (from tags)" (not Update Tags) will switch the "Image File" column to "Inside File" if MC can read an image from the tag.

If you have a file that MC can't read or write an image into the tag, perhaps you could share it.  The files from earlier today did have art in them.

Thanks.

I ran Update Library from tags on 2 separate sets of FLAC files (one about 3 files, and one of about 10 files), ran fine, with no failures, but the Image File column still reflects the path to the image file, it does NOT say Inside File. 

So running Update Library from Tags, and Update Tags from library, neither one seemed to correct the issue I am experiencing.

To address your second statement - I don't think I have any files that MC can't read or write an image to, but will keep checking.

All of you have come up with a lot of suggestions and thoughts and so far nothing has worked.  I'm starting to get worried that the well of ideas is about to run dry and I'm just going to have to live with this problem........

[edbro]

'm starting to get worried that the well of ideas is about to run dry and I'm just going to have to live with this problem........

Don't worry, you aren't the only one experiencing this problem. I'm confident it will get fixed.

[Alex B]

cwilliams222,

Does externally linked cover art work? You mentioned that you have the image files in a defined cover art folder.

If yes, do you actually need embedded cover art for some other program? (I mean for now, until the reason for the behavior has been found and the problem fixed.)

[cwilliams222]

cwilliams222,

Does externally linked cover art work? You mentioned that you have the image files in a defined cover art folder.

If yes, do you actually need embedded cover art for some other program? (I mean for now, until the reason for the behavior has been found and the problem fixed.)

Not really sure I understand your question.  I have no other program that uses these cover art files, the MC library or anything like that. 

All of the cover art I use for MC is stored on an external USB drive attached to the PC.

Did I address your question?

[JimH]

I'm not convinced this is an MC problem.  It may be, but it's acting like something may be preventing a tag from being written.  A virus checker or other security app could do that.

Still, I'm not convinced that it isn't an MC problem.

cwilliams, thank you for your patience and for all the information you've provided.

[Alex B]

Not really sure I understand your question.  I have no other program that uses these cover art files, the MC library or anything like that. 

All of the cover art I use for MC is stored on an external USB drive attached to the PC.

Did I address your question?

Can you see the externally linked cover art in the main display during playback? Can MC create thumbnails for the view schemes and tooltips? I.e. does it matter if the Image File field shows a file path instead of "Inside File"? (Assuming the displayed path is correct.)

BTW, by default the cached thumbnails are stored in the application data folder. For example, my default location is C:\Documents and Settings\Alex B\Application Data\J River\Media Center 12\... Do you have write access to these folders?

[glynor]

And one other thing....

If you delete/move/rename one of the "linked" image files, and then tell MC to rebuild thumbnails from scratch, does it then pull the image inside the file (since others indicated the FLAC you posted did indeed contain an embedded image)?

[cwilliams222]

I'm not convinced this is an MC problem.  It may be, but it's acting like something may be preventing a tag from being written.  A virus checker or other security app could do that.

Still, I'm not convinced that it isn't an MC problem.

cwilliams, thank you for your patience and for all the information you've provided.

I'm open to any idea or solution.  I personally would lean more to it being an MC issue as I had the problem on an earlier laptop PC that had an entirely different software loadset installed (different anti-virus, software, different OS, etc.)  I really love MC and want it to work "properly."

I did just go ahead and install 372 as it is now on the main board.  After doing that I tried the updating tags from library and library from tags, still no fix.

Not sure what other information I can provide.....Again, I will provide any logs that may help, just tell me what to setup/configure and I'll try and get it done.

You had earlier asked what security/virus software I have installed and I replied Symantec Anti-Virus, I forgot to also include that this PC has Proventia Desktop (formerly blackice) installed as well.  I checked its logs and there is nothing there that seems to be related to MC, the share where the library is.

I also checked the Event Viewer logs on the PC and nothing jumped out being related to this issue (not saying it wouldn't be there, but nothing obviously seemed to be related)...

[edbro]

Here's another clue.

1) I took a song from one album and removed the coverart. Album is Aaron Neville's Gospel Roots. Original coverart was named "Aaron Neville - Gospel Roots Disc 1.jpg"
2) I attached art to that Aaron Neville song from another album (B.B. King)
3) MC asked if I wanted to copy the art to the default folder. I said yes.
4) MC now displays the new (B.B. King) art for all the files in that album. I only changed one.
5) The tag shows the original cover art file (C:\Documents and Settings\Ed\Application Data\J River\Media Center 12\Cover Art\Aaron Neville - Gospel Roots Disc 1.jpg"
6) When I look in the coverart folder on my hard drive, there is the B.B.King art renamed to Aaron Neville. So, all the rest of the songs in that album are now pointing to the B.B. King art that MC renamed and copied as "Aaron Neville - Gospel Roots Disc 1.jpg"
7) The art is not embedded. Update Library (from tags) does nothing but show "library updated for 1 files".

Files are all ape. MC ver 12.0.372

[cwilliams222]

And one other thing....

If you delete/move/rename one of the "linked" image files, and then tell MC to rebuild thumbnails from scratch, does it then pull the image inside the file (since others indicated the FLAC you posted did indeed contain an embedded image)?

Glynor -- Good suggestion, I did try this, took a file in the coverart directory, deleted it, and MC from that point just showed the file path in the Tag window for the corresponding FLAC file, and an X in Playing Now.  I restored the file back and everything went back to normal...  It did NOT appear to try and pull the coverart internally from the file.

I think you are thinking of the "smaller" of the 2 issues I was reporting, not the big one that is affecting my library --- sure you didn't have time to read through my 30 or so posts on this subjetc - you must have a life or something.....  Anyway, I had about 5 FLAC/APE files that my MC showed as having the cover art embedded, even though MC couldn't actually show it to me via thumbnails, or when I looked at the tag.  I believe this is a separate (but could be related) issue from the main one I am reporting about all (or more accurately, all but 5) of my FLAC and APE files being reported in MC as not having the cover art embedded in the file despite how MC is setup.....

[Matt]

Glynor -- Good suggestion, I did try this, took a file in the coverart directory, deleted it, and MC from that point just showed the file path in the Tag window for the corresponding FLAC file, and an X in Playing Now.  I restored the file back and everything went back to normal...  It did NOT appear to try and pull the coverart internally from the file.

For these same files, if you look at Action Window > Tag > Format, does it say that the tag contains an image?  I'm still trying to understand if the tag actually has an image and MC doesn't know about it, or if MC can't read or write the image to the tag.

[cwilliams222]

Can you see the externally linked cover art in the main display during playback? Can MC create thumbnails for the view schemes and tooltips? I.e. does it matter if the Image File field shows a file path instead of "Inside File"? (Assuming the displayed path is correct.)

Alex B - Yes, I can see the cover art picture in the main display during playback.  I usually have a 3 tab setup, with one tab set to Playing Now, and use the "All I need" track info visualization for this and I see the cover art fine for all files (the MP3 files that do indicate that the cover art is inside the file, and the FLAC/APE files that MC indicates the file path to where the cover art is stored).

BTW, by default the cached thumbnails are stored in the application data folder. For example, my default location is C:\Documents and Settings\Alex B\Application Data\J River\Media Center 12\... Do you have write access to these folders?

I just verified this, I have full control of all the folders/files under ...\J River\Media Center 12\....

[cwilliams222]

For these same files, if you look at Action Window > Tag > Format, does it say that the tag contains an image?  I'm still trying to understand if the tag actually has an image and MC doesn't know about it, or if MC can't read or write the image to the tag.

Matt - Didn't check that the first time, so I re-ran my test and the Action Window>Tag>Format screen looks different to me now with version 372 than it did with 370.

I took one FLAC file, took the cover art that was in the cover art folder and removed it.  I played the file and there was no cover art show in Playing now (just an "X"), but the thumbnail was still there as I didn't get rid of it.

When I look at Action Window>Tag>Format there is now a little "section" called:  # of Pictures and the information it has is this (this is the whole Format window):

Code: [Select]

Free Lossless Audio Codec (FLAC)
  44.1 kHz Sample Rate
  16 Bits Per Sample
  2 Channels

  Min Block Size = 4096
  Max Block Size = 4096
  Min Frame Size = 1594
  Max Frame Size = 13891
  Padding Block = 2582 bytes

# of Pictures = 1
  Type 3 (4043 bytes)

SeekTable Block (396 bytes):
  # of points = 22

Vorbis Comment Block (1561 bytes):
  Vendor String = reference libFLAC 1.1.4 20070213
  TITLE = Romancing The Stone
  ARTIST = Eddy Grant
  TRACKNUMBER = 1
  Comment = <Too Long To Display>
  date = 1984/01/01
  genre = Whitburn Pop
  TOOL NAME = Media Center
  TOOL VERSION = 12.0.372
  ALBUM = Going for Broke
  LTESTATUS = Lyrics Updated on 11/14/2007 6:37:27 PM
  LYRICS = <Too Long To Display>

Putting the file back didn't seem to change anything.  I went ahead and tried it on an APE file as well, as when I looked at the Action Window>Tag>Format information for an APE file, it looked different than for the FLAC file.  When i removed the cover art file for the APE file, Playing now showed no cover art (just an "X") and the Action Window>Tag>Format information had this:

Code: [Select]

Monkey's Audio 3.99 (fast)
Format: 44.1 kHz, 16 bit, 2 ch
Length: 3:59
Compression: 66.78% (26.9 MB / 40.3 MB)
Tag: APE Tag 2.00 (34162 bytes)
   Track: 49
   Year: 1983
   Genre: Oldies
   Title: Automatic
   Album: Break Out
   Tool Version: 12.0.370
   Comment: Cruiser CD Rip
   Tool Name: Media Center
   Media Jukebox: Date: 30317
   Artist: The Pointer Sisters
   Media Jukebox: LTEStatus: Lyrics Updated on 11/14/2007 6:45:19 PM
   Lyrics: <too large to display>
   Cover Art (front): <too large to display>
This did not change when I put the file back (still said too large to display).


Does this help with the troubleshooting?

[JONCAT]

Hopefully relevant, but if not, ignore:

http://yabb.jriver.com/interact/index.php?topic=43317.msg295680#msg295680

The gist is that on one machine cover art displays "everywhere" i.e. tool-tip, Image in tree, Playing Now, and Display View>Cover Art.

On the other machine, laptop, using a mapped drives, cover art won't display in Image in tree, Playing Now, and Display View>Cover Art but the thumbnail works as well as tool-tip.

The problem lies in the fact that I copy my library to a local location on the laptop. All mapped drives have the SAME letter assigned on both machines, but it seems that MC on the laptop, with the copy of the library, is confused about the location of cover art even though the library and tags clearly, and correctly, report cover art as Inside File.

If I create a brand new library on the laptop everything is kosher. Strange though that with identical drive letters, the ability to play the same files, that the copy of my library will not allow MC on the laptop to display cover art.

My question is, would this same behavior happen using the "approved" method of write/read-only library sharing?

DC

[bbrip]

I am having the same issues as reported by cwilliams.  I also cant get MC12 to store coverart inside APE files.

I am not entirely sure when it started it happen as I just recently ripped a couple of CDs after I hadnt done any for a couple months.

I am not sure whether this might be related to the fact that I have in the meantime moved all files to a network drive (as Library Server only "serves" Audio files but no video files).

I have not done testing as to what might happen if files sit on a local drive. Has someone already tried this?

BBRip

[JimH]

Doc Cilantro,
Great clue.  Thanks!

Are there any NAS drives involved?  The reason I ask is that I believe sometimes these drives use SAMBA and there may be a case problem (S: vs. s:, for example).

[JONCAT]

Hey guys & gals,

HTPC has PATA, SATA, and external Firewire HDs; no true NAS but all drives are obviously mapped over the network by the laptop.

I got a chance to setup a library share, the write/read-only method, and I am observing the same behavior. MP3s display okay. I'm pure monkey so I don't have any FLAC files left to test.

DC

[JimH]

Can you provide more details on the external drive?  Brand, model, etc?

[JONCAT]

The external is one of my four drives. It is a PATA Seagte 500GB drive mounted in a FireXpress (made by Adlogix IIRC?) enclosure which has both USB2.0 & Firewire400. I have .ape files spread out across all  the drives.

DC

[glynor]

Dr. C's system is very similar to mine, and I'm not seeing the same issues (I don't think).  My only cover-art related issue is that which I discussed ad-nauseum above, and I also haven't verified that I haven't just been being impatient.  I'd have to check more thoroughly to be sure...

[Matt]

I think we found the issue.  The APE and FLAC plugins were trying to extract image files to a directory that didn't exist.  That didn't work, so we were never able to get the image back out of the tag.

To test this theory, create "JRTemp" under the temp folder on your machine.  It should start working then.  For XP, the full path should look like this:
C:\Documents and Settings\[Username]\Local Settings\Temp\JRTemp

Recently we made this change, but it didn't make it to the input plugins that don't use the JRiver shared code:

Changed: Temporary files are now stored in the JRiver application data folder instead of the temporary folder. (allows better support when running with very restrictive privileges)

This will be fixed in the next public build.  Thanks to everyone for all the help.

[cwilliams222]

I think we found the issue.  The APE and FLAC plugins were trying to extract image files to a directory that didn't exist.  That didn't work, so we were never able to get the image back out of the tag.

To test this theory, create "JRTemp" under the temp folder on your machine.  It should start working then.  For XP, the full path should look like this:
C:\Documents and Settings\[Username]\Local Settings\Temp\JRTemp

Recently we made this change, but it didn't make it to the input plugins that don't use the JRiver shared code:
This will be fixed in the next public build.  Thanks to everyone for all the help.

Matt - thank you very much.  Just did as instructed above, ran "Update Tags from Library" on a number of FLAC and APe files, and now my "Image File" column says that the cover art is inside the file.

Again, thanks for the persistence on getting this resolved.

[JONCAT]

Fix working on Vista x86...thanks!!!!!!!

DC

[AoXoMoXoA]

Fix working on Windowz XP, Thanks.


Question: must I now use "Update Tags from Library" on all the affected files to properly re-embed the images?

[cwilliams222]

I think we found the issue.  The APE and FLAC plugins were trying to extract image files to a directory that didn't exist.  That didn't work, so we were never able to get the image back out of the tag.

To test this theory, create "JRTemp" under the temp folder on your machine.  It should start working then.  For XP, the full path should look like this:
C:\Documents and Settings\[Username]\Local Settings\Temp\JRTemp

Recently we made this change, but it didn't make it to the input plugins that don't use the JRiver shared code:
This will be fixed in the next public build.  Thanks to everyone for all the help.

Matt - if you don't mind me asking, what pointed you to this being the cause of the problem that was being described?  Just curious as how you made this connection.

thanks

[JimH]

Matt made a lucky guess.  Looking at the code helped.

[AoXoMoXoA]

Matt made a lucky guess.  Looking at the code helped.

I thought that was a trained bug-sniffing dog he had there   

[bbrip]

Can you provide more details on the external drive?  Brand, model, etc?

For me, its a LaCie Bigger Disk Network Drive  (2TB)

[bbrip]

Posted the last one before reading to the end..... Great to hear you found the issue.  Not fiddling with temp folders now but eagerly awaiting your next release with the fix