Giocoso 3 – The Pro Menu : Push Plays to a remote database

1.0 Introduction

The option to "push" plays (meaning 'copy them') to a remote database allows non-primary Giocoso clients to add their play history to a globally-shared Pro database that has previously been initialised by a primary client. All non-primary clients will need to take this option at least once (immediately after they've been configured to connect to the Pro database, using the Administration menu, Option 2), since the Pro database will otherwise only know about the primary device's play history.

Clients may need to take this option on other occasions, too: if they have performed plays of music whilst not being connected to the Pro database for some reason, for example. In a case like that, the client's local table of plays will contain rows of data that are not in the global database (because that database was not contactable at the time the local data was stored, for whatever reason): the 'push plays' option allows the client to 'catch up' the Pro database with data that it would otherwise be missing.

As each play is pushed to the Pro database by this option, it is assigned a unique identifier (called the 'playhashvalue') which is computed from the recording's COMPOSER and COMPOSITION tags, plus the time of play's completion (down to the second). It is thus physically impossible for two recordings to acquire the same playhashvalue unless it involves, literally, the same composer, composition and time of play ...in which case, it is the same play! The Pro database will not allow the same play to be recorded in the database table twice, so attempts to do so silently fail (though rather a lot of time will be wasted as the client pushes the data without realising the Pro database is ignoring it!)

This means that you can safely take the Pro menu, Option 2 from the same Giocoso client device as many times as you like: no spurious data will be created if you do. However, after you've taken the option once on any given client device, it usually needn't be taken again, as each further play on that device is copied across to the remote database automatically. It's only if that automatic transfer of data fails for some reason that you would ever need to consider doing a manual re-transfer.

2.0 Running the Push Plays process

When you first take the Push Plays menu option, there will be a pause as the program checks the local database to ensure that it contains no data that wouldn't fit into the remote database. If there is found to be data that wouldn't fit, the push process will warn you about what is wrong and will then exit without having initialised anything. It's up to you at that point to work out what data is 'bad' and needs fixing at source. Examples of bad data would be full paths to a FLAC that exceeds 512 characters, or a Composer name that exceeds 256 characters, or a composition name that is longer than 512 characters. The chances of legitimate composer or composition names actually breaching these limits is small, of course: that's why these generous limits were specified in the first place! However, if you've tagged your FLACs in ways this site doesn't approve of, you might (for example) have the conductor, orchestra and soloists entered into the ARTIST tag, which Giocoso will have read as the COMPOSER tag ...and then you might have issues.

If you've tagged according to this site's prescriptions, however, then you are likely to be fine and instead receive this message of encouragement:

You can back out at this stage, without anything having been done to the remote database: just tab round until the 'No' option is highlighted, then press [Enter]. If you press [Enter] when the 'Yes' option is highlighted, however, then this happens:

Again, you can back out of the entire process without any data having moved to the Pro database, but if you are certain you want to proceed, just click [Enter] with the 'Yes' option highlighted:

This time, you are again given an opportunity to back out (not explicitly, it's true: but you could click Ctrl+C here to stop the process actually doing anything), but if you click [OK] (or [Enter]) to proceed, the local PLAYS table data will start to be be copied or 'pushed' to the remote Pro database -though note the message that duplicate records won't be created by doing this:

Finally, data starts to be copied from the local device to the remote server: you're told how many plays have to be copied across in total, and how many have been processed so far, along with a convenient display of a percentage progress bar.

Unlike a Pro database initialisation (see Pro menu, Option 1), the push plays process doesn't start its work by wiping any existing content in the global_plays table in the Pro database. The data that is being copied across is therefore merely added to whatever data is already in that remote table. The process absolutely will not duplicate existing data, however: though the 'Processing Play Number' indicator may click up through thousands of possible records, only ones that that the remote database has genuinely never seen before will be added to the remote table. Anything that looks to duplicate existing data is simply (and silently) discarded.

The transfer process is actually quite slow, even if no new data ends up being added to the Pro database, because actual computation of whether a pushed play is a duplicate or not is taking place. For every item in the local PLAYS table, the program is taking the COMPOSER and COMPOSITION tags, smashing them together and adding in the time of the play in question, resulting in something like 'BRITTENPETERGRIMES030924', for example. That whole concatenated string is then passed through a hash function to create a weird-looking string of numbers and characters that uniquely identify that particular play of music, called the PLAYHASHVALUE. It's this which the Pro database uses to determine 'uniqueness of play' and which thus allows it to draw the distinction between 'new play I need to add' and 'old play being resubmitted, which I can ignore'... and it takes a little bit of time to smoosh the different bits of data together and compute the hash value from them. On the other hand, it's more work for the Pro database to perform a fresh insert of a new play than to ignore the resubmission of a previously-submitted play ...so re-runs of the push procedure are definitely faster to complete than pushes that have a lot of genuinely fresh data to transmit. I can push 19,000 plays in around 10 minutes, anyway: that should be your (very!) rough benchmark: it will obviously depend on the speed of your network and the power of your pushing and receiving computers.

Should you press Ctrl+C in the middle of the play push, the process will immediately terminate. No particular harm is thereby done: if you re-launch Giocoso and take Option 2 once again, the push process starts over from the beginning and, if left to run to completion, those records that didn't make it across to the Pro database during the first interrupted run will make it second time of asking.

When the last local play record has been copied across to the Pro database, this happens:

Once you see this confirmation message, you're done. Click [OK] to dismiss it and you'll be returned to the Pro menu.

3.0 Summary

Pushing plays to a Pro database is something every Giocoso client will need to do at least once, so that its private, local store of play history is added to the shared, global play history. After a first 'push', however, it should not ordinarily be necessary to ever re-push, as normal plays thereafter are automatically copied to the Pro database. Network outages or random inaccessibility of the Pro database may, however, require a re-push by way of 'catching up' the Pro database with things that happened on the local device whilst it was out of communication with the Pro mothership.

Pushing plays repeatedly is not advised, however, simply because it's unnecessary and consumes quite a lot of computing and network traffic resources.

The push process itself is quite straightforward to do, though: just keep confirming you want to go ahead with it when (repeatedly!) prompted and then sit back and wait for the percentage bar to climb to 100%: job done!