By default, Synology NAS devices will index all media files (pictures, music, videos) and generate applicable thumbnails. When a new file is indexed, this kickstarts a process that asks the thumbnail generator to get to work generating various thumbnail sizes for a given file. A common complaint from Synology users is that they can’t tell if the thumbnail process is frozen. I myself was curious which exact file the conversion process was working on, so I found the means which I’ll explain here.

The background process that generates thumbnail images for Synology devices is the aptly named synomkthumbd, presumably for Synology Make Thumbnail Daemon. In Synology DiskStation Manager, this process is called Thumbnail Conversion.

Here I’ll detail how to connect to the Synology device via SSH to find out what files synomkthumbd is currently performing thumbnail conversion for.

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).

Update 08/2015: Windows 10 now includes SSH in PowerShell.

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.

You must be logged in as root or the final query will give you a “Permission Denied” error.
ssh root@[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. By default, the root password should be the same as your admin account.

Find Thumbnail Conversion Process ID

Every computer process always has a unique process ID (PID) associated with it for reference. This number will usually be different each time this process is started, so we can’t assume what the number will be. First we query the system to find out the Process ID of synomkthumbd

pidof synomkthumbd

It will answer with the PID which will simply be a number.

List File Descriptors

Next we list the file descriptors that are being used by that process using the ls command

ls -l /proc/[pid]/fd

This should output a list of (what appears to be) workers that generate the thumbnails. On my box I see three folders called 0, 1, and 2, which I believe act to generate thumbnails for multiple files at a time. Note that PID number will change each time a new synomkthumbd creates a new process, so if you get a “no such file or directory” error in this step, go back to the previous step and see if the PID has changed.

If, for whatever reason, it appears that the thumbnail conversion process has frozen, it can be stopped and restarted without restarting the entire Synology NAS this way:

/usr/syno/etc/rc.d/S77synomkthumbd.sh stop
/usr/syno/etc/rc.d/S77synomkthumbd.sh start

The the same basic process is applicable to video thumbnail generation, except videos are generated by ffmpeg-thumb instead of synomkthumbd; there also appears to be folders 0 through 4 for that service.

Update: May 2015

It appears that the methods for starting and stopping the thumbnail conversion process that I described above are obsolete. (Thank you Peter). It previously worked as of DSM 5.1 but it was probably deprecated and since the 5.2 update they presumably got around to eliminating the old way.

Instead, Synology has added a central service management system, which you can call via SSH by running synoservicecfg.

If you feel the need to go down the rabbit hole, you can get a list of command arguments by running

synoservicecfg --help

Or you can simply get a list of services (which includes the synomkthumbd service) by using this command:

synoservicecfg --list

Armed with the name of the service you want to stop and start, the same synoservicecfg command can stop, start, or restart it.

synoservicecfg --stop synomkthumbd
synoservicecfg --start synomkthumbd
synoservicecfg --restart synomkthumbd

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. Depending on the type of media being indexed, it may not in fact be frozen and there are perhaps more files to index than you are aware of.

Here I demonstrate the process to monitor the index progress to see if it is truly frozen, or simply to check the index progress out of curiosity.

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).

Update 08/2015: Windows 10 now includes SSH.

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.

