This Database Management option is highly experimental and has not been exhaustively tested for total robustness! Be warned!!
The issue it's attempting to address is simply this: you install Giocoso on a PC which becomes your 'hardware music player'. Maybe it's one you tuck away in a discrete audio cabinet of some description in your 'listening room'. Then you want to go to bed and maybe listen to some music before you sleep on your laptop or tablet, via headphones. As things stood in Giocoso Version 2 days, you could certainly install Giocoso on that laptop; and that Giocoso installation would have a music database; and any plays you made in bed would thus be added to the laptop's database. The trouble, however, is that you also have a music database in your listening room which won't have recorded the laptop 'plays': and the laptop, obviously, won't know what you have been listening to in the listening room. Multiple installations of Giocoso, in short: fine. A single, 'primary' database of what you've listened to? Not happening.
Enter Giocoso Version 3 and this 'Pull remote database to be primary' menu option. The idea is that you install Giocoso on PC and laptop independently, as before. When you are in bed with the laptop, you can take Database Management menu Option 8 and pull the main PC's music database over to the laptop: plays made on the laptop now reside in that database. When you wake up and resume listening in the listening room, you first take Option 8 on that Giocoso installation, pointing at the laptop. The laptop's database is now pulled across the network to the main PC, which then becomes the 'primary database' once more. Listening room plays are now added to those made on the laptop. The next night, the cycle repeats: the laptop becomes the primary, its plays are added to those made in the music room; at morning the Listening room becomes primary yet again.
Specifically, the option does three things:
- Takes a backup of the local in-use database on whatever device is currently in use
- Prompts you for the remote PC's IP address or hostname
- Prompts you for the name of the database on the remote host you want to take over
- Uses the 'secure copy protocol' (SCP) to pull the remote host's copy of a music database across to the local device
The option does not prompt you for a username to connect to the remote host: it is assumed you are 'you' on all your devices. In my case, if I'm 'hjr' on the listening room PC, I'm going to have to be 'hjr' on the laptop, too. The remote hostname is either a name that is resolvable in your internal network (thanks to a local DNS server, for example); or it can be a raw IP address. It is assumed that all machines involved in this 'who wants to be primary' dance are running an ssh server: the menu option uses 'scp' to do the database copying, which requires this. It is further assumed that the ssh server running on all associated machines is running on the default port of 22. The menu option does not prompt for a non-default port at this stage. Finally, everything only works if you don't have firewalls screwing things up: port 22 needs to be opened internally to allow the appropriate network traffic between hosts (though if you're not running a firewall at all, you're braver than I am... but everything should at least work!)
Rather crucially, too: you have to remember that Giocoso stores the names of folders that contain playable FLACs in its RECORDINGS table. The data in that table on my main listening PC might say something like '/sourcedata/music/classical/B/Benjamin Britten/Ballet/Plymouth Town (Llewellyn - 2005)'. If that database is now copied across to my laptop, the laptop had better be able to find that exact folder or nothing will work. This is a rather Draconian requirement, but is not difficult to achieve: by definition, if you're interested in this menu option and its functionality, you are playing a source of music files that is networked. It is not difficult to ensure that the same network share is made available on two different machines in precisely the same way. In my case, my NAS shares are made available via NFS, so the export share is identical on both my machines, and can be mounted locally in precisely the same way, too.
The entire thing is simply an easy wrapper around a database copying capability: were you to play new music on the listening room PC after you'd copied its database to the laptop and played music on that device, you would now have two divergent copies of the music database ...and there's no way to reconcile them. If you subsequently pull the laptop's database back to the listening room PC, for example, you would simply lose the 'plays' recorded on the listening room PC after the laptop had been declared 'primary': pulling the laptop's copy of the database back to the listening room PC simply over-writes the listening room's copy of the database, obliterating its (unique) contents. So, you have to be very clear in your mind at all times: what device is now declared the 'primary'; only perform 'plays' on the primary database; do not play anything on a device that has ceded primary ownership of the database, unless you first take ownership of the database back. Frankly: if you're trying this on more than 2 or possibly 3 computing devices, good luck!
A consequence of the above thought is this: don't transfer a database that's in use to a new device. If my main PC is playing something, it would be silly to make my laptop the primary database owner: the main PC is going to want to record a 'play' in the database after it's been copied to the laptop: 'split brain syndrome' awaits!
So, let's do a worked example. My main hardware music player runs on a PC called 'sparky3'; I want my laptop (called 'tallis') to become 'primary database' for the evening. Assuming we've finished all plays in the main listening room for the evening and that database is therefore no longer needed for the day, here's what I have to do:
First, I note that I've just installed Giocoso on the laptop: I haven't even created a database yet. So the 'Aggregate Statistics' report shows that I'm configured to use a database called 'music' (because that's the default), but the report of that database produces errors: there is no table called 'recordings', which happens when a database doesn't actually exist at all. So: the laptop is a blank slate. I therefore now take the Database Management menu Option 8:
The program first prompts me to specify either the hostname or IP address of the remote PC (the one that's currently primary). Here, I'm able to type the host name because my local DNS server knows how to resolve that into a usable IP address. If I didn't have a home DNS server, I'd have to supply the IP address directly.
Next, Giocoso wants to know what database exists on the specified remote PC that you want to take control of:
There are no helpful hints here: you have to know the database name used on the other PC. The program is really only interested in the database name, not the file name. Thus, if my database is called 'main', it would be physically represented by a file called 'main.db'... but I should not specify the file extension here, because I am interested in the concept of a database, not physical files with file name extensions. However, if I typed 'main.db' without thinking, the program would ignore the file extension anyway, so it's not critical whether you mention the file extension or not, either way.
As soon as you press [Enter] to submit the database name, this might happen:
This sort of message appears if it's the first time you've ever connected from one PC to another via ssh. It prompts you as to whether you are sure you want to connect: the correct response is therefore to type the word 'yes' and press [Enter]. During future attempts to become the primary, this type of prompt will not appear, as the relevant server security 'fingerprint' will already exist. Once you've agreed to continue connecting, this happens:
You can see that after saying 'yes' to the first question, the remote hostname has been 'added to the list of known hosts' on my laptop (which is fine)... and then I'm prompted to supply my user's password on that remote PC. So, I supply that password when prompted and this then happens:
You can just about see on the bottom line of that display that a file called 'main.db' is being transferred across to my laptop. It only takes a second or two: mine is what I'd consider a large music database, but it's still only around 30MB in size and that should copy across the local network in less than a couple of seconds. Once it has come across, the laptop is in possession of the 'main' database, grabbed from off the usual music player PC, and can immediately start using it:
That's my laptop playing music from the 'main' database (as shown in the program header area). Note that I haven't re-configured my laptop's Persistent Configuration file to use 'main' as the default database: if I quit Giocoso and re-launch it, I'd revert to using the non-existent 'music' database (because that's what's still set in the Persistent Configuration file). I could use Database Management menu Option 4 to manually switch to using the 'main' database, though. Immediately after becoming 'primary', however, there's no need to even do that: the just-copied-across database is opened for use by default.
If I were now to re-run the Aggregate Statistics report on my laptop:
...you can see that I already have big numbers displayed for how many recordings are in my collection and the number of them I've already played: 14000 plays on a machine I've never run Giocoso on before is a pretty good indicator that this laptop is now accessing a database that has seen heavy use on another PC. Proof of that comes when I run the same aggregate statistics report back on Sparky3, the main music playing PC:
You'll note that the numbers are identical (although Sparky knows this database was refreshed, whereas the copy on Tallis has not been). At this point, therefore, the database on Sparky3 is identical to the one on the Tallis laptop... but the moment I let a new 'play' complete on one machine or another, that's when the two databases will begin to diverge. When I run Database Management menu Option 8 on Sparky in the morning, the database will be copied back from Tallis and the two databases will be synchronised once more. New plays on Sparky will thus be added to those previously made on Tallis. And so ad infinitum.
Bear in mind that every time a PC becomes 'primary', it's own copy of the database being pulled across from another PC will be over-written (and thus obliterated). This is not relevant the very first time Tallis becamse primary, of course, since no database called 'main' ever existed on it before. But each time after the first one that Tallis becomes primary, a fresh copy of 'main' will be pulled from Sparky -and the previous copy of the database will therefore be overwritten in its entirety. For this reason, Giocoso takes a backup copy of the database about to be over-written, if it exists:
Here, you see my $HOME/.local/share/giocoso3/db folder on a PC that has repeatedly been promoted to primary: a series of backups of the 'main' database have been made, a new one every time Database Management menu Option 8 has been taken. The backups are simply re-named copies of the original database with a yyyy-mm-dd-hh24-mi-ss timestamp added into their filename so that each one is kept distinct from the other. You may well want to manually tidy up (i.e., delete!) these backup copies if you continually pass a database between different music playing PCs, as they as they will begin to consume significant quantities of disk space over time.
As previously advised: be warned that this copying of databases between PCs is quite experimental and not particularly robust. It will check for connectivity to the specified remote host, for example, and display this error if it can't ping it:
It will also confirm if the specified database doesn't exist on the remote host and therefore can't be copied across:
...but it can only work out that the file copy has failed due to non-existence after it has already renamed an existing local database of that same name. That is, imagine Tallis has a local database called 'main' and I tell it to become primary by pointing it to a new PC called 'bach', mentioning database 'main'. Tallis' copy of main is renamed to become a backup (so it still exists, but can't be used again until its filename is manually corrected) and only then do we work out that Bach doesn't have a 'main' database to copy back in its place. Result: Tallis has nothing at all to play from at this point (though it's recoverable).
In short: tread carefully. The program will certainly try to let you know when things go wrong, but it's really down to you understanding your setup and ensuring you're trying to copy well-known databases between machines that know of and can readily connect to each other.