Print

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

[Audioclyde]

I have been making some changes in my cover art (I have the jpg saved in the album folder and also select the option to have it added to the track's metadata), and all has been going well.  Just now I tried to change the cover art, and now JRiver will no longer save/add my cover art...any ideas?

thanks,

Randy

[Audioclyde]

Any subsequent attempts result in a crash.  I will attempt to send error log.

[JohnT]

Is it a particular music track and jpg, or does it now work on any?  If a particular one, you could Dropbox it to us.

[MrC]

Cover art is having problems for me too.  I imported about 18.3k mp3 files, each containing embedded cover art.  Very few show cover art, and rebuilding thumbnails does not help.  [Image File] has the value "Inside File".

[JohnT]

Cover art is having problems for me too.  I imported about 18.3k mp3 files, each containing embedded cover art.  Very few show cover art, and rebuilding thumbnails has no affect.  [Image File] has the value "Inside File".

Could you send one of those files to me?  It sounds like we're able to detect the image in the tag but not extract it for some reason.  Thanks!

[MrC]

I sent you a link via PM.

The files were all created on Windows via MC's HH sync, converting FLAC to mp3 and embedding artwork.

[JohnT]

johnt @ jriver ?

Nevermind, I sent you a link via PM.

The files were all created on Windows via MC's HH sync, converting FLAC to mp3 and embedding artwork.

Darn, they all worked fine for me on both our Mavericks and 10.8 systems.  The tags say 'inside file' and the image looks fine.

[MrC]

My procedure was to set up auto-import to import the entire collection of mp3 files.  Auto-import is configured to not build thumbnails, as i wanted to do that later.  But it appears I can't get most to build.  Some I'd say less than 20% build, including the one you have.

[JohnT]

I started on a fresh system and used the same procedure and didn't have the issue, so wondering if there's a problem in the thumbnail database.  
Key question: do you see the cover art OK in Playing Now when you play the tracks?

[MrC]

Yes, it appears during Playing Now.

[Matt]

Yes, it appears during Playing Now.

This is a good clue.

It means import works, the library has the correct data, and the program is able to get and decode the cover art for the file.

So the problem must be in the thumbnail database.

Some things to try:
1) Resize the thumbnails in the list to see if any size works
2) Do right-click > Cover Art > Rebuild thumbnail on a few to see if this makes them work
3) Force MC to rebuild thumbnails (Options > Tree & View > Thumbnails > Erase all thumbnails...)

It would be nice to figure out the root cause.  Thumbnails are stored in a few big files in the app data folder.  They should be built on demand by any list.

[MrC]

1. No change.
2. No change.
3. Erased all thumbnails, and they stay erased.

I quit MC and restart, selected a small group of files, and then tried to Rebuild Thumbnails.  There is a dialog indicating MC is about to make N changes, I approve.  However, there is no change.  All thumbnails are now missing.

[Matt]

If you make a second library, and import that one file, does it still have no thumbnail (but will have cover art in Playing Now when playing)?

If so, I would expect us to be able to reproduce if we had the file (and I thought John did have the file).

[MrC]

John does have an album full of files.  But to be clear, it is 18,300 files or 1460 albums full of no thumbnails, so it isn't related to a file or two.  I now don't have a single thumbnail (since the clear).

It seems the problem is that once the failure occurs, thumbnails will not rebuild for any file.

Shall I still try your requested test?

Update: If I resize the thumbnails to really large, they suddenly appear.  So it is the smaller, scaled versions that are failing.

[Matt]

It seems the problem is that once the failure occurs, thumbnails will not rebuild for any file.

I wonder if it could be a database issue?  Anything suspicious in the [App Data]\Thumbnails folder?  What if you rename that folder and launch?

Shall I still try your requested test?

I'm just trying to figure out any way to reproduce.

Update: If I resize the thumbnails to really large, they suddenly appear.  So it is the smaller, scaled versions that are failing.

At a large enough size, it switches to full resolution images.

[MrC]

Here's what I have. 

Code: [Select]

$ pwd ; ls -lR
/Users/MrC/Library/Application Support/J River/Media Center 19/Thumbnails
total 0
drwxr-xr-x  3 MrC  staff  102 Sep 27 09:04 {17E641DC-8C49-A74B-96F8-6552D7A0B108}/
drwxr-xr-x  3 MrC  staff  102 Nov  4 12:41 {51C8EF47-D14D-FD43-A122-E2390CE1321D}/

./{17E641DC-8C49-A74B-96F8-6552D7A0B108}:
total 0
drwxr-xr-x  9 MrC  staff  306 Nov  6 13:11 Normal (v3)/

