Corrupt poster images

[Spectrum]

I've been noticing quite a few corrupted poster images lately. Not sure if it is happening during transfer or rescaling and it only seems to affect posters. So far I haven't seen anything else pop up corrupt. Deleting the offending file, removing its entry from the ignore list, and issuing a rescan seems to correct the issue, but that's a lot of manual work Images attached for reference.

I poked around a bit and didn't see this mentioned in the known issues thread and don't see any other posts about it so maybe it's unique to my system? Any thoughts on where to look or logs I can capture for you? I don't think that the hard drive where these are stored is crapping out, it isn't showing any other symptoms of errors, but I've been wrong on these things before....

[gplasky]

Can't say I've seen this a lot but I have seen 3 or 4 of these. And if I go to tvdb and find the images manually I can download them with ho issues. So the problem is not in the original image.

Gerry

[Spectrum]

Originally Posted by gplasky

Can't say I've seen this a lot but I have seen 3 or 4 of these. And if I go to tvdb and find the images manually I can download them with ho issues. So the problem is not in the original image.

Gerry

The 3 I posted are just in the past week or so and I've corrected ~ another 4 or 5 in the same time frame. And every time I've checked tvdb for the image, the source has been fine. It seems to be corruption either in transmission of the original image, or in the resize.

Have the ones you have noticed been posters or has it occurred in banners/backgrounds/etc?

[stuckless]

In terms of downloading and scaling, bmt handles all image types the same. I would expect to see the same problem worth banners and backgrounds.

While I've never experienced this myself, any type of transmission d error may cause this.

Without specifics and a reproducible issue it's pretty hard to solve.

[PLUCKYHD]

Yeah I would lean more towards download/connection issues. TVDB and TMDB get overloaded and have issues quite often.

[Spectrum]

Originally Posted by stuckless

In terms of downloading and scaling, bmt handles all image types the same. I would expect to see the same problem worth banners and backgrounds.

While I've never experienced this myself, any type of transmission d error may cause this.

Without specifics and a reproducible issue it's pretty hard to solve.

Understood.

Any idea if disabling poster and background scaling (banner is already disabled) would have horribly ill effects on performance for Phoenix/Diaimond? It would definitely rule out the rescaling question and just leave transmission and other negligible gremlins to watch for.

Originally Posted by PLUCKYHD

Yeah I would lean more towards download/connection issues. TVDB and TMDB get overloaded and have issues quite often.

Makes sense

[stuckless]

Originally Posted by Spectrum

Any idea if disabling poster and background scaling (banner is already disabled) would have horribly ill effects on performance for Phoenix/Diaimond? It would definitely rule out the rescaling question and just leave transmission and other negligible gremlins to watch for.

I'm actually considering removing the scaling from bmt anyways. Most fanart plugins already use the scaling features in the image apis, so, there really isn't a need for bmt to do it. This is carry over from the bmt 3.x and sage6 implemenation. I think you'll be fine if you disable them.

I suspect though, that if the scaling is the problem, then it will simply be moved to the scaling in the image apis (uses the same basic logic)

[razrsharpe]

Originally Posted by stuckless

I'm actually considering removing the scaling from bmt anyways. Most fanart plugins already use the scaling features in the image apis, so, there really isn't a need for bmt to do it. This is carry over from the bmt 3.x and sage6 implemenation. I think you'll be fine if you disable them.

I suspect though, that if the scaling is the problem, then it will simply be moved to the scaling in the image apis (uses the same basic logic)

if the scaling was removed (or disabled) in bmt that would help narrow down if it was the download or the scaling (if done by the plugin using the image apis) that was causing the problem though because if it was a problem with the scaling the original image in the fanart folder would still be ok.

[Spectrum]

Originally Posted by stuckless

I'm actually considering removing the scaling from bmt anyways. Most fanart plugins already use the scaling features in the image apis, so, there really isn't a need for bmt to do it. This is carry over from the bmt 3.x and sage6 implemenation. I think you'll be fine if you disable them.

I suspect though, that if the scaling is the problem, then it will simply be moved to the scaling in the image apis (uses the same basic logic)

OK Scaling disabled. I'll keep an eye on things and may try deleting some fanart and re-scanning just to create some updates. I'll update as soon as I know something definitive or have let it run for awhile and not seen anything bad. Purely for your info at this point, I don't think it's something you should spend a lot of time chasing down. You got better things to do

Originally Posted by razrsharpe

if the scaling was removed (or disabled) in bmt that would help narrow down if it was the download or the scaling (if done by the plugin using the image apis) that was causing the problem though because if it was a problem with the scaling the original image in the fanart folder would still be ok.

This is true assuming that they rescale then cache the image. If that's the case then the image in the cache would be corrupted and the image in the fanart directory would still be good. Of course if they rescale then overwrite the original , all bets are off!

