Giocoso Pro Concepts – Absolutely Baching

1.0 High-level Overview

Giocoso Pro is an entirely free and optional addition to standard Giocoso's functionality. It enables a local installation of Giocoso (what is termed hereafter a 'Giocoso client' or 'client device') to push its recordings and plays data to a remote server or PC hosting a special Giocoso Pro database, using the MySQL database engine (though see Section 11 below regarding the database engine actually in use on any given computing device).

The point of doing that is to enable the client's play history to be shared out to other Giocoso clients: in this way, plays made on a laptop in the bedroom at night are visible to the desktop PC that is used throughout the day, and vice versa. Reports and statistics produced by any Giocoso client will therefore accurately reflect the nature of the music played by all clients, not just the reports and statistics that could be derived from a client's local Giocoso database (which is only ever aware of the plays made on that specific device). The Pro database doesn't replace the local database: that's still there, present on every device; it is, however, an 'aggregation' of lots of local databases. Its play history is thus comprehensive, not device-specific.

Diagrammatically, you might imagine a Giocoso Pro implementation looking a bit like this:

Here we have two client PCs (one could be a laptop, another a single-board computer, whatever: the specifics don't matter!). Each client device is part of a single home network and can therefore access a shared storage device (here labelled a NAS, but it could simply be a third PC's hard disk shared out via SMB or similar), which contains the home's digital music collection. Thus each PC can play network-accessible music files. Their non-Pro database of what is playable and what has been played is stored on each client's internal hard disk, local to each PC and only really accessible by the Giocoso software installed on each PC. It's important to notice that no data passes directly between the client PCs: in earlier versions of Giocoso, there was a mechanism for one client to pass a copy of its local database to another, but that was clumsy and prone to error, so has been removed from Giocoso Version 3.30 and above. The current situation is as shown above: the Giocoso clients do not talk to each other, but all talk to a single Pro server.

Giocoso Pro is the addition of the bit you see in the top right of the diagram: a new server, labelled 'Pro Server', is visible to the two client devices across the network. It runs a database of recordings and plays, so each client PC can access that Server-based database to store data about recordings and plays that the other client can immediately see (and add to as needed). Note that the Pro Server here is not accessing the NAS device: a Pro Server doesn't need access to the music collection itself. It knows about what digital music files exist and where they can be found because the clients tell it, not because it works it out for itself. Since each client can see the same Pro server as the other(s), what one client writes there, the other can immediately read. Plays performed on one client are known about by others, because they all share the one, common Giocoso Pro database.

For this diagram to work, you need to do three things:

Build a Giocoso Pro Server
Install a MySQL client on each client device
Switch on Pro features for each client device

Separate instructions for building a Giocoso Pro Server are are provided elsewhere, but it basically involves installing MySQL server and then running a special configuration script that is downloaded from this website.

If you were performing a completely fresh installation of Giocoso Version 3.30 then the MySQL client software would be automatically installed as part of Giocoso's software prerequisite checks. However, upgrading to Version 3.30 from an earlier Giocoso release doesn't trigger this important software installation -so I've provided separate documentation that explains how to do the job manually, if you have to.

Finally, switching on Pro features for a client device is simply a matter of setting three new persistent configuration options: I'll discuss the details of this immediately below.

2.0 Switching Pro Client features on

After upgrading a client's Giocoso version to 3.30 or above, the Administration menu, Option 2: Create or Edit the Configuration file can be used to edit the local persistent configuration file:

Three new configuration options are provided, as shown: a MySQL IP Address and Port number, and a 'local folder prefix'. A fourth new option asks whether this is a primary device or not: we'll see how that works in Section 5 below.

For now, it's important to know that Pro features are turned on by setting a value for the MySQL Server IP Address parameter. If it is blank (as shown above, and as it will be by default) then Pro features are turned off. The IP address entered for this parameter is not validated at this point (but if it's invalid or inaccessible, no 'Play Music' menu options will work): it needs to be the IP address of the server running MySQL that has already been configured to act as a Giocoso Pro database. That will vary, depending on your own home network setup and configuration -but the client PC definitely needs to be able to connect to it over the network. Note that the IP Address parameter has to be a raw IP address, not a hostname that is resolved into an address via a DNS server or a hosts file. Giocoso literally checks any entry here at the point of submission and will blank out anything that is not submitted in the form a.b.c.d, where a, b, c and d are all numbers between 0 and 255.