./{17E641DC-8C49-A74B-96F8-6552D7A0B108}/Normal (v3):
total 286828
-rw-r--r--  1 MrC  staff  218103808 Oct 29 12:38 Thumbnails (large).jmd
-rw-r--r--  1 MrC  staff   58720256 Oct 29 12:38 Thumbnails (medium).jmd
-rw-r--r--  1 MrC  staff   16777216 Oct 29 12:38 Thumbnails (small).jmd
-rw-r--r--  1 MrC  staff      95954 Nov  6 13:11 field (thumbnail info (local)).jmd
-rw-r--r--  1 MrC  staff       2930 Nov  6 13:11 field (thumbnail offset large).jmd
-rw-r--r--  1 MrC  staff       2930 Nov  6 13:11 field (thumbnail offset medium).jmd
-rw-r--r--  1 MrC  staff       2930 Nov  6 13:11 field (thumbnail offset small).jmd

./{51C8EF47-D14D-FD43-A122-E2390CE1321D}:
total 0
drwxr-xr-x  4 MrC  staff  136 Nov  4 12:41 Normal (v3)/

./{51C8EF47-D14D-FD43-A122-E2390CE1321D}/Normal (v3):
total 8196
-rw-r--r--  1 MrC  staff  8388608 Nov  4 12:41 Thumbnails (medium).jmd
-rw-r--r--  1 MrC  staff       25 Nov  4 12:41 field (thumbnail info (local)).jmd

[MrC]

If I rename Thumbnails to Thumbnails.save, all thumbnails are rebuilt correctly.

And here's what I have now:

Code: [Select]

$ pwd ; ls -lR
/Users/MrC/Library/Application Support/J River/Media Center 19/Thumbnails
total 0
drwxr-xr-x  3 MrC  staff  102 Nov  6 13:14 {17E641DC-8C49-A74B-96F8-6552D7A0B108}/

./{17E641DC-8C49-A74B-96F8-6552D7A0B108}:
total 0
drwxr-xr-x  9 MrC  staff  306 Nov  6 13:15 Normal (v3)/

./{17E641DC-8C49-A74B-96F8-6552D7A0B108}/Normal (v3):
total 65668
-rw-r--r--  1 MrC  staff  41943040 Nov  6 13:15 Thumbnails (large).jmd
-rw-r--r--  1 MrC  staff  16777216 Nov  6 13:15 Thumbnails (medium).jmd
-rw-r--r--  1 MrC  staff   8388608 Nov  6 13:15 Thumbnails (small).jmd
-rw-r--r--  1 MrC  staff     96730 Nov  6 13:15 field (thumbnail info (local)).jmd
-rw-r--r--  1 MrC  staff     10340 Nov  6 13:15 field (thumbnail offset large).jmd
-rw-r--r--  1 MrC  staff     10336 Nov  6 13:15 field (thumbnail offset medium).jmd
-rw-r--r--  1 MrC  staff     10312 Nov  6 13:15 field (thumbnail offset small).jmd

[Matt]

Is it possible the program doesn't have write access to those files somehow?

For example, "Thumbnails (large).jmd" is around 200MB.  After deleting all thumbnails, I would expect it to be much, much smaller (maybe 65k).

Also, the date on the data files is a week ago even though you can see the .jmd files were changed recently.

[Matt]

I'm testing on Windows right now, but the data files (Thumbnails (large).jmd, etc.) get deleted as soon as I pick 'Erase all thumbnails...'.

They get recreated when building the first thumbnail, and start as 8MB.

[Matt]

John just tested on OSX 10.9 and the files get deleted when erasing thumbnails for us.  Any idea what might be different?

[MrC]

I'm trying to see what it might be.  The (effective) UID is the same for MC and the files, and the file is writable so that's not the issue.

I copied, preserving timestamps, the old Thumbnails directory back, and started MC.  MC immediately started updating the thumbnails, with a quirky exception.   It would not update thumbnails if I scrolled beyond a set of files, regardless of returning to those files later.  So its like those that are skipped, stay skipped.  Manual update worked.

When I now erase all thumbnails, they do get erased entirely, and then automatically start to get regenerated, with the same quirk noted above.  In a non-thumbnail view, the Thumbnails (large).jmd gets deleted when erasing all.

[MrC]

I restored the Thumbnails folder from an early morning snapshot via Time Machine to be sure I had exactly the same contents and timestamps.  Upon opening MC, thumbnails started rebuilding.  So, is there some lock or something that might have prevented the file or folder from being touched or used?  Or is there some possibility another thumbnail file / UUID was being used?