Print

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

[blgentry]

MC's client server support, where there are two or more MC computers, one of which is the master music server.  This works.  People use it.  But it could really use some improvement.  It's very complex and has a big list of gotchas.  Like you can't edit anything from a client.  Like you have to have a drive mapped with the exact paths or it won't play.  Or do you?  This point is very confusing.  Cross platform client/server seems to have problems as well.

My point is that it's very complex and hard to understand.  I think MC would have a bigger selling point if client server was a fully baked, easy to understand solution, that worked without having to know a lot of arcane things.  Additional configuration is ok.  It's more about the gotchas and the incompatibilities.

Brian.

[JimH]

Brian,
I don't think you must be using it. No drive mapping is needed,  for example.  Please give it a soin before calling it half baked.

[blgentry]

Brian,
I don't think you must be using it. No drive mapping is needed,  for example.  Please give it a soin before calling it half baked.

I've just done some experiments using Linux as a server and Mac as a client.  No drive mapping required.  So why does the documentation clearly state that it is required?

https://wiki.jriver.com/index.php/Media_Server#Access_from_another_PC_on_your_LAN

4. On the Library Server PC, it is important to share any folders where the media is stored. In Windows Explorer, find the relevant folders, right click and select "Share with" then select "Homegroup -read/write" (assuming you have a Homegroup set up).

4. In order to be able to play all file types on the Client, it is important that the media file path is the same for the client as described in the file paths of the Library and used on the Library Server system. This may require mapping the drives used on the Library Server MC on the Client. You will need to do this in Windows Explorer on the Client.

So let's pretend that's out of date documentation, or it's a special use case or something.  What about editing from the client?  Like playlists for example.  Other confusing elements remain:  Everything is transfered as MP3 by default, unless you know the special option to change (which I do).  Accessing a remote server works of course and I can make it work.  But it's kind of arcane don't you think?  Old servers stick around forever.  I just experienced this as an old server was at the top of my list, with an almost identical name to the current (linux) server.  So loading the library failed repeatedly until I figured it out.

I'm not saying it doesn't work.  I'm saying it's clunky.  Compare this to highly polished environments like Sonos or similar and I think you can see quite a difference in the effort required to make it work.

Wouldn't making Media Network easier be a win for JRiver?  Wouldn't that attract more customers?  Surely I know my JRiver chops pretty well by now.  ...and I think it's clunky.  No insult intended.  It could just be better.

Brian.

[Hendrik]

So let's pretend that's out of date documentation, or it's a special use case or something.

It is required only for certain video types, like Blu-ray structure rips, which consist of not one file, but multiple, which the streaming through MC can't replicate.
Any ordinary video and audio playback works fine without a common share.

What about editing from the client?  Like playlists for example.

You should be able to edit playlists and file tags from a client just fine, assuming you have enabled authenticated access on the server. Of course we don't want libraries to be editable by default without ensuring the access is secured.
There are some select things you cannot edit on a client, largely limited to parts that go beyond the plain MC library, ie. additional files on the harddrives, like Cover Art.

[jmone]

Brian - have a look at this in the Wiki (Example 3) - https://wiki.jriver.com/index.php/Home_Networking_Examples

The only way I could see that it could be easier, is if there was an option in MC GUI like "Convert to Library to Network Share", that automated the 2 parts needed:
1) Create a Network Share
2) Renamed the Path to the new Network Share

[JimH]

Brian,
I edited the wiki.

Jim

[blgentry]

You should be able to edit playlists and file tags from a client just fine, assuming you have enabled authenticated access on the server.

I just tried this by editing the Album tag on an album.  The change appeared to work just fine.  Then I disconnected and reconnected.  The change is gone.  This is exactly the behavior I've seen reported over and over again in the forums.

I made sure I was authenticated and then retried several times.  Finally, I was able to make changes "stick" by switching away to another view, then switching back, and finally disconnecting and reconnecting.

See, this isn't consistent.  It's clunky.  Sure it works, but very few people would expect you to have to go through the extra unusual steps that I did in order to have changes stick.

Oh and being able to edit tags (sometimes) and NOT cover art?  That makes no sense to the average person.  These are the types of special knowledge I'm talking about.  This is the lack of consistency and polish I'm talking about which make MC's client/server support seem unfinished.

I'm highly technical; I really do "get" MC at a deep level.  My aim here is to make MC better and to lower the barrier for entry for less technical people.  You might say I'm trying to make you more money with this suggestion.  Because I am! 