The default MySQL port number (i.e., the port on which the MySQL listens out for remote connections) is 3306, and the configuration options screen will have this entered by default. Without an IP address entry, however, the presence of a port number here will not switch on Pro features. It is generally unlikely that you would ever want to configure a Giocoso Pro server to use a non-default port, so the default provided here to client devices is probably not going to need to change... but if you do elect to use a non-default port, here's where you tell the client what you've done. Note that if you are running an internal firewall, you need to open it to allow traffic through on whatever port is configured here, otherwise the port will be considered closed and network communications will not be able to flow between clients and server.

It is critically important when enabling Pro functionality in a Giocoso client device that you specify a valid value for the 'Local folder prefix' parameter, and I'll discuss that in some detail next.

3.0 File Storage Locations

The Pro database contains a global_recordings table which will contain data about all the recordings that any client device might want to play. It's important to realise, however, that the Pro database only stores a location to a digital file, not the file itself. It follows that if this global_recordings table is to be shared between multiple clients, then the recording location has to be applicable to, and valid for, all clients.

Imagine the scenario, therefore, where the shared NAS device on which your digital music files exist stores its music at, say: /mnt/bulkdata/music/classical/... and in lots of sub-folders within that basic path. You make this NAS location available to all your network client devices via file-sharing technologies such as SMB or NFS. Each client device then maps this network-accessible folder to a local mountpoint... and the problem is that different clients might mount the network location to very different mountpoints.

For example, my desktop happens to be the 'source of truth' for all digital music in my house, so it finds music at /home/hjr/Music. My main listening PC happens, for historical reasons, to map the NAS folder to /sourcedata/music. My laptops, unconstrained by history, tend to map the same NAS folder to /netmusic.

The problem is that the Pro database must respond to queries from all these devices about 'where do I find Beethoven's Symphony No. 5?' and provide a response that works for all devices. If it replied 'at /home/hjr/Music/Beethoven/Symphonic/Symphony No. 5', that would make my desktop PC happy, but would be completely wrong for my main listening PC and my laptops. If it answered with a full path, the path would have to be identical on all client devices for it to work for all of them... and constraining things that way would defeat the intended purpose of making Giocoso 'device independent'.

So what Giocoso Pro does is to store, in the global database, only the part of the path which genuinely does apply to all client devices. This is called the folder suffix. Each client device then prepends the part of the path which makes the file suffix work for that device: this is called the folder prefix. So, for example, imagine I have these devices and paths:

Main PC: /home/hjr/Music/Beethoven/Symphonic/Symphony No. 5
Laptop: /netmusic/Beethoven/Symphonic/Symphony No. 5
Listening PC: /sourcedata/music/Beethoven/Symphonic/Symphony No. 5

...then I hope it's obvious that /Beethoven/Symphonic/Symphony No. 5 would be valid for all my client devices and thus be a suitable folder suffix, and the /home/hjr/Music, /netmusic and /sourcedata/music parts of the paths must therefore be valid device-specific folder prefixes.

Here's the completed configuration screen for my main PC, therefore:

When the global, shared Pro database tells my main PC to play "/Beethoven/Symphonic/Symphony No. 5", therefore, my PC automatically sticks "/home/hjr/Music" onto the front of that and thus searches my hard disk for the complete path of /home/hjr/Music/Beethoven/Symphony No. 5... and will be successful in accessing that complete path. Different devices can look in paths that make sense to them, too, because they'll be configured with different folder prefixes, each one appropriate to each specific device. In this way, Giocoso Pro ensures device independence yet provides single, centralised responses to 'what recordings exist?' queries.

Incidentally, note that it doesn't matter if you enter your local folder prefix with a trailing slash or not: Giocoso Pro treats /home/hjr/Music/ identically to /home/hjr/Music (without the trailing slash).

4.0 Consequent Changes to the local installation

When you switch Pro features on for a client devices by configuring a Remote MySQL Server IP Address, the behaviour of the local client installation changes significantly, as follows:

