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.
The Command
#change directory to the index spooler directory cd /var/spool #restart index service sudo synoservicectl --restart synoindexd exit
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.
I just tried to use the command, but it doesn’t stop indexing, so I can’t start re-indexing.
But, by using your other sql queries I can see by doing interval queries, that the last file indexed seems to be the same, so indexing must be stuck.
Best,
Peter
Damn it, I forgot to log in as root. Sorry. Works great now :-)
Thanks for the very useful tips.
Best,
Peter
Sorry I usually try to respond faster. Glad I could help!
Andrew,
I checked whether indexing is frozen using plsql. It is indeed frozen for a few days.
I ran the following command:
DiskStation> cd /var/spool
DiskStation> rm syno_indexing_queue*
And I got the following error message:
rm: can’t remove ‘syno_indexing_queue*’: No such file or directory
These are the files existing in the directory:
DiskStation> ls
MailScanner conv_progress_photo.aWZBkl cron postfix thumb_create.queue.tmp webapi
conv_progress_photo conv_progress_video php thumb_create.queue update_data_format
What shall I do now?
Thank you very much for your support.
Fyi I have a Synology DS411j with DSM 5.2-5592 Update 3
Thanks.
Alain
What are you trying to index? Assuming you have killed both the synoindexd and synoindexscand processes, then you merely need to click the Re-Index button to try indexing.
It works for me fine (I am using putty). But problems remains… after I kill synoindex, it starts reindexinx and stucks againd. So anytime I download new files I need to perform this commands again and again. Any help?
Hmmmmm can you tell what file it’s getting stuck on? What is your indication that it is stuck and not merely finished?
Excellent tips.
I had tried many options and by just exactly following your “manual” everything was solved.
Thank you so much for sharing.
Glad I could help!
Thank you Andrew now it work fine for me
I get “permission denied” when running “rm syno_indexing_queue*”
Logged in as root on DSM 5.2-5644 Update 5
My mistake, logged in as admin, not root. Works fine as root.
Hi, I tried this solution, but now I get this error in the kern.log : Mar 30 11:58:04 NAS kernel: [ 330.124784] type=1400 audit(1459331884.778:109): apparmor=”DENIED” operation=”open” parent=27253 profile=”/volume*/@appstore/PhotoStation/bin/photostationd” name=”/var/spool/thumb_create.queue” pid=27255 comm=”synomkthumb” requested_mask=”rac” denied_mask=”rac” fsuid=0 ouid=0
(I “touched” the /var/spool/thumb_create.queue as it was not created automatically). Any hint on what’s going on ?)
S.
Well I’m not sure it was necessary to create thumb_create.queue since it only gets created/exists when there is a thumbnail queue to process, and is a separate function from indexing so for the most part is irrelevant. And in fact depending on how you created this file, it might even interfere with the legitimate process from functioning normally. Did you create the file before or after you noticed the error?
Since you are referring to a kernel log rather than a shell error, I would assume this is the case. Check the thumb_create.queue file again to make sure it’s empty (I believe it will be), then delete it. It might be necessary to reboot the system. If the indexing doesn’t start automatically, you should be able to start it manually from the DSM control panel.
Hi Andrew, Just wanted to say thanks so much for this. I’ve been racking my brains on how to sort my indexing problem and having found loads of different explanations i found yours to be the most helpful. But have to say i still had to try it loads of times and read it over and over. I have DSM 6 and it didn’t matter what i did i couldn’t get root access. Turns out it was something small i was doing wrong. All good now and glad i’ve sorted it with your help.
No problem Anthony. Glad you got it sorted out.
I just went back and made a few alterations to the tutorial to clarify method changes when dealing with DSM 6. I hope future readers will find the changes helpful.
Nice post ! Also checked your other post on the postgress db for the indexing, exactly what I needed to know :)
Regarding your comment below:
Note: In DSM 6, you have to precede the above commands with a SUDO command since you can no longer login directly as root.
Although for security reasons it should be left this way, you can overcome the root user login issue as follows:
SSH to DS as the admin user/pass
Enter cmd “sudo su” and provide the admin password.
Enter cmd “synouser -–setpw root “
Now you can again login directly as root user again.
You’re very welcome.
I knew of that way to bypass the security restriction (forbidding direct root access) but I strongly agree with the new way of doing things, as this has been the accepted best practice in the sysadmin world for some years. Frankly I’m surprised it took so long for Synology to make that the default behaviour.
So you’re absolutely right but I’d be very cautious about it!
If there’s anything anyone would like me to cover on my blog please leave a comment!
Cool!!!!!! Thx for the DSM6 update, very useful!
champion. thanks for this solution. reindexing has begun.
Hello
Can I be in a situation where only the video upload is frozen and not the photos ? I checked through SQL command that indeed photos are still uploading but I am stuck on videos. Can I unfreeze just videos ??
thanks in advance
I assume you have already uploaded the photos and videos, and what you mean is the Index is stuck. So in other words, the files already exist, but they don’t show up in the Video Station or Photo Station. And in that case your videos aren’t frozen if the photos are indexing. It’s just waiting its turn. The index doesn’t happen simultaneously. Each type is indexed sequentially. So as long as the photo index is still working, just be patient and it will finish and then continue on to videos.
Ok ! Will do. Thanks a lot for the quick answer !
Many thanks for this info. I’m desperately trying to ‘kill’ Synology’s indexing/converting of about 40,000 items that’s been going for several years now (not joking) I got to the first stage of this process but it would’t recognise my password :-( in Terminal. I checked my stored ‘1-Password’ entries for Synology and I know that the one entered is ‘right’. Any ideas for getting past this point to stage 2? VERY many thanks Philip
Sorry for not replying sooner.
Which DSM version are you using? If you’re using DSM5 you can SSH directly as root, which by default has the same password as the first admin user you created. If you’re using DSM6 you have to first SSH as an admin user (assuming SSH is permitted for that user) and then “sudo -i” to impersonate the root user.
After that it should be fairly straightforward. I’ve recently made some discoveries that somewhat simplifies the process when the indexer gets stuck, but it sounds like your technical issue goes a bit deeper. It sounds like you may need to take the atomic route.
The following is a destructive command but basically it deletes the media server database. Apps like Photo Station, Download Station, Video Station, etc. all store information here so if you have any half-finished torrents or a lot of customizations in Photo Station (like comment history), they will disappear. Use this command at your own risk.
rm -rf /var/database/pgsqlrm -rf /volume1/@database/pgsql
Then reboot the DiskStation and it will recreate the postgreSQL database and populate it with a clean slate. If you then hit the “reindex” button as above, it should start from scratch.
Thanks for the tips but I’m still struggling.
Any file change in the media folders prompts a perpetual indexing media files process.
An example, I’ll add a small photo to a photo station folder & see the spinning update squares continually & can’t open the photo until I reboot. Likewise with new videos not appearing in DS video until a reboot.
Is nuclear option suggested earlier my only hope?
Thanks for any assistance
Tried the nuclear option by deleting the pgsql folder but issue persists.
I have noticed in same folder there are more pgsql folders. Should I delete these too?
https://goo.gl/photos/2wyJdw5CsQASA4Gh8
Those files are simlinks to the real postgresql service configuration at /etc/postgresql/postgresql.conf
You can confirm this by going into one of those .pgsql… folders and running this command against the file inside:
readlink -f postgresql.conf
Only one of those folders/files is necessary and I’m pretty sure it will get recreated at reboot so if you feel the need, back them up first before rebooting and see if it works.
As for the media indexing, I just want to reiterate that especially after the “nuclear option”, the indexing can take DAYS to complete, even for photos and videos that were previously indexed and thumbnailed. Depending, of course, on the number of files it needs to process.
I’m also having trouble where fileindexd will not stop running. I checked the current photos being added and it’s stuck on a particular PNG file. I tried restarting the service running the `synoservicectl –restart synoindexd & synoservicectl –restart fileindexd` but to no avail. Our server is running the most recent kernel version. What should I do now?
Okay so the indexing seems to have completed but I get these errors in the log file when attempting to search a particular folder. Searching does work in other folders.
2017-01-06T18:34:54-05:00 NNHS-MEDIA-SRVR synocontentsearchd: worker.cpp:240 Request: {“action”:”search”,”index”:”/volume1/GraphicsLab/@eaDir/SYNO@.fileindexdb”,”max”:2147483647,”query”:{“condition”:{},”pattern”:”((SYNOMDSearchFileName:(*tom*)) (tom))”}}
2017-01-06T18:34:55-05:00 NNHS-MEDIA-SRVR synocontentsearchd: error.cpp:60 Lucene err type: 9, reason: Read past EOF
2017-01-06T18:34:55-05:00 NNHS-MEDIA-SRVR synocontentsearchd: utils.cpp:41 CreateSearchEngineImpl failed, db_path=/volume1/GraphicsLab/@eaDir/SYNO@.fileindexdb, code=10, reason=No such file or directory
2017-01-06T18:34:55-05:00 NNHS-MEDIA-SRVR synocontentsearchd: search.cpp:102 (search.cpp:102)(No such file or directory)Failed [NULL == _pSearchEngineImpl], err=No such file or directory
2017-01-06T18:34:55-05:00 NNHS-MEDIA-SRVR synocontentsearchd: worker.cpp:323 (worker.cpp:323)(No such file or directory)Failed [!pSearcher->Search(query, SearchCallbackFunc, (void*)&_fd, maxResult)], err=No such file or directory
I believe I’ve solved this one myself. I had to stop the synoindexd process then cd into the @eaDir folder and remove the SYNO@.fileindexdb file. I then started up synoindexd and the indexes rebuilt themselves but this time I saw all necessary processes running besides fileindexd and could fully search the share within a few days of rebuilding.
Thanks for your articles and i am current facing Indexing Media Files Bug. it keep saying indexing but actually doing nothing.
I found that the problem is syno_index_queue.tmp only have a single line of my Personal Photo Album dir, all of the new files change is located in the queue file without tmp, however it cannot complete the tmp file and go to the queue file….so all new photos are not indexing.
I tried to rename the tmp or queue file to let them work, but i dont have correct password for sudo command, could you please give me some advice?
Nice Post…
Very thanks….