Brian.

[Hendrik]

I just tried this by editing the Album tag on an album.  The change appeared to work just fine.  Then I disconnected and reconnected.  The change is gone.  This is exactly the behavior I've seen reported over and over again in the forums.

I made sure I was authenticated and then retried several times.  Finally, I was able to make changes "stick" by switching away to another view, then switching back, and finally disconnecting and reconnecting.

See, this isn't consistent.  It's clunky.  Sure it works, but very few people would expect you to have to go through the extra unusual steps that I did in order to have changes stick.

I don't think this is a very realistic assesment. Its possible that there is a sync missing when you manually disconnect from the remote library right after making changes, however, this doesn't seem like a very typical use-case. Most people use one library, either remote or local, and not switching repeatedly. It definitely enforces a sync when you quit MC, which is the far more common case, and if you keep it on, it syncs back and forth on a timer anyway.

And even then, that would be a tiny bug to fix. I'll test on Monday to see if that sync is missing.

You seem to start on the premise that MCs client-server model is quite broken, or barely usable. But its not. And to me it seems like you haven't actually used it outside of testing (apologies if I picked that up wrong), so if thats a setup you are interested in, I would strongly recommend to just use it for a while in a common scenario, without forceful disconnects or what have you.

Anything can be improved for sure, and allowing some of the missing tasks like coverart to be performed on clients would probably be pretty good (although probably also pretty complex), but its by far not terrible.

A comparison to Sonos or the likes is not quite as simple. Can any remote clients even do any sort of maintenance there? Isn't that just playback? (I don't own a Sonos specifically, but as far as I could find out, the amount of "management" you can do in general is extremely minimal, it largely seems to just index songs based on their metadata, and thats it). Thats much simpler, and outside of the Blu-ray case mentioned above, also just works. We can discuss changing the default from MP3 to untouched streaming, if that seems more logical, but what else?

[paoloboccardi]

My two cents to improve the use of double (or more) jriver:  I've been using jriver since two weeks on two PCs (the most powerful server and the PC client is simpler and fanless). I can not understand how the dsp work: on the server I can set the dsp and if I want to set them in the client? and in this case the convolution, for example, works on the server or the client do it? on Daphile there was an option that made clear that every dsp is performed by the server.

[Hendrik]

My two cents to improve the use of double (or more) jriver:  I've been using jriver since two weeks on two PCs (the most powerful server and the PC client is simpler and fanless). I can not understand how the dsp work: on the server I can set the dsp and if I want to set them in the client? and in this case the convolution, for example, works on the server or the client do it? on Daphile there was an option that made clear that every dsp is performed by the server.

Between two MC instances, DSP is performed on the system that actually plays the audio out to the DAC, so likely your client in your setup.

There is various reasons for that. Different clients might want different DSP settings based on their audio hardware, for example. And decoding the audio on the server, processing it, and then re-encoding it somehow for transmission to the client would also be rather wasteful, if not detrimental to the quality in some cases.

If you play to a DLNA device on the other hand, the server can perform DSP, since DLNA devices may not have any DSP options themselves. But the way DLNA is setup, you could also specify different DSP for individual DLNA devices, so at least the first argument is being covered. For the second, thats just a price one has to pay for that, since there is no other choice.

[rec head]

Last I remember, not all library management is available on a client. It would be great if it was.

[paoloboccardi]

Between two MC instances, DSP is performed on the system that actually plays the audio out to the DAC, so likely your client in your setup.

There is various reasons for that. Different clients might want different DSP settings based on their audio hardware, for example. And decoding the audio on the server, processing it, and then re-encoding it somehow for transmission to the client would also be rather wasteful, if not detrimental to the quality in some cases.

If you play to a DLNA device on the other hand, the server can perform DSP, since DLNA devices may not have any DSP options themselves. But the way DLNA is setup, you could also specify different DSP for individual DLNA devices, so at least the first argument is being covered. For the second, thats just a price one has to pay for that, since there is no other choice.

Ok: in my case I have a powerfull PC server in a room and a celeron j1900 client in another room. I set in DLNA on PC server a series of dsp including convolution: in this case the server sends the stream decoded to the MC client device? or not?

[RoderickGI]

I shouldn't buy into this discussion, but...

I use my Client/Server setup a lot, from my HTPC to my Workstation. I know it pretty well. I actually use the fact that Views aren't synced back to a Server all the time, to test View changes on my Workstation while connected to the Server, knowing the changes will be overwritten on next connection.

