[RELEASE] Stream Link/File Manager for Channels [Streaming Library Manager Extension]

Thank you,

My directory layout was different that the one you use and I've now matched yours and moved files and directories as appropriate. I also changed the directory in both SLM and Channels and started a file scan in channels. I'm going to leave SLM to run it's processes early morning to verify it corrects the problem.

I continue to see the stream files for the first two seasons of Brooklyn Nine-Nine pointing to Netflix yet those seasons have been removed from Netflix. I think everything ran correctly. I'm wondering if the issue is the source you use thinks they are still there. What source do you use and how do I see it? If it's wrong, I'll report the issue to them.

Answer in the Troubleshooting / FAQ

Thank you,

I looked at the document for the answer. Did not spot the trouble shooting guide. I will bookmark it.

The issue is them and I will report the change of seasons on Netflix.

It is a great resource and wee will be using it to find shows to watch.

Thanks again,

Morris

After a reboot of my Mac, the docker container running slm will not restart. This had been working. I am using a directory outside of the library container for the slm files and I have it setup to perform backups if that is relevant. The python errors from the container log are these repeated over and over again.

Created: /app/channels_folder/Imports/TV/slm/White Collar (2009)/Season 04/S04E08.strmlnk
Traceback (most recent call last):
  File "/app/slm.py", line 5278, in create_backup
    shutil.rmtree(os.path.join(dst_dir, old_backup))
  File "/usr/local/lib/python3.12/shutil.py", line 759, in rmtree
    _rmtree_safe_fd(stack, onexc)
  File "/usr/local/lib/python3.12/shutil.py", line 703, in _rmtree_safe_fd
    onexc(func, path, err)
  File "/usr/local/lib/python3.12/shutil.py", line 686, in _rmtree_safe_fd
    with os.scandir(topfd) as scandir_it:
         ^^^^^^^^^^^^^^^^^
NotADirectoryError: [Errno 20] Not a directory: '/app/program_files/backups/.DS_Store'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/app/slm.py", line 10342, in <module>
    create_backup()
  File "/app/slm.py", line 5281, in create_backup
    shutil.rmtree(os.path.join(dst_dir, old_backup))
  File "/usr/local/lib/python3.12/shutil.py", line 759, in rmtree
    _rmtree_safe_fd(stack, onexc)
  File "/usr/local/lib/python3.12/shutil.py", line 703, in _rmtree_safe_fd
    onexc(func, path, err)
  File "/usr/local/lib/python3.12/shutil.py", line 686, in _rmtree_safe_fd
    with os.scandir(topfd) as scandir_it:
         ^^^^^^^^^^^^^^^^^

Thanks for the great product!

Jim

By the way. In case there is any confusion, the last line of my post was not meant to be sarcastic. It truly is a great product! Thanks.

You have a file in your backups directory (/program_files/backups) called .DS_store and this is not allowed; only folders with timestamp names can be in there. I'm guessing from your description that you have some external backup program running, and that program appears to be putting files where they don't belong. Disable that feature and delete that file and it should start up just fine.

In the next release, I'll have a fix so that the backup process ignores files and only looks at folders. Tested it out after I was able to replicate your issue and it works!

It’s a Mac thing:

Thanks for the quick reply. Deleting the .DS_Store file did fix the problem. I think your suggested fix in the next release would be helpful. My understanding is that this file gets created or updated anytime you use the macOS finder to look at a directory's contents so it can be hard to avoid its continual recreation. Thanks again for the terrific software.

Jim

Ah, Apple idiosyncrasies, causing all sorts of fun for us recently, eh, @Fofer? :stuck_out_tongue_winking_eye: :shushing_face: :laughing:

1 Like

The latest adventure, Certificate Errors
Note: this is the Windows version of SLM

