Print

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

[TP1964]

Have tried a “rebuild thumbnails” - it’s all gone. Help would be appreciated.

[Awesome Donkey]

A thumbnail cache rebuild is required because of this change in MC 34.0.20...

Changed: Media Center will cache a higher resolution thumbnail for cover art, reducing access to the full resolution image. This will cause the thumbnail cache to be rebuild. Updating both server and client is recommended.

On the bright side, higher quality thumbnails.

[TP1964]

Thanks! Just selected all and restarted the build. As long as I’m not having to do this myself… all is good!

Appreciate the info!

[TP1964]

Well, I’d love to tell you that this was the answer - but, alas, no. A huge portion of my library has no artwork - and previously it was complete. Any other ideas or should I just go back to 33?

[JimH]

You may need to set your cover art directory in MC's options.  Search window at the bottom.

Wait longer.

[TP1964]

I waited overnight. No change. Cover art is set in 34, to a 34 application directory - but I don’t see a “cover art” directory in 33. I also don’t recall setting one. Please tell me that all of these aren’t just lost.

[mwillems]

I waited overnight. No change. Cover art is set in 34, to a 34 application directory - but I don’t see a “cover art” directory in 33. I also don’t recall setting one. Please tell me that all of these aren’t just lost.

You should have automatic backups of the MC33 library that may contain the thumbnails.  If you roll back to MC33, do the images come back? I think JRiver always stores cover art somewhere (either in the file or in a specified directory or both) so it would be very odd if the art that was previously present is gone. 

To be clear, you ran the "build missing thumbnails" menu item under Options-->Tree and View?  Or something else?

[TP1964]

So here is where I’m at:

1. Upgraded from 33 to 34 - no artwork.
2. Ran rebuild thumbnails - waited overnight - about 50% of the library had no covers.
3. Ran rebuild thumbnails again with all albums selected - still only about 50% of library had covers.
4. Tried to go back to 33, acts like it’s a completely new install. So I just gave up on that - don’t want to start from scratch.
5. Ran quick find in file / Cover Art Directory on all albums - this brought me back to about 90%-ish of all artwork.

So now I’m going through and restoring the few that didn’t by “add from file” in the cover art menu item. I’m about halfway done, so I’m not going to pursue this further. But if there is a recommendation of the best practice on the settings, so one doesn’t lose the artwork between versions like this, I’d very much appreciate the guidance.

If it helps, I would say the majority of the albums that were missing artwork were SACD iso files. Now most of those recovered after I ran “quick find in file…” - but initially those were the ones that acted like there was no artwork and now the ones that are left are just random. Various file types and the majority had artwork in their folders.

Again, guidance is most welcomed.

[mwillems]

I am also seeing major issues with missing cover art in MC 34 for Linux as well.  About half my files don't have cover art and attempting to add back the old cover art from files manually is not working.  Almost all the files showing no cover art have cover art embedded in the file and I can see it in other software, but JRiver can't seem to see it or add it back?

Weirdly, my "missing cover art" smartlist shows only one or two albums for which cover art is genuinely missing.  All the other albums that are not showing cover art in normal library views are not appearing in that smartlist?

This is after manually rebuilding all thumbnails.  Something strange is going on.

[Awesome Donkey]

Is the missing cover art embedded in the files or external cover art images (e.g. folder.jpg). For me all my cover art is embedded in FLAC and DSF files but maybe there's issues with external cover art images?

[mwillems]

Is the missing cover art embedded in the files or external cover art images (e.g. folder.jpg). For me all my cover art is embedded in FLAC and DSF files but maybe there's issues with external cover art images?

So I figured out my issue.  The new thumbnails took up quite a lot more space than the old ones (3-4x as much space) which exhausted the space on the partition that I use for JRiver's library.  So I was just seeing some squirrelly behavior because I'd run out of harddrive space because the JRiver library went from 3 GBs of thumbs to 12+ GBs of thumbs.  Making room on the drive and rebuilding fixed my issue, so not the same issue as OP.

[TP1964]

AD - I’d say the majority - if not all - of the ones with missing artwork for me, were external artwork. As I said previously - the majority were SACD iso files, which I presume have to keep everything external since you can’t really write into them with tags.

[TP1964]

