Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

atm backing up settings is an option on top of library backup, this means clients do not appear to take scheduled backups at all and that means that if something bad happens to the client settings, there is no way to recover

I think this behaviour is quite broken and should be changed so that servers and clients take backups on a schedule.

This would also remove the current confusing UI around backup/restore in a client (have to load a local library, restore then switch back).

[tzr916]

...This would also remove the current confusing UI around backup/restore in a client (have to load a local library, restore then switch back).

+1

[BryanC]

Thanks for the reminder to make backups on my clients!

[blgentry]

Are you saying that automatic backups don't happen on MC instances that are connected to a remote library?

I don't use MC that way so this is unexplored territory for me.

Brian.

[mattkhan]

Are you saying that automatic backups don't happen on MC instances that are connected to a remote library?

Correct

[dtc]

How about backups scheduled for a particular day and time?

[mattkhan]

How about backups scheduled for a particular day and time?

I don't see any backups at all

[dtc]

In Scheduler you can set a schedule for running backups. Does that work?


EDIT : Just tried it. Does not work.  In fact, File - Library has Backup greyed out. Looks like you cannot even do a manual backup of the client when it is connected to the server.  Given that the client is running off what is basically a copy of the server library that makes sense.

[tzr916]

If it's connected as a Client then no, MC scheduled task library backup does not work (task says "finished" but nothing in the folder). Neither does a windows task MCC command.

[Matt]

If you're connected to a library, there's really no library to backup.  The server should be doing the backups.

[marko]

If you're connected to a library, there's really no library to backup.  The server should be doing the backups.

Consequently, clients never have their settings backed up.

I had to add a single, solitary file to the HTPC main library, then remember to switch to it and make a backup here and there in order to have a settings backup.
Would be good if MC could take care of this for us

[Matt]

I could enable backup when connected to a library server.  But restoring the files without restoring the connection would be kind of broken.  Advice?

[mattkhan]

You need to backup and restore settings if you are a client. If you do this internally via some snall hack like an empty library that gets ignored then it's fine, just make it take backups

[Matt]

Enabling restore would be messy too since that would overwrite the connected library.

If it somehow understood that it was settings only it might be neat, but all the library backup logic doesn't know about that today.

So in the menu there would be "Back Up Library" and "Back Up Settings".  The scripted backup stuff would need to know which one to choose as well.

[mattkhan]

I really don't see why this is hard. It knows it's a client so if it's a client only restore the settings. Clearly it has settings and those settings are stored somewhere that is client specific so it must be able to back them up and restore them without impacting the server. I suppose it's some detail of how MC is implemented that makes it hard?

[BryanC]

I could enable backup when connected to a library server.  But restoring the files without restoring the connection would be kind of broken.  Advice?

Are you saying that it's not possible to just continue backing up the default library on a schedule (with or without local library files) while connected as a client (i.e. without the default library loaded)? Perhaps on a schedule, just prior to library client connection MC could switch to default library, backup files/settings, then switch to remote library?

Otherwise a "settings-only" default library backup in client mode would work, maybe add a switch to the backup and disable the library database restore option on library restore of such a backup, otherwise do as mattkhan suggests and just use an empty library. Something (saved settings) is better than nothing, and users with local libraries can always switch and do it manually for a full backup.

[mwillems]

Enabling restore would be messy too since that would overwrite the connected library.

If it somehow understood that it was settings only it might be neat, but all the library backup logic doesn't know about that today.

So in the menu there would be "Back Up Library" and "Back Up Settings".  The scripted backup stuff would need to know which one to choose as well.

When restoring a library backup there is an option to restore the library and playlists or just the settings or both.  Couldn't you effectively make backups work the same way?  Maybe that's naive and "assembly isn't the reverse of disassembly," but it seems like a distinction that already exists in some of the code paths right?

Are you saying that it's not possible to just continue backing up the default library on a schedule (with or without local library files) while connected as a client (i.e. without the default library loaded)? Perhaps on a schedule, just prior to library client connection MC could switch to default library, backup files/settings, then switch to remote library?

That's also not a bad idea; just take a quick backup on launch every so often.

[leezer3]

I really don't see why this is hard. It knows it's a client so if it's a client only restore the settings. Clearly it has settings and those settings are stored somewhere that is client specific so it must be able to back them up and restore them without impacting the server. I suppose it's some detail of how MC is implemented that makes it hard?

