charrua Wrote:1-The reason for an image cache in the first place is speeding up loading times, and I'm not sure if that would be the case with a networked repository instead of a local one.
I agree that the image cache has to stay on the local hard drive for latency issues.
Here's what I'm proposing, let me know your thoughts:
When an XBMC instance finds a new movie and it's not in the database, it should then scrape all the movie information and update the database. For the thumbs/fanart/images, they should be stored locally in its cache, but also written to the database (as BLOBS). If any of these images are ever updated, they should be updated in the local image cache and in the database (along with a last-modified field).
Now when a second client comes along,
we don't have to worry about client-specific URI's; it only needs to know how to connect to the database. It sees the new movie in the database, and checks to see if it has any thumbs/fanart etc. stored in its local cache.
From here, it has 3 options:
- If it doesn't have them stored in its cache, then it downloads them from the database and writes them to its cache.
- If it has them in its cache, but the file has been modified (based on a last-updated field), then it updates it's cached image.
- If it already has them and they're all up to date, then it simply skips.
This way the local, speedy cache gets preserved on all XBMC instances. It also keeps all images in sync across all XBMC instances. When an image needs to be downloaded for any subsequent clients, it gets downloaded quickly from the local MySQL server, as opposed to across the internet. The client then has a local cached copy for even faster subsequent reads.
Thoughts?