Server Version#: 1.25.7.5604
Player Version#: 4.77.3 (web, but not a player issue)
I don’t know exactly when this change took place. It may have started with 1.25.4.5468. It was definitely in place by 1.25.6.5577 and later. There was a change in how the Scanner handles symlinks (in Linux for sure, but possibly other OSes as well).
Previous PMS Scanners made decisions based on the symlink’s file name. The current PMS Scanner makes decisions based on the symlink target’s filename.
This becomes a problem if you’re crossing library types, which I do. A lot.
Example: you have a cartoon short as part of a collection, best organized within a TV library, but you also have a Movie library in which you would like to include the same cartoon short as a stand alone entry.
Here’s the TV library directory and file:
/TV/Cartoon - S03E05 - something.mp4
You create a relative symlink in the Movie library directory:
ln -s …/TV/“Cartoon - S03E05 - something.mp4” Something.mp4
The result:
/Movie/Something.mp4 → …/TV/‘Cartoon - S03E05 - something.mp4’
In the previous PMS Scanner versions, this would work well. It would look at “Something.mp4” and match based on that. In the current version, the scanner doesn’t look at “Something.mp4.” It looks at “Cartoon - S03E05 - something.mp4” and decides that this naming structure does not belong in a Movie library (and is thereby ignored).
This discovery is the result of a LOT of troubleshooting. I had movie libraries in which some symlinks were working and others were not. I finally found (and tested the above pattern). The functional symlinks were those that were referencing a filename that would be compatible with the Movie library type. Those that had a filename in the style for a TV library all failed.
Any thoughts on what may be done about this? Was there a reason this change was made? Is there some other trick I can use to have the Scanner make its decision on the symlink name, not its target?
Any help is greatly appreciated. Thanks!
