Topic: Conundrum...sync changes with server, stop deletions, but keep clients sync'd. (Read 9601 times)

HTPC4ME · « **on:** January 25, 2015, 08:24:38 pm »

Well after posting a suggestion in the Too Easy thread, and noticing what i just noticed below, I thought i would start a new thread so as not to fill up the too easy thread.

I took Jrivers advice to avoid our whole library from accidentally being deleted. Now after turning off authentication for Server, i'm noticing on all clients that none of them are auto updating the library... meaning ive imported many files into server since turning this off but those files are not showing up on clients connected to the Server library.

Our conundrum... I'm not asking for miracles here, just what is a possible solution for those of us that are already customers, and those new potential customers in this situation.

1. How does one share their library with clients feeling ease of mind that files won't be deleted, But yet not have to shutdown/Reload ALL clients to update the clients to be current with the server?

Here's info of what has been discussed so far.
Thank You.

HTPC4ME · « **Reply #1 on:** January 25, 2015, 09:33:50 pm »

after questioning myself about writing this whole thread I've went to wiki, and forum. and im not finding info on what this does. (Auto sync with Server)
I am noticing Auto Sync with Server under Client Options on Server Library is unticked... Please tell me im not being an idiot, and this needs to be ticked?

I decided to tick it for testing and waited about 15 minutes but none of the clients have the new files i imported today.

I have noticed on clients if i leave theaterview... Esc\Exit Theaterview\File\Library then click on the Main Server, (5 Steps) it will reload/scan the server and the clients will be updated.

Perhaps an "Add Item" could be incorporated on the home screen of theaterview next to exit that states reload/Refresh library... one could click this and it would do those steps that are done in standard view with one click?

For standard view maybe under tree and view\customize toolbars there could be a Reload/Refresh current library icon we could place on toolbar that does the same?

CountryBumkin · « **Reply #2 on:** January 27, 2015, 07:20:26 am »

It is my understanding that box on the Client to "sync changes to Server" is what allows tagging (such as adding/changing a rating) on the Client with those changes then being made/saved on the Server. It also allows the deletion of a file on the Server from the Client (such as removing a watched TV episode, etc.).

I assumed that if you don't check this box on the Client you would not be able to make changes on the Server, but I have not tested with it "not checked".

Did you find that you were able to delete files and/or make changes on the Server from the Client with the "Sync changes" box unchecked on the Client?

This link is on Automatic Sync: http://wiki.jriver.com/index.php/Library_Server_Sync

rossp · « **Reply #3 on:** January 27, 2015, 08:03:51 am »

I use this feature a lot but it would be nice if you could turn off the file deletion aspect of it on the server side.
I could then open up my library to my Father over the internet. Currently I can't because of the opportunity for him to delete my content.

Ross

CountryBumkin · « **Reply #4 on:** January 27, 2015, 11:58:32 am »

It would be desirable if the "Users" account setup could also restrict Users from deleting files. I thought I read in post that one could setup a User account (like "Kids" account) and prevent that account/User from deleting files, but I don't see that function mentioned in the Wiki http://wiki.jriver.com/index.php/Users and I can't find the post now.

SO if User Accounts don't currently have that ability - it would be great if the developers could add it at some point.

HTPC4ME · « **Reply #5 on:** January 27, 2015, 12:14:19 pm »

are my suggestions not feasible in a easy manner? couple tick boxes (if authentication on), or a refresh button for library so clients are up to date if authentication is off?

as my title states it's quite the conundrum...

share library with clients keep them up to date... allow tagging but fear loosing your whole library.
OR
disable authentication and no syncing will take place, leaving you the user having to update each client.

I hope someone see's my/others worries and could at least just add a enable authentication, but disable deletions. as i mentioned if a catastrophy would happen at least the datas not gone, and one could just restore tags from library.

Quote

Did you find that you were able to delete files and/or make changes on the Server from the Client with the "Sync changes" box unchecked on the Client?

As i mentioned, ive spent some time googling/jriver wiki/forum searching but no clue what it does?

rossp · « **Reply #6 on:** January 28, 2015, 02:14:11 am »

The 'kids' account idea is OK but is very easily avoided. All you have to do is restart MC and you are admin.
I think the best and easiest option is a simple check box on the server (not client) to disable 'client deletes'. Then we are all happy and can allow non MC savvy people to use our libraries.