All options on the Play Music menu that have to do with selecting things to play (except for the 'play music in specified folder') now source their selections from the shared Giocoso Pro database, over the network
Numbered options on the Play Music menu have changed position to accommodate the new Global Resumption feature (see Section 10 below). Options 6 and 7, to do with using playlists, are now Option 7 and 8, and global resumptions are handled by a new Option 6.
During plays of music, the 'n' key now invokes the 'Global Notes' mechanism (see below, Section 9), not the local one
When a play concludes, it is still recorded in the local plays table; it is then copied to the remote, Pro database. In other words, the local plays table continues to be a complete record of what this specific device has played.
Playlists created before Pro features are enabled are invalidated: their full-path locations will now conflict with Giocoso's expectation of needing to add the local file prefix onto any paths given to it to play
All options on the Database Management menu continue to reference the local database: if you create a database, it's a local one; if you fast or full-scan refresh a database, it's the local database that is being refreshed (but see below); if you backup or optimise a database, these are operations that only affect the local database... and so on.
As just stated, any fast or full scan database refresh is always of the local database... but if Pro mode has been enabled, the program will always performs a full push of the local recordings table to the remote, shared database after the local database has been brought up to date. Thus, if your local database knows of 1000 recordings after a refresh, so will the global database. If you were then to add a single new recording to your collection, you'd perhaps perform a fast refresh of the local database. At one point, just as the local scan concludes, the local database would know of 1001 recordings, but the remote Pro database still only knows of 1000. A fraction of a second later, the local database will know of 1001 recordings whilst the remote database knows of 0 (yes, zero!), because the remote database's table of global recordings is always completely wiped as part of a refresh. Another fraction of a second later and the local system will start to push its recordings table to the remote database from scratch. Eventually, all data will have been transferred and both the local and remote databases will now, finally, agree that there are 1001 recordings to choose to play. Once the Pro database knows of this one new recording, all client devices are immediately aware (and can play) the new recording, too.
The reporting menu can use either the local database as its source, or the remote, shared database: but it can't use both at the same time. Option 9 on the new Pro menu allows you to switch sources back and forth, between local and remote mode.
If reporting is done in Pro mode, then all output from the Advanced Reporting by SQL function (Option 5) will open in your system's default browser.
Nothing in the Administration menu changes meaning or functionality
A new Pro menu is accessible. This allows a client to wipe the remote recordings table and to re-populate it ab initio. It also allows you to produce a couple of 'aggregated statistics' reports, whereby you can see which devices are playing how-much music and what operating systems they're using to do so.
Configured parameters that affect music search (e.g., setting a maximum and/or minimum duration, or setting the unplayed works or under-played composers flags on) still affect searches performed by that device.

It's important to note that Pro features can be switched on and off, at will. You do so by supplying or removing an entry for the 'Remote MySQL Server IP Address' configuration parameter (accessible via the Administration menu, Option 2). If you switch them on, all the changes mentioned above immediately kick in. If you switch them back off, then everything reverts to the way Giocoso behaved before remote databases were even a thing: plays revert to being sourced from the local recordings table and completed plays continue to be stored in the local plays table, for example.

5.0 Are All Clients Equal?

Conceptually, all Giocoso clients have access to the same collection of digital music files (though the specifics of the paths needed to get to them might vary, as previously discussed), so each is as equally well-equipped to talk to the remote Pro database as any other. However, the file prefix/suffix business does affect the answer to the 'are all clients equal' question!

Suppose you have one PC whose folder structure to get to the music files is: /sourcedata/music/classical/A/Aaron Copland... and another PC has /netmusic/classical/A/Aaron Copland... If you were to let the first PC say the file prefix was '/sourcedata/music/classical' and the second to say it was '/netmusic', you'd have problems on your hands, because that would result in different suffixes (specifically "/A/Aaron Copland" and "/classical/A/Aaron Copland"): if the global database was populated with the one, then it wouldn't work for the other.

Now, you could just let the two PCs fight over this: every time a PC refreshed its local database, they would re-write the global_recordings table with the suffix that applies to it, thereby immediately rendering music unplayable on the other device, because the prefix+suffix no longer describes music folders that it can get to.

Of course, the real fix for this is to sort out the prefix definitions so that they correctly result in suffixes that apply to all devices (in this case, /sourcedata/music and /netmusic would work; so would /sourcedata/music/classical and /netmusic/classical, as both would result in suffixes of '/A/Aaron Copland...' that would apply to both devices).