Well gentlemen - I’m back to Media Center 33. There is definitely something up with the thumbnail generation. MC34 locked up on me several times. Every time I’d get back in - the thumbnails were gone and it was like starting over.

I restored MC33 and pulled in from my last backup. There are also no thumbnails in there either now, but I’m betting since they aren’t large in scale - it shouldn’t take long to rebuild.

You might want to make this an option - especially for those of us with really large libraries. I also think the large about of thumbnail rebuilds is what was choking up the thing and causing it to lock up, not sure. I’ve been perfectly happy with the resolution of the thumbnails I have - I’ll check back in later on and see if progress has been made - but for me - for now - MC34 is unusable.

I’ll also mention that it mucked up my remote connectivity as well. I lost access to it from clients. But that’s neither here nor there at this point. Just things you may want to look at.

Thanks

[JimH]

Disk space?

[Awesome Donkey]

I noticed that too during my thumbnail rebuild with MC34 on my M4 Mac Mini that it used up all the disc space during the process, which I had to stop, close MC and reboot the Mac then verify that disc space was back to normal then restart the rebuild process. I ended up having to do it twice, which was a little strange.

So there *is* something funky going on with thumbnails, not sure why it would cause all space to be used while running the rebuild process.

[TP1964]

JIMH - if it’s using my root disc as a temp location - then, very likely. I don’t have much space there. The files are on a 40TB NAS - so if it is using the music folders - then, no, shouldn’t be running out of space at all.

AD - my observation as well - but I didn’t check the disc space. And I doubt seriously that I could free up enough to make it work. So unless there is a fix or we are allowed to set a temp directory, I may be stuck on 33.

[TP1964]

Just following up - I would say disc space was a likely culprit for me as well - I only have about 490MB left on my 256GB drive - and if these new thumbnails get as big as people are saying - then that’s probably the issue. Any work around?

[TP1964]

Update - I think I may have this figured out - might just be my own lack of understanding of all of the settings of MC. I’ve stuck pretty much with the defaults except where it came to sound manipulation.

I’m still running MC33, but I went into OPTIONS—> FILE LOCATION—> PROGRAM FILES —> Temporary Files

I set this to a folder I created on my NAS.

Now while rebuilding the thumbnail cache - it is dropping the temporary files on the NAS instead of my woefully undersized main drive. Yes, it’s a lot slower, but it’s not eating up my root drive space.

i’m going to let this finish and if it works out well, I’m going to reload MC34 - set the temp directory, restore from a backup of MC33 once I get it where i want - then retry the thumbnail rebuild.

I’ll report back once I’m through all of this. Hopefully that’s it. While it hasn’t been an issue up until now, I think the size of the new thumbnails - combined with the fact that it appears to hold on to the “temp” files until the task is complete - which in my case means, quite literally, hundreds of thousands of files — times 3 (I assume these are large, medium and small)

[EnglishTiger]

I'm not surprised those Larger Thumbnails are causing problems when it comes to disk  space on the mac.

Attached Image 2 is for the thumbnails for just under 30,000 tracks on my win PC and Image 2 is for those for just under 3,430 tracks on my Mac PC.

Although the difference in the numeric part of the file sizes is understandable/explainable the fact that on the win the file size is in Kb's whilst they are in Mb's on the Mac is not.

[bob]

Just following up - I would say disc space was a likely culprit for me as well - I only have about 490MB left on my 256GB drive - and if these new thumbnails get as big as people are saying - then that’s probably the issue. Any work around?

If that's an SSD you REALLY should try to leave 10% space free or you could get some crazy hangs when the disk tries to reorganize blocks.

[TP1964]

Thanks Bob - I did do quite a bit of clean up before I discovered I could move the TEMP folder. I’ve got around 50GB open out of 256GB now - so that should help on several fronts.

I’ll let you know how bumping up to MC34 does, if I can get to it over the weekend.

Have a good Friday!

[TP1964]

So, another update - I reinstalled MC34 - and… out of the gate it seems to be working fine (this is different then what happened the first time where I essentially had no thumbnails - so I don’t know if the TEMP file relocation helped or what.)