Ross

mwillems · « **Reply #7 on:** January 28, 2015, 07:44:51 am »

Quote from: rossp on January 28, 2015, 02:14:11 am

The 'kids' account idea is OK but is very easily avoided. All you have to do is restart MC and you are admin.

Clients default to whatever user the server is currently set to. So if the server is set to the "kids" user, any client will start up in "kids". This will ensure that a restart produces as "safe" result, without impairing the ability of clients to change users if they have the password.

If you have the drives mapped, they'll still have file access if they can figure it out, but that's another kettle of fish and there are workarounds.

Doesn't help the deletes situation, though.

glynor · « **Reply #8 on:** January 28, 2015, 09:03:42 am »

Are the file mapped to the clients? Because I'm pretty sure the deletions only work if the client has direct access to the files in question.

Assuming that is correct (it would only take a simple test to verify), then the solution is simple... Map the shares as read-only on the clients.

HTPC4ME · « **Reply #9 on:** January 28, 2015, 04:35:43 pm »

Quote

Are the file mapped to the clients? Because I'm pretty sure the deletions only work if the client has direct access to the files in question

Thanks for stepping in Glynor...Pardon my ignorance...what do you mean are the files mapped to clients?
In my particular situation, i have server 2008 r2 which has 24 drives connected to it via map unc (\\Server Name\Movies\then movie drives\then folders)

all the clients that connect to that jrvier library in home network or outside if authentication is set to on, have the ability to delete all of the server jriver files/Mapped unc files.

If i turn off authentication, then all clients can access jriver server but no syncing/updates are sent to the clients.
Hope i explained better.

I don't know about you or others here, But i'd be willing to pay for this feature even if it is only as discussed, just a tick box on server to allow authentication, but disable deletions from all clients.

glynor · « **Reply #10 on:** January 28, 2015, 09:49:55 pm »

Quote from: xtacbyme on January 28, 2015, 04:35:43 pm

In my particular situation, i have server 2008 r2 which has 24 drives connected to it via map unc (\\Server Name\Movies\then movie drives\then folders)

all the clients that connect to that jrvier library in home network or outside if authentication is set to on, have the ability to delete all of the server jriver files/Mapped unc files.

Exactly. That's what I mean. Why??

Ignore JRiver for a minute. On the share, especially if you're serving them off of Windows Server, but even if they're on Windows regular, you can choose permissions for the share. I'll assume that the Windows user that all of your client machines are logging in as has Read/Write/Modify permissions on the share (Full Control in Windows parlance). Why?!? The whole idea is you don't want these people to delete the files. MC has nothing to do with it (that's just the mechanism they're using to delete the files). Block them from deleting the files.

I'm not 100% that this will work, but I'm about 85% that it will. I can explain...

I have a setup at the office that is just the opposite. We have a file share on the Isilon that contains all of the lecture captures we do at the office. This UNC path is watched by a copy of MC, which auto-imports their contents, and then our web server uses the JRSidecar XML files to generate a "corporate YouTube" on the fly from the metadata in MC's Library. It sounds fancy, but it is actually pretty clunky (and really should use MCWS -- if it did, it'd be way cooler).

Anyway, I have a set of users who run the lectures, and actually do the captures. They have copies of MC installed and can tag the files, adding [Name], [Description], and [Series] (for the name of the course or event or whatever). A lot of times what happens when you're recording these things is you end up with little 3-30 second "stub" files that are junk. You think they're about to start... The dude walks up to the podium so you hit start and then they realize they forgot something or their shoe is untied, and it is a fake-out, so you click stop and wait a bit more. It doesn't matter. You end up with these little useless stub recordings.

I'd have to check what actually works, but the policy we have (which I invented) is that when they have one of these, they send the filename to me and I delete them. Because (again, I need to check it to be sure this is true) they cannot. They have Read-Only access to the actual UNC path, and when the MC client tries to delete a file (I'm 85% sure) the client deletes it "locally" from disk. It doesn't "tell the server" to delete it, it updates its local cache of the Library (which eventually gets synced to the server) and then it tries to delete the file locally. Since they don't have permissions to delete the file on the UNC path, this fails (silently) and this happens:

* MC Client copy deletes the file.
* It can remove the file from the Library, and does, but cannot delete the file from disk.
* MC Client eventually syncs this to the server, which removes the file from the Library.
* MC Server's Auto-Import immediately re-imports the file (since the Ignore Previously Removed option is unchecked, because I'm not an animal)
* Since the file was previously removed, MC doesn't re-import it from scratch, but "un-deletes" it, as it does, and no metadata is lost, regardless of the JRSidecar status.

The only "metadata" I lose when they forget and try to delete one of these is the [Date Imported]. For me, this is actually pretty convenient since I have a Recently Imported view that is my default on that server, so I just pop it open and notice 2 or 3 new 3-second clips at the top of the list, and I email them and scold them for forgetting to tell me to delete them, and I delete them.

This scenario plays out on a monthly basis. The only part I don't know for sure is the mechanism of the deletion, because I haven't tested it explicitly (at least recently). But, if I could have these users delete the files directly, I would (because it is a pain in my butt and it really isn't my problem if they accidentally delete their own valuable content)... So, I think this is exactly how it works.

So... Make the clients log in to Windows with user credentials that cannot delete anything. It still risks the MC Library metadata, if you care about [Date Imported] anyway, but MC auto-backs-up the Library anyway so it really doesn't matter. You can always restore the backup, and they cannot delete the files themselves (the real risk). If they do mass-delete like jerks you:

* Find them and smack them.
* Restore the Library Backup
* Sigh and crack open a beer reveling in how awesome you are.

rossp · « **Reply #11 on:** January 30, 2015, 05:32:37 am »

Quote from: xtacbyme on January 28, 2015, 04:35:43 pm

I don't know about you or others here, But i'd be willing to pay for this feature even if it is only as discussed, just a tick box on server to allow authentication, but disable deletions from all clients.

This must be a fairly simple modification for the devs.

Glynor - restore from backup is not really useful as you will lose all other modification since the backup was taken won't you?

HTPC4ME · « **Reply #12 on:** February 13, 2015, 01:11:04 pm »

Quote

This must be a fairly simple modification for the devs.

Glynor - restore from backup is not really useful as you will lose all other modification since the backup was taken won't you?

Any chance you guys could tackle this one?

Note:
I have read Glynor's post (as rossp has) the point and concern of my post is for the less advanced/noobs who 1. don't have a clue how to setup what he describes, 2. are afraid of messing up all there files, 3. will run into tons of problems when on home network after messing with their shares/users by family/business members/specific pc's wanting to change/delete files via networking/explorer and being bombarded with windows password dialogs, and other issues noobs might run across (i have no clue what other problems a noob may run across, because well i'm one of them)

Perhaps you could take a poll on how many JRiver users have setup shares properly, have a clue how to do it, and above all feel confident about it?

Thanks for your time, and considering.

glynor · « **Reply #13 on:** February 13, 2015, 01:38:20 pm »

Quote from: xtacbyme on February 13, 2015, 01:11:04 pm

I have read Glynor's post (as rossp has) the point and concern of my post is for the less advanced/noobs who

Note: Windows makes all new shares read-only by default. To override this, you have to take explicit action, and kinda know what you're doing.

glynor · « **Reply #14 on:** February 13, 2015, 01:46:47 pm »

Also note, I'm not trying to comment on whether this option should be added or not. Just trying to help you solve your problem without requiring a change, if we can.

CountryBumkin · « **Reply #15 on:** February 13, 2015, 03:07:21 pm »

I'm sure you know that JRiver added a feature so you could remove the "delete" button from Theater View. Does this not take care of the problem?

Are you wanting to protect the server's files from being deleted under all circumstances from a client system - or just by an uninformed User watching a Show or Movie with Theater View? Or maybe I'm missing the point entirely.

HTPC4ME · « **Reply #16 on:** February 13, 2015, 05:12:53 pm »

Quote

Note: Windows makes all new shares read-only by default. To override this, you have to take explicit action, and kinda know what you're doing.

i have to disagree with you here...the explicit action noobs take is share and chose everyone. for if not, the noob runs/can run into alot of issues as i outlined in my prvt email to you.

