@finite void said:
so whilst i wait for several hundred gigabytes to import to PLEX & automagically provide Thumbnails!?! which it is unable to,… meh.
can re-install Windows 10 LTSB x64 if needed Developer input,…
hundred gigabytes is the cached images / posters?
@finite void said:
pls BUMP to Developers,…
I don’t have anything to bump. Have not got any logs of an initial scan going wrong. All we had was some existing cached images that were suspect. What I am doing about this is raise a suggestion to the Plex Development team that they look into possibility of refreshing suspected cached images if detected as such.
apologies for earlier my bad was getting frustrated.
update: completely removed PLEX including ALL Caches, then reinstalled - issue persists
i’m going to build PLEX in VMware Workstation Pro 12.1.1 & run both servers side-by-side on same physical hardware: replicate current PLEX system as close as i can, same operating system, same test media, et al.
i’ll continue to update this thread once virtual machine is built (this may take some time)!
apologies for earlier my bad was getting frustrated.
update: completely removed PLEX including ALL Caches, then reinstalled - issue persists
i’m going to build PLEX in VMware Workstation Pro 12.1.1 & run both servers side-by-side on same physical hardware: replicate current PLEX system as close as i can, same operating system, same test media, et al.
i’ll continue to update this thread once virtual machine is built (this may take some time)!
thanks again & best regards,
finite void
is it still these errors ? ERROR - Source image with format 25 and size 1x1, refusing to create strange sized thumbnail of size 1x1 ERROR - Error resizing an image, we don't trust what we cached
and it is definitely not ReFS where these are stored C:\Users\roof\AppData\Local\Plex Media Server\Cache\PhotoTranscoder ?
The logs after the first scan of a test TV Show eg Breaking Bad would hopefully have clues
I am not available for a couple of days - once settled in my destination for internet access etc I will have a look - but maybe someone else would step in and advise you once you get the first set of logs
once i have the virtual PLEX machine built i can compare with current PLEX system
thanks again & best regards,
finite void
re the support page i mentioned which lists various possibilities - main causes are ReFS and Drive Pooling for the appdata area but have a look at the whole list
Re the error - what we need are the logs when that cache was written earlier on - so logs covering when the images were downloaded and cached and later on when accessed and found to be suspect
So best a new test library. one tv show - Breaking Bad and collect all logs from launch up to time of error - logs recycle every 5Mb (and agents every 1Mb) but hopefully will get the issue before all 6 logs files are written (.1, to .5 and .log)
May 18, 2016 15:56:04:482 [4560] DEBUG - Photo transcoder: Request for url [127.0.0.1:32400/library/metadata/659/thumb/1463538976?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx] (is local: 1 upscaled: 0)
May 18, 2016 15:56:04:482 [4560] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
May 18, 2016 15:56:04:482 [4560] DEBUG - Auth: Came in with a super-token, authorization succeeded.
May 18, 2016 15:56:04:485 [7072] DEBUG - Calculated media file path for item 794: C:\Users\roof\AppData\Local\Plex Media Server\Metadata\TV Shows\3\7f6b961c26086f1b8adbe76cf4773b680284b8b.bundle\Contents_combined/art/com.plexapp.agents.thetvdb_220bc95c0b5690a4b1918a8122d544687ac54e38
May 18, 2016 15:56:04:506 [4280] DEBUG - Calling back into ourselves for photo to transcode, optimizing the process (status: -1)
May 18, 2016 15:56:04:506 [4280] DEBUG - Photo cache obtained 43 bytes from http://127.0.0.1:32400/library/metadata/659/art/1463538976?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx
May 18, 2016 15:56:04:506 [4280] DEBUG - Saving original media file to C:\Users\roof\AppData\Local\Plex Media Server\Cache\PhotoTranscoder\57\57471f66910147ffc19ffa061f68ad197a0ae08b.jpg
May 18, 2016 15:56:04:506 [4280] ERROR - Source image with format 25 and size 1x1, refusing to create strange sized thumbnail of size 1x1
May 18, 2016 15:56:04:506 [4280] ERROR - Error resizing an image, we don’t trust what we cached [C:\Users\roof\AppData\Local\Plex Media Server\Cache\PhotoTranscoder\57\57471f66910147ffc19ffa061f68ad197a0ae08b.jpg]
May 18, 2016 15:56:04:506 [4560] DEBUG - Computed media url for item 659: http://127.0.0.1:50311/system/agents/media/get?guid=com.plexapp.agents.thetvdb%3A%2F%2F260586%3Flang%3Den&mediaType=2&url=metadata%3A%2F%2Fposters%2Fcom.plexapp.agents.thetvdb_c1d35f0df71ca4547987f9f9b97e7a304f04918b
May 18, 2016 15:56:04:506 [4560] DEBUG - HTTP requesting GET http://127.0.0.1:50311/system/agents/media/get?guid=com.plexapp.agents.thetvdb%3A%2F%2F260586%3Flang%3Den&mediaType=2&url=metadata%3A%2F%2Fposters%2Fcom.plexapp.agents.thetvdb_c1d35f0df71ca4547987f9f9b97e7a304f04918b
May 18, 2016 15:56:04:508 [6480] DEBUG - Completed: [192.168.1.10:50360] GET /photo/:/transcode?width=236&height=133&minSize=1&url=http%3A%2F%2F127.0.0.1%3A32400%2Flibrary%2Fmetadata%2F659%2Fart%2F1463538976%3FX-Plex-Token%3Dxxxxxxxxxxxxxxxxxxxx (25 live) TLS GZIP 54ms 441 bytes 500 (pipelined: 2)
<<
You never confirmed to me that you are not using Drive Pool or ReFS - could you please confirm
If you are then that could be the cause
If it is not ReFS and is NTFS for the metadata area and no Drive Pool, I will pass this to the devs
We have the scan of the library starting at
May 18, 2016 19:21:56:623 [4408] DEBUG - "C:\Program Files (x86)\Plex\Plex Media Server\Plex Media Scanner.exe" --scan --refresh --section 1
We have the com.plexapp.system.log showing a request for one of the bad images (hash thetvdb_a57512e7f6a0db2697339c7fb0765dacc60b59d5 coming in at
2016-05-18 19:22:01,871 (e24) : DEBUG (runtime:717) - Handling request GET /system/agents/media/get?guid=com%2Eplexapp%2Eagents%2Ethetvdb%3A%2F%2F81189%3Flang%3Den&mediaType=2&url=metadata%3A%2F%2Fposters%2Fcom%2Eplexapp%2Eagents%2Ethetvdb_a57512e7f6a0db2697339c7fb0765dacc60b59d5
2016-05-18 19:22:01,871 (e24) : DEBUG (runtime:814) - Found route matching /system/agents/media/get
2016-05-18 19:22:01,874 (e24) : DEBUG (logkit:13) - Reading existing data for metadata://posters/com.plexapp.agents.thetvdb_a57512e7f6a0db2697339c7fb0765dacc60b59d5 (in com.plexapp.agents.thetvdb)
2016-05-18 19:22:01,874 (e24) : DEBUG (logkit:13) - Writing data for metadata://posters/com.plexapp.agents.thetvdb_a57512e7f6a0db2697339c7fb0765dacc60b59d5 (in com.plexapp.agents.thetvdb)
2016-05-18 19:22:01,875 (e24) : DEBUG (logkit:13) - Recombining the metadata bundle for com.plexapp.agents.thetvdb://81189?lang=en (TV_Show)
2016-05-18 19:22:02,230 (e24) : DEBUG (runtime:924) - Response: [200] str, 43 bytes
and we have all the retrievals logged in thetvdb agent log starting 19:21:57
Could you zip this folder and attach this
C:\Users\roof\AppData\Local\Plex Media Server\Metadata\TV Shows\a\d3d4266c0f4dbb7801056a11f73a093e4cef98c.bundle\
Also can you use curl.exe to manuall fetch all these - you can do manually but that will take longer
Then we can compare what you get with what is in the folder I asked you to zip
I have arranged for @“MovieFan.Plex” to continue with this as I am flying out shortly
Most of the files are 43 byte size each - these are probably all the suspect retrieved image files. It will be interesting to see what the file sizes are when you run the batch through curl.exe requests. May be something is terminating the downloads prematurely replacing then requested jpg files with 1x1 pixel gif files
So all thetvdb retrieved images are being replaced somehow by these 43 byte 1x1 pixel gifs. What security software do you have running? Maybe it is thinking they are suspect and replacing the files with these
The requests are for jpg but you are getting gif
This is an extract from the support page highlighted earlier
Something Local is Blocking Connections
If the images are present on the metadata resource site, then the most common reason you’d see this is if something on either your computer or network is blocking the connection to retrieve the images. In these cases, it’s often caused by a firewall, proxy, or router feature.
Beyond a standard firewall or proxy, you may also run anti-virus, anti-malware, ad-blocker, or similar software that can behave in many ways as a firewall or proxy. In the past, we’ve specifically seen some of the following cause issues for users:
◦DD-WRT (or other router) firmware ad-blocking features
◦Glimmerblocker
◦Little Snitch
◦Peer Guardian
◦VirusBarrier
There are undoubtedly other applications that could cause issues, too.
Try disabling your firewall, proxy, or other software and see if that makes a difference.
unfortunately i was unable to get cuRL to batch download any data from the links you provided.
the culprit was Anti-Banner part of Kaspersky Total Security 2016, will check the logs to find out how this was enabled i’m expecting an Application Update
disabled Kaspersky completely. Anti-Banner remains enabled - blocking ALL data including image requests from: cuRL and http://thetvdb.plexapp.com
after disabling Anti-Banner completely & re-enabling Kaspersky Total Security ALL data requests are returned as expected.
please could you double check the attached bundle files if possible?
unfortunately i was unable to get cuRL to batch download any data from the links you provided.
the culprit was Anti-Banner part of Kaspersky Total Security 2016, will check the logs to find out how this was enabled i’m expecting an Application Update
disabled Kaspersky completely. Anti-Banner remains enabled - blocking ALL data including image requests from: cuRL and http://thetvdb.plexapp.com
after disabling Anti-Banner completely & re-enabling Kaspersky Total Security ALL data requests are returned as expected.
please could you double check the attached bundle files if possible?
I am arranging for Kapersky Total Security Anti-Banner module to be added to the list of security software that is known to cause such issues - list on this support page https://support.plex.tv/hc/en-us/articles/201424327
was getting frustrated.
was getting frustrated.