[razrsharpe]

Originally Posted by Spectrum

This is true assuming that they rescale then cache the image. If that's the case then the image in the cache would be corrupted and the image in the fanart directory would still be good. Of course if they rescale then overwrite the original , all bets are off!

I certainly wont speak for all plugins but i think most are doing the caching to decrease access time to the image.... so i dont think they they're replacing the original....

[PLUCKYHD]

Originally Posted by razrsharpe

I certainly wont speak for all plugins but i think most are doing the caching to decrease access time to the image.... so i dont think they they're replacing the original....

I sure hope not that would be a horrible practice to replace people's original image.

[razrsharpe]

Originally Posted by PLUCKYHD

I sure hope not that would be a horrible practice to replace people's original image.

oh ya agreed 100 times over

[Spectrum]

I noticed a corrupt image a few days ago and scanned through the cache/fanart directories and came up with the one I noticed and another one. In both cases the original image is fine and the cached image is corrupt. I've uploaded the cached images, the source images are both >750k so I'm not bothering with uploading them here. If you want them, let me know and I'll get them to you without eating up the forums storage space

Interestingly, these look more like color problems than the first ones I found did.

[razrsharpe]

all of the corrupt images i have are color shifted like your examples... I just disabled the scaling that bmt does by default when an image is first downloaded. Now I'll be on the lookout for differences between the cache and central fanart folder...

[Spectrum]

Originally Posted by razrsharpe

all of the corrupt images i have are color shifted like your examples... I just disabled the scaling that bmt does by default when an image is first downloaded. Now I'll be on the lookout for differences between the cache and central fanart folder...

These were the first 2 I caught that were bad in the cache but the originals were ok. Of course these are the first 2 I caught after I disabled scaling on any of the downloads

If this is a problem with the rescaling algorithm it might be tough for Stuckless and the (other?) Phoenix devs to track down; I bet they didn't actually write it. At this point it is more of a nuisance than anything, but I would like to help track it down if I can

[stuckless]

Originally Posted by Spectrum

I noticed a corrupt image a few days ago and scanned through the cache/fanart directories and came up with the one I noticed and another one. In both cases the original image is fine and the cached image is corrupt. I've uploaded the cached images, the source images are both >750k so I'm not bothering with uploading them here. If you want them, let me know and I'll get them to you without eating up the forums storage space

Interestingly, these look more like color problems than the first ones I found did.

I'd like to see the originals, since from those, i can can run the scaler and see what it produces.

[Spectrum]

Originally Posted by stuckless

I'd like to see the originals, since from those, i can can run the scaler and see what it produces.

YGPM, let us know the results

[Spectrum]

These are just the originals. These seem to rescale improperly every time. I deleted the cached images and flicked back and forth until they got cached again and they show up with the color distortion just like before. I also tried having the ui at a diff resolution so they would scale to a different size and the distortion still occurred. Files md5 the same as the originals from tvdb so it's not like they got corrupted in transit. This is really bizarre!

Also, don't feel like I'm rushing you on this, I'm not. Just trying to provide enough info for you to track down whatever is causing it

[stuckless]

Originally Posted by Spectrum

These are just the originals. These seem to rescale improperly every time. I deleted the cached images and flicked back and forth until they got cached again and they show up with the color distortion just like before. I also tried having the ui at a diff resolution so they would scale to a different size and the distortion still occurred. Files md5 the same as the originals from tvdb so it's not like they got corrupted in transit. This is really bizarre!

Also, don't feel like I'm rushing you on this, I'm not. Just trying to provide enough info for you to track down whatever is causing it

Sorry for the delay... but I've been so busy with other projects that I haven't had time to look at these. I'm sure when I do get time... hopefully I can figure out what is happening based on the images that you've provided. In the meantime the scaling code is in Phoenix, is anyone wants to take a stab at it... I don't have an ETA on when I can get to it

[stuckless]

After doing some research on this, the conclusions are not good. Apparently it's a known bug that the Java ImageIO library (which is what I use for reading/writing images) has issues with some jpeg files that use a different kind of color model.

http://stackoverflow.com/questions/1...ns-jpeg-colors
http://bugs.sun.com/bugdatabase/view...bug_id=4799903

I tried the solutions listed in those articles but it did not fix the problem. The only way I was able to get the file to convert correctly was by changing the source file. If I opened the source file with an image editor, and then just saved it, they the java image scaling would produce the correct file.

Just a note that the issue here is not the scaling. In my test, I would simply read the file and then write the same to another name using the build in java image apis (ImageIO.read, ImageIO.write) and the resulting file was corrupt every time.

Unfortuntely, java doesn't appear to to be resolving this issue, and I'm not sure there is much that I can as well