Questions about image handling

I have a media management application that I am attempting to extend to support the firecore media player. It was previously designed for xbmc (i.e. generated .nfo and .tbn files) but I have modified it to support the xml format firecore uses as well as the file naming conventions. It is working fine, but i noticed some behavior while doing this that made me curious as to how the image handling is performed internally.

In a nutshell, I noticed when firecore is doing its first time loading of metadata that certain image files load very very quickly (nearly instantly) while others take as long as 3 or 4 seconds to load. I can find no rhyme or reason to why though…

It does not seem to be due to file size differences or size - as i have tried resizing/recompressing them all different ways. I have even tried storing the data as BMP or PNG (retaining the .jpg extension) - which works fine but doesn’t make a substantial difference in load times. I even tried compressing them to specific byte sizes (i.e. 8kb, 16kb), but no difference. It seems noting I do changes this behavior - certain files just intrinsically load faster. I guess it could be some odd network/sever/sambe side-affect, but what it weird is that the files that load very quickly ALWAYS load very quickly - regardless of compression, format, or size…

I was just curious if anyone who might know could share what causes this. I am linking 4 files from below - the first two load almost instantly on my setup, while the 2nd two load normally (i.e. slowly).



Note: I am linking directly to the images from themoviedb, but my code loads these images directly from the media source folders (which is on a smb share).

Anyway, my hope was to determine why firecore loaded the 1st two so much faster and possible apply this “optimization” to all of my images.

Also… I realized the 2 examples I gave are visually very simple and contain alot of black - which might have been a possible explanation. But the following image also loads very very quickly, and is both complex and contains a large number of distinct colors

What is it about these images…? Its really bugging me :slight_smile:

Are all your files contained in the same folder, or do some folders have a higher number of items?

In the current version, metadata loads much quicker in folders that contain a low number of items (less than 50) whereas folders with more content take longer to load.

The good news is that the next version (coming later this week) includes a number of improvements that result in substantially faster cover art loading.

No. Let me clarify my description a bit.

Lets say you have a source folder with movie content and 4 movies (the 4 example movies I gave). You have it configured to use list view and you are using .jpg files stored with the media for the cover art. The very first time you access this folder (no cached metadata) media player will go through the files and extract whatever metadata it can get - but it does not load cover art until an item is actually viewed.

Now you go use the remote to scroll through the 4 movies. The ones I described as loading “fast” do not display the “fetching” animation at all (or it happens so quickly that you hardly notice it). The other 2 display it for like 3 or 4 seconds. This seem to happen regardless of the resolution of the images or their format…

Granted this only happens once, because at the point of loading them the first time they are cached locally on the ATV. But I was just curious if there was an explanation for WHY it seems to consitently behave differently with certain images.

Got it.

This may be resolved with this weeks version, but I’ll see if we can replicate the issue here to figure out what’s going on.

Good to know. Thanks for following up.

Before you go on a wild goose chase… I figured it out. I should have tried this before I reported the issue - Im a developer so I should know better. Sorry.

Anyway, I was setting up a test case for you and in doing so realized what was happening. I was replicating the scenerio I described above, but was using a small 1MB avi file to represent each movie. After setting this and testing it everything loaded fast… So then I tried with my original movie files instead (which are large mkvs) - this triggered the behavior I described. So it appears it is not the images that cause this at all - it is something about the media files themselves.

I just assumed that once media player did its background metadata load upon opening a folder it would no longer be digging into the media files themselves when you scroll through them - but it appears that it does in fact read them again (maybe this is the point at which the codec and stream info is detected).

Anyway, sorry about that. Mystery solved. I suspect that you guys are loading the cover art on one thread and inspecting the media on another, and the 2nd thread causes the 1st one to slow down on certain files (or you are simply waiting for both processes to complete serially before the UI gets updated).

If that is in fact what is happening I would suggest you may want to delay inspecting the media for codec information until the user wants to play the file (or until the information is otherwise needed) as it does slow down the UI considerably for some files.