Don't hardcode localhost (maybe?)

[f00b4r0]

Hama.bundle/Contents/Code/common.py

Line 49 in 70f480b

PLEX_LIBRARY, PLEX_LIBRARY_URL = {}, "http://127.0.0.1:32400/library/sections/" # Allow to get the library name to get a log per library https://support.plex.tv/hc/en-us/articles/204059436-Finding-your-account-token-X-Plex-Token

On some setups (in particular FreeBSD jails without VNET), localhost may be any IP within the 127.0.0.0/8 range

Hardcoded 127.0.0.1 will either not work or be redirected to a different IP, at which point the agent won't work (as in https://forums.plex.tv/t/agents-not-working/156168 )

To be fair, I haven't tested that Plex does the right thing (for a change) and considers 127.0.0.0/8 as being localhost, vs only 127.0.0.1.

In any case, it's usually good practice not to assume localhost will always be 127.0.0.1 (see https://tools.ietf.org/html/rfc5735#section-3)

A correct approach should thus be "http://localhost:32400/library/sections/"

A similar issue affects the Absolute Series Scanner.

HTH

[avluis]

This looks like a FreeBSD specific fix (as detailed in the very post that is linked)

For example; on an install where there were no such issues; I'm now seeing:
2020-05-03 17:26:04,630 - 1554cecda700 - Loading model with GUID com.plexapp.agents.hama://tvdb-173271?lang=en 2020-05-03 17:26:04,631 - 1554cecda700 - Deserializing from /config/Library/Application Support/Plex Media Server/Metadata/TV Shows/7/cac08cc5bd1f6cf5e71569aa58fa1b372b6a79b.bundle/Contents/com.plexapp.agents.hama/Info.xml 2020-05-03 17:26:04,966 - 1554cecda700 - Requesting 'http://127.0.0.1:32400/library/metadata/518700/tree' 2020-05-03 17:26:05,210 - 1554cecda700 - Requesting 'http://localhost:32400/library/sections/' 2020-05-03 17:26:05,212 - 1554cecda700 - Error opening URL 'http://localhost:32400/library/sections/' 2020-05-03 17:26:05,213 - 1554cecda700 - PLEX_LIBRARY_URL - Exception: 'HTTP Error 401: Unauthorized' 2020-05-03 17:26:05,214 - 1554cecda700 - ==== common.PlexLog(file="/config/Library/Application Support/Plex Media Server/Plug-in Support/Data/com.plexapp.agents.hama/DataItems/_Logs/_unknown_folder.agent-update.log") 2020-05-03 17:26:05,218 - 1554cecda700 - Requesting 'http://localhost:32400/library/sections/' 2020-05-03 17:26:05,220 - 1554cecda700 - Error opening URL 'http://localhost:32400/library/sections/' 2020-05-03 17:26:05,220 - 1554cecda700 - PLEX_LIBRARY_URL - Exception: 'HTTP Error 401: Unauthorized' 2020-05-03 17:26:06,389 - 1554cecda700 - Requesting 'http://localhost:32400/library/sections/' 2020-05-03 17:26:06,391 - 1554cecda700 - Error opening URL 'http://localhost:32400/library/sections/' 2020-05-03 17:26:06,392 - 1554cecda700 - PLEX_LIBRARY_URL - Exception: 'HTTP Error 401: Unauthorized' 2020-05-03 17:26:06,395 - 1554cecda700 - Requesting 'http://localhost:32400/library/sections/' 2020-05-03 17:26:06,397 - 1554cecda700 - Error opening URL 'http://localhost:32400/library/sections/' 2020-05-03 17:26:06,398 - 1554cecda700 - PLEX_LIBRARY_URL - Exception: 'HTTP Error 401: Unauthorized' 2020-05-03 17:26:11,117 - 1554cecda700 - Serializing to /config/Library/Application Support/Plex Media Server/Metadata/TV Shows/7/cac08cc5bd1f6cf5e71569aa58fa1b372b6a79b.bundle/Contents/com.plexapp.agents.hama/Info.xml 2020-05-03 17:26:11,123 - 1554cecda700 - Sending packed state data (104 bytes) 2020-05-03 17:26:11,123 - 1554cecda700 - Response: [200] str, 16 bytes

Rather than simply replacing the loopback address for localhost, it is best to test for it first.
Additionally, this is from the RFC:

This is ordinarily implemented using only 127.0.0.1/32 for loopback

[f00b4r0]

As I pointed out, I didn't test that plex wasn't stupid.

But as far as I can tell, it works well on my setup with localhost == 127.0.0.2 and I haven't authorized 127.0.0.0/8 in Allowed Networks. This is with 1.19.1.2645.

And if localhost points to 127.0.0.1 in your setup, it should be a NO-OP, i.e. a transparent change, unless Plex does something even more stupid than I anticipated. What does ping localhost return on your system?

Of course, if Plex had a proper bug tracker it would be easy to point out the problem there 😛

Regarding the RFC, the keyword is "ordinarily". Ordinarily loopback is 127.0.0.1, but not always. The whole block is available for loopback, as clearly stated in the first sentence:

127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher-level protocol to an
address anywhere within this block loops back inside the host.

[f00b4r0]

For the record, I "reported" the issue here. Let's hope they will see the light.

[ZeroQI]

Not sure i understand fully your posts...
scanner code is good but plex bad and look for 127.0.0.1 in some calls at least?

