Yahoo! That worked v 2129 on linux.
Thank you, thank you , thank you.
Is this the fix should it happen again in future versions?
I had same issue for quite a while and deleting that file fixed it! Thanks a lot!
v1.18.2.2058 on Linux
Currently, on 1.18.2.2058 - Working correctly after deleting the folder. - Scan didnāt update the posters, but Refresh worked on existing movies in the library. I added a new movie to the library and everything is now working correctly. Thank you again for finding the solution to this strange problem. Let me know if there is additional logging or testing that you may require.
Thank you all for replying.
This confirms our hypothesis. Now, we need to do a few things on our end but this will get sorted out such that deleting the file is no longer necessary
Chuck,
Thanks for the update. This confirms my hypothesis that Plex is the best and there is nothing even close.
Yes I deleted the HTTPCookies file and refreshed the metadata to recreate it and now everything works fine!
Plex ver. 1.18.3.2129 on Synology
Worked!! Thank you. Plex ver. 1.18.3.2129 on QNAP . And yes I had to also refresh meta data.
Thank you, thatās working for me now as well.
Server version: 1.18.3.2129 on Shield 2015 (P2571)
PMS data on external (non-adopted) storage - SD card
Steps for me were:
- Stop PMS
- Delete
"[EXT-STORAGE]/Android/data/com.plexapp.mediaserver.smb/Plex Media Server/Plug-In Support/Data/com.plexapp.system/HTTPCookies" - Reboot Shield (restarting PMS + refresh metadata without rebooting did not work for me)
- Refresh metadata - scan only did not work for me
Update: Issue has recurred.
Iāve created a new test library with a small subset of movies, and scanning seems to proceed fine for a period of time, then grinds to a halt. I can see what appear to be a bunch of curl timeouts in the logs, and am wondering if this is the underlying cause?
Is the issue that PMS is not ageing out cookies per their āexpiresā value (or similar), and the agent is attempting to use stale cookies in fresh HTTP requests?
If this is the case, until the fix is released, are we required to periodically delete the HTTPCookies file to force a new cookie to be fetched?
Note: I am not a programmerā¦ 
Thank you to all for your help so far.
may I see the Log ZIP please?
Self-update: The answer appears to be yes. Repeated the same procedure and the agent is again working as expected. Itās good to have a known working workaround.
Also, it seems that a plain old scan picks up metadata for titles which the agent has never touched, whereas a refresh metadata is required for titles which the agent has previously touched, but did not complete.
Plex Media Server Logs_2019-12-13_15-25-04 - small test library.zip (3.5 MB)
Plex Media Server Logs_2019-12-13_15-37-17 - possible agent hang.zip (3.5 MB)
Plex Media Server Logs_2019-12-13_15-55-29 - delete HTTPCookies, no reboot.zip (3.3 MB)
Plex Media Server Logs_2019-12-13_16-14-07 - delete HTTPCookies, with reboot.zip (3.5 MB)
Edit: Note, I reverted to the PMS public branch after trying the beta for a fix - the logs are from PMS 1.18.2.2079.
The verification test I asked everyone to conduct was to delete the HTTPCookies.
I had asked a āRefresh All Metadataā be performed when deleting the HTTPCookies.
Iām seeing several different types of timeouts in the logs.
Itās going to take a bit to determine which is the root cause here. I will need a bit more time.
I see:
- TMDB returning error & timing out
Error refreshing metadata for com.plexapp.agents.imdb://tt0308353?lang=en
- A null XML return value from TMDB
Dec 13, 2019 15:29:03.346 [16862] DEBUG - HTTP simulating 408 after curl timeout
Dec 13, 2019 15:29:03.347 [16862] ERROR - Error parsing content.
Dec 13, 2019 15:29:03.347 [16862] ERROR - Exception caught while attempting to match metadata on item 349: Error parsing file
Dec 13, 2019 15:29:03.347 [16862] ERROR - XML was (0 bytes):
This looks like TMDBās API is having a problem. PMS isnāt tripping up on the cookies or a failed connection. Itās not getting valid XML back.
How long has this been happening?
The behaviour has been similar for a couple of days, as far as I can tell. Today was the first chance I had to try and capture the behaviour with a small test run.
It could very well be possible that HTTPCookies is a red herring in this case, and it was a reboot that fixed things. TMDB fixing itself between reboots is possible, but the timing would seem to be too much of a coincidence now that itās happened to me twice.
Thanks again for looking into this.
@ChuckPa I think this explains the issue that I and a few others have been having, from Movie and TV Posters not Loading After PMS-2058 - #2 by connor_greene
Here is a screenshot of my HTTPCookies file. You can see at the end of each line is a ^M, which is how vim encodes 0xD or the \r carriage return.
When the Python HTTP library was inserting the headers into the artwork request, it saw the \r without an accompanying \n and threw an exception. My change to the httplib.py (from the thread linked above) was to insert the missing \n and sent the request.
It looks like this is introduced in build 2058 (patch notes here Plex Media Server - #303 by StSimm1) specifically:
(Agents) Make the Framework use modern HTTP libs, fixes certain TheTVDB requests failing among others.
Hope this helps the team to resolve the issue!
I understand.
The instructions from Engineering is to simply delete HTTPCookies . The argument is why change code for a temporary datafile which will get recreated during the next āRefresh All Metadatā ?
Part of PMS was upgraded for TheTVDB in all this. I think this is the foundation of their point.
The interesting thing is that during a Refresh All Metadata on a large selection, or against a large library, there is a definitive amount of time that deleting HTTPCookies will work for, which is 15 minutes from when the cookie is first inserted into the temp file. After 15 minutes the behaviour recurs without fail, and requires the same stop PMS / delete HTTPCookies / reboot cycle.
A new Refresh All Metadata does not work for me after 15 minutes unless this is done. After the reboot, everything works normally until 15 minutes after a new Refresh All Metadata request.
I havenāt taken a packet capture to verify, but I would suspect that PMS is continuing to reuse the same cookie even though it has aged out server-side.
There is a piece of information which youāre not aware of.
Specifically, the old HashCodes which were inherent to the mechanism have been removed from the backend API for movies and TV series.
Additionally, This change is moving toward the LONGSTANDING request to actually be able for force a rematch & redownload of anything without the infamous āPlex Danceā.
The final piece of the puzzle is all the agent Python is going away because the scanners and agents are going into compiled code.
When āChannelsā were removed (those plug-ins) it took a huge chunk out of the already minimized need for the Python layer.
Regarding the āDelete HTTPCookies / Reboot / Delete againā cycle, Iāve rebuilt libraries several times and canāt recreate that fault.
If I can recreate it (capture it and show the Steps To Recreate) then I can get eyes on it. As it stands now, for which Iām sorry, there only seems to be a few instances of what youāre describing. Am I wrong? Can anyone help me recreate this reliably?
Thanks @ChuckPa, thatās a genuinely interesting look behind the scenes.
I can only relay the experience Iām running into, and only on the hardware I have available to me. Iād certainly appreciate the perspective of anyone else out there who can provide their experience to the forum, and particularly those who are running PMS on a Shield.
As it stands, Iāve reset the Shield to factory, installed the latest patches, installed Plex and PMS fresh from the Play Store, have spent the past 2 days rebuilding libraries from scratch. The behaviour seems consistent and replicatable to me, particularly with regard to the timings.
Iām very happy to run any scenarios you or the community can think of, and provide logs of the results. The restriction I have is that I donāt have access to / without rooting the Shield, only whatās visible to me as part of the āuser accessibleā parts of PMS.
