Neureka 16 Posted November 8, 2025 Posted November 8, 2025 (edited) I’m not sure how this specific API endpoint is implemented, but it would be amazing if we can make the scans instant. There seems to be a delay after files are imported before Emby will actually start a scan of the folder that changed. My use case is that my media is downloaded and imported extremely fast (strm files), and I’d love for Emby to pickup on these changes instantly. It definitely offers a better wow factor when I push friends and family to that Premiere subscription. Edited November 8, 2025 by Neureka
rbjtech 5284 Posted November 8, 2025 Posted November 8, 2025 (edited) Get the library ParentID's and simply use the API to force a Refresh as part of any scripting, or a post command from the Arrs. You can also force any scheduled item as well by using it's ID - this is useful to run other tasks post the scan, such as Intro's and Thumbnails etc You can see all the ID's in a browser just by browsing to that item and copy it from the URL. As an example .. Quote rem ** Refresh Library Films ** c:\curl\bin\curl -X POST "http://emby.rbjtech.lan:8096/emby/Items/%EmbyFilmsParent%/Refresh?api_key=%EmbyAPIKey%" -H "accept: */*" set logtime=!time: =0! && echo [!date! !logtime:~0,8!] Info EmbyAPI Refresh Emby Films Task Requested ... >> !logfile! rem ** Refresh TV Series ** c:\curl\bin\curl -X POST "http://emby.rbjtech.lan:8096/emby/Items/%EmbyTVSeriesParent%/Refresh?api_key=%EmbyAPIKey%" -H "accept: */*" set logtime=!time: =0! && echo [!date! !logtime:~0,8!] Info EmbyAPI Refresh Emby TV Series Task Requested ... >> !logfile! rem ** IntroSkip ** c:\curl\bin\curl -X POST "http://emby.rbjtech.lan:8096/emby/ScheduledTasks/Running/%EmbyIntroSkipTaskId%?api_key=%EmbyAPIKey%" -H "accept: */*" set logtime=!time: =0! && echo [!date! !logtime:~0,8!] Info EmbyAPI Emby IntroSkip Task Requested ... >> !logfile! rem ** Video Thumbnails ** c:\curl\bin\curl -X POST "http://emby.rbjtech.lan:8096/emby/ScheduledTasks/Running/%EmbyVideoThumbnailsId%?api_key=%EmbyAPIKey%" -H "accept: */*" set logtime=!time: =0! && echo [!date! !logtime:~0,8!] Info EmbyAPI Emby Video Thumbnails Task Requested ... >> !logfile! Edited November 8, 2025 by rbjtech
sh0rty 714 Posted November 8, 2025 Posted November 8, 2025 (edited) 2 hours ago, rbjtech said: Get the library ParentID's and simply use the API to force a Refresh as part of any scripting, or a post command from the Arrs. You can also force any scheduled item as well by using it's ID - this is useful to run other tasks post the scan, such as Intro's and Thumbnails etc You can see all the ID's in a browser just by browsing to that item and copy it from the URL. As an example .. This is the way! @NeurekaIn case you use Linux, this is my script for scanning the whole library when media is added as a post script: #!/bin/bash curl -X 'POST' 'http://EMBYIP/emby/Library/Refresh?api_key=EMBYAPIKEY' -H 'accept: */*' -d '' You need to set the script up in Settings-> Connect->Custom Script (same for Windows/Linux). There you can also define which events you want to use as trigger. Edited November 8, 2025 by sh0rty
Q-Droid 989 Posted November 8, 2025 Posted November 8, 2025 You shouldn't have to trigger a scan for an entire library. The API also has an option to update a specific path unless this has changed recently. 1
sh0rty 714 Posted November 8, 2025 Posted November 8, 2025 (edited) 43 minutes ago, Q-Droid said: You shouldn't have to trigger a scan for an entire library. The API also has an option to update a specific path unless this has changed recently. The whole library scan is intended on my side. Edited November 8, 2025 by sh0rty
ebr 16169 Posted November 8, 2025 Posted November 8, 2025 6 hours ago, Neureka said: There seems to be a delay after files are imported before Emby will actually start a scan of the folder that changed. Yes, the delay is by design because if we reacted "instantly" then a series of scans would be triggered for each file as it came in (actually, maybe even as it is still downloading). The system needs to wait for a period of no activity to know that the file operations have actually finished. 1
Neureka 16 Posted November 8, 2025 Author Posted November 8, 2025 57 minutes ago, ebr said: Yes, the delay is by design because if we reacted "instantly" then a series of scans would be triggered for each file as it came in (actually, maybe even as it is still downloading). The system needs to wait for a period of no activity to know that the file operations have actually finished. Isn’t that what the options are for in the arrs when adding Emby in the connect section? (See attachment) On Import Complete should be once the import is complete and an immediate scan would be suitable. I don’t understand why everyone is manually scripting this when it’s already an option in the arrs. Can you guys please elaborate? Is there an endpoint that bypasses the delay? If so that is an acceptable solution. The goal here is to immediately scan without delay.
Q-Droid 989 Posted November 8, 2025 Posted November 8, 2025 (edited) 1 hour ago, ebr said: Yes, the delay is by design because if we reacted "instantly" then a series of scans would be triggered for each file as it came in (actually, maybe even as it is still downloading). The system needs to wait for a period of no activity to know that the file operations have actually finished. Was the delay setting moved to the DB or is it still this in system.xml? <LibraryMonitorDelaySeconds>90</LibraryMonitorDelaySeconds> Edited November 8, 2025 by Q-Droid
ebr 16169 Posted November 8, 2025 Posted November 8, 2025 You'll have to ask the developer of that software what they are doing. We have no direct integration with them. The delay I was referring to is in the file system monitor.
rbjtech 5284 Posted November 9, 2025 Posted November 9, 2025 (edited) 23 hours ago, Neureka said: Isn’t that what the options are for in the arrs when adding Emby in the connect section? (See attachment) On Import Complete should be once the import is complete and an immediate scan would be suitable. I don’t understand why everyone is manually scripting this when it’s already an option in the arrs. Can you guys please elaborate? Is there an endpoint that bypasses the delay? If so that is an acceptable solution. The solutions have already been provided above to scan individual libraries or you can even specify the individual path if you wish but I don't do this, as I scan at the end of the 'batch' because I post process the files - so I wait until all that is completed, THEN scan the results. I do not use file monitoring, that is turned off. If you use the built in arr's option - then it scans the entire library, for every file received - ie not efficient, especially if you plan on post processing the file. I use the arr's to write all the new files, and use that as part of my scripting. ie if working on a season, then I process after the season, not indvidual episodes as an example. Edited November 9, 2025 by rbjtech
Neureka 16 Posted November 11, 2025 Author Posted November 11, 2025 8 minutes ago, Luke said: @Neurekahas this helped? I was going to script it in the arrs but the script failed because ffprobe couldn’t run on strm files. As a workaround I made a cronjob to refresh all every minute. Not ideal, but was good enough for me. I decided to stop using strm files since there were tiny problems I ran into along the way. I haven’t looked at the Emby API yet, but if I can run an immediate refresh on a specific directory without having a delay that would be the ideal solution for me. Whatever the arrs are doing seems to have a delay.
ebr 16169 Posted November 11, 2025 Posted November 11, 2025 13 hours ago, Neureka said: Whatever the arrs are doing seems to have a delay. Again, I'm sure this is by design. The trick is knowing when the operation is truly "finished" or you are going to be spamming your server with redundant scans.
Neureka 16 Posted November 11, 2025 Author Posted November 11, 2025 (edited) 17 minutes ago, ebr said: Again, I'm sure this is by design. The trick is knowing when the operation is truly "finished" or you are going to be spamming your server with redundant scans. Like I said before, you can trigger it once the file is fully imported and can then only scan that specific file or directory if the API supports that functionality. It’s 2025, this is not crazy engineering here. Modern file systems are fast and it’s not rocket science to selectively scan individual files / folders. Edit: The plex connection scans it like I mentioned and doesn’t scan the entire library for a single file import. It’s a weird take when you act like a whole library scan is the only option. That is why I was asking if the API exposes anything that lets us immediately scan a file or directory rather than the whole library. Edited November 11, 2025 by Neureka
ebr 16169 Posted November 11, 2025 Posted November 11, 2025 If 100 files are coming in, it would still be very inefficient to kick off 100 scans. Like you said, file systems are fast so wait until all 100 are in and then bring them all in at once. That is the general philosophy. Since we derive identity partially from file structure, a single file can change things in a larger context than just that file or directory but, in defined cases, more targeted scans could get the job done.
Neureka 16 Posted November 11, 2025 Author Posted November 11, 2025 36 minutes ago, ebr said: If 100 files are coming in, it would still be very inefficient to kick off 100 scans. I agree that on benchmarks 100 scans would technically have more overhead, but the delay of 5-10 minutes for new files to show up feels bad. An API endpoint that can immediately scan in a file(s) based on path, be it the directory or complete file, would be awesome.
ebr 16169 Posted November 12, 2025 Posted November 12, 2025 21 hours ago, Neureka said: but the delay of 5-10 minutes for new files to show up To be clear, the delay in our system is 60 seconds so the delay you are talking about above is related to the length of the overall file operations - not the delay in the system. I can't speak to whatever the other software is doing.
Q-Droid 989 Posted November 12, 2025 Posted November 12, 2025 16 minutes ago, ebr said: To be clear, the delay in our system is 60 seconds so the delay you are talking about above is related to the length of the overall file operations - not the delay in the system. I can't speak to whatever the other software is doing. Quick question for clarity. If an episode is added to a season path triggering Emby's RTM 60 second timer, will adding another episode to the same folder within 60 seconds reset the timer or queue a new event with its own timer for each subsequent new episode added? This is for cases when adding a full season with many episodes that could take more than 60 seconds to copy.
ebr 16169 Posted November 12, 2025 Posted November 12, 2025 2 minutes ago, Q-Droid said: Quick question for clarity. If an episode is added to a season path triggering Emby's RTM 60 second timer, will adding another episode to the same folder within 60 seconds reset the timer or queue a new event with its own timer for each subsequent new episode added? This is for cases when adding a full season with many episodes that could take more than 60 seconds to copy. It works just like screensaver logic. The timer is continually reset as long as there is activity such that it only "expires" after the set period of no activity. A long file transfer still works because the file system reports as the file is transferring (because the target is continually changing). The whole point is to just scan when the overall operation (however many files) is complete. 3
Q-Droid 989 Posted November 12, 2025 Posted November 12, 2025 1 minute ago, ebr said: It works just like screensaver logic. The timer is continually reset as long as there is activity such that it only "expires" after the set period of no activity. A long file transfer still works because the file system reports as the file is transferring (because the target is continually changing). The whole point is to just scan when the overall operation (however many files) is complete. That's what I thought but didn't want to assume.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now