How it works
This wiki page briefly describes how the plugin works.
I will explain the database methods, both when using triggers and when using file timestamp to do the synchronization. The difference is mainly in the mechanism which kicks-off the synchronization as the actual synchronization process is common to both methodologies.
The thumbs synchronization is somehow straightforward and will be explained later on.
This method comprises in creating a new table, mpsync_triggers, in every database selected for synchronization. On every remaining table (excluding system tables) inside the database, 3 triggers will be created to capture modifications on the particular table. The change events are Insert, Update and Delete. These triggers are created on those databases that serve as the source from which data is synchronized. In a typical setup, these would be created on the Master Client and the Central Server from which other clients synchronize.
Below you can see an example of the created triggers on one of the tables:
mpsync_triggers table will contain a list of tables that have been modified by their respective plugin and the time when that modification occurred.
The table has the below structure:
Below is a sample of the same table for MovingPictures database:
Once a synchronization cycle is kicked-off, the plugin will read mpsync_triggers table and only compares/synchronizes content of tables whose name appear under column tablename and their lastupdated time is after the time when last cycle was kicked-off. This enables the plugin to process only modified tables, thus eliminating the need to process all the tables in the database and compare contents between source and target. This method brings huge improvements, both in time to process, I/O and CPU usage.
This method comprises in comparing the last modified date and time of the database files between source and target. If these differ, the plugin would then read and compare all content of all tables in the database of both source and target and any difference from source synchronized to target. Although this method reduces the number of databases processed, it still needs to go through all the tables and all their content.
This additional synchronization is done similarly for the above two methods mentioned above. The direction of this synchronization is the inverse of that selected by user, meaning that if you are synchronizing from source to target, then Watched Synchronization happens from target to source.
To achieve this synchronization, a new table, mpsync, was created in selected databases that cater for watched status and possibility to resume from last stopped position of movie, series or video.
The table has the below structure:
Below is a sample of the same table for MovingPictures database:
Thumbs synchronization is done in two steps:
The first synchronization pass is done by comparing image files on the source with those on the target. Missing ones from the master are added, while extra ones on target are deleted. For changes, it uses the last modified date of the image. If this is different on target, the one from the master is copied over.
A watch process is started on the source thumbs folder. This process will monitor for any change, which in turn is immediately synchronized on the target.
This eliminates the need to perform step 1 every time the thumbs synchronization cycle kicks-off, thus freeing up substantial CPU usage and I/O.