The MC Client Server arrangement does need special knowledge to get the best out of it.
The solution does seem clunky, and mostly that is because a Client can do some stuff, but not all stuff, and what it can do isn't all that visible. The syncing process isn't visible, which is sort of good, but it means mistakes can happen. I've had Playlists created on the Server, transferred to and edited on the Client, then changes disappear from the Server, and I'm aware of syncing. I've deleted a Playlist on a Client, only to have it reappear on next connection, because Playlist edits work on a Client, but Playlist deletes don't. (That was some time back, but I believe I am remembering correctly.)

The point is here, MC is a complex product that can do a lot, so there is a lot to remember about what works and what doesn't. Some issues aren't exactly black and white, and what a Client can and should do isn't documented well anywhere, and updated. It is trial and error for most users. When a User gets burned by something that doesn't work, maybe due to a missing sync perhaps, they just stop trying to use that function.

Anyway, I don't have the solution. I don't want to do all maintenance on my HTPC. I would like to be able to do it on my Workstation. But that isn't an easy fix.

Maybe just visibility of the sync state on the MC interface somewhere would help. A green button for all synced up. A red button when a Client requires a sync, which is active so that a click forces a sync. At present I can't even add a "Sync Now" button to the toolbar. If I could do that, and it changed colour as above, that would help make the issue visible.

[BillT]

I do like the red/green button idea.

My "server" runs headless in the garage; I don't do anything much on it. If a lot is to be added I close it down and connect to the library on a local machine for ripping and tagging.

It would be a lot better to be able to make changes on a client, but, apart from tagging audio files, what can be changed is quite unclear and you only find out by trial and error. I didn't know that view scheme changes would propagate back to the server, for example

[JimH]

One of the things that makes this more difficult is that not all clients should be able to change the server.  A house full of kids could do a lot of damage.  So we're cautious.  And an experienced user/admin can get around the problems.

If someone wants to make a list of essential additions to the current functionality, we'll consider them.  Ripping to a server seems reasonable, for example.

[RoderickGI]

I didn't know that view scheme changes would propagate back to the server, for example

I probably didn't write that up corerctly. View scheme changes aren't propagated back to the Server, and the whole Client library is refreshed when it next connects to the Server. So I experiment with Views on my Client, knowing that none of the changes will end up on the Server, so it is safe. Everything I do to Views gets undone automatically.

If someone wants to make a list of essential additions to the current functionality, we'll consider them.

That could take a bit of time to think through, which I don't have at the moment. But quickly;

Yes, ripping to the server would be nice, though I deliberately rip on my Client and then copy to the Server using shares at the moment, which gives me a sort of arms-length workflow that avoids potential errors. I would probably change my workflow if I could rip straight to the Server, and have tagging from the Client go with the files.

I am still fixing lots of tags in my HTPC Library, typically I fix tags and then want to move the files to their correct location based on the new tags, so I want to tag then use the RM&CF function immediately. From the Client.

Both of the above could be fixed with appropriate shares on the Server I guess. Also, I sometimes use MusicBrainz to identify and fix tags, which would require shares if I did that from the Client.

Despite what I said above about Views, I would like to be able to edit and have changes permanently synced from the Client to the Server. I may want to be able to select which Views are sent to the Server though, and also which Views are sent from the Server to the Client. Same with Theatre View views, also controlling where the Views appear.

I haven't played with the MC User functionality, but maybe which user is logged on should determine which Views appear.

Anyway, I haven't thought much on this, because I don't have a good list of what works and what doesn't, at the detailed level, and I have always just worked around the issues.


I will be interested to hear what others have to say.

[thecrow]

I don't want to seem like I am piling on here as I am generally very happy with my client server setup, it works well for me.
But there is one aspect I find frustrating and that is using the client to stream to a DLNA renderer.
As I understand it, when using a local library the "client" streams direct to the renderer but when connected to a server the client asks the server to stream to the renderer instead. This is actually indicated in MC by the fact that the name of the renderer changes from something like "OPPO-UDP-203" to "There: OPPO-UDP-203".
I have a laptop that is sometimes used, without the server, connected to a limited local library and at other times connecting to my server which houses everything I own. Often when connected to the server streaming to a renderer will fail because the client has not updated the DLNA zones to reflect the server connection and tries to stream directly to "OPPO-UDP-203" instead of "There: OPPO-UDP-203".
Additionally if I switch off some DLNA renderers, although the server updates the available zones this does not seem to be passed onto the client even after selecting "Refresh Dynamic Entries" on the client. Disconnecting and reconnecting appears to be the only way to get them back in sync.
If I power up some renderers after my client is connected to the server they usually appear as local renderers i.e. without the "There: " before them, again disconnecting and reconnecting appears to be the only way to correct this.