Part of the issue IMHO is that MC isn't a true client / server setup.

The client keeps a local copy of the library and gets / sends changes periodically, but internally basically acts just like an independent copy.

Would I suspect require some pretty serious logic changes.

[mattkhan]

it's already preserving its own settings independent of the library sync so it really can't be that hard to implement

[JimH]

it's already preserving its own settings independent of the library sync so it really can't be that hard to implement

Please don't tell us what's hard and what isn't.

Suppose your client is not always a client?  And sometimes it's a server instead of or in addition to being a client?

Sometimes changes look simple and end up having lots of twists and turns.

[JimH]

Part of the issue IMHO is that MC isn't a true client / server setup.

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.

[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]

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.

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

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.

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]

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

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]

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.

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.

[Matt]

One thing we could do would be to enable backup and restore on a library server client.

We would make the backups not contain the library files.  They would only contain settings.

We would make a library restore disable the choice to restore the library.  Only the choice to restore settings would be available.

We would make automatic backups work on connected clients, creating a backup of settings only.

Would this be a good change?

[JimH]

There's a problem I can see.  I use the same copy of MC in three modes at different times.

Stand-alone
Client
Server

We'd need to handle restoring each and we'd need to separate how they are stored (sub-directory for clients?)

Note that we're not committing to make a change yet.  Just discussing and thinking.

[DJLegba]

There's a problem I can see.  I use the same copy of MC in three modes at different times.

Stand-alone
Client
Server

We'd need to handle restoring each and we'd need to separate how they are stored (sub-directory for clients?)

Note that we're not committing to make a change yet.  Just discussing and thinking.

The user gets to decide which backup file to restore, so I don't think this will present a problem.

[JimH]

The user gets to decide which backup file to restore, so I don't think this will present a problem.

How will they know?  The types of backups need to be distinguished somehow. 

[dtc]

There's a problem I can see.  I use the same copy of MC in three modes at different times.

Stand-alone
Client
Server

We'd need to handle restoring each and we'd need to separate how they are stored (sub-directory for clients?)

Note that we're not committing to make a change yet.  Just discussing and thinking.

I may be missing something, but why are these separate backups? Is seems like a single backup of the standalone on disk library covers everything that is needed.

When running as a client I do not think you want to back up the server portion of what is temporarily on the client, since that may change on the server between the backup and the restore.  Once the restore is done on the client, it can simply reconnect to the server and be up to date.

When running as a server, does the system actually store anything specific to being a server other than what is stored in the main library?

I think what is needed is exactly the backup that you would get by disconnecting the client from the server and doing a backup of the standalone system. So, why not just backup appdata\roaming\J River\Media Center 31 or some subset of that?  Other things may be needed, but it seems those would be unique to the standalone system? I guess you might lose the current playing now and some other dynamic items, but I am not sure that is critical to the backup and may not be wanted if running as a client.

It seems like backing up the standalone system and then having the user reconnect to the server may be the right way to go.  For me, I would expect to have to do a reconnect after a restore, but I defer to those you run a lot of clients continuously.

Obviously, without knowing the full internal structure it is hard to know exactly what is required. Just thinking out loud.

[Awesome Donkey]

If this idea about client settings backups proceeds and you guys have to make changes how clients handle their settings (and their backups), maybe this idea could be revisited too since it's in the same area?

[DJLegba]

How will they know?  The types of backups need to be distinguished somehow.

Include the name of the active library in the backup file's name.

[mattkhan]

There's a problem I can see.  I use the same copy of MC in three modes at different times.

Stand-alone
Client
Server

We'd need to handle restoring each and we'd need to separate how they are stored (sub-directory for clients?)

Note that we're not committing to make a change yet.  Just discussing and thinking.

https://yabb.jriver.com/interact/index.php/topic,136541.msg946396.html#msg946396
It's what I was suggesting here, if there are materially different backups then you just need to filter them for the user

[markf2748]

Include the name of the active library in the backup file's name.

Agreed - that seems to be what happens now by default and is useful when choosing a restore point, particularly if you have multiple libraries.  But since user can alter the default backup filename (though I personally never reduce its information content), the active library source information needs to be encoded within the backup file itself as well to insure integrity (most likely that's also done today(?)).