2013-06-17, 07:43
I've got a bit of an oddball use case here, so bear with me while I explain. I'm using XBMC in an embedded linux environment where the filesystem is normally run in read-only mode. I've scanned content into my library (while the filesystem was read/write), then switched to read-only mode. At this point, things work more-or-less correctly. I can navigate the system and things look correct on screen. I can use the Android remote successfully, and things look and function correctly. Now when I go to use the iOS remote on an iPhone, that's when problems arise. Specifically, no thumbnails were showing up. As a test, if I switch to the filesystem read/write mode, then thumbnails show up in the iOS remote UI. In looking at what's writing to disk, what I can see is that as I navigate with the iOS remote, XBMC is populating new thumbnails into it's thumbnail database. Here's an example from my data:
2013-06-16 23:21:51.473880230 -0600 ./userdata/Thumbnails/b/bdd27d66.jpg
2013-06-16 23:21:48.823943992 -0600 ./userdata/Thumbnails/7/7b6c01b7.jpg
2013-06-16 23:15:00.293740190 -0600 ./userdata/Database/Addons15.db
2013-06-16 23:14:06.135035085 -0600 ./userdata/Thumbnails/4/4b747f9c.jpg
2013-06-14 22:41:53.734311030 -0600 ./userdata/Database/MyVideos75.db
2013-06-14 22:41:50.014405391 -0600 ./userdata/guisettings.xml
2013-06-14 22:41:50.004405645 -0600 ./userdata/profiles.xml
Notice the bolded items have a timestamp that is two days later than everything else. That's because those items were created when I tried browsing using the iOS remote and switched to a read/write filesystem.
I know XBMC's thumbnail database can be a fickle beast. But I suspect that there's something about how the iOS remote queries images that is causing it to think it has to re-generate thumbnails. The thumbnail filename comes from the hash of the path/URL of the source image. If the source image path is somehow subtly different, that would cause it to think it has to generate a new thumbnail file. The content in my library has special characters (eg: ampersand, and single quote), and thus it is possible that the source image path has those characters in an escaped format, and that is leading to this confusion.
Regardless, I think there is a potential bug here that will cause users who browse the library with the iOS remote to generate duplicate thumbnail images.
2013-06-16 23:21:51.473880230 -0600 ./userdata/Thumbnails/b/bdd27d66.jpg
2013-06-16 23:21:48.823943992 -0600 ./userdata/Thumbnails/7/7b6c01b7.jpg
2013-06-16 23:15:00.293740190 -0600 ./userdata/Database/Addons15.db
2013-06-16 23:14:06.135035085 -0600 ./userdata/Thumbnails/4/4b747f9c.jpg
2013-06-14 22:41:53.734311030 -0600 ./userdata/Database/MyVideos75.db
2013-06-14 22:41:50.014405391 -0600 ./userdata/guisettings.xml
2013-06-14 22:41:50.004405645 -0600 ./userdata/profiles.xml
Notice the bolded items have a timestamp that is two days later than everything else. That's because those items were created when I tried browsing using the iOS remote and switched to a read/write filesystem.
I know XBMC's thumbnail database can be a fickle beast. But I suspect that there's something about how the iOS remote queries images that is causing it to think it has to re-generate thumbnails. The thumbnail filename comes from the hash of the path/URL of the source image. If the source image path is somehow subtly different, that would cause it to think it has to generate a new thumbnail file. The content in my library has special characters (eg: ampersand, and single quote), and thus it is possible that the source image path has those characters in an escaped format, and that is leading to this confusion.
Regardless, I think there is a potential bug here that will cause users who browse the library with the iOS remote to generate duplicate thumbnail images.