ssh [username]@[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. By default, the username and password should be the same as your admin account.

Ask (Query) The Database

psql mediaserver postgres

This will open a PSQL command prompt where you can perform what’s called a SQL query, which is basically a fancy way of saying you’re asking the database a question. SQL stands for Structured Query Language and is the standard language for database interaction.

SELECT COUNT(*) AS video_count FROM video;
SELECT COUNT(*) AS music_count FROM music;
SELECT COUNT(*) AS photo_count FROM photo;
SELECT COUNT(*) AS dir_count FROM directory;
SELECT * FROM music WHERE id = (SELECT MAX (id) FROM music);
SELECT * FROM photo WHERE id = (SELECT MAX (id) FROM photo);
SELECT * FROM video WHERE id = (SELECT MAX (id) FROM video);
SELECT * FROM directory WHERE id = (SELECT MAX (id) FROM directory);

The above query is actually 8 separate queries. For the first four it will answer with a table indicating how many photos, videos, songs, and folders have been indexed, followed by a comprehensive list of the most recently indexed file under each category, along with related tagging information (such as file name, format, length, etc). Generally, (at least in my experience) photos will be more numerous so will take the longest. So we can check the progress for just the photos like this:

SELECT COUNT(*) AS photo_count FROM photo;

Or if you simply wanted to see the name and location of the photo it most recently indexed, you could use this query:

SELECT path FROM photo WHERE id = (SELECT MAX (id) FROM photo);

Note that each query starts with a “SELECT” statement and each query ends with a semicolon (;). Capitalizing the different SQL statements is not necessary, just a force of habit.

Update February 22, 2016: As Sietse noted in the comment section, changes between DSM 5.2 and DSM 6 mean that by default, you can no longer login to the root account directly via SSH. Instead you must login as an admin user and escalate to root using the SUDO command. (e.g. sudo psql mediaserver postgres.

Update March 2, 2018: I hadn’t revisited this subject in some time now but I recently had a power outage that seems to have triggered some kind of full reindex of Photo Station.
I had uploaded a bunch of photos and music and nothing had shown up for a couple of hours, which indicated to me that the index was busy doing something else.

For reference, /var/spool/syno_indexing_queue is where all file changes are queued up for the indexer to process. Once the indexer triggers, it moves this file to sync_indexing_queue.tmp, so that’s the file to check when you want to see what it’s currently working on.

When I ran:

cat syno_indexing_queue.tmp

It showed:

#offset:128;                                                                                                                   
PhotoStation:1:R:photo

Something told DSM to run a full reindex of Photo Station. I’m not sure if it was a coincidence or if it really was the power outage — I’ve never got a straight answer about what exactly triggers a full index, though I’ve seen it more than once. The power outage seems less likely though, since it was shut down smoothly by my UPS controller.

In any case, it got my attention again.

The SQL queries I wrote about before are all well and good, but sometimes I just want a continuous poll of where it’s at, without having to manually run the command over and over. I could do some kind of cron job and output to an HTML file with an auto refresh but it comes up rarely enough that I just wanted a quick & dirty shell script to do it.

Long story short, here’s what I came up with:

while sleep 30; do ls -l /proc/$(pidof synomkthumbd)/fd | grep volume ; done

Basically what the above one-liner does is every 30 seconds it’ll poll the synomkthumbd process and find out what it’s working on and print the results to the console. A new line will output every 30 seconds until you exit the command. the grep volume section at the end just cleans up the output so that it only shows you the relevant information (assumes volume is in the response line as in volume1, volume2 etc).

The command may take a bit to show results because there are times when it’ll be between files so it won’t have any output. Just wait a minute or two and you should start to see results. Or alternatively you could shorten the polling period from 30 to something shorter.

Is your index frozen? Learn how to restart it.

Very recently some my clients began experiencing a troubling problem: while using Outlook 2011 on Mac OS X, they were constantly getting prompted for a password, stating that the old password was incorrect. Now, having experience with that kind of thing before, the first thing I checked was that their account was not getting locked out somehow (usually due to too many incorrect password attempts). But in this case, that was not the problem.

Next, I simply had them shut down Outlook completely and start it up again. Sometimes programs get unstable when left running for too long. It shouldn’t happen, but it does. And this is Microsoft software on a Mac so it seems par for the course. But still the problem continued.

Then I checked the Keychain, which is a utility on the Mac that stores authentication for different programs in a central place. I checked it for errors, fixed the ones it found, and when even that didn’t work, I wiped out the old entries and created new ones. Still the problem continued.

Eventually while digging in Google, I came across the solution.

For some unexplainable reason (or at least not any reason Microsoft has made public), instead of the usual user@domain.com username format, Outlook 2011 requires the following:

yourdomain.onmicrosoft.com\username@yourdomain.com

So for example, let’s say your domain is contoso.com and your username was alfred. In that case, when setting up your account settings, you would input this in the username field:

contoso.onmicrosoft.com\alfred@contoso.com

For my client, it had worked before fairly consistently with the old user@domain.com-style username, but after an update or when upgrading to OS X 10.10 Yosemite, or some other mysterious combination of circumstances, this issue appeared.

I hope this helps others — I really had to dig to find this gem.