BBritten.com - softwares:giocoso:promenu

clearpause

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T17:54:09+00:00

Clear all global pauses

1.0 Introduction

The last item on the Pro menu deletes the entire contents of the global_pausestatus table.

“Global Pauses” is the mechanism by which, when you pause music playback on Device A, a piece of data is written to the Pro database saying that, 'Device A is playing recording X and has reached Y seconds into it'. The idea is that Device B can then use the Play Music menu, Option 6 to pick up the playback at exactly the same point Device A had reached. If you start playing something in the kitchen, you can continue playing it to conclusion in the main listening room, or bedroom, or garden shed…

Normally, when the pausing device itself resumes a play, it takes care to delete the data about its pause out of the Pro database's global_pausestatus table. If Device A pauses, data is written; if it resumes, data is erased.

If your playing device crashed or was simply switched off, however, this bit of data tidy-up doesn't get a chance to happen -and that means a 'record of a pause' is left in the pausestatus table that really ought not to be there. When you take that Play menu option to resume a global play, for example, you might start seeing devices listed that claim to be in a state of paused play which you know aren't actually in a paused state at all.

If you see spurious devices listed, you could fix that by simply re-launching Giocoso on those devices: every time Giocoso is freshly started, it clears out all possible data about that specific device's paused state. By re-starting Giocoso on Device A, therefore, you cause all data about Device A being paused to be deleted: by definition, a program that has only just been freshly launched cannot be in a state of paused music playback, so this 'clean up on launching' process makes sense.

Sometimes, re-launching Giocoso to clear its paused status is more of a pain than you'd like, however. For example, I sometimes power off virtual machines that were running Giocoso in a paused state and it's quite a bit of faffing around to re-launch the entire virtual machine before finally being able to re-launch Giocoso. In that case, the Pro menu offers Option A: Clear all global pauses which will wipe the entire global_pausestatus table, regardless of what devices are listed there. All of them go, in one fell swoop, regardless of the device(s) involved.

This doesn't mean all your paused devices suddenly spring back to life playing music at once! It's not the fact of them being paused that's being erased, but the record of them being paused that's being deleted. The devices stay in whatever state they're in, but the Pro database no longer knows that they're paused or unpaused. Option A simply 'pops the stack', therefore, ensuring that the pausestatus table is emptied and can start over, from a clean slate.

The menu option returns practically instantaneously, with just this confirmation message:

Note that there's no 'are you sure' prompt: the table is simply wiped the moment you take the A menu option. That's largely because wiping the pause table doesn't really harm anything: if you wanted to re-populate the table with the fact that, say, Device C is actually paused at the moment, you could simply resume playback on Device C for just a moment… and then immediately put it back into a paused state. That will add Device C back to the pausestatus table once more. Until you do that, of course, no other Giocoso client device could ever resume Device C's play.

In Summary

This is not an option you'll need to use very often (unless you're the kind of person that frequently switches off PCs in mid-paused-play!), but it's there if the Play Menu Option 6 starts listing paused devices that you don't think should be listed and it's a bit awkward to re-launch Giocoso on such devices.

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |

clearrec

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T13:27:00+00:00

Clear The Remote Recordings Table

1.0 Introduction

When you take the Pro menu, Option 1 to initialise a Pro database, you trigger the complete wiping of the Pro database's recordings and plays table (and their re-population with data derived from the equivalent local tables). Every time you subsequently play a piece of music on a local device, that new play is 'pushed' or copied to the Pro database. Similarly, every time you use the Database Management menu, Options 2 or 3 to refresh the local database with details of new recordings found, the Pro database equivalent global_recordings table has anything newly-discovered on the local device copied to it. It is not perhaps obvious, therefore, why you might ever need to wipe the remote recordings table and populate it from scratch: if the local database refreshes are picking up new additions to your collection and copying that data over to the Pro database, why would you nuke the Pro database's table completely?

Well, it comes down to the precautionary principle: since you might ever need the facility, it's made available to you… but it's hopefully there, never to be used!

The reason why it's conceivable you would want to use it comes down to understanding how the Pro database's definition of 'new recording' differs from the local database's definition: something I've documented at length elsewhere: see Section 7 of the Pro Concepts documentation.

