[split] Issue with Generic Album Scraper
#16
Great that it's working for you Big Grin

From what you said, I guess you are using Emby more as a media manager than anything else, as this is indeed an area that Kodi doesn't excel in.  However, there are third party managers that can produce nfo files for Kodi to scan but don't need complicated addons or much/any setting up to interface with Kodi.  It's very much a user preference here, but I myself use a 3rd party media manager 99% of the time.  It means I know exactly what is in the nfo that Kodi is going to scan, what the artwork will be etc etc.  It's maybe not as automatic as some solutions but "it works for me"!.

There is a section of the forum dedicated to such supplementary tools for Kodi here Maybe some food for thought in the future.
Learning Linux the hard way !!
Reply
#17
Hey ok great, thanks @black_eagle!

I hadn't thought in that direction in the past (obviously), but I appreciate the lead.

I'm going on a short trip for a few days, and I'll take a look at the threads you linked to when I return. I'll let you know how I go either way, and thanks very much again, warm wishes, Peter.
Reply
#18
Hi again @black_eagle 

Once again, thanks very much for your assistance, I’m really happy with my now almost complete set up.

I’ve followed your very helpful suggestion to consider using a 3rd party media manager, and I’m pleased to report I have had great results and I see clearly how such a set up gives me much more control over the outcome than using Emby or Plex to manage my metadata.

I also understand now I never even needed an Emby/Plex server, given that my Mac will serve to my Shield via SMB 2/3 anyway.

An overview of how my set-up now is:
* I’ve abandoned Emby server
* I’m not using Kodi on the Mac as a server either (just using Kodi there to scrape the ratings), I’m just connecting my Mac to my shield with SMB3.
* Scraping the ratings on the Mac Kodi version worked beautifully (aside for a few (maybe 1%) discrepancies in metadata, but they’re easily sorted out using Picard)
* I’ve started using MediaElch to view/edit my metadata, it works really well! No more unanticipated Emby rescans of metadata/images I’ve already set, I imagine I’ll not need to edit these files again.
* Kodi on my Shield is flying along, and only has 0.5 Gb of storage used, so I’m imagining most/all of the imagery is actually on my Mac, and that’s how I like it.

I really think I’m all set!

The only question I have left if you would be kind enough to indulge me is what the following entries in the various updated album NFO’s (created by Kodi on the Mac) are:
* <thumb spoof="" cache="" aspect="thumb" preview="http://assets.fanart.tv/preview……

I’m almost certain they are links that Kodi (client on my Shield) will use to load imagery on the fly when I call up the album.

If true, I presume that on the fly loading is happening instead of referencing any previously scraped imagery on my (server) Mac. Is that the case, and if so, is my (small, 16Gb) internal storage on my (client) Shield at risk of filling up through repeated use of this feature?

I ask because I think I might prefer to organise my (mostly already downloaded artwork) with MediaElch on my (server) Mac instead of the (client) Shield doing things on the fly….  My reasoning: desire to keep the Shield cache as lean as possible, speed of loading the data on the Shield (quicker across the LAN than from Australia to a server in the US), and just because I could then see all the images in MediaElch for future edits.

If any of the above makes sense, I’m wondering if it is prudent/possible to ensure the NFO’s don’t get the thumb/spoof entries in them (again an assumption, this one being the spoof entries override local network image reading, I understand that might be incorrect).

Hopefully the above reasoning/questions isn’t too off beam, and I’m really happy to be corrected. I’ve tried to do searches on the spoof entries but didn’t find much, except for entries in the context of writing scrapers.

Thanks again, I appreciate your assistance and patience. I believe I’m pretty set now, I’m really happy, thanks.

Cheers.
Reply
#19
Glad you've got it all working how you want!

How it works with images is like this.  The initial images are loaded from wherever they are located, so http s://somesite.com/someimage.jpg or smb://myfiles/mystuff/mypic.png  etc etc.  However, for speed of access (and historically I think because of internet hiccups etc) Kodi caches each image locally and uses the cached image subsequently.  This works well usually but can cause some or all of the following issues
  • When exporting libraries, if you export cached art it will replace local art but will be of inferior quality
  • Updating local art is not always reflected in Kodi for 24 hrs (time for cache to expire)
  • Images can get 'stuck' whereby the cached image is loaded even though it's changed locally or remotely
  • The thumbnail cache can grow quite large, especially for devices with limited on-board storage
You can use path substitution to move the thumbnail cache onto your Mac, avoiding it taking up any space on your shield. If you do happen to hit any art cache issues, there is a script somewhere on the forum that can fix nearly all issues.

So what will happen in your case is that Kodi will load the initial image from your Mac, create a cached copy on the shield and then use that cached copy. After 24 hours it will check to see if the original image still exists at the original location and if so, it will continue to use the cached copy. If not, it will load the new image at that location, cache that and check again in 24 hrs etc etc

As an example, my current thumbnail cache for my main machine is 29,823 items, totalling 5.1 GB. In contrast, the thumbnail cache on the rPi3 in my bedroom is 212.3M Thumbnails/ - both machines access the same shared libraries but the rpi doesn't have access to the PVR artwork that the main machine has.
Learning Linux the hard way !!
Reply

Logout Mark Read Team Forum Stats Members Help
[split] Issue with Generic Album Scraper0