Symlinks not working...sometimes (within the same library) since upgrade

Plex Media Server
1

Server Version#: 1.25.6.5577
Player Version#: 4.75.0 (though problem not relevant to client)

I have a library that is largely symlinks to other file areas on the same volume. For the sake of discussion, say I had a storage volume mounted at /Videos:

/Videos/Movie/movie1.mp4
/Videos/TV/movie2.mp4
/Videos/Misc/movie3.mp4

And then I have a movies library defined to look at:

/Videos/Library/

Inside this library are symlinks:

/Videos/Library/movie1.mp4 → …/Movie/movie1.mp4
/Videos/Library/movie2.mp4 → …/TV/movie2.mp4
/Videos/Library/movie3.mp4 → …/Misc/movie3.mp4

There are hundreds of these, and I’ve used them for years. Since a recent upgrade, most of these stopped working. I want to say it was after 1.25.4.5468, but I honestly don’t know for sure if that was the version. It was sometime this last month.

At first, it appeared that all symlink files were not working, as there were so many, but there are a few that still work. File permissions haven’t changed. The server is not running SE Linux. Locations haven’t changed.

Even more baffling is that the library is aware of the symlinks and reacts to them. In our previous example, let’s say “movie1.mp4” was currently not showing up in the Library. If I delete movie1.mp4 (the symlink), that triggers a scan. If I recreate the symlink, that triggers a scan. If I force-recreate the symlink (“ln -sf”), that also triggers a scan. And yet, “movie1.mp4” is not displayed in the Library.

Looking at the console, there’s a message stating that it detected a change to the file, and a scan issues, but there’s no mention in the console that it’s scanning or erroring on this file.

I’ve verified permissions repeatedly, as that would seem like the most obvious problem. And by “verify permissions”, I mean the entire directory hierarchy.

I can copy the file (instead of a symlink), and the Library recognizes it and displays it. Change it back to a symlink, and it disappears.

Any ideas? What can I provide that might help?

2

After a LOT of troubleshooting, I finally figured this out. I’m opening a new topic for clarity. Very long story short, when dealing with symlinks, previous versions of PMS scanner would make decisions based on the filename of the link. NOW, it uses the filename of the target of the link. This becomes a problem when you are linking to a file across library types.

For example, you have a real file in a TV directory (a directory used in a TV library), so it is named “TV Show - S01E03 - something.mp4”. Now let’s say you have a Movie directory (a directory used in a Movie library), and you would like to include “TV Show - S01E03 - something.mp4”. That naming format will tell the Scanner that this file belongs in a TV Library, so you create a symlink: ln -s …/TV/“TV Show - S01E03 - something.mp4” Something.mp4.

In the previous versions of PMS Scanner, it would make decisions based on the filename “Something.mp4”. NOW, it makes decisions based on “TV Show - S01E03 - something.mp4”.

Previously (possibly 1.25.3 and earlier), this trick would work. The Scanner would look at “Something.mp4” and match accordingly. Now (1.25.6 and later), instead of seeing “Something.mp4”, it sees “TV Show - S01E03 - something.mp4” and decides that this filename does not belong in a Movie library.

3

You are 100% correct. TV episodes do not belong in a movie library and the scanner knows this.

It’s for this reason – Symlinks are dangerous.

If you have a “For TV” movie, which airs as a multi-part sequence, recommend you follow the rules and make it a “single season TV series”.

-OR-

Put all the files together and name it as the movie it is in a movies library section.

4

That’s disappointing.

If I understand what you’re saying, the approach is simply “it worked before by accident; please don’t do that anymore.”

My only recourse, then, is to greatly increase my storage, by copying what’s needed in other libraries and renaming them.

I appreciate your response, in spite of it not being what I wanted to hear. Thanks.

6

That is interesting and I have to admit that I don’t fully understand what exactly has changed here. I have similar use cases and also use symlinks here and there - without any problem so far.
Let’s have a look at an example where I don’t understand how it is different to the OP’s situation.
I have added the 4K83 project version (Star Wars - Return of the Jedi) to my library as a separate item (“split apart”). I have done this by creating a dedicated folder and putting symlinks in there. Since I wanted to mimic the playlist created by the project (intro, BBFC banner, movie) I added three links. This is the folder content (path info removed from the source to improve readability).

Star Wars - Episode VI - Return of the Jedi (1983) [4K83]

Star Wars - Episode VI - Return of the Jedi (1983) - pt1.mkv -> 4K83 [2160p]/01-TN1_LFL.mkv
Star Wars - Episode VI - Return of the Jedi (1983) - pt2.mkv -> 4K83 [2160p]/02-ROTJ-BBFC.mkv
Star Wars - Episode VI - Return of the Jedi (1983) - pt3.mkv -> 4K83 [2160p]/03-Return.of.the.Jedi.4K83.35mm.minimalNR.v1.6.UHD.2160p.re-encode.mkv

I am wondering why this works when the OP has a problem. If the scanner cared about the source name, I would expect that it won’t be able to match them (at least the first two items) and not recognize them as parts of the same movie.

8

I’m curious: Do you see the same behavior using hard links? I wouldn’t expect you to as there would be no breadcrumbs for PMS to follow back to the original filename.

9

The question was addressed to @jonfullmer but I gave it a try. Indeed, as suspected, it works with hard links (his case, mixing TV and Movie content).

1 Like
10

Correct, @Andreas_B . Hard links do work. This will suffice for my situation for now, but the inconvenience is that hard links do not work over multiple volumes. Soft links do.

11

Also, @Andreas_B , regarding your earlier post, symlinks still work…kind of. If you’re linking something with a filename that would not be foreign to the library type, they work fine. The problem is when you involve a target that has a filename that does not belong in a particular library. In my example, I was trying to link a file in a TV library into a Movie library, but I’m sure the problem would persist vice-versa.

It’s frustrating to me, as it shouldn’t matter what the filename of the symlink target is. It certainly didn’t before. But what was done is done. Hard links would be an alternative, as long as you don’t cross volumes.

12

@jonfullmer

There is something else you must consider.

PMS keeps track of files by their header checksum (fingerprint).

This is the duplicate detection mechanism.

If PMS has a file first matched in Series-A/Season 1
and then symlinked to something else,

The first thing matched will win.
The second-found name will be considered a duplicate and not listed with Series-B.

13

@ChuckPa, to clarify: if you’re using links (hard or soft, as even hard links would yield the same header checksum) within the same library (in your example, a TV library), the link may not appear, as it would be considered a duplicate (even if, as you said in your example, it’s associated with a different show in the same library).

I can say for certainty that going from a TV library hardlinking into a Movie library definitely works. I wonder if linking between two different TV libraries would work? Would the header checksums only be relevant to the library? For example, linking TVLib1/Series-A/S01E01 to TVLib2/Series-B/S03E05?

I appreciate your discussion on this, @ChuckPa.

14

Remember what happens at the filesystem level between the two types of links.

  1. A symbolic link is a file which points to another file BY NAME.
  2. A hard link is a file name which shares the SAME INODE in the file system as another.

They are two entirely different animals.

If you delete the target of a symlink, the symlink is left pointing off to nothingness
If you delete one of two files which are hardlinked, the inode use count is decremented (inode reference count).

Remember, when no file names point to a file (inode reference count) and the in-use count (open file handles) == 0, the file is deleted.

15

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.