If you physically relocate a recording of someone's Sinfonietta from /orchestral to /symphonic, for example: the local database will see the change, remove the /orchestral item from its database and add the /symphonic version to its database. It will then push that new record to the Pro database …but the 'push' only copies new data across to the Pro database: it doesn't trigger the removal of the old /orchestral item from the Pro database. Therefore, Pro clients will potentially be told they can play a recording that physically no longer exists on disk.

The opposite situation also causes problems. Let's say you don't physically move a FLAC in any way, but you correct the spelling of the COMPOSER tag from “Bartok” to “Bartók”. That change in metadata is not something the local database will notice and will therefore not push to the Pro database. However, the metadata change would be something that would define a new recording in the Pro database and therefore the recording really ought to be re-pushed to the Pro database so that the metadata alterations are picked up by it.

Basically: if you are doing a lot of additions, deletions and metadata curation to your music collection, the local database of recordings and the Pro copy of it can get confused as to what actually exists, what no longer exists and what the things that are claimed to exist should be catalogued as! From time to time, in that scenario, a wipe-and-start-again approach might therefore be considered appropriate: and that's why the option to nuke the remote recordings table is provided.

Be warned that the option is destructive, in that it literally zaps the entire Pro recordings table -and, given that the Pro database is shared amongst all Giocoso clients, that means no client will be able to play any further music at all until the re-population of the recordings table completes (see the Pro menu, Option 4). However, it's a safe option to perform in the sense that the recordings on disk still exist and can thus be re-discovered and re-catalogued if necessary. It's also completely safe in that wiping the Pro database's copy of the recordings table doesn't do anything to the local copy of the same thing. Re-creating the Pro version of the table is thus trivially easy to do. Nevertheless, the wipe function does mean all music playback must stop until the re-push option is taken, so this is something you would only really want to do 'out of hours'.

2.0 The Clear Recordings Process

There's not a lot to document here! If you tap '3' when viewing the Pro menu, this immediately happens:

And that's the job done and dusted! It takes no time at all to complete and there are no 'are you sure? are you really, really sure?' warnings (on the grounds that re-populating the table is trivially easy to do, though it might take some time).

3.0 Next Steps

Having wiped the global_recordings table, it ought to be re-populated. That's done in two ways:

At the next local database fast or full refresh, if the client is declared in the Configuration options to be a primary device, the entire local recordings table is copied to the remote, Pro equivalent; or
Any client device, primary or otherwise, can manually take the Pro menu, Option 4: Push recordings to remote database and thereby have the entire local recordings table copied to the remote Pro equivalent on demand

Until such time as the global_plays table has data re-inserted into it, no Pro clients will be able to play music, unless they re-configure themselves to not being a Pro client (by using the Administration menu, Option 2 and wiping out the Remote MySQL Server IP Address entry, setting it to blank).

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |

devicerpt

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T15:27:09+00:00

Analyse Plays By Device & OS

1.0 Introduction

The main Reports menu is where you do most of the reporting on your plays and recordings -and remains so, even when Giocoso is operating in Pro mode. However, the specific feature that Pro mode enables is for multiple devices, perhaps running multiple operating systems, to play the same music collection… and it may be of interest to you to know how many plays are being done by different devices and operatings systems.

The Pro menu, Option 7 allows you to produce a simple report from the Pro device that groups plays by device, and then by operating system, and presents the results in a single report, like so:

The report is actually output to the text file shown at the bottom of the screen: $HOME/.local/share/giocoso3/tmp/proqueries.txt. You could visit that location with your standard file manager and open the report in any text editor of your choosing. For convenience, Giocoso displays the file by piping it through the less program, so you just tap 'q' to quit when you've read enough and you'll be returned to the Pro menu once more.

The “Device” columns displays the configured hostnames on each of your Giocoso clients: mine tend to be the names of assorted composers, but don't let that fool you into thinking I've played 302.6 days of Robert Schumann's music! Definitely not!! I've merely played 302.6 days of music on a machine that's called Schumann

The “Operating System” column displays the results of poking around inside the “/etc/os-release” file and grabbing whatever value is assigned there to the NAME parameter.

All the other columns are mere mathematical computations applied to various summarisations of the global_plays table, rounded where appropriate.

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |

proinitdb

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T11:20:16+00:00

Initialise A Remote Database

1.0 Introduction

Initialising a remote database doesn't mean creating it or building the server it's running on: that's something you have to do as a separate exercise and for which I've provided documentation elsewhere!

