When you add new music, photos or videos to a Synology share, by default, the device will scan the new files, render some new thumbnails and index the file in the appropriate library if applicable. This indexing process is necessary for the files to be shown through the various media services such as Photo Station and Music Station. A common complaint from Synology users is that this indexing or thumbnail conversion process can get stuck.
Unfortunately, at the time of this writing, Synology has not implemented any kind of progress bar or anything to indicate whether the process really is frozen.
Here I’ll explain the simple process of restarting the frozen index and thumbnail conversion process. The downside of this is that it will start the indexing from the beginning, but any thumbnails generated up to the point of it being frozen will remain.
Connecting Via SSH
This process assumes some familiarity with command-line tools like telnet. In Mac you merely need to open a terminal window, but in Windows you would have to third-party utility like PuTTY (because Microsoft’s Telnet solution does not support SSH protocol).
If, for whatever reason the Synology does not respond to the SSH request, make sure SSH is enabled by logging into the DiskStation Manager interface and navigating to Control Panel > Terminal & SNMP > Terminal.
In DSM 6 for security reasons you must login as an admin user (not necessarily “admin”) and then run the commands as root by preceding commands with “sudo”
ssh admin@[synology IP]
At this point it may say something about an RSA key fingerprint (particularly if this is the first time you’ve ever connected via SSH) and ask if you’re sure you want to continue connecting. Just say yes. The first admin user you created when setting up the DiskStation and root will have the same password.
#change directory to the index spooler directory
#restart index service
sudo synoservicectl --restart synoindexd
Update 09/16: Previously this article included a command to delete the two temporary files syno_indexing_queue and syno_indexing_queue.tmp, but this is should not be necessary unless the files themselves are corrupt somehow. The problem with deleting the queue files is that they feed the indexer the information it needs to know what to index, and if we delete those the index may be incomplete, with no way of knowing what it was going to index. If you do end up deleting them for whatever reason, the only sure way of getting a complete index would be to force a full re-index.
I’m not sure yet what triggers the synoindexd service, but on occasion it seems that for days it does nothing. It’s not until I reboot it that it seems to kickstart the indexing process again.
When you edit/add/delete files, they are automatically logged in the syno_indexing_queue file. When the indexing service is triggered, it renames it syno_indexing_queue.tmp while it processes it (which can take a while if it hasn’t been triggered in a long time). In the meantime while it’s processing the .tmp file, any subsequent changes will go to a new syno_indexing_queue file.
The bottom line is if you see this .tmp file, theoretically the indexer is already processing it. If you see a syno_indexing_queue file but no syno_indexing_queue.tmp, then the indexer hasn’t been triggered and can be triggered manually with the command above.
Is your Synology index really frozen or just taking a long time? Learn how to check.