[DEBUG | 2025-03-12 06:10:58,464] - https://apis.justwatch.com:443 "POST /graphql HTTP/1.1" 200 None
Brooklyn Nine-Nine (2013) | S03E02 assigned Stream Link: Watch Brooklyn Nine-Nine | Netflix
[DEBUG | 2025-03-12 06:10:58,479] - Starting new HTTPS connection (1): apis.justwatch.com:443
[DEBUG | 2025-03-12 06:10:59,306] - https://apis.justwatch.com:443 "POST /graphql HTTP/1.1" 200 None
Brooklyn Nine-Nine (2013) | S03E03 assigned Stream Link: Watch Brooklyn Nine-Nine | Netflix
[DEBUG | 2025-03-12 06:10:59,319] - Starting new HTTPS connection (1): apis.justwatch.com:443
[DEBUG | 2025-03-12 06:11:00,056] - https://apis.justwatch.com:443 "POST /graphql HTTP/1.1" 200 None
Brooklyn Nine-Nine (2013) | S03E04 assigned Stream Link: Watch Brooklyn Nine-Nine | Netflix
[DEBUG | 2025-03-12 06:11:00,066] - Starting new HTTPS connection (1): apis.justwatch.com:443
[DEBUG | 2025-03-12 06:11:00,819] - https://apis.justwatch.com:443 "POST /graphql HTTP/1.1" 200 None
Brooklyn Nine-Nine (2013) | S03E05 assigned Stream Link: Watch Brooklyn Nine-Nine | Netflix
[DEBUG | 2025-03-12 06:11:00,836] - Starting new HTTPS connection (1): apis.justwatch.com:443
[DEBUG | 2025-03-12 06:11:01,589] - https://apis.justwatch.com:443 "POST /graphql HTTP/1.1" 200 None
Brooklyn Nine-Nine (2013) | S03E06 assigned Stream Link: Watch Brooklyn Nine-Nine | Netflix
[DEBUG | 2025-03-12 06:11:01,602] - Starting new HTTPS connection (1): apis.justwatch.com:443

What is the question?

Yes. What is the question? Feels like recently @babsonnexus is being asked to chase a higher number of (seemingly) user setup issues that aren't related to SLM.

1 Like

Exactly!

You mentioned certificate errors and then posted part of a log showing successful stream link assignments. So....... :question: :question: :question: :question:

BTW, please put logs inside a "preformatted text" so they are readable in plain text and don't take up excessive space:

image

PS, I went back and saw you are using a non-standard setup. If that is still the case, I cannot provide support. As I said then, doing so will cause you problems later. My recommendation is to take your program_files to the side, install in a standard manner, and then restore those program_files to get all your data, settings, and whatnot back.

I changed to the file layout that you expect and reported that a while ago. I understand that you can't track everyone's configuration in your head.

Looking at the log closer I was reading it incorrectly, 443 is the port. My error and It is clear why my post is confusing.

So here is my question: After reporting that seasons 1 and 2 are no longer on Netflix to Justwatch and there no longer showing them as available on there web site, I allowed a day to pass so that SLM processing happened. The stream link files for seasons 1 and 2 still appear in:
\NAS\dvr\DVR\Imports\TV\slm\Brooklyn Nine-Nine (2013)\Season 01
\NAS\dvr\DVR\Imports\TV\slm\Brooklyn Nine-Nine (2013)\Season 02

Am I mistaken that they should be deleted by SLM as none of the streaming services I have configured have them available?

Thank you

Okay, I found the issue. Looks like I inserted a bug in a recent version. Got it working in my development environment and this will be fixed in the next release.

In the meantime, if you or anyone else wants to test out that this is working, you can upgrade to the prerelease version:

Glad you found it. Bugs like that happen and it can take a QA team to regression test well enough to find something like this. I'll load the prerelease if times allows me this evening and will let you know how that goes.

Thank you for all you do!

Morris

I followed the upgrade procedure for the prerelease. The version is still showing v2025.03.05.2024. Looking through the directories, at least some of the files are new.

Nope...

image

You must have missed one of the two steps. Either you didn't download the new batch file or didn't type in "prerelease" correctly. It will install the regular version with any other word in that position.