[avluis]

My Plex install is under Docker for which ping isn't included;
Nevertheless, that doesn't matter as it is using the same network as another container that does, which resolves localhost properly.
Plex is doing something with localhost that is causing this under certain environments; wish they had a bug tracker as well but
¯\(ツ)/¯

[f00b4r0]

@ZeroQI

Not sure i understand fully your posts...
scanner code is good but plex bad and look for 127.0.0.1 in some calls at least?

Yes, that's what it looks like, although the current scanner code works fine for me with PMS version 1.19.1.2645. I don't see the behavior @avluis reports. Maybe @avluis can tell us which version of PMS he's running?

@avluis host localhost maybe then?

[avluis]

Version 1.19.3.2740 -- Plex Pass

And as mentioned, localhost resolves; meaning it points to 127.0.0.1.
Nevertheless, I do agree that we should be using localhost here.
Unfortunately, Plex does not always agree.

[f00b4r0]

sigh. The only way I can explain this is if Plex is actually parsing the http request and looks for "127.0.0.1" in the request host header, which would be really stupid, and doesn't match what I see on my setup.

Then again, my PMS version is only slightly older than yours, I hope this is not a new behaviour. When I say I tested the current code, I started a brand new library from scratch with c.20k files in it and threw it at Hama/ASS: not a single glitch. Could it be docker doing something weird?

[f00b4r0]

@avluis localhost may resolve to something outside of 127.0.0.0/8. It could be incorrectly set to resolve to your LAN (non loopback) address, and that would be a plausible explanation for what you see. Hence my question. If you have confirmed this is not the case then there's some other problem.

[f00b4r0]

@avluis I don't know anything about docker, but a quick google search, first hit is https://pythonspeed.com/articles/docker-connection-refused/

Could this be related?

[avluis]

No worries, there are no network misconfiguration issues on my end; localhost resolving outside of 127.0.0.0/8 would kill a few of my programs here.

The link provided goes into detail how a Docker container works; besides that, it doesn't pertain to our issue as localhost not resolving in the Plex container would have nothing to do with it resolving outside of the container or on another system.

The library I have here follows Hama/ASS without many issues (renaming is automated and backed by AniDB -- each file is matched by ed2k hash and then renamed with each folder containing the AnidDB ID); it still trips up Hama/ASS with certain edge cases.
But once again, unrelated so not going further on that.

Anyways; if it works for you then I guess that's cool; hopefully the Plex team is not introducing additional issues with newer Plex versions (which I wouldn't discount honestly).

[f00b4r0]

@avluis thanks for taking the time to explain. I'm running out of ideas (and it's late for me :). Maybe you want to chime in on the Plex forum post I made here about this issue?

I'll try to test a newer Plex version see if I trip on that bug, but I really hope we can get Plex to do the right thing. Hama/ASS is technically correct at the moment, I hope it can stay that way 😉

[avluis]

No worries; I'm gathering some additional details on my end and building a few containers with additional networking tools (alongside a Plex distribution) to add to your issue on their forums.

--
OOT: @ZeroQI -- have you joined the list? https://github.com/sponsors
I would love to sponsor your work outside of the occasional PayPal donation~

[f00b4r0]

Just a quick follow-up: I retested today with 1.19.1.2701 (last version currently available from FreshPorts). I removed my Anime Library and added it back (c20k files).

The scan worked well: identification and matching works fine, metadata is correctly fetched.

However I took a look at Logs/PMS Plugin Logs/com.plexapp.agents.hama.log, and I see the PLEX_LIBRARY_URL - Exception: 'HTTP Error 401: Unauthorized' message there. Yet everything seems to work regardless. Weird.

HTH

[ZeroQI]

If you put your token id in a file it won't show this error but not required. It helps finding root folders for libraries.

[ZeroQI]

9685e95#commitcomment-40265959
@sven-7 is impacted if using localhost.
@f00b4r0 Unless you can convince me my I shouldn't revert back, this code change will be reverted

[f00b4r0]

@ZeroQI if standards won’t convince you I don’t know what will.

Plex code is garbage in that area (and others) and since they seem unwilling to fix it I don’t know what to say.

If you revert it you will break the setup of some users (myself included, although I know what to patch now) and if you don’t it seems it breaks others. Caught between a rock and a hard place 😜

Maybe make this user configurable, if that’s not overly complicated?

[EndOfLine369]

Just before setting "PLEX_LIBRARY_URL", simply test against "localhost:32400", and if fails use "127.0.0.1:32400".

[f00b4r0]

@EndOfLine369 that won't do. I see the same errors in my logs, but it doesn't affect my usage of Hama since I don't care about the behavior described here #394 (comment) (I haven't put the token in a file)

[EndOfLine369]

It will do. And even then, would just be a socket/telnet test. Not if any data is available or not.

[f00b4r0]

The problem reported here 9685e95#commitcomment-40265959 is not a problem of name lookup for localhost (that would be a serious misconfiguration on the host system). If I read it right, it's a problem of Plex rejecting the HTTP content if the requested URI has 'localhost' instead of '127.0.0.1'. If that's the case, your proposed test won't do anything (unless you want to test for that, which will then break the setups like mine who don't care about token).

[EndOfLine369]

Plex token is now pulled from the env in both HAMA & ASS.

[EndOfLine369]

Closing as not hearing any more complaints post add of env pull of plex token.