When the Pro menu talks about initialising the remote database, therefore, it means:

Checking the local RECORDINGS and PLAYS table, to ensure that no existing data breaches the data lengths allowed in the remote database
Wipe any and all data in the remote GLOBAL_RECORDINGS and GLOBAL_PLAYS table
Connecting to the remote database
Coping the entire contents of its local PLAYS table contents to the remote database
Copying the entire contents of its local RECORDINGS table contents to the remote database
Creating a bunch of views (essentially, stored select statements) in the remote database, thereby enabling full Pro client functionality

Initialisation is therefore destructive (in that if the remote database already has some recording or play data, it's just wiped) and therefore really only ever ought to be performed once, preferably by the client device that you've declared to be 'a primary client' (in the Administration menu, Option 2).

On the other hand, it's a process that can be run as many times as you like: it's the remote database that gets destroyed and re-created, after all. The local PLAYS and RECORDINGS tables stay completely intact, with none of their data altered or deleted in any way. A second run of the initialisation process therefore merely re-creates and re-populates the remote database tables, no harm really done. On the other, other hand: bear in mind that a working remote database may have plays data that comes from multiple devices. Running the initialisation process means the global_plays table will only have play data that comes from the client device doing the initialising.

But on the (I've lost count…) other, other, completely different hand: other client devices still have their play data intact and can therefore use the Pro menu, Option 2 to re-push their play history data to the re-initialised remote database… so, again, in the long run, initialising a database doesn't actually destroy anything irretrievably. It's still not something you want to do very often, however!

If you don't do it at least once, however, then nothing about Giocoso Pro works as intended. So, the moment you configure a remote MySQL database IP address in your Administration menu on your primary device, Option 2, the first thing you should do is run the Pro menu, Option 1. If you try to play music on a primary client without having first initialised the Pro database, for example, you'd see this error message:

Similarly, trying to run the Aggregate Statistics report (Reports menu, Option 1) would simply return these messy-looking results:

These are all symptoms of needing to initialise the remote Pro database!

2.0 Running the Initialisation Process

When you first take the Initialisation 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 initialisation 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:

The initialisation process, as I mentioned in the introduction, is destructive to data in the Pro database -so, the initialisation wizard is very careful to prompt multiple times, letting you back out before anything actually happens in the Pro database itself. So, you're again asked at this point whether you are certain you want to proceed. Click [Enter] with the 'Yes' option highlighted to go ahead:

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, it's the local PLAYS table data that will be copied or 'pushed' to the remote Pro database:

Finally, data actually 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. You are past the point of return now: any existing data has been wiped from the remote database and the new data is being copied across. You can interrupt the process (press Ctrl+C), but you'll then simply have to re-run the initialisation process… and start over again from zero as you do so. It's thus better to just let the process tick along at its own pace until it completes. Just one word on terminology, in case there's any doubt: “pushing” or “transferring” data simply means the local data is copied across to the remote database: it does not mean that the local database ever once 'loses' its data. That's how it's possible to re-run the initialisation process, after all: it creates copies of data in one database, but the source doesn't disappear out of the local database, so it's still there should a re-run ever be thought necessary!

Incidentally, the transfer process is quite slow because actual computation 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.

Once the local PLAYS table has had its data copied to the Pro database, this happens:

This is just information to let you know the next stage of initialisation is about to happen: there's no 'yes/no' option here and therefore no chance to back out, so just press [Enter] to continue: at this point, the local recordings table will get copied across to the global_recordings equivalent in the Pro database:

A progress bar is once more displayed, along with more specific numbers showing you precisely how many of the local recordings have been copied across. Again, the process takes time because each recording's COMPOSER and COMPOSITION tags are being smooshed together and passed through a hash function to generate a unique identifier called the RECHASHVALUE.

Once the transfer of recordings is complete, this message will appear:

Press [Enter] to dismiss the confirmation message and you'll be returned to the Pro menu. Immediately, at this point, you could run the Reports, Aggregate Statistics option and see something like this:

Instead of the ugly messages you saw before, now you've got real numbers to play with -and you know these numbers are coming from the Pro database, rather than the local one, because of the message about “GLOBAL Aggregate Statistics Report” in the top right-hand corner of the screen (and the fact that the table borders consist of dashes and plus signs!)

You can also go to the Play Music menu, take Option 1 and have this happen:

That's music playing locally, because the global Pro database told the local machine what to play next: basically, once the global database has been initiated, it acts as both 'source of information about what recordings to play' and 'repository of data about what recordings have been played'.

3.0 Summary

Initialisation of a Pro database is a once-off affair, performed by the client Giocoso device that has been declared to be 'primary' in the Administration menu, Option 2: Create or Edit the Configuration file. It involves creating various tables and views in the Pro database, then copying across data from the local recordings and plays tables to become the contents of the global_recordings and global_plays tables. Once you've initialised the Pro database, it can be used by all Giocoso client devices to know what can be played and what has been played.

The initialisation process can be interrupted once started, but then needs to be re-started from scratch and allowed to run to completion.

Should another client device ever take the initialisation option, it will erase the existing Pro database's global_plays and global_recordings tables and replace them with data from its own local equivalent tables. In theory, that makes no difference for the recordings/global_recordings tables, because all client devices are assumed to be able to 'see' the one music collection, so one device's recordings table should be identical to any and all others'. Plays are different however, being unique to the device that played them. The re-populated global_plays table will only contain the initialising devices plays: to have the plays made by other devices added to that, you'll need to use the Pro menu, Option 2 : Push plays to remote database option, which is described separately.

Initialisation is not hard to do and doesn't destroy any local data, but it takes time to complete because each recording and each play has to have unique identifiers (rechashvalue and playhashvalue, respectively) computed before transmission to the Pro database can take place.

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |

pushplays

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T13:14:29+00:00

Push Plays To 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 'push plays' 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 <em>local</em> 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:

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!

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |

pushrecs

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T14:39:10+00:00

Push Recordings To A Remote Database

1.0 Introduction

The option to push (i.e., 'copy') a local plays table to the remote, Pro database equivalent is one that can be used by any Giocoso client device: it should be remembered that a client device that has been declared (in the Administration menu, Option 2) to be a 'primary device' already pushes its copy of the recordings table to the Pro database any and every time it performs either a fast or a full refresh (see Database Manager menu, Options 2 or 3). Precisely because the primary device re-populates the global database automatically on a refresh, the need for a non-primary device to refresh the global database's recordings table is pretty thin: this is not an option you're likely to need to use very often, in other words.

Reasons for having it as an available option at all are simply ones of convenience: if you are working on your laptop, away from your main, primary PC; and you've refreshed the laptop's local database in order to pick up the new 4-CD boxed set you just added to your music collection; then you might find pushing the laptop's up-to-date recordings table to the shared database more convenient to do right now than wait for the main PC's nightly database refresh to do the job.

All of this assumes, of course, that both the laptop and the main PC 'see' the same physical music collection on a shared networking device, which is indeed an assumption underpinning the entire raison d'être of Giocoso Pro. In that scenario, it matters not whether the Pro database gets its recordings data from the laptop or the main PC, since they are identical in content. The only functional difference between the two devices, then, is that one is declared a 'primary device' and thus automatically updates the Pro database when it performs a local refresh …and the other doesn't do the automatic refresh but has the ability to use this 'Push recordings' option to do the job manually.

Pushes of data made with the Pro menu, Option 4 do not delete data out of the existing global_recordings table. The option adds data that may be present on the local device, but it does not clear out anything already present in the shared database (compare this, for example, with the Initialisation that takes place with Pro menu, Option 1, which literally zaps the shared recordings table clean before doing anything else).

2.0 Running the Push Recordings Process

The first thing that happens when you take Option 4 is that Giocoso will examine the contents of your local recordings table and make sure that no data contained within it breaks the size limits imposed by the remote, shared equivalent table. 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:

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 RECORDINGS table data will start to be be copied or 'pushed' to the remote Pro database:

Finally, data starts to be copied from the local device to the remote server: you're told how many recordings 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.

As I mentioned in the introduction, the push recordings process doesn't start its work by wiping any existing content in the global_recordings 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 Recording 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 data transfer process is actually quite slow, even if no new data ends up being added to the Pro database, because computation of whether a pushed recording is a duplicate or not is taking place. For every item in the local RECORDINGS table, the program is taking the COMPOSER and COMPOSITION tags, smashing them together, resulting in something like 'BRITTENPETERGRIMES(PEARS-1958)', 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 recording, called the RECHASHVALUE. It's this which the Pro database uses to determine 'uniqueness of recordings' and which thus allows it to draw the distinction between 'new recording I need to add' and 'old recording 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 recording than to ignore the resubmission of a previously-submitted recording …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 16,000 recordings 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 recording push, the process will immediately terminate. No particular harm is thereby done: if you re-launch Giocoso and take Option 4 once again, the push process starts over from the beginning and, if left to run to completion, those recordings 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 recording 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 recordings to a Pro database as a manual exercise is not something you'll want or need to do very often, because a client designated (in the configuration options) to be a primary device will push its recordings to the Pro database automatically after ever fast or full local database refresh anyway. However, the option to 're-push' or to push recordings manually is provided for those occasions when you need to inform the Pro database about some new additions to the music collection that have been made on a non-primary device.

The process is non-destructive, in that the Pro database's existing recordings are not wiped or replaced, but data that looks new to the Pro database is merely added to what is already there.

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |

togglemode

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T17:49:21+00:00

Switch Reports To Local/Global Mode

1.0 Introduction

When you first put Giocoso into Pro mode (by filling in a MySQL remote database's IP address, using the Administration menu, Option 2), all reporting functions immediately switch by default into selecting from the shared, remote Pro database, rather than from the local database found on a specific Giocoso client device's proximate hard disk. For example, here is what a local report of the 'Aggregate Statistics' looks like (i.e., taking the Reports menu, Option 1 in non-Pro mode):

And here's the same menu options taken, and the same report produced, but this time operating in Pro mode:

The two reports look very different, because the Pro version is coming from a remote MySQL database, which insists on putting dashes and plus signs around its output for tabular reporting purposes. If you look closely, however, it's not just the look-and-feel that's different. Notice how the local database thinks 2.47% of recordings remain as-yet unplayed, but the global database thinks it's only 2.44% that's unplayed. The difference is, of course, that some recordings were played on devices other than the one producing the local report: in local mode, my main playing PC is unaware of these “other-devices” plays… but in Pro mode, the shared database is fully aware of them.

The point is, therefore, that knowing what a specific device has played is of interest (even in Pro mode), but knowing what all devices have been up to is also of interest -and, thus, that there is a point in being able to report from either the local or global databases, at will. Switching back and forth between these two modes of reporting is precisely what the Pro menu, Option 9 : Switch reports to xxxx mode allows you to do. The “xxxx” bit of the option text will vary, in a reverse-toggle sort of way: if you are reporting in local mode, the text will say 'switch reports to global mode'. If you are already in global reporting mode, the text will say 'switch reports to local mode'.

As you can see from the above screenshots, you'll know what reporting mode you're in by looking toward the top of the screen on most reporting screens: the report display will say “GLOBAL…” or “LOCAL…” very clearly. Some do not do this, for quaint technical reasons that needn't detain us: however, the Reporting menu itself tells you what reporting mode you're in before you run any particular report:

As a rough-and-ready guide, however, if your report opens in a web browser or contains lots of dashes and plus signs: it's a global report. If it opens in terminal windows with nice line-draw characters defining the columns and headers, you're running a local report.

Every time you take the Pro menu, Option 9, you'll switch to the alternate reporting mode and be immediately transported to the Reporting menu: the program assumes that if you're changing the reporting mode, you probably want to run a report!

To be completely unambiguous about it: reporting in local mode does NOT mean you've stopped operating Giocoso in Pro mode. It just means that, for reporting purposes only, you've chosen to use data from your local database, rather than the shared, Pro one. You can switch back and forth between local and global reporting modes at will, as often as you like, by taking the Pro menu, Option 9, which toggles between the two reporting modes as often as you like.

On the other hand, if you clear out the 'Remote MySQL Server IP Address' entry in your configuration options (Administration menu, Option 2), you're completely switching off Pro mode, so reports automatically switch back to local mode and cannot then be run in global mode until you once again enter an IP address for a remote Pro database server. This is 'toggle-able', in other words, but a much less convenient way of doing things than using the Pro menu, Option 9!

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |

viewnote

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T17:41:08+00:00

View A Global Note

1.0 Introduction

Global notes can be made whenever a recording is being played, just by tapping 'n' (or 'N': the case doesn't matter). The nano text editor opens and you can just start typing any observations or criticism of the recording that comes to mind. For example:

Each note you create in this matter over-writes any earlier note you may have made on the same client device …but, crucially, it's stored in the Pro database, in a table called global_notes, as it is saved. The one local file (note.txt, stored in $HOME/.local/share/giocoso3/tmp) therefore keeps getting over-written by each new note; but each note is also stored permanently in the Pro database, uniquely and permanently 'attached' to the rechashvalue that determines the uniqueness of a recording:

That's me viewing the global_notes table in the DBeaver MySQL database browser tool. If you squint hard enough, you'll see the 'O mio babino caro starts at 2:11:00ish' comment that you saw me writing in the nano editor in the earlier screenshot: proof that local file content is transferred to the global, shared database!

A view in the Pro database called “notes” makes accessing the underlying global_notes table slightly easier: though the names of the various composers associated with these notes is definitely visible in the above screenshot, it's not terribly easy to sort by their names, because they're 'embedded' within the 'notes' column. The view fixes this:

It's very much the same information as before, but rather than an impenetrable 'rechashvalue' to identify a recording, the view has split out the composer and composition into nicely-accessible (and separate!) columns. It is this view which the Pro menu, Option 8 uses to produce its output.

Making notes is thus simply done whenever a recording is playing. Viewing the notes after they've been made is only possible using this 'View a global note' option of the Pro menu and it's done by selecting a composer first, then a specific recording second. When you first take the option to view a global note, therefore, you'll see this:

This is a tabulated version of the 'Composer' column in that Notes view I showed you earlier: each composer for whom a global note has ever been created is listed precisely once. Your job is to up- and down-arrow until your choice of composer is selected, then press the [SpaceBar] to put an asterisk in the brackets next to the name. If you selected the wrong composer by accident, arrow up and down again until you land on the right one: another hit of the [SpaceBar] will move the asterisk to the newly-selected composer. You'll note you can only pick one composer at a time!

Once the right composer is selected, press [Enter] whilst the [OK] button is highlighted: if you merely want to back out without doing anything, tab round until the [Cancel] button is highlighted and then press [Enter]. Assuming you've selected [OK] though, pressing [Enter] makes this happen:

This screen lists all the recordings attributed to the previously-selected composer for which global notes exist. In this specific example, Puccini only has one recording with notes, so only one item is listed. But if I'd notated a dozen of his opera recordings, all dozen of them would be listed here. Again, your job is to hit the up and down cursor keys until the right recording is highlighted. When it is, hit the [SpaceBar] to put an asterisk next to it… then click [OK] or press [Enter] whilst the [OK] option is highlighted. Once again, you can tab to the [Cancel] button and press [Enter] to back out without displaying anything at all, if you prefer.

Once you've selected a specific recording and pressed [Enter] on the [OK] option, however, this happens:

Now the note you created in nano is displayed to you. It's read-only, so strictly no editing! It's also word-wrapped (at 90 characters per line), so that may result in slightly awkward line breaks: you can see some of them in this screenshot, for example… though it's not entirely clear to me why there's a line break after the words “I treasure”, as there's plenty of space on that line for what follows! The point is that the display of the text is an approximation at best and certainly not perfect!

You can scroll up and down (using up and down arrows or page up and down keys) to your heart's content. Any other keypress, however, triggers the 'Exit' option (which also has its own dedicated button, so pressing [Enter] will trigger it, too), returning you to the Pro menu once more.

It is definitely not pretty, therefore! But, thanks to the Pro shared database, it is a mechanism that allows you to make notes about recordings on any device and to then read them on any device thereafter. The notes certainly don't have to be long essays, such as Ian Lace's review of Pappano's recording of Il Trittico (on Classical CD Reviews), which I pasted in for the purposes of this documentation: pointing out where the big arias start and stop is usually the limit of my note-taking… but I know plenty of listeners who are much more engaged in this sort of thing than I am, so I hope this basic functionality meets their needs to some extent, at least.

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |

xtrctplay

Anonymous (anonymous@undisclosed.example.com) — 2025-12-10T14:59:17+00:00

Extract Remote Plays Or Recordings To CSV

1.0 Introduction

It's all very well having a remote, shared, Pro database of recordings and plays …but how can you see that data and make sure it's what you think it should be? To be honest, the best way of viewing data in a MySQL database is to install a GUI client and start browsing through the database structures and data in a nice, point-and-click manner: my own recommendation is to use the DBeaver tool for this purpose:

Some people might find using a tool like this a bit daunting, however, and therefore Giocoso allows the remote recordings and plays data to be extracted to a local “CSV” file. The abbreviation 'CSV' means 'comma separated variable', where each piece of distinct data is separated from the next by a comma. However, classical music has names such as “Serenade for tenor, horn and strings” to deal with… and the extra comma in that name could cause trouble! Therefore, Giocoso actually uses the pipe character (i.e., | ) to separate the various bits of data: so you'll end up with something more like “Benjamin Britten|Serenade for tenor, horn and strings|Peter Pears” and so on. Regardless of what the data delimiter actually is, however, you can simply import a “CSV” file into a spreadsheet tool like Excel or LibreOffice Calc and have the data presented to you in easily-readable format, without the need to install specialist database management tools first.

The Pro menu, Option 5 extracts the remote PLAYS table data to a local text file; Option 6 does the same thing for the remote RECORDINGS table. Both options write their output into the $HOME/.local/share/giocoso3/txt folder, over-writing any previous data extraction when it does so, without prompting. Note that the term 'extracting' does not imply that any data is actually removed from the Pro database: it definitely isn't, and the Pro database remains fully populated and functional no matter how many times you take these options. “Extracting” in this context simply means “making a copy of”, in a totally non-destructive manner.

2.0 The Data Extraction Process

Whether you're using the Pro menu Option 5 (extract the plays) or Option 6 (extract the recordings instead), the program immediately responds like this:

That is to say, the relevant remote data (recordings in the case of the above screenshot, but it looks and works almost identically for plays) is immediately written out to a local file and the full path to and name of that file is shown to you in the resulting confirmation message: it takes less than a second to extract around 20,000 records on my not-fast system, so it's practically instantaneous.

Click [OK] to dismiss the message (making a note of the path and filename first, of course!) and you'll return to the Pro menu display.

3.0 Using the Data Extractions

The new file(s) can be found using your system's standard file manager:

You could inspect the contents of either file by opening them in, say, your system's default text editor. In my case, I can right-click one of the files and open it in, for example, the kwrite text editor:

You'll note that the lines of data are very long -but you should be able to make out the pipe delimiters separating the different bits of information about each play or recording. In this state, you could certainly search for particular strings of data, but it's obviously not terribly useful to see the data this way.

So, instead, if I launch my computer's spreadsheet program (which happens to be LibreOffice Calc, but could just as well be Excel or something similar), take the File → Open options and point it at one of the data extraction files, I see this:

The program knows that this text file isn't a native spreadsheet, so proposes a way of interpreting the data so it can be imported into a normal spreadsheet. The crucial bit to set correctly here is the 'Separator options' one: that's where you specify what the delimiter is between the different columns of data within the extract. Various 'normal' delimiters are offered, such as tab, comma, semi-colon and so on, but none of these are correct for what Giocoso has just produced! Instead, you see me putting a tick next to the 'Other' option and then, in the box provided next to that, I've typed the pipe character |. Toward the bottom of the screen, you can see that the spreadsheet program is immediately parsing the text file with this pipe delimiter in mind …and looks to be making a pretty good job of distinguishing (in this example) the rechashvalue from the filesuffix column, so the pipe delimiter definitely looks like the correct thing to use. Click [OK] to confirm that:

The data is then imported in a much more usable form than before: you may well have to fiddle with column widths and row heights and all the other formatting paraphernalia that modern spreadsheet programs provide, but at least the data is intelligible! By default, the data is extracted in composer-name order, but you can use the spreadsheet's options for sorting data to achieve a sort on any of the columns you like.

4.0 Summary

It's not suggested that there's a pressing need to extract the Pro database's recordings and plays tables to local text files, nor that you will want to do this very often. Indeed, if you did ever feel the need to inspect your Pro database's data often, I would encourage you to invest that time and effort (but no money, happily!) in learning a tool like DBeaver, which makes the live version of your Pro data immediately available.

For those who only have an occasional need to inspect their Pro data, however, or who don't need or want to master a 'proper' database management or query tool, Giocoso's data extraction options are provided to make occasional, one-off, data extractions as painless as possible. The extraction process itself is unsubtle, asks no questions and is completed in mere seconds (if that). Actually using the data thus extracted probably takes longer to do than the data extraction itself! Even so, it is generally a matter of a few tweaks of import options for pretty standard spreadsheet programs.

| Back to Software Home | Back to Giocoso Documentation Home | Back to Pro Menu |