This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |
| softwares:giocoso:dbmenu:fastscan [2025/11/22 12:05] – hjr | softwares:giocoso:dbmenu:fastscan [2026/02/06 22:36] (current) – [3.0 Fast Scans and Giocoso Pro] hjr |
|---|
| However, the release of Version 3.30 introduced the concept of 'Giocoso Pro', whereby a device's //local// database contents can be 'pushed' to a remote MySQL/MariaDB database that is shared amongst all music-playing devices. Accordingly, from that version onwards, and **//if//** Pro functionality has been enabled by setting a remote database server's IP address in the Giocoso configuration file, a fast refresh will complete its local work by going on to copy the refreshed local RECORDINGS table to the remote shared database. Essentially, the local **RECORDINGS** table's data is inserted into the remote database's **GLOBAL_RECORDINGS** table. | However, the release of Version 3.30 introduced the concept of 'Giocoso Pro', whereby a device's //local// database contents can be 'pushed' to a remote MySQL/MariaDB database that is shared amongst all music-playing devices. Accordingly, from that version onwards, and **//if//** Pro functionality has been enabled by setting a remote database server's IP address in the Giocoso configuration file, a fast refresh will complete its local work by going on to copy the refreshed local RECORDINGS table to the remote shared database. Essentially, the local **RECORDINGS** table's data is inserted into the remote database's **GLOBAL_RECORDINGS** table. |
| |
| This data copying process is //always// a complete **replacement** of the GLOBAL_RECORDINGS table contents. It starts by deleting all rows from that table and then re-loading it from scratch. In this way, the GLOBAL_RECORDINGS table always contains up-to-date data about the recordings that the device doing the fast refresh can and can't see. This thorough approach does mean, however, that a fast refresh might no longer be particularly fast! | Where a full local refresh triggers a complete **replacement** of the GLOBAL_RECORDINGS table content, a **fast** local refresh triggers a process of working out what records the local database has the remote one hasn't (those 'missing' records need to be added to the global table). There's also a process of working out whether the global database knows about recordings that the local database no longer thinks exist: those need to be //removed// from the remote database. In either case, a full or fast refresh keeps the remote database completely 'in sync' with the local one, but the fast refresh is, as its name implies, considerably faster to perform than a full one, especially if it's just a question of keeping the databases informed after you've catalogued 3 or 4 new CDs that day! |
| |
| If you are using Version 3.30 or higher of Giocoso and have //not// enabled Pro functionality, then fast refreshes do as they have always done and keep only the device-specific //local// database up-to-date. | If you are using Version 3.30 or higher of Giocoso and have //not// enabled Pro functionality, then fast refreshes do as they have always done and keep only the device-specific //local// database up-to-date. |