More > JRiver Media Center 31 for Windows

MC clients don't take backups on a schedule

<< < (5/8) > >>

JimH:

--- Quote from: leezer3 on July 20, 2023, 05:16:50 am ---Part of the issue IMHO is that MC isn't a true client / server setup.

--- End quote ---
That's sometimes said (and repeated), but software that accesses data from a server is a client.  That it does so all at once in a single chunk is different from other client strategies, is true.  But, in this case, it does so for performance reasons.

dtc:
I think the idea is to back up the stand alone library that permanently resides on the system. Why? Because that library also contains some settings that are used when it is acting as a client.

The idea is that if the system fails for any reason, there is a way to restore the on-disk library that the system would run when it is running stand alone. If that backup is restored the system returns to its original stand alone state and the system can then become a client again with the same attributes it had before the restore.

I guess one issue is whether when doing a backup is the backup simply the on disk stand alone library or does it somehow incorporate information that is in the memory of the running version. If it just is a copy of the main standalone on disk library, then it seems like that could be copied to a backup, independent of whether the system is running as a client or standalone or as a server at the time.  When running as a client, does the system have the knowledge of where the systems permanent library is? Since it is storing some settings there, I guess it does. The question then becomes can it copy that library to a backup file.

Obviously, only Matt et al know exactly what data and library files are available when running as a client and what is available standalone and how much those are mixed when running as a client. And, it is certainly more complicated than doing a standalone backup. But, if the backup simply copies the stand alone library, it might be doable.

JimH:
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.

Are you not able to make a backup manually?

dtc:
I think the distinction is whether the client permanently stores data on itself or not.  In the case of MC some of the settings are actually stored on the local system and used in client mode, which is what makes the backup of the local system necessary.

It is somewhat analogous to the way cookies are used for browsers. If you want the state restored completely, you need to back up the cookies. If not, some of the information is lost. For MC if the local settings ("cookies") are not restored then the client system cannot be directly restored to its previous state.  The settings have to be redone.

dtc:
Jim - I think the idea is to simply backup the standalone library, which happens to have settings which are used whenever the system is used as a client whenever that system is connected to any server. The idea is not to somehow backup unique characteristics for each server that the client connects to or to backup a unique library for when it is acting as a client versus when it is standalone. The thinking is that everything that is needed to restore the system is included in the standalone library. Anything unique to the server it connects to will be copied from the server when it reconnects to that server. The idea is to backup/restore the settings that are stored in the stand alone library.

Navigation

[0] Message Index

[#] Next page

[*] Previous page