"Fix Incorrect Match" not working

Plex Media Server
101

The difference between my setup and yours is your agents are authorized. Follow my log snippet above compared to yours: both search queries look the same, but where your server invokes the search agents and returns data, mine does not and returns 401.

Hell, I can repeat this at whim:

“”"
cerebus@garcon$ telnet localhost 32400
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
GET /system/agents/search?mediaType=1&id=2&identifier=com.plexapp.agents.imdb&duration=8303896&filename=%252Fhome%252Fcerebus%252Fplexdata%252Fdata%252FMovies%252FZulu%2520(1964)%252FZulu%2520(1964)%252Emp4&lang=en&openSubtitlesHash=4ddd3aec38407bbe&plexHash=975988c485b8056d4e1de4347d5f54a364003ac0&name=Zulu&year=1964 HTTP/1.1

HTTP/1.1 401 Unauthorized
Content-Length: 91
Content-Type: text/html
X-Plex-Protocol: 1.0
Cache-Control: no-cache
Date: Sun, 05 Mar 2017 05:32:41 GMT

Unauthorized

401 Unauthorized

Connection closed by foreign host. """

Here’s the verbose log of that event:

“”"
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] DEBUG - Request: [192.168.86.254:47556 (WAN)] GET /system/agents/search?mediaType=1&id=2&identifier=com.plexapp.agents.imdb&duration=8303896&filename=%252Fhome%252Fcerebus%252Fplexdata%252Fdata%252FMovies%252FZulu%2520(1964)%252FZulu%2520(1964)%252Emp4&lang=en&openSubtitlesHash=4ddd3aec38407bbe&plexHash=975988c485b8056d4e1de4347d5f54a364003ac0&name=Zulu&year=1964 (4 live) Signed-in
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * duration => 8303896
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * filename => %2Fhome%2Fcerebus%2Fplexdata%2Fdata%2FMovies%2FZulu%20(1964)%2FZulu%20(1964)%2Emp4
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * id => 2
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * identifier => com.plexapp.agents.imdb
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * lang => en
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * mediaType => 1
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * name => Zulu
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * openSubtitlesHash => 4ddd3aec38407bbe
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * plexHash => 975988c485b8056d4e1de4347d5f54a364003ac0
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] VERBOSE - * year => 1964
Mar 04, 2017 23:32:41.287 [0x7f28efbfe700] DEBUG - Completed: [192.168.86.254:47556] 401 GET /system/agents/search?mediaType=1&id=2&identifier=com.plexapp.agents.imdb&duration=8303896&filename=%252Fhome%252Fcerebus%252Fplexdata%252Fdata%252FMovies%252FZulu%2520(1964)%252FZulu%2520(1964)%252Emp4&lang=en&openSubtitlesHash=4ddd3aec38407bbe&plexHash=975988c485b8056d4e1de4347d5f54a364003ac0&name=Zulu&year=1964 (4 live) 0ms 249 bytes
“”"

Meanwhile, com.plexapps.agents.imdb.log is empty.

Feel free to engage engineering. I think you have more than enough data upthread to keep them busy.

Let me say it again: This is a clean install. All previous PMS installs were purged. I’ve even run the damn thing in a container to ensure there’s no detritus of previous of installations. None of it makes a damn bit of difference.

Maybe I should bail for Kodi.

102

This was interesting in com.plexapps.agents.themoviedb.log:

“”"
2017-03-04 20:09:40,955 (7f1fc7fff700) : CRITICAL (runtime:493) - Exception matching route for path “/” (most recent call last):
File “/usr/lib/plexmediaserver/Resources/Plug-ins-03e4cfa35/Framework.bundle/Contents/Resources/Versions/2/Python/Framework/components/runtime
.py”, line 464, in match_route
raise Framework.exceptions.FrameworkException(“No route found matching ‘%s’” % path)
FrameworkException: No route found matching ‘/’

2017-03-04 20:09:40,955 (7f1fc7fff700) : ERROR (runtime:846) - Could not find route matching /:/plugins/com.plexapp.agents.themoviedb
2017-03-04 20:09:40,956 (7f1fc7fff700) : DEBUG (runtime:88) - Sending packed state data (110 bytes)
2017-03-04 20:09:40,956 (7f1fc7fff700) : DEBUG (runtime:924) - Response: [404] NoneType, 0 bytes
“”"

An actual stacktrace is slightly encouraging.

Theory: The agents aren’t registering for whatever reason. I’ve previously cleared out /usr/lib/plexmediaserver[…]/Plug-ins but I’ll try it again for grins.

103

I just realized something… In looking at your info.

Where’s the media? Where’s PMS?

Can PMS read the media? It looks like it’s in your home directory. Screwy things have happened when PMS doesn’t have 755 on the directories and 644 on the files (plex runs as its own user and group)

104

Purged and reinstalled again, now I have no agents.

105

Then Purge isn’t doing what you think it’s doing. Try things my way please?

  1. Stop PMS
  2. Remove the package
  3. sudo rm -rf /var/lib/plexmediaserver
  4. sudo userdel plex
  5. sudo groupdel plex
  6. restart
  7. now install plex
106

Agents finally installed themselves.

Since TheMovieDB is kept in AWS S3, and S3 went tango-uniform a couple of days ago, could this be related?

107

The Agents install themselves as part of the First-Run sequence. Are you rushing in before it’s had time to perform all this?

I don’t know at this point. I’ve not had anyone report issues as severe as yours. I’m also east coast and on the Ashburn node.

108

I am having the same problem and I also get these messages:
DEBUG - HTTP 401 response from GET http://127.0.0.1:32400/system/agents/search?mediaType=1&id=154&identifier=com.plexapp.agents.themoviedb&lang=en&name=Term%20Life&year=2016&manual=1

The media is in my home directory but PMS is running with my user id, not with plex user id.
So It should not be related to the file permissions (?) …

Also, I don’t see any tcp packet using “tcpdump host www.themoviedb.org”
So it seems that nothing is actually sent to themoviedb ?

109

I know how permissions work, and media is chown’d, chgrp’d, and chmod’d properly.

–purge in all debian derivatives does everything you list except remove /var/lib/plexmediaserver, (which, BTW, is a bug in your debian packages), and I’ve been doing by hand at each removal. When I said purge, I meant purged. In addition, some installs were in containers (so I could run 1.3.4 and 1.4.3 side-by-side), so when I purged those I was removing the container, which definitely removes all traces of previous installs.

I’m aware of the first-run sequence, and yes, I had rushed that install a bit. Eventually it completed. However, I’m thinking the first-run sequence may be part of the problem.

Lastly, I’m not east coast, so I don’t know which S3 node I’m tapping. I’ll see if I can figure it out from the logs or I’ll start collecting packet traces.

110

I did some pcaps and this problem is entirely PMS-internal. When executing a metadata query no packets are emitted to the network.

I ran two captures from loopback and the eth0 and executed a metadata search (via “Match…”, then Search Options, and searching against the Plex Movie agent). eth0 shows no HTTP traffic relevant to that search. On loopback, I see the agent HTTP GET containing the search request and the 401 response from PMS.

pcaps attached.

I’m starting to think something is going wrong during first-run that prevents PMS agents from being invoked later. They’re downloaded and registered, else they wouldn’t show in the UI, but they can’t actually be called to search.

PMS logging seems to be inadequate in this instance: since PMS never calls the agent, nothing shows in the agent log, and the server log doesn’t show anything except the 401 response. However, the agents do get spawned as I can see com.plexapp.agents.* processes when PMS starts up, though eventually they idle out and get reaped by PMS.

111

Resolved. The issue was IPv6. Explanation:

When I disabled IPv6 via sysctl, (via net.ipv6.conf.all.disable_ipv6 and net.ipv6.conf.lo.disable_ipv6) it appears that it didn’t actually take effect on loopback because that interface is also bound to multiple containers (I run various workloads in LXD and docker on this server). Rebooting allowed sysctl to act on all interfaces before any services had started.

Servers shouldn’t have to be rebooted, dammit! Razzin’-frazzin’-no-good-#$%@*&!

I’m putting PMS back in its docker container, with sysctl flags explicitly set on it just in case the host reverts. My initial test with a small library worked fine, so confidence is high.

This doesn’t explain why the PMS was running fine with IPv6 enabled until the update, but whatever. I won’t argue with success. :slight_smile:

112

You got lucky regarding IPv6. That’s why I kept pushing the V6 point. V6 is so ‘rag tag’ at this point, unless everything is perfect, it is more trouble than it’s worth. It’s as bad as increasing MTU size.

Regardless, I’m glad you got it working.

You run multiple systems and didn’t remember to reboot? Been that long, eh? (don’t worry, i’ve done that move too… haha)

113

How do I fix this on Win 10? I’ve got IPv6 turned off on PMS. Does it have to be off for the whole server?

114

If you have only one adapter, then the answer for Windows 10 appears to be a yes but this IS NOT official or confirmed at this time. This is a work in progress as we figure out what’s going on.

I can tell you definitively, AWS doesn’t use/support IPv6

What has been discovered is that if IPv6 is being directed at the loopback adapter http://127.0.0.1 (PMS internal address) , it will fail.

If you can spend the time to help qualify and quantify what’s happening, it would be greatly appreciated.

115

@ChuckPA said:
If you have only one adapter, then the answer for Windows 10 appears to be a yes but this IS NOT official or confirmed at this time. This is a work in progress as we figure out what’s going on.

I can tell you definitively, AWS doesn’t use/support IPv6

What has been discovered is that if IPv6 is being directed at the loopback adapter http://127.0.0.1 (PMS internal address) , it will fail.

If you can spend the time to help qualify and quantify what’s happening, it would be greatly appreciated.

I stumbled upon this thread as I have been having issues with matches and fix incorrect matches not working on my Windows machine.

I am running Plex on Windows Server 2016 Standard. I followed the advice of disabling IPV6, and it worked. I am now able to fix incorrect matches. I disabled IPV6 both within Plex itself and on the primary network adapter used by the server. My secondary adapter already had it disabled as it is used strictly for Hyper-V.

116

The true test of any ‘fix’ is: Can you create a fresh library, even if a duplicate, and have it pull all the metadata without issue / incorrect matches? :slight_smile:

117

@ChuckPA said:
The true test of any ‘fix’ is: Can you create a fresh library, even if a duplicate, and have it pull all the metadata without issue / incorrect matches? :slight_smile:

I can give this a try this evening to see if it works and will post my results.

118

Have fun! Oh, and if you have a 50-bazillion video sized library? All bets are off :tongue: lol

119

It seems that this ipv6 interface on the loopback device is not what causes trouble for me.
I would be interested to know from other people.
If I run the following commands :
" ip addr show dev lo"
It does not show any ipv6 address.
Also the following command:
" ping6 ::1"
does not return anything.

120

To add information here. I’ve been chatting with the dev team in light of my writeup about IPv6. They see some issues and are looking at it now.