the explicit action you speak of isnt rocket science. (right click file share with everyone) but setting up shares properly ( user accounts, passwords, group policies, letting some pc's see network files, and others not, the ease of being able to jump from pc to pc to edit files) is.

Just because i mention these terms above does not mean i'm knowledgeable in setting them up (I originally started this post by talking with others outside of the forum about jrivers wonderful product and trying to get them to jump on board... they brought this up to my attention, and then i tested it, and confirmed it, and thought of the potential issues that could arise for myself and others.) so I thought I'd push a bit for this.

if the program has access to files it would be nice for that program to prevent possible catastrophes. (in standard view AND theaterview) rossp mentions another great point on a possible catastrophe... a father\loved one\friend that you'd like to share your family pictures and videos/library with have no intent on wiping you out... but they could without knowing it.

Quote

I use this feature a lot but it would be nice if you could turn off the file deletion aspect of it on the server side.
I could then open up my library to my Father over the internet. Currently I can't because of the opportunity for him to delete my content.

Ross

Quote

Also note, I'm not trying to comment on whether this option should be added or not. Just trying to help you solve your problem without requiring a change, if we can.

Your one of the smarter ones here glynor, and from some of the topics Ive seen you write/participate in i can assume your pretty good at code... is what i'm / others are asking for call for a whole rewrite of jriver? or can something like this be implemented easily? for your comment above is leading me to believe it's much easier for a planet of noobs to do there research, make changes outside of it, then to give us a box that one can simply check or uncheck. (hope i'm not coming off as harsh, its not my intent i'm just trying to show jriver (and now you) how this isnt just an only me problem, it has potential for others to run into the same conundrum who are not as advanced as others here)

you guys ask for tips sometimes, feature requests, too easy's, and I know there have been discussions in the past on how to make jriver a "simplier" player... well, this can potentially be a too easy way for someone to lose all they have, or prevent them from being able to enjoy the wonderful features the program offers such as... the ability to tag 5 stars, add to playlist, and above all see server changes on the clients automatically without having to leave theaterview and going to file\library and reloading).

to me it seems like a reasonable tweak of a feature that's already implemented.

Quote

I'm sure you know that JRiver added a feature so you could remove the "delete" button from Theater View. Does this not take care of the problem?

for theaterview yes. but not standard view. (personally if the program is going to offer authentication, and we're allowed to have servers, it would make one feel much more at ease if they knew their library was authenticated (password needed to access it/so that it does not get compromised) BUT YET once connected know that it still won't get compromised... Otherwise im not understanding why we even have authentication... what are you protecting yourselves from? your files could be wiped out right after the password is entered, and at anytime afterwards because once connected authentication doesn't need to ask you again for password. so once your in , your in, and all you have to do is hit audio, images, vides and accidently be on ALL, hit delete and you are wiped out. done, kaput, no more...unless of course you have a backup scheme. Or... everyone on the planet takes setting up Linux, Mac, android, Windows (blah blah) sharing 1o1.

But wait there's more...

Does everyone have a backup scheme? is this easy to explain here for everyone to setup? backup schemes are bibles themselves... took me months to get mine setup, tweaked, to read all the details.. ok not months but you get my drift. does everyone know how to restore there backup scheme? how many drives are in your library? how long would the restore take? are you knowledgeable enough to know that jriver has a few posts that state just a mirroring backup scheme isn't enough? that users should have 3 drives to every one? what if you trip and fall and the hdd slams on the ground and that was your restore drive?

if one sets up a weekly, monthly annual backup scheme, and the clients connect to the jriver server let's say a a few times a week, and there are multiple clients.. well they don't need to wipe out your library completely. IN FACT if they did, that would be a god send (for once you turned on your backup bank and ran your profile it would alert you that these 24 drives this many files will be removed from your backups). the worst scenario I see. Is the clients slowly deleting files and you the backup manager for the JRiver Servers don't even notice that files have been deleted, and you go about running your backups, and you eventually find your backed up drives/restore drives no longer have those files for they have been told to be removed. (NOW... if your like me and you have all of your 24 drives setup to do backup schemes, and then once a file is deleted it is moved from the backup scheme to a "JUNK DRIVE" that sorts all the changes from the Left/Ride side, then you have got one last out where you could go and restore those files. Do most have this implemented, would most even think of this scenario?

EDIT providing the users have a junk drive/S that = the total size of their library. We have a 500GB junk drive... so from all those drives we would only be able to restore upto 500gb total... wiping us out.

Well, there's my pitch, hoping it can be looked into and considered...As it sits in our household we have authentication on, so no outside sources can get in, And the family has been instructed that no one is allowed to use jriver outside of theaterview... by doing so at least I the manager do not have to exit theaterview for every server update, and I can tag for the immediate family if need be... And at every backup time, I just watch my backups like a hawk for bold RED Delete notifications from those 24 drives (LlEFT & RIGHT), and then I verify it was indeed me that intended for those files to be deleted.

rossp · « **Reply #17 on:** March 10, 2015, 02:07:11 am »

HTPC4ME · « **Reply #18 on:** March 10, 2015, 12:49:56 pm »

Quote

bump

+1

eezetee · « **Reply #19 on:** March 11, 2015, 10:52:03 pm »

Now that I've got 2 clients, both set for authentication (Security concerns of course) I realized that a client can indeed delete files.

To Glynor's post about the network shares. What happens in environments whereby the UNC path is not shared directly but playable with DLNA?

A "read-only" mode is preferred (no-delete).

glynor · « **Reply #20 on:** March 11, 2015, 10:56:47 pm »

Quote from: eezetee on March 11, 2015, 10:52:03 pm

To Glynor's post about the network shares. What happens in environments whereby the UNC path is not shared directly but playable with DLNA?

I don't think MC can delete files from a DLNA-only device, though I could be wrong.

rossp · « **Reply #21 on:** March 25, 2015, 11:49:34 am »

Arindelle · « **Reply #22 on:** March 25, 2015, 04:26:42 pm »

I'm not at all an expert on this one, but would it be feasible to have a clone of the main library set up on all clients which they only can access, with none of the fields set to actually write to the disk? Just to the cloned library? Then the person(s) with access to the main library PC could have a view indicating all modified records on the cloned library, and copy and paste the tag information into the main library having 2 instances of JRiver running. The main library would actually write to disk. The libraries themselves could be backed up on a schedule. Maintaining it would be a PITA, even if it was possible I suppose.

But reading this again, and I'm sure I'm confused, so sorry to waste your time if so - you have people, family etc. on a LAN (like no outside access) and you trust them modifying all tags (which would include titles, pathnames etc.), but you are afraid that someone accidentally or other wise will delete the files themselves? If the lan has read/write sharing in place which it seems to, there's nothing to stop them just going into Windows explorer and deleting them directly. Wouldn't an hourly scheduled backup for the library and a daily incremental backup of the media cover almost everything except intentional sabotage? I'd be much more paranoid about losing my tagging than losing data . Anyway to backup data right after import?, otherwise wouldn't you need a RAID setup to be really sure? That would be real easy to do

Or maybe it could be possible to just have a part of the media set to read only. Stuff you really care about and don't want anyone messing with you just move to a big read-only folder? The other users might want to move their stuff into it too for that matter.

HTPC4ME · « **Reply #23 on:** March 25, 2015, 04:36:00 pm »

the majority of home users that use jriver, i dont think would know where to go in explorer to delete them all (plus there are ways of hiding those files from the users ...using a $ sign for example on shared folders). however if they are in jrivers interface all files are there for them to delete with just a few clicks.
goto to audio click on all files, select all, hit delete. ('m not responsible for you loosing your files.. jriver will be).

I did mention i do backups. (tad lengthy perhaps) but i touched on the pros and cons of that.

Quote

Does everyone have a backup scheme? is this easy to explain here for everyone to setup? backup schemes are bibles themselves... took me months to get mine setup, tweaked, to read all the details.. ok not months but you get my drift. does everyone know how to restore there backup scheme? how many drives are in your library? how long would the restore take? are you knowledgeable enough to know that jriver has a few posts that state just a mirroring backup scheme isn't enough? that users should have 3 drives to every one? what if you trip and fall and the hdd slams on the ground and that was your restore drive?

if one sets up a weekly, monthly annual backup scheme, and the clients connect to the jriver server let's say a a few times a week, and there are multiple clients.. well they don't need to wipe out your library completely. IN FACT if they did, that would be a god send (for once you turned on your backup bank and ran your profile it would alert you that these 24 drives this many files will be removed from your backups). the worst scenario I see. Is the clients slowly deleting files and you the backup manager for the JRiver Servers don't even notice that files have been deleted, and you go about running your backups, and you eventually find your backed up drives/restore drives no longer have those files for they have been told to be removed. (NOW... if your like me and you have all of your 24 drives setup to do backup schemes, and then once a file is deleted it is moved from the backup scheme to a "JUNK DRIVE" that sorts all the changes from the Left/Ride side, then you have got one last out where you could go and restore those files. Do most have this implemented, would most even think of this scenario?

EDIT providing the users have a junk drive/S that = the total size of their library. We have a 500GB junk drive... so from all those drives we would only be able to restore upto 500gb total... wiping us out.

Rossp's concern along with mine (and those friends of mine who have yet to purchase jriver due to this issue) is for those outside our home network.

Arindelle · « **Reply #24 on:** March 26, 2015, 12:57:51 pm »

Quote from: xtacbyme on March 25, 2015, 04:36:00 pm

Rossp's concern along with mine (and those friends of mine who have yet to purchase jriver due to this issue) is for those outside our home network.

hmm ok sorry missed that. Certainly not a setup for noobs

Personally, I wouldn't leave that kind of access open externally even if the delete was optionally removed. I'd put my stuff in a read only folder and let them screw up their data if they want. If you are really concerned about people being vicious, they might give the access to friends of friends. Well, hope you find a solution, sorry to have butt in -- the clone idea would be much more admin intensive than a backup up of the library file every 15 minutes anyways

HTPC4ME · « **Reply #25 on:** March 26, 2015, 02:21:26 pm »

didnt mean to come on to strong. im glad you jumped in...I'm just verifying info.

Quote

Personally, I wouldn't leave that kind of access open externally even if the delete was optionally removed. I'd put my stuff in a read only folder and let them screw up their data if they want. If you are really concerned about people being vicious, they might give the access to friends of friends.

I'll have to say from what Glynor has posted he would agree with you 100%, my point of this topic was for the vast majority of users who do not know anything about shares/the less savy/the noobs. And the possibility of jriver wiping out their own entire library(OR another users) by allowing deletions to be possible.
And to just simply give the library holder/owner the option to disable this deletions while authentication is enabled.

Rossp start selling.

Funkmeister · « **Reply #26 on:** March 26, 2015, 07:20:38 pm »

Thanks for the link from my other thread xtacbyme, this is exactly the concern I have.

For me, it's music I'm making available so using Theater View isn't really a workable option. I'd like to be able to 'lock' my JRiver library from the host side and allow clients to only be able to play tracks with no option to delete.

This is a pretty fundamental requirement as at present I'm trusting my mate not to do something stupid with my carefully-tagged and sorted files. All this needs is a tick-box in the Media Network settings to say, "Make Client Access to Library Read-Only". That would solve everything very nicely!

HTPC4ME · « **Reply #27 on:** March 26, 2015, 07:30:23 pm »

i concur.

rossp · « **Reply #28 on:** March 27, 2015, 02:46:34 am »

+1 I concur. This to me is a fundamental option if you have the ability to share your music / video / pictures to family and friends. You can't expect them not to make a mistake and delete / re-tag files. Especially when MC has such huge tagging functionality.

Come on devs please make this happen.

Ross

HTPC4ME · « **Reply #29 on:** July 14, 2015, 11:49:06 am »

Glynor if you are still subscribed to this... would it be possible by any chance to setup a scheduler some how to say... every night at 3am switch view from theaterview to standard view, click on file then click on main library (the library it is already connect to... allowing for a refresh).

So the library's on all clients that are connected to server would get the newest files for the day/week, and so that the thumbs/covers would be updated?
I'd be willing to pay you/someone to achieve this goal/schedule/script if it's at all possible?
thanks

rossp · « **Reply #30 on:** July 14, 2015, 12:14:35 pm »

A lock function must be in V21 surly. If not why not

Ross

INTERACT FORUM

Author Topic: Conundrum...sync changes with server, stop deletions, but keep clients sync'd. (Read 9601 times)