However, went to rebuild the thumbnails in MC34 and it has just eradicated any free space I had on my drive in a matter of minutes (before I started the free space was 54.1GB) - I’m at about 26k of thumbnails out of 156k total and I now have 515MB left on my root drive.

I still have MC33 installed - the thumbnails folder in that version is 1.39GB for the same library.

MC34 isn’t even a third of the way through the generation process and is up over 52GB.

Bob - I have to say, unless you tell me that MC34 is creating some kind of super hi-res thumbnails (which I’m not entirely sure what the point of that would be) - there is something definitely wrong with the creation of the new thumbnails in MC34 for Mac.

Now if this is by design and this is the direction that JRiver wants to go with MC34, then I’m going to highly suggest adding a setting to relocate Thumbnails as well, because relocating the TEMP directory only definitely isn’t enough.

I’m going to let it continue to run, at least until it comes crashing down and I’ll report back. I know Mac has the tendency to manage disc space in a really weird way - so maybe at the end of the process a bunch of space will open back up - who knows.

I’ll keep you posted.

[TP1964]

Adding… I am monitoring the root drive, thumbnail folder and the temp folder (which is on an external drive now):

52GB taken up on the root drive in total (this is with about half of the thumbnails generated)
The thumbnail drive says 4.7GB (but then in parentheses says 52.38gb space taken on disc)
Plus the TEMP drive is varying between 8 and 20GBs at any given time.

Interestingly, the space left on the root drive varies between 480MB and 515MB (it goes up and down and the root drive has never “filled up”)

The thumbnail generation continues to work apace. So, I’m letting it run. I’ll give a final report of where the space is, assuming it completes the generation - after i do a reboot.

At this stage I can’t really say if this is an MC issue or just Mac weirdness on how it manages drive space.

I know when I generated all of the thumbnails on MC33, it did something similar - and after it ran - and after a reboot, it jumped back up to 54GB of free space.

[TP1964]

Final Report - Happy to report that the rebuild DID complete - no errors, no lockups - even though while it was running it left barely 1% of the drive space available.

After generation and after reboot:

Root Drive: 48GB out of 256GB - this jumped up from 482MB after a reboot.
Temp Drive: 22kb - before the restart, the temp drive had close to 32GBs in it.
Thumbnail Folder: 4.73GB - up from 1.39GB in MC33 - so roughly 4x the size.

I’ll leave MC33 in place, but it looks like it is working correctly. You may just want to advise some kind of warning to move the TEMP folder to another location if the root drive doesn’t have a lot of space (which I’m guessing is common in Mac Minis) because between the two (temp folder and thumbnail folder) it seems to use up all of the drive space - causing the lock ups.

Happy to answer any questions if you need more info - but happy to be up-to-date.

Thanks to JimH, AD and Bob - as always - you guys make this program great with your responsiveness!

[Hendrik]

Thank you for sticking with it, the information is helpful.

I may have identified a (Mac exclusive) issue that would result in the excessive space usage which disappears once its done or you rebooted. Will follow up on that issue today and hopefully have it fixed soon.
Not quite sure why its using so much Temp space yet, it may be a related issue or something else entirely, but will also check that once the known issue is resolved.

Your final file size for the thumbnails is expected and even with your ~156k files within expectations - and hopefully also not excessive for the system resources available.

[TP1964]

Happy to make a tiny contribution - glad to hear it was helpful. In my case, since the excessive temp files clear out after a reboot, it was fine. I still believe it may be beneficial at some point to allow relocation of the thumbnail folder as is done with the cover art folder. But for now it’s working well for me. Thanks for getting to the bottom of it!

[Awesome Donkey]

The Mac space issue when rebuilding thumbnails was really the only issue I encountered, so it's much appreciated that you've hopefully found the issue. Thanks Hendrik!

[Hendrik]

I have also identified the issue that caused temporary files to be left behind, unfortunately that fix didn't quite make the latest Mac build, but the next one will have it of course.

[TP1964]

I have also identified the issue that caused temporary files to be left behind, unfortunately that fix didn't quite make the latest Mac build, but the next one will have it of course.

FANTASTIC Hendrik - that was the last bit that I noticed. I just went ahead an manually deleted them but good to know that this is taken care of for the future! Great work!

[Awesome Donkey]

Should be fully fixed in 34.0.24 now.