Otherwise I love the ability to have a central MC server to store, maintain, and deliver all my media to anywhere in and outside my home.
(always a good idea to end on a positive note)

[rec head]

In no particular order:
 
1) A list of what changes are possible and permanent from the client.

2) Personally I would like all aspects of library management available. I completely understand about other household members really mucking up the server. So maybe permissions per client, or a pop up on the server of what changes were made on the client and to accept/reject them. That could also save us from ourselves.

3) An easy way to share Views between the server and client. Perhaps this exists. I know it is possible already and maybe there is a quicker way than what I did: Save the view on my client then add a new view on the server and load it. Something like a check box to make Global Views? If there is already an easier way maybe it could be made more obvious.

4) The sync green/red button sounds like a good idea.

5) Ripping to the server does sound good. I have thought about changing the server to this PC but the BD drives are on the HTPC and I haven't wanted to deal with it. Again something that is probably possible but easy is better.





 

[dtc]

In client/server mode there is an option to use a track (file) from the client if the track is on the client. I have not looked into this in a while, but my understanding is that only happens if the full filename is identical including drive designation. Given that both client and server are running MC, it would be nice to have the determination be based on track attributes (tags) without the need for the path to be identical. This is particularly useful for remote access.  Since there is no indication that a track is playing from a local file, it is pretty difficult to determine if the local file is used or not.

[leezer3]

IMHO the biggest thing missing is import from clients.

This is somewhat paralell to the ripping idea, but from my experience, downloaded media is perhaps as common (if not more so with the proliferation of iTunes) etc. as disk based stuff

[blgentry]

I don't think this is a very realistic assesment.

You seem to start on the premise that MCs client-server model is quite broken, or barely usable. But its not.

I think Media Network works.  But I think it's very hard to understand.  Most regular people won't be able to get very far if they encounter any kind of issue.  There is a rather complex and specific list of "doesn't work" items.  This isn't user friendly.  I'm lobbying for a more user friendly solution.

A comparison to Sonos or the likes is not quite as simple. Can any remote clients even do any sort of maintenance there? Isn't that just playback?

Sonos is both a great example and a bad example.  It's a bad example because the Sonos model is very different than MC.  It's not so much about library management as it is about playback management.  When you connect Sonos components, it could not be easier.  It's all very automatic and everything just works.  Setting up zones is trivial.  Every client knows about every zone; automatically.  The point isn't so much that Sonos has a specific feature that's good.  The point is that everything it does requires absolutely minimal customer knowledge and is easy to set up.

We can discuss changing the default from MP3 to untouched streaming, if that seems more logical, but what else?

I'm starting with the premise the the client server portion of Media Network needs a total revamp.  This isn't the "too easy" thread.  This came from the "important directions" thread, which implies large projects and/or big changes.

The idea I get from reading JRiver responses here is that JRiver thinks Media Network is world class and needs only minor tweaks.  I'm not sure that we will get positive results from this discussion based on what I've seen so far.  Should I continue to address this topic, or just let it sit?

Brian.

[mattkhan]

How would local file playback via tags work? Wouldn't that mean you have a separate local library otherwise how would MC know the file exists?

Convert format is another feature that is server only but would be useful if it could be done on the client.

Import would also be useful

For me, the cross platform issues (long standing file path separator mainly) is the biggest impediment to client-server use (as I would prefer to run the server on Linux but can't). Having said that I imagine bd support would be another problem in that case as the server would need to be able to manage things it can't play (conceptually seems reasonable to me but I don't know if MC can do this).

[Hendrik]

I'm starting with the premise the the client server portion of Media Network needs a total revamp.  This isn't the "too easy" thread.  This came from the "important directions" thread, which implies large projects and/or big changes.

We're not going to entirely revamp a core feature of Media Center without drastic problems in its core design, and it just doesn't have that.
If you want to discuss improvements, no matter if small or big, thats fine, but starting from a point where you consider it unsalvageable is unlikely to be something we will agree with, afterall a lot of people use it every day.

Ultimately it comes down to the age old problem. If you want something super simple that "just works", then you give up a lot of advanced functionality and customization, because those often stand in direct conflict.

[dtc]

How would local file playback via tags work? Wouldn't that mean you have a separate local library otherwise how would MC know the file exists?

There is a local library on the client. The client is running a full version of MC.  In normal mode, the client can run as a stand alone system. In client/server mode the client uses the library from the server, but the local library is present. The client uses the local views, it should be able to use the local tags also. I am not saying it is trivial to do, but it certainly is possible.

In my case, I maintain my main library on a central server with 2 4 GB drives. But my laptop also has MC on it with a condensed version of the library. In particular, many of my high rez or DSD files are not on my laptop. When traveling, or at my second home,  I can us the laptop which has most of the tracks I listen to regularly. But when I want to use the full library I use the laptop as a client across the Internet. Still, the majority of my tracks are on the local laptop and could be used directly. 

[JimH]

What Hendrik said.

[tyler69]

We're not going to entirely revamp a core feature of Media Center without drastic problems in its core design, and it just doesn't have that.
If you want to discuss improvements, no matter if small or big, thats fine, but starting from a point where you consider it unsalvageable is unlikely to be something we will agree with, afterall a lot of people use it every day.

Just for my understanding, could you (or some other JRiver employee) please share your opinion on:

What does a "drastic problem in its core design" (in general) imply with regards to user experience in JRiver definition?

What are "big" improvements from JRiver point of view in MC24?

[JimH]

I believe Hendrik means, and I agree, that there is no fundamental problem with MC's Media Server design or it's functionality.  It works.  It gets used a lot.   It's generally trouble free.

[tyler69]

Thanks for the quick reply.
My first question was rather general, so not solely regarding the client/server functionality, sorry for the misunderstanding.
Also in my first question I asked what implications a drastic problem on user experience might have. I understand your answer is that when many people use it and it has few bugs you do not consider the implementation having a "drastic problem".

Yes, "it works". However, I agree with blgentry. It is not easy to set it up, users tend to give up. I am a customer since a few years and I experienced several situations where I
1. either was not able to set up things or
2. MC is/was just not able to do what I want.
I never got to know the difference.

[Hendrik]

What does a "drastic problem in its core design" (in general) imply with regards to user experience in JRiver definition?

Thats not something that can be answered in a general sense and would end up being rather philosophical anyway.
In most cases it would only be the case if we realize a feature has to go another path entirely then it was originally planned to go, and we literally had to start from scratch to get there. This is extremely rare.

As a general rule for everyone, what serves us all best is to actually focus on conrete problems or suggested improvements. "It is hard to use" or "It is clunky" is not really concrete feedback we can easily act on. We're all engineers here, its hard for us to ignore what we know and try to make things easier. If you encounter a problem, its best to directly address it specifically, then we can take note of it and perhaps improve it.

Even better yet is to also explain the motivation behind an improvement or concern. Even if something doesn't get changed immediately, knowing why a change is being asked for allows us to formulate a better overall design in the future, so that maybe some problems are solved differently, or the reason for such a question just goes away.

We're all subject to the XY problem, so understanding the motivation behind suggested improvements or calling out shortcomings can often result in much better solutions.

[DJLegba]

When something is playing locally from the server and a client changes from a local library to the server's library, playback stops. That should not happen.

[tyler69]

I also do not think that playback should stop when the client is closed (and the server is still residing in the tray on the same machine).

[DJLegba]

Stop After Current File does not work from client.

[RoderickGI]

My motivation is that I don't want to sit in front of the HTPC to do maintenance, of which I still have a lot to do. My HTPC uses a Bluetooth keyboard with a touchpad, plus Function Keys are a two key press, and it just isn't as easy or efficient as using a full keyboard and mouse of my desk. A 65" TV is great for viewing media. Not so great for doing maintenance. My Workstation screen effectively runs a higher resolution than the 4K TV, because I need to set Standard View on the TV to 200% so that I can see it from the couch. So I can see more of Standard View on the Workstation, which is handy. In fact, I haven't progressed as fast as I should have because I don't want to sit in front of the HTPC. I live with bad tagging and identification of tracks.

I'm sure all those people with headless servers, servers in cupboards, Linux servers with Windows Clients, etc. would feel the same. I have found maintenance via RDP, Teamviewer, etc. to be an exercise in frustration, because screen draws and response times are much slower.

So I would like to have all tagging and file management functions available on the Client. That would include;

Ripping  (Doesn't work now, but can be worked around using network addressing instead of drive letters. Or shares.)
Importing (Doesn't work now but is pretty easy to do, since when files are placed in the correct place on the Server, they get imported.)
Tagging  (Works fine now.)
Metadata collection including Cover Art, Get Movie & File Info, Get From Internet, etc. (Partly works now? The tagging part probably works, the file management parts don't. Could all work with network addressing or shares.)
Rename, Move, & Copy Files to move files to new locations appropriate to new tags.  (Doesn't work now, but again could be worked around using network addressing or shares.)

Note: As we know, network addressing and shares don't work between OS platforms.

Basically, I would like to be able to sit down at my Workstation and fix all my Library, and have it updated on the HTPC Server.

View management would actually have a lower priority than the above, for me, as I can work around that easier, and I change things less often.


Overall with Media Network, I don't think many people understand that;
1. A MC Server and Client connected using JRiver technology (i.e. using the Access Key and having a copy of the Server Library sent to the Client) don't use DLNA.
(I'm still not entirely sure whether any part of DLNA is used to identify Clients to the Server and visa versa or not.)
2. A MC Server and Client can be used together without connecting using JRiver technology, but using purely DLNA. In fact, Zonesync 2 works using DLNA only, as far as I can tell, and is better than Zonesync 1 used via JRiver Media Network connection, which requires tweaking of the timing between Zones, which drifts anyway. So in an environment where you want synced audio, DLNA actually works better.

Particularly, the difference between the two above methods, and the implications (DSP where? Conversion where and why? etc.) aren't well understood. Media Network settings are mixed with DLNA settings. I suspect lots of people think both methods are all the same, except when they are sending to a non-MC Renderer.

A surprising number of users on the forum have trouble with copying files, searching the forum and Wiki, etc., let alone settings up network addressing and shares, and keeping track of what is happening where. If all that stuff could be transparent to users, or at least there was the option for it to be, then the User Experience for those people would be much better.

[Hendrik]

I kept wondering about Importing and Ripping, and what exactly it is one would expect in functionality there, and more importantly, how to make users actually understand whats going on.

Importing in MC never moves any files, so on that basis the files you are trying to import would already be made available to the server somewhere. I would think anyone using a NAS-like setup with a headless server, or something of that sort, would know that his files would need to actually be on that "NAS" to be managed by it.

So what would an Import on the client look like? Show an import dialog, just instead of doing it locally, instruct the server to do the import? That probably wouldn't be very hard to do, but I wonder how intuitive that really is, since you browse around a "foreign" folder structure on a different PC. As a bonus, allow managing auto-import rules remotely as well the same way? Can probably make that happen.

Now Ripping, thats like importing, just worse, because you actually have to get the data over to the server. In a similar fashion, should we just have it point to a directory in the servers file system and magically transfer the files there?
That again makes me wonder if people would actually understand where their files are going to end up after the rip. Or should it just rip to a folder local to the client, and simply not import the files into the database (because the server doesn't know where they are)?

[RoderickGI]

I'm really out of time now but...

Importing on a Client would look like a RM&CF function, maybe included in it so that folder structure at the target was visible and based on tags, perhaps with just an additional checkbox that said, "Move to server".

Similarly, ripping on a Client would look exactly like ripping on a Server, but with that same additional checkbox, "Rip to server", which might initiate a popup like the RM&CF function to specify where, or maybe that rip would happen locally and then once tags have been collected, a RM&CF function would popup for the move.

The real key, without going overboard like iTunes, would be to make the process transparent to the user. No understanding or setting up Shares, at least not after the initial Client/Server setup, which could be all driven by the Access Key process anyway. That is, the Client knows the Server folder structure, and puts ripped files, and files to import, into the appropriate Server structure. So audio under "Music", if that is the base directory for music.

Some people actually love that iTunes moves files around for them. Personally, I don't. But moving files from a Client to a Server would be a benefit for the above functions. If it added value by avoiding digging into the OS to set things up in advance.


I haven't thought through a workflow in detail. That is probably what is required. But does the above add some light?

[DJLegba]

When I set up MC for my brother-in-law several years ago I needed to install a copy on his desktop PC so he could rip CDs, as his DAC is connected to a headless NUC running MC in another room. I tried to help him understand the idea of switching libraries on the client PC - local for ripping, remote for tagging - but the concept was beyond him. He does understand ripping on the desktop and using VNC to complete the process on the server, but it would have made things a lot easier if MC could rip while connected to a remote library. The server shouldn't need to care about the file path the client rips to - it just needs to import from watched folders. And he'd still need VNC to manage cover art until that ability finally gets added to MC.

[jmone]

Thankfully I do all my ripping and maintenance on the instance running MC Server and just consume of the MC Clients.  There have been a heap of requests over the years however for those with a headless server to enable ripping from Clients.  There are a couple of scenarios however:
1) If a Share is being used:  If both the Server and Client have access to the share it should be easy.  The Client already has the Library, has access to the file store (would need to be Read/Write), so ripping to the share then updating the Library from the client does not seem that "hard"

2) No Share being used:  I think this is harder.  The Client does not have access to the file store used by the Server (or it is read only).  The client would need either first rip to a temp location and then transfer it to the client, or someway of presenting a pseudo file share that can be used by not only MC Clients but also the 3rd party rippers that people use. 

I'd start with #1 and see how that goes.

The other idea could be is for an option In Media Network for MC to create and use a share when you enable "Use Media Network to share this library..." and avoid #2 all together. 

[dtc]

I think it is important to note the client/server is not just a LAN activity. It can be done wide area. In that case, using NAS or other share strategies does not help. As to ripping, I would like to do it wide area, since I spend months away from my main server. Yes, I know it means moving files over the Internet, but that is OK, as long as you know the limitations. I am perfectly willing to let it happen in the background or overnight. After all, people are doing that to the cloud every day.  Certainly wide area presents certain problems, but any solutions to existing problems should at least consider wide area needs.

[glynor]

I didn't read this whole thread, but my setup moved to a server hosted in a rack in my basement early last year. Overall, it works pretty well, but it drives me crazy that Rename, Move, and Copy Files doesn't work from the client side.

I get that this could be complex, but it is frustrating for me because this used to work just fine before MC's Client/Server functionality got so fancy.

It would be nice if some version of the "If local file exists, blah" logic that plays files locally for people who have the network shares all mapped out, could automatically detect and re-enable RMCF when possible.

[BillT]

Stop After Current File does not work from client.

It doesn't work when playing on the server, controlled by the client; it does work when playing on the client.

[JimH]

2) No Share being used:  I think this is harder.  The Client does not have access to the file store used by the Server (or it is read only).  The client would need either first rip to a temp location and then transfer it to the client, or someway of presenting a pseudo file share that can be used by not only MC Clients but also the 3rd party rippers that people use. 

I don't think we will try to support 3rd party rippers.

[JimH]

I kept wondering about Importing and Ripping, and what exactly it is one would expect in functionality there, and more importantly, how to make users actually understand whats going on.

Importing in MC never moves any files, so on that basis the files you are trying to import would already be made available to the server somewhere. I would think anyone using a NAS-like setup with a headless server, or something of that sort, would know that his files would need to actually be on that "NAS" to be managed by it.

So what would an Import on the client look like? Show an import dialog, just instead of doing it locally, instruct the server to do the import? That probably wouldn't be very hard to do, but I wonder how intuitive that really is, since you browse around a "foreign" folder structure on a different PC. As a bonus, allow managing auto-import rules remotely as well the same way? Can probably make that happen.

Now Ripping, thats like importing, just worse, because you actually have to get the data over to the server. In a similar fashion, should we just have it point to a directory in the servers file system and magically transfer the files there?
That again makes me wonder if people would actually understand where their files are going to end up after the rip. Or should it just rip to a folder local to the client, and simply not import the files into the database (because the server doesn't know where they are)?

How about introducing an "Export", allowing a user on a client to designate a server location to move all files to?  Handheld Sync can do that now.

[dtc]

How about introducing an "Export", allowing a user on a client to designate a server location to move all files to?  Handheld Sync can do that now.

Not everyone uses auto import, so a remote import function would also be needed.

[JimH]

Not everyone uses auto import, so a remote import function would also be needed.

I don't think it's unreasonable for you to set up auto-import on the server, just to import the uploaded files.

[dtc]

I don't think it's unreasonable for you to set up auto-import on the server, just to import the uploaded files.

I think requiring the use of auto import is unreasonable. It does not fit with my management scheme. I have a typical artist/album folder scheme. When I add new albums they go into that structure. To use auto import would mean I would have to set it up for the entire folder structure, something I do not want to do.

[cncb]

I also think it would be helpful to be perfectly clear what cannot be done on a client (i.e. don't even allow actions on the client that are not fully supported).  I recently reported an issue in MC24 where I did an update Library From Tags on the client for images which caused a bunch of warnings on the server and duplicates with url file names.  In my opinion, the client should not offer this action at all.  Similarly, it allows Get Movie & TV Info from the client and appears to get the poster properly, but when you reopen the client the poster is gone and it has to be redone on the server.

[Manfred]

I have two MC client's to my server and my workflow is the following:

- PC (Home Office, Win 10 Home, UW 34'' Monitor) for ripping Audio through MC - for that I have to switch to local library manually; BD, DVD I use mkv for ripping to a ssd on the PC where all ripped content and downloaded content from HighResAudio etc. is stored (nothing else, ssd is 8 years old). From this I move the files per drag and drop (Win Explorer) to the ~14 different top folders (no deep folder hierarchy) on the server. PC is also used to listen to music if I work at home and for testing new MC functionality. Before I move the files they are all checked by Antivirus.

- Media Renderer (Living Room, Win 10 Pro) optimized for SQ and for playback of video, audio, images; nothing else. I can access the Media Renderer from the PC through Win Remote Desktop to check/modify settings etc.

- Media Server (In a separate room, Win 10 Pro, Server MB with iKVM for remote management, Management LAN, Data LAN) where I manage MC's library, tagging, adding new fields, configure my references for Standard View, Theatre View, JRemote View, use of  Autoimport, Adding Lyrics, Backup Library, Backup Media Files, Moving Files through MC, Get Movie & TV Info etc. I access the Media Renderer through Win Remote Desktop for library management and iKVM if something is not working (Windows, Hardware issues->never happend during the last year)

In general I am happy with this. To switch to the local library for ripping and back after ripping is not so nice but it is not a major concern for me. To have some functionality where I could map a folder on my ssd to a folder on my server and MC watches this folders and imports the content according to the defined rules to the server would be nice. But for me it is nice to have and not a deal breaker.

[RoderickGI]

Here is another area where JRiver's Client/Server setup falls down.

While Playlist contents are synchronised from a Client back to a Server, and vice versa, Playlist layout changes (columns shown) are not.

How confusing is that?!

It seems layout changes fall into the same category as View changes.

https://yabb.jriver.com/interact/index.php/topic,119466.msg826054.html#msg826054
https://yabb.jriver.com/interact/index.php/topic,119444.msg826052.html#msg826052

Yes, I tested everything I wrote in those posts, in case you were wondering.

[drmimosa]

Full Authentication isn't possible for MC clients when Authentication is enabled and Read-only Authentication is set to "Everyone."

This is a problem for systems that use Panel with Read-only Authentication (no password operation), MC remote desktop clients can't get full authentication for metadata tagging (on a laptop, for example).

Detailed further in this thread:

Ah, I understand the issue now. You need a way to force MC to let you log in with Read/Write Authentication, when the Client is already connected with the Read-only privileges of "Everyone" by default.

...I've got nothing. I can't think of any way to make that happen. The functionality to do so appears to be missing. There may be a hidden feature like the one Matt mentions in this thread, but I don't know about it.

In fact I can't even think of a way to switch a Client that is logged on with Read/Write Authentication back to Read-only Authentication. It seems to be a gap in the functionality. MC needs a Logout feature, or perhaps better a "Switch Authentication" feature, since the word Connection is already used in association with connecting to a Library, and Logout implies disconnection.

I wonder how other people who use mixed Read/Write and Read-only Authentication on their Clients manage this. It would be a problem even if Username and Password Read-only Authentication was used. Only changing the Username or Password forces re-logging into the desired Authentication level.

[flac.rules]

One of the things that makes this more difficult is that not all clients should be able to change the server.  A house full of kids could do a lot of damage.  So we're cautious.  And an experienced user/admin can get around the problems.

If someone wants to make a list of essential additions to the current functionality, we'll consider them.  Ripping to a server seems reasonable, for example.

I would like transcoding to a device to work from the client. If i transcode video directly (without client server stup), it gets transcoded and moved to the device (like a tablet), if i do it on a client, it is transcoded, but just put in a folder at the server. Not transferred to the tablet.

I would also like library backups to backup all settings even if you are connected to a server.