However, in the absence of 'corrected' file prefixes like this, what will actually happen is that you'll wake up one morning to try and play music on one PC and be told that no music can be found to play ...because the other PC had a scheduled database refresh overnight and thus clobbered the Pro database with file suffixes that no longer work for my regular PC (ask me how I know!). Therefore, Giocoso asks you to declare one client device to be the 'primary device': its database refreshes will be local, of course, and then be pushed to the remote database. Non-primary devices will only refresh their own local database: there won't be a subsequent push of recordings data to the Pro Server. Practically, this means it is the primary device's choice of file prefix/suffix that becomes the one that all other devices then have to work with.

Now: there's nothing to stop you declaring all your client devices as primary. It just means when each refreshes itself, it will also refresh the Pro Server: if you've got your file suffixes and prefixes sorted out correctly, then there's no harm in that at all, though it's a tad unnecessary! So, again: conceptually, all client devices are as equal as each other... but practically, it makes sense to nominate one device to keep the global_recordings table up-to-date whenever it refreshes its local database ...and for all the other devices simply to read the results, but not to create them.

Bear in mind, too: the Pro menu, Option 4: Push Recordings to remote database is there to allow any client device to push its local recordings table to the remote Pro Server database under manual control. The 'primary-ness' of a device only affects whether it automatically pushes its recordings to the remote database every time it locally refreshes. It's also true that you can re-designate a primary device as a non-primary one, and promote a non-primary one to be primary as your needs and requirements dictate. It's not a set-and-forget option, incapable of modification.

6.0 Do Clients need a local database any more?

Since all clients, once Pro features are enabled, get their 'source of plays' from the Pro server; and since they write their 'history of plays' to the same Pro server, it's a reasonable question to ask whether or not the local Giocoso database is necessary any more on client devices. The answer to that is unequivocably: yes.

There are a number of reasons for this. First and most important: when a play concludes, as was mentioned in Section 3.0 above, the details of the play are first written to the local database and only then copied to the Pro one. If there is no local database, that first write would fail, messily.

Secondly, the Pro database is a summation or aggregation of multiple local databases, not a replacement for any of them. Thirdly, and related to the prior point: the network might go down and if it does, it should be possible to continue using Giocoso in local mode. Once connections to the Pro database are available again, fine: the stuff that took place locally should be push-able to the Pro database by way of catch-up (that's what the Pro menu, Option 4 is for, after all). If there were no local record of plays made, that sort of catch-up wouldn't be possible; and if we instead said 'make the Pro database the only one that clients use', Giocoso would be rendered unusable the second the network or the Pro server itself failed. Putting point 3 in a different way, then: we don't want a single point of failure to render Giocoso unusable; having a local database we can read from and write to means we don't have to take that risk.

Finally, as has been mentioned previously, Pro mode is switchable: you can turn it off and on. If you didn't have a local database, you couldn't do that usefully.

So: in short, you must have have a local database when you want to run in Pro mode. Get your local database created and populated first, and then turn on Pro mode to unlock the new features it provides, whilst still having a usable local installation should it prove necessary.

It is technically true that only one client device needs to do a scan for music files and thus populate the local recordings table, before pushing this to the Pro database. That's because all other clients will thereafter be told what music to play and what location it can be found in by the Pro database: a local recordings table is therefore not needed to perform that function (and one could be created easily enough should Pro-mode ever be turned off). But this 'lack of necessity' definitely does not extend to the local plays table. If you want to play music on a Giocoso client device, it must have access to a local plays table... which means a local database is a necessity, at all times.

7.0 Definition of Uniqueness

In Pro mode, the definition of a unique recording is the COMPOSER tag plus the COMPOSITION tag, conjoined: this is called the RECHASHVALUE. The definition of a unique play is COMPOSER+COMPOSITION+PLAY_DATE: this is called the PLAYHASHVALUE. In both cases, in Pro mode, the uniqueness of a composition or a recording are derived from the tag data stored within FLACs themselves. If you modify the composer or composition metadata associated with a FLAC after it has been added to your Giocoso database, then it will appear as a new recording when ultimately transferred across to the shared Pro database.

This is very different to the way old-school Giocoso (and current, but non-Pro, Giocoso) works. In non-Pro mode, it is the full path to a FLAC on the hard disk which defines uniqueness (called the DIRNAME in both the plays and the recordings tables). If you were to move a FLAC from a folder called /orchestral to one called /symphonic, for example, then this would look like a new FLAC to non-Pro Giocoso... but since the composer and composition tags didn't change, it won't look like a new recording to Giocoso in Pro mode.

The significance of this is that some Giocoso behaviours depend on the definition of 'what constitutes a unique recording'. If you are asking to play unplayed recordings, for example, then the test in non-Pro mode is 'does this recording's full path (i.e., DIRNAME) appear in the PLAYS table?' In Pro mode, however, the definition is 'does this recording's RECHASHVALUE appear in the GLOBAL_PLAYS table?'. Going back to that previous example, then, it becomes obvious that in non-Pro mode a physical move of a file will make Giocoso think the file is new and thus unplayed ...but if neither the composer nor composition tags were modified, Giocoso running in Pro mode will know the file has been played before, because the physical move won't have changed the file's RECHASHVALUE. This means not only music selection can change between Pro and non-Pro modes (recordings one thinks are previously-played might look unplayed to the other) but the reporting on things like 'how many recordings are unplayed' will vary between the two modes, too.

8.0 Table and Column Definition Changes

In standard Giocoso, non-Pro mode, you would query the RECORDINGS and PLAYS tables. When Giocoso is running in Pro mode, however, you will query the almost-equivalent GLOBAL_RECORDINGS and GLOBAL_PLAYS tables. The GLOBAL_ tables are functionally equivalent to their non-global equivalents, but there are actually quite considerable internal differences between RECORDINGS/GLOBAL_RECORDINGS and PLAYS/GLOBAL_PLAYS, some of which have been mentioned above, but which I'll re-iterate here.

In RECORDINGS and PLAYS, every record is uniquely identified by an automatically-assigned ID number. Every new full scan of recordings (Database Management menu, Option 3) completely wipes the RECORDINGS table and potentially assigns different IDs to the same recording than it had before. Accordingly, the ID is really a meaningless piece of data in RECORDINGS (it is less volatile in the PLAYS table, however, since that is never wiped).

In GLOBAL_RECORDINGS, the unique identifier is RECHASHVALUE. This is an MD5 hash string which is directly derived from the COMPOSER and COMPOSITION metadata tags found within the digital music file itself. In the GLOBAL_PLAYS table, the unique identifier is PLAYHASHVALUE, which is another MD5 hash string derived directly from the COMPOSER and COMPOSITION tags, plus the date and time of the conclusion of the specific play. Since these hash values are derived from metadata, they are genuinely invariant unless the metadata associated with a digital music file is actually changed.

I've also already mentioned that non-Pro RECORDINGS and PLAYS tables used a column called DIRNAME to store the full path to the location of a digital music file; in Pro mode, the GLOBAL_RECORDINGS table has a column called FILESUFFIX and this stores only the device-independent part of the path that locates any given digital music file. The non-Pro PLAYS table also stores the DIRNAME when a play concludes: in Pro mode, the GLOBAL_PLAYS table merely stores the RECHASHVALUE of a recording, without any indication of the physical location of the file(s) just played. Both PLAYS and RECORDINGS and their Pro equivalents go on to store the GENRE, COMMENT, PERFORMER and DURATION of each recording or play, so there is no change there.

Finally, the GLOBAL_PLAYS table stores the name of the client device doing the music play, and the details of the operating system it is running, in columns called DEVICENAME and OS_TYPE. There are no equivalents of this data in non-Pro mode.

Being aware of these details is important when it comes to constructing Advanced SQL play requests (Play Music menu, Option 4) or Advanced SQL reports (Reports menu, Option 5). If, for example, you had previously wanted to play previously-played masses by Haydn, you might have submitted a query such as:

composer='Joseph Haydn' and genre='Choral' and composition like '%missa%' and dirname in (select dirname from plays)

In Pro mode, that same query would have to be re-written as:

composer='Joseph Haydn' and genre='Choral' and composition like '%missa%' and rechashvalue in (select rechashvalue from global_plays)

Note the change from testing 'dirname' to 'rechashvalue' and the change of table name from 'plays' to 'global_plays', for example. These changes are not applied automatically for you: there's a reason this stuff is called 'Pro'... you're deemed to understand what's needed to construct valid SQL statements!

9.0 Global Note-taking

Since Giocoso Version 3.12, it's been possible to tap the 'n' key as a recording plays and thereby open up a text document (called classical_music_notes.txt, stored in $HOME/.local/share/giocoso3/txt) where you can type in assorted notes and observations. This facility remains unchanged in Version 3.30, but if you switch on Pro features, the new 'Global Notes' feature is invoked instead.

"Global Notes" means that a new table is created in the Giocoso Pro database, called (somewhat unimaginatively!) GLOBAL_NOTES. It is queried when the 'n' key is tapped: either existing notes for the currently-playing recording are found in the global database, in which case they are opened in nano for editing; or no existing notes for the current recording are found, in which case nano is opened with a new document that is blank (except for the composer and composition names, which are auto-inserted on the first line of text):

In either case, you can just start typing your notes and observations as before. You will note that the text wraps when needed, but not particularly nicely (see, for example, the way 'from the trumpets and drums' wraps in the above screenshot on line 3 of the main text): it is a basic text editor that's being used for its simplicity and ubiquity, not because it handles long lines of text particularly well! Once you're done writing, the edited text is saved (by pressing Ctrl+X) and, at that point, it is written back to the Pro database: no copy of the text is stored locally, at all. Once nano closes, Giocoso returns back to the 'now playing' screen, which continued to run in the background for as long as you were editing text.

Note that any local notes you may have made before enabling Pro features are not transferred across to the global database. They remain accessible in the local classical_music_notes.txt file, but transferring them across to the global database is a manual job.

Also note that global notes are specific to the recording that was playing when the 'n' key was tapped. The global_notes table consists of only two columns: rechashvalue as the unique key, identifying the work for which the notes are provided; and notes -which is a long text field, accepting up to 4GB of input (which should be sufficient for most recordings, I think!)

Global notes can be viewed by taking the Reports menu, Option 5 and typing the query select * from notes (the report will open in your system's default browser). You can, of course, supply extra clauses, such as 'where composer like '%Mozart%' and composition like '%Mass%' to narrow things down, if you need to. An option on the new Pro top-level menu also lets you see all notes in your system's browser, without fine-tuning selection criteria (Option 8).

10.0 Global Pause and Resume

When Giocoso clients operate in 'Pro' mode, if music playback is ever paused, data about what recording was being listened to and the point to which playback had reached is written back to the Giocoso Pro database (into a table called GLOBAL_PAUSESTATUS). If playback is resumed on that original client device, the previously-created playstatus record is deleted. The playstatus table therefore only contains data about recordings that have been, and still are, paused.

Whilst playback remains paused on the first Pro client device, therefore, it's possible for another Giocoso Pro client device to use the contents of the playstatus table to start playback itself, of the same recording, from the point to which the first device had reached. Putting it as bluntly as I can: one device can resume a play that another device was in the middle of. Practically, this means that I can listen to a long opera on my headphones using my laptop in bed at night; hit the pause button when I think I'm too tired to continue; then in the morning, I can resume the opera from the point I'd reached but on the main listening room PC. The journey can be done in the other direction, too, of course: hit pause in the listening room, resume the playback once I'm safely in bed with the laptop at the ready.

The resumption is not perfect: Giocoso rounds things to whole seconds, so playback resumption might skip a fraction of unplayed music, or repeat a fraction of played music. The resumption on a second device also doesn't stop the original client device from thinking it's paused in the middle of playback: if you were to return to the original device, it will still think it's paused in the middle of whatever piece it had been playing. You can always simply hit the 'Terminate' option to deal with this, of course -though listening to a good opera second time round is no bad thing, either!

Pauses are device-specific. That is, the global_playstatus has three columns: the device, the recording and the current playback position. When a second device wishes to resume a global play, therefore, the user is prompted for which device's paused play it wishes to 'take over':

Note that if there's only one device is in pause mode, this 'prompt for a device' doesn't appear: the one and only device in pause mode is assumed to be the one you're trying to resume.

If the prompt for a device does appear, however, you simply use the up and down arrow keys to select the appropriate device name, then press [Space] to select a device and finally press [OK] to confirm the choice: playback then starts on the new device immediately. I trust it's obvious that a device can only play one piece of music at a time: therefore, only one piece of paused music can exist on a device at a time. Accordingly, by picking the device name in this dialog box, you've implicitly said what music you want to resume.

Resumed plays always start immediately: the usual 'countdown' of the number of 'seconds to wait before playback starts' (as configured in the Administration menu, Option 2) does not apply to resumed plays, because resumption is a deliberate one-time act that it's assumed you're in control of!

Attempting to perform a Global Resume when not operating in Pro mode results merely in the display of an error message explaining that resuming someone else's play requires Pro mode. Similarly, if you attempt to resume something when no other client device has paused playback, you'll simply see a message to this effect and nothing further will happen.

11.0 A Plan of Action

Switching over to running Giocoso in Pro mode can be a little awkward and one client device can trip things up for all the others if you're not careful. Here are a few guidelines for how to go about a successful Pro implementation:

Make every client device a proper non-Pro Giocoso device first. Create a local database and populate it with recordings from your collection. Make a few plays on that device, too, to ensure everything is working correctly in non-Pro mode first
Choose one device to be the primary client: the one that will be responsible for refreshing its own local database of recordings on a regular basis and then pushing that to the global database. Other clients then need to be set to be non-primary: their local database refreshes will still happen but won't be pushed to the global database
Make sure that the primary device's folder structure can be split into suitable prefix and suffix components that will work for all proposed client devices
Build a Giocoso Pro Server and ensure it's ready to accept client connections from across the network
Configure the MySQL IP address for all non-Pro clients that you wish to convert to Pro clients, along with appropriate Port, File Prefix and Primary flags in the Administration menu, Option 2.
Double-check the file prefix settings: are you sure that when applied to your music folder structure, they will correctly identify a physical location where that device can find the necessary FLAC files?
On the chosen primary device, use the Pro menu, Option 1: Initialise a remote Global Database to push the local recordings and plays tables across to the Pro server
On all the non-primary devices, use the Pro menu, Option 3: Push Plays to remote database to add their plays into the global_plays history

After that lot, you should be ready to run in Pro-mode in earnest: good luck!

12.0 MySQL or MariaDB?

Throughout this documentation, the database engine the Pro server uses will be called MySQL. However, in practice, nearly all Linux distros these days install a database engine called MariaDB, even if you explicitly ask to install MySQL: the two names are basically aliases of each other and are treated as such by nearly all mainstream Linux distros. If you are not aware of the history, it might cause some confusion when I talk 'MySQL' and commands seem to talk 'mariadb'. The short version of that history, therefore, is that MySQL was an independently-developed and mostly open source database engine before being purchased by Solaris, who in turn got purchased by Oracle Corporation. Now, Oracle Corporation is not enamoured of open source projects and are renowned for being a corporate nightmare to have dealings with: I used to work for them and 'Orrible 'Oracle was a common enough epithet to hear thrown about by staff and customers alike!

Accordingly, the moment Oracle bought Solaris, the MySQL software was forked, which basically means 'copied and re-named and independently-developed thereafter'. The forked copy was called MariaDB. That's all perfectly legal to do in the world of open source software, but it meant that further development of MariaDB could be pursued without Oracle involvement. Thus, MySQL and MariaDB are no longer the identical copies of each other that they were immediately after the fork happened. Nevertheless, for the sort of functionality that Giocoso is making of MySQL/MariaDB, they can be considered equivalent, practically identical, database engines.

This then explains why most Linux distros (who prefer not to touch proprietary software with a bargepole, and who definitely don't want to be in Oracle Corporation's legal and licensing sights) have quietly aliased MySQL and MariaDB, such that if you ask for the one to be installed, you'll get the non-Oracle other instead.

This complex history needn't detain you for long: just know that the two names can, for the current purposes of Giocoso Pro, be used completely interchangeably. If I say 'start MySQL' the command to do that may well be to 'start MariaDB', but the results will be the same in either case.

With all that said, however, the Pro Script which turns a server into a Giocoso Pro server, running a database waiting for Giocoso clients to connect to it, installs MariaDB, not MySQL... and (here's the real kicker) if MySQL Server is already present on the server, it is automatically erased and replaced by MariaDB. So that's something to consider if you're thinking of plonking the Giocoso Pro Server on the same box you run a web server on, for example: don't do it! If you really want to do it, however, you can: you just can't run the Pro script to do the job automatically. Instead, download it and open it in a text editor and follow the commands given for your distro except for the commands that download "mariadb" or "mariadb-server". You can then manually run the commands to create a database called giocoso3, grant all privileges on it to a user called giocoso3 and give that user a password of giocoso3.

However you decide to proceed, you cannot mix the products. If you want to run 'proper' MySQL client software, your Pro server needs to be running 'proper' MySQL Server; if you run MariaDB client, you need to be talking to a MariaDB Server. You cannot run a MariaDB client against a MySQL database, in other words (nor vice versa!).

[ User Manual Home ] | [ Build a Giocoso Pro Server ] | [ Giocoso Pro Menu ]