More > JRiver Media Center 31 for Windows
MC clients don't take backups on a schedule
JimH:
I do understand that.
mwillems:
So I'll make a pitch for why I think automated local backups of at least the settings are important. The client's local settings are all of the stuff that controls playback (i.e. the DSP, zones and zoneswitch, audio device settings, JRVR settings, etc.). Those (especially DSP) can get quite complicated and involve a lot of work to tune and get right. Years ago now, I was mostly using MC on a single PC, noticed the automated library backups and thought they were awesome. I promptly configured them to deposit backups on a separate drive for safety, and went about my business. When I shifted to a server client setup I didn't realize that clients don't also take any automated backups as long as they're clients. So I had a hard drive failure on a client machine where I'd done a lot of DSP work (over months) and discovered, to my dismay, that the backup I assumed was there wasn't. And I had to recapitulate all that work.
Now that I know about the issue it's easy to work around, but it seems like making no automatic client backups at all is a bit of a trap for the unwary. The simplest thing might be to do BryanC's suggestion: at startup periodically take a regular backup of the full local library before connecting to the server library. That wouldn't require distinguishing between settings and the database, etc. It's basically a programmatic version of how I work around the issue now: once in a while on clients, I switch them away from the server library to their local library, take a manual backup, and then immediately switch them back to the server's library.
mattkhan:
--- Quote from: JimH on July 20, 2023, 07:13:56 am ---Backing up just settings from any client of MC is probably not complicated. But now you have two types of backups. How do you distinguish them and present the distinction in the UI? When do you do that?
What do you do when MC is a client of multiple servers?
Or when it is sometimes a client, sometimes a server, and sometimes stand-alone? You'd need multiple types of backups. Do you make them automatically? Where do you put them?
And so on.
--- End quote ---
it sounds like you need to be able to
1) filter backups so that only the ones relevant to the current state of MC (i.e. which server it is connected to, if any) are accessible when you choose to restore (i.e. encode the servername somewhere in the backup)
2) remove the options of what to restore when you're a client so that it only restores settings
3) take backups on a schedule as a server does taking a backup of whatever state the client is in at the time the backup executes (so if it's connected to server XX at the time, it backs up those settings)
no doubt there are a number of corner cases not covered by this but the fact corner cases exist is not a reason to cover (what seems to be) the common case
--- Quote from: mwillems on July 20, 2023, 09:04:21 am ---Now that I know about the issue it's easy to work around, but it seems like making no automatic client backups at all is a bit of a trap for the unwary. The simplest thing might be to do BryanC's suggestion: at startup periodically take a regular backup of the full local library before connecting to the server library. That wouldn't require distinguishing between settings and the database, etc. It's basically a programmatic version of how I work around the issue now: once in a while on clients, I switch them away from the server library to their local library, take a manual backup, and then immediately switch them back to the server's library.
--- End quote ---
it's exactly what I do atm as well except that's not something I am ever likely to remember doing regularly, computers exist to do boring menial things for us after all :)
dtc:
--- Quote from: mattkhan on July 20, 2023, 09:28:55 am ---it sounds like you need to be able to
1) filter backups so that only the ones relevant to the current state of MC (i.e. which server it is connected to, if any) are accessible when you choose to restore (i.e. encode the servername somewhere in the backup)
2) remove the options of what to restore when you're a client so that it only restores settings
3) take backups on a schedule as a server does taking a backup of whatever state the client is in at the time the backup executes (so if it's connected to server XX at the time, it backs up those settings)
no doubt there are a number of corner cases not covered by this but the fact corner cases exist is not a reason to cover (what seems to be) the common case
it's exactly what I do atm as well except that's not something I am ever likely to remember doing regularly, computers exist to do boring menial things for us after all :)
--- End quote ---
As I understand it, the settings on the client that need to be preserved are stored in the normal stand alone library. (I may be wrong, but that is what I believe is happening.) So, all that is necessary is to back up the standalone library. No information about the server is necessary. While doing a restore, disconnecting and reconnecting to the server may be necessary, but the restore is a manual process anyway, so it seems reasonable to do that if necessary. With that, it seems like no special logic just for the settings is necessary, just a backup of the stand alone library. Again, I may be wrong on the internal structure, but I leave that to Matt et al.
mattkhan:
--- Quote from: dtc on July 20, 2023, 09:53:45 am ---As I understand it, the settings on the client that need to be preserved are stored in the normal stand alone library. (I may be wrong, but that is what I believe is happening.) So, all that is necessary is to back up the standalone library. No information about the server is necessary. While doing a restore, disconnecting and reconnecting to the server may be necessary, but the restore is a manual process anyway, so it seems reasonable to do that if necessary. With that, it seems like no special logic just for the settings is necessary, just a backup of the stand alone library. Again, I may be wrong on the internal structure, but I leave that to Matt et al.
--- End quote ---
I have no idea how it's implemented internally, I was just responding to Jim's reply which I took to be saying that there are a bunch of different places that settings are stored due to how MC is implemented hence some additional filtering to hide those details from the user is necessary to avoid breaking stuff. Regardless of how it's implemented, it's a gap that would be nice to fill.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version