2024-10-10, 12:24 PM
(This post was last modified: 2024-10-10, 04:51 PM by TheDreadPirate. Edited 1 time in total.)
(2024-10-10, 04:21 AM)netduke999 Wrote: 1. I have always suspected this reason, but I have been using it for several years and only discovered this issue this week. At this time, the TMDB website is experiencing overload and website replacement issues, so I suspect that there may be a problem with the API and website coordination.
2. In addition, TMDB images can still be seen from Jellyfin, but they cannot be downloaded. Other metadata, actor information, and images can all be scraped normally. POSTER, MARK, BACK DROPS cannot automatically scrape from TMDB to the local area. And TVDB and FANART are both normal, but the information on these two websites is not as comprehensive as TMDB's.
3. These three types of images can still be uploaded and downloaded from CHROME, but cannot be automatically completed by Jellyfin. They can be manually downloaded separately and then manually added to the scraping process by Jellyfin. In fact, 80% of the scraping work can still be completed normally in the current situation, after all, the three types of images are not very heavy by hand, and FANART can provide a good alternative, while scraping data is more and more heavy.
4. By the way, the POSTER, MARK, and BACK DROPS in the movie series are all normal and can be automatically scraped by Jellyfin. So if it's a problem with the ISP, it's hard to explain this situation.
5. Is it possible that my API authorization has been locked by TMDB?
Thank you for your response.
I noticed that depending on what you're doing with TMDB it uses different certs. What happens when you curl just the TMDB api URL?
Code:
curl -vvv https://api.tmdb.org
A good result would be a "301 Moved Permanently" message.
Another thing I noticed is that images.tmdb.org using a different cert when you are actually downloading an image. What happens when you curl JUST the base images.tmdb.org URL?
Code:
curl -vvv https://images.tmdb.org
Here are the various certs I see when accessing those URLs.
curl -vvv https://api.tmdb.org
Code:
* Server certificate:
* subject: CN=*.tmdb.org
* start date: Sep 22 00:00:00 2024 GMT
* expire date: Oct 20 23:59:59 2025 GMT
* subjectAltName: host "api.tmdb.org" matched cert's "*.tmdb.org"
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M03
curl -vvv https://images.tmdb.org
Code:
* Server certificate:
* subject: CN=images.tmdb.org
* start date: Sep 22 02:12:51 2024 GMT
* expire date: Dec 21 02:12:50 2024 GMT
* subjectAltName: host "images.tmdb.org" matched cert's "images.tmdb.org"
* issuer: C=US; O=Let's Encrypt; CN=R11
BUT, if I curl the images URL to download an image it uses yet another cert that has a validity date of Oct 6.
curl -vvv https://image.tmdb.org/t/p/original/uqIV...xiyY4z.jpg -o /tmp/futurama.jpg
Code:
* Server certificate:
* subject: CN=image.tmdb.org
* start date: Oct 6 12:45:51 2024 GMT
* expire date: Jan 4 12:45:50 2025 GMT
* subjectAltName: host "image.tmdb.org" matched cert's "image.tmdb.org"
* issuer: C=US; O=Let's Encrypt; CN=R10
Now, I don't know how the Internet in your country works, but if your country is acting as a proxy for all TLS connections that leave your country, but your country's proxy doesn't recognize the new cert used when downloading images, that could be why the connection is getting reset.