Cover Images Missing

[Stoom]

All the cover images in CDPedia on my Mac have gone missing. But they are still all there in PocketPedia on my phone. Anyone know how to get them all back on to the Mac. Syncing has not worked.

[Conor]

Hi Stoom,

Thank you for the details. The sync is not backwards as CDpedia acts as the master database, only images specifically added in Pocketpedia are synced backwards. Do check your data folder in ~/Library/Application Support/CDpedia. To open your home Library folder, hold down the option key on your Mac and use the Finder "Go" menu and select the "Library" command. There is a folder called "Covers" should have all your covers in JPEG format, feel free to restore it from your backup method if there is nothing there. Otherwise let me know more details and we can source out what is going on.

Regards,
Conor

[Stoom]

Ok I know what happened now. I lost my desktop and backup hard drive on the same day. (long story). So when I got my new desktop Mac I restored from Pocketpedia - and that's why all the artwork is missing. Guess I'll be putting them all back in by hand!

Thanks for the help.

[FineWine]

Conor I notice when I connect my iPhone iOS 11.3 to iTunes and in File Sharing > Pocketpedia, in Pocketpedia Documents there is a Folder called Covers, it is zero bytes. Would it not be convenient to have that Covers folder populated with the covers stored by the pedia's in sub folders for each pedia so that the above situation like 'Stoom' could be easily rectified.

[Conor]

@Stoom Sorry to hear about your Desktop and backup dying on the same day. Worry not, the covers can always be pulled of the net again.

If you select all your items with "Edit -> Select All" and then control click on the image well on the bottom left and use "Download Cover -> original search site". This function is exact, it will only get the cover if there is a unique ID for that search site. Dog tag for Doghouse, ASIN for Amazon, Catalog Number for Discogs, etc. If you are not sure about the original site, you can look at the URL field for an item, to see where it came from, click on the title in the details view and it will take you to the original website.

If after that you still have some items without covers you can use "Album -> Update from -> Doghouse". Since Doghouse is under our control it's very good about exact matches as it gets all the data and can make sure that title, album, release year all match. Other sites on that list have more basic searches and might pick up a identical named album from another artist, so it's best to run on smaller selections and verify.

@Finewine The covers for the iPhone have been down sampled and resized for the iPhone and hence why it tries not to bring them back. But that is a legacy decision when smaller resolution screens ruled and space was limited. Now that default iPhones are finally coming with more than 8 gigabytes of storage, it's time to send the full resolution covers and rework the sync so that it can send them back in large chunks. It does try to send with the automatic restore like Stoom did, but was never meant to go that way for so many covers.

Apple frowns on displaying the internal files. I would have loved to simply display the entire data folder in the File Sharing area, but Apple would have rejected Pocketpedia. I get away with displaying that Covers folder you see, that has the covers that are not yet synced to the main Database simply because some people use Pocketpedia without a Mac and would need access to covers then. So in that folder are all the covers you capture in Pocketpedia but when you sync them they go to the hidden place were Apple likes them.

The solution is to send the original covers covers and get that restoring as well, so there no difference between Pocketpedia data and CDpedia data.

[Stoom]

Wow! Thanks so much. That has saved me a lot of work.

[FineWine]

Ah Ha I understand now. Is full use of iCloud still on the cards?

[Conor]

Yes, will wait and see the adoption rate of 6.0. That will limit Mac OS version and make it more feasible. Specially if the use of 10.13 is dominant over 10.12.