Print

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

[bunglemebaby]

Hi...
I'm struggling to try to understand how to use the server to play to a renderer in my JRiver setup.

What I'd like to do is use my phone to find some music, hosted on the server, and then play it to a zone/renderer (on a different machine than the server).

I can't get it to work consistently though. The closest I've gotten is by connecting the renderer/client machine to the server library, then creating ANOTHER server on the client renderer machine and then connecting to the second machine's shared library (a 2nd server, serving my 1st server's files??) from the JRemote app. This allows me to find music and play it to my selected zone on machine #2. This works fine, as long as I don't mess with the Now Playing list until everything has stopped...which should be fine under normal conditions. But all sorts of buggy fun breaks loose if I start to modify things...but that's probably a problem for another day.

Is this the intended setup/behavior? It seems non-intuitive to me that I'd need to setup a shared library on every single zone that I'd like to play music to (when they are all getting their libraries from the single server). My plan is to setup one or a few headless nuc/pi zones eventually, which sounds like headaches waiting to happen if they each need to be setup this way.

Thanks for any clarification here...

[mwillems]

If your server is set up as a controller, than you should see other JRiver renderers as zones on the server and should be able to control them from the server.  But the server is functioning as a controller as well as a server at that point (you need to have both the DLNA controller and server boxes checked on the server, and the renderer boxes checked on the endpoints).  If you've enabled DLNA controller on the server and don't see your renderers as zones on the server, it's probably a firewall issue somewhere along the line preventing SSDP from working.

[bunglemebaby]

Here's what I've got configured at this point (which now that I look at it makes things more confusing):
Server:
DLNA Server: YES
DLNA Renderer: YES
DLNA Client: YES

Client:
DLNA Server: NO (I'm not clear on how I'm connecting JRemote to this "server" since this is not checked)
DLNA Renderer: YES
DLNA Client: YES

One source of my confusion may be what the "Use Media Network to share this library and enable DLNA" means. How is this different than the DLNA Server checkbox? (this option is enabled for both server/client).
All connections are made using the Access Key for either server or client.

I am able to see my client's zones from the server. I am able to start playback that way. In this case however, I get a transcoded file at the client (there have been some songs that were blatantly worse sounding, so it's not just a GUI type issue). I also only see the currently playing track (and recently played tracks) in Now Playing on the client. If I try to skip to the next track using the client, nothing happens (presumably because it thinks there is no next track). This seems to share the weird behavior below that I get with JRemote connected to the server pc and playing to the client pc.

If I connect JRemote to the server and then select my client zone as the renderer, I am able to play music, but I get strange behavior.
   - The client winds up playing transcoded files (mp3 instead of flac), but if I play directly from the client or if I select the client as the server, then I get full resolution playback (both server and client are on a wired network, files are stored on a NAS with a wired connection through the same switch as the server).
   - The Now Playing list goes wonky. Sometimes the JRemote and the server keep a stale version of the Now Playing list. On JRemote, it will show the old/stale Now Playing info, but the play progress bar shows the updated client's song info (playback time). I can use the controls on JRemote to control the client playback, but I get weird behavior because e.g. JRemote shows a paused states instead of playing. In that case if I hit the play button it will start playing the JRemote Now Playing on the client again.
   - Sometimes, if I start playback on the client pc after having started playback originally using JRemote, it will show the full new Now Playing on the client, but then revert to the next song from the previous Now Playing after the first song plays.

So, all of the above doesn't sound to me like a firewall issue, from a gut level. I realize that weird things can happen though...I'm just not really sure where to go next for debugging, plus I'm not entirely clear on how this setup should work in the first place.

From your description mwillems, it sounds like when I connect JRemote to use my server pc as the server I am effectively using JRemote as a controller for the server DLNA controller, which then pushes media to my client zone. If I connecct JRemote to my client pc as the server I am effectively using JRemote as a controller for the client's DLNA controller, which pulls media from the server. Pulling media works, pushing media does not then...I think. I've got a lot of guessing going on here....

I've written a book now, hopefully it makes sense to somebody who can help me make sense of this.

[mwillems]

So you have two separate issues; transcoding and playing now/control issues.  Neither is a likely firewall issue.

You can control whether or how the server transcodes when playing to renderers by setting options under the heading "add or configure DLNA servers" under Media Network.  The default setting is indeed transcoding to MP3 (as I recall), but you can configure it to pass the files without alteration.

The playing now issues you're seeing are a result of the DLNA model, the controller only pushes a track or two at a time to the renderer/endpoint, and local renderer controls won't always work as expected when the controller is controlling it if that makes sense.

You can get relatively seamless JRemote control if you follow the following advice:  turn on all three DLNA options on all computers (server, renderer, and controller on all computers).  Configure the endpoints as library clients of the server's media library.  Then use JRemote to connect directly to the client/endpoint that you want to control (you can save different "servers" in JRemote for easy switching).  JRemote directly connected to the client will show you the server's library passed through to the client, and this will provide the most "normal" control environment (you can easily turn off transcoding, playing now works as normal both on the client and on JRemote, local controls on the endpoints all work as expected).  The only thing you give up by doing it this way is the possibility of playing the same content synced to multiple endpoints, but you can configure that in parallel on the server if you really want that.

The key is that the endpoint is the place that you want to initiate and control playback (what you call "pulling") for maximum flexibility.  Things will work even more smoothly if you can provide the client local access to the server's files through network shares and then check the client option to play local files if possible. 

[RoderickGI]

DLNA, playing to networked devices, and so on is such fun, isn't it! 

The method Mwillems has outlined will work, but you have said you don't want the extra maintenance of running a DLNA Server on the Client. Well, you don't have to.

A couple of points... okay, three:
a) The three components of DLNA that can be turned on in MC are the DLNA Server, DLNA Renderer, and DLNA Controller. You called the last one a DLNA Client in Reply #2 bunglemebaby. That can be confusing. I think you know this from later comments.
b) Turning on Media Network turns on a "MC Library Server", not a "DLNA Server". The "Media Network" functionality does use the SSDP protocol to discover UPnP/DLNA devices, but you don't need any of the DLNA components turned on in MC for that to work. MC's Client/Server arrangement, where a MC Client loads a MC Library from a MC Library Server, works the same way. You don't need to turn on any DLNA components for that to work, just Media Network.
c) JRemote doesn't connect to a MC Library Server using DLNA, but uses MCWS commands instead

So, for clarity, I am going to call your two PCs PC1 and PC2. My definitions are deliberately very simple.
PC1 runs a MC installation with a local Library that you wish to share with other installations of MC.
PC2 runs MC and is where you want to play media.

Before I forget, I am using JRemote2 running on my Android phone. It isn't clear to me if you are running the original JRemote for Android, JRemote2 for Android, or JRemote for iOS. That may make some difference.

Now try this interesting little test. Use the following settings:
PC1 running its local Library:
DLNA Server: NO
DLNA Renderer: NO
DLNA Controller: YES

PC2 also running its local Library (not connected to PC1 as a MC Client):
DLNA Server: NO
DLNA Renderer: YES
DLNA Controller: NO

Then connect JRemote to the MC Library Server (note, not a DLNA Server).
Select PC2 as the Zone to play to in JRemote. Note that PC2 will appear as a Zone of PC1, and the actual Zone used on PC2 will be the default Zone, which is Player.
Select a FLAC album in JRemote, and play it. Audio will be heard on PC2.

So what is happening in this scenario?
1. JRemote is using the JRiver Access Key and connecting to the PC1 Library Server via MCWS commands.
2. JRemote is acting as a Controller of PC1. I haven't checked if it uses MCWS commands exclusively, but I think it does. Of course, it may use some DLNA commands... something to check if interested.
3. PC1 is acting as a DLNA Controller of PC2.
4. PC2 is acting as a DLNA Renderer only.
5. JRemote tells PC1 what to play.
6. Playing Now on PC1 shows all media files added by JRemote, for the PC2 Zone. Playing Now on PC1 matches Playing Now on JRemote, if the "Server follow app zones" setting is turned on.
7. PC1 as a DLNA Controller is telling PC2 as a DLNA Renderer what to play, file by file. In actual fact, PC1 tells PC2 what to play, and then PC2 requests the file from PC1. DLNA works that way.
8. Playing Now on PC2 will show only files that have already been played, and the currently playing file. Some MC settings will change that behaviour.
9. So what controls any transcoding done in this arrangement? Well, nothing apparently. As playback is a DLNA function, I would have expected the settings in "Options > Media Network > Add or configure DLNA servers... > {select a DLNA Server} > Audio > Mode" to control any transcoding. My MC Library Server only has one DLNA Server defined, and the Library Server thinks that my target PC is associated with that DLNA Server. But of course, the DLNA Server is turned off, so... Well, those settings have no effect. I played FLAC files, with the DLNA Server set to transcode to MP3. My target PC played the original FLAC format. The other area where transcoding can be defined is on the target PC in "Options > Media Network > Client Options > Audio Conversion > Conversion", but the target PC isn't a MC Client of the MC Library Server, so those settings have no effect either. I think the MC Library Server just does the default action and sends the original file. I haven't dug into the detailed network traffic to see what is actually happen, and won't be doing that. 

So this configuration works fine. Sure, you can't do transcoding, but as you are playing to a MC installation, transcoding probably won't be required.

I'm going to look at a MC Client/Server configuration next to see how that works for transcoding. In that case the MC Client Options should control transcoding. I suspect MC Client/Server makes more sense for your environment bunglemebaby.


PS: If you set this configuration up to test, or any variations, it isn't a bad idea to restart MC on both PCs to make sure changes are active. I don't think it is necessary, but I did restarts just to be sure. Particularly as I run Media Server on my MC Library Server PC.

[RoderickGI]

Okay, so one minor change to the above: Load the PC1 MC Library on PC2, so that they are operating in Client/Server mode.

You still need the DLNA Controller turned on in PC1 and the DLNA Renderer turned on in PC2 so that the PC2 Zone will appear in PC1, and hence appear in JRemote. Well, in my network environment. I'm not 100% confident that would be true in all network environments, as my network has some quirks.

Anyway, all the above discussion is still the same, except that now transcoding can be controlled using the settings in "Options > Media Network > Client Options > Audio Conversion > Conversion" on PC2.

So that is all as per Mwillems' first post.


The other issue that you had was:

This works fine, as long as I don't mess with the Now Playing list until everything has stopped...which should be fine under normal conditions. But all sorts of buggy fun breaks loose if I start to modify things...but that's probably a problem for another day.

That is straight forward. MC monitors which device is the Controller, and if another Controller on the network takes control and makes changes, MC releases control.

So if you start playback using JRemote or PC1, then PC1 is the Controller. If you then change something using MC on PC2, MC on PC1 releases control, and PC2 becomes the Controller. When PC1 releases control it can no longer update Playing Now. It can also no longer tell JRemote what is going on, and update its Playing Now screen.

Note however that JRemote can assert control again if left to its own devices. In that case, Playing Now on JRemote and PC1 will start to be updated again with the full list, and Playing Now on PC2 will be updated with past and current files.

[bunglemebaby]

The key is that the endpoint is the place that you want to initiate and control playback (what you call "pulling") for maximum flexibility.  Things will work even more smoothly if you can provide the client local access to the server's files through network shares and then check the client option to play local files if possible.

This seems to be the main summary of things for me at this point. I've been operating this way since you posted this and things have been working well. I haven't had a chance to do any deeper testing for edge case oddities, but under normal usage I can get things to behave as I wish. This is a huge improvement, so thank you!

I'm not at all clear on the network streaming model/concept still. I'm not clear if the JRiver team is either frankly. e.g. Why is there a server/renderer/controller nomenclature if it's either not actually used or is used in such an obtuse manner as to be further complicated by this seemingly simple model? Anyway, I'm venting like a grumpy old man and that's probably not going to help matters any....

RoderickGI, I see that you've added another book here 
Life is busy for a few more days and I'll have to return later to see what other nuggets your words can give me. Thank you for the response though!

[mwillems]

I'm not at all clear on the network streaming model/concept still. I'm not clear if the JRiver team is either frankly. e.g. Why is there a server/renderer/controller nomenclature if it's either not actually used or is used in such an obtuse manner as to be further complicated by this seemingly simple model? Anyway, I'm venting like a grumpy old man and that's probably not going to help matters any....

Well one thing to note about the model is that DLNA is an industry standard/protocol shared by lots of software and hardware.  JRiver implements the DLNA spec, and the spec contemplates servers, controllers, and renderers. 

JRiver also implements its own network client/server system using MCWS that provides more functionality than DLNA does, but it's implemented in parallel. 

The DLNA options exist in JRiver for compatibility with other non-JRiver devices, the MCWS library server models exist because it provides more/different functionality than the DLNA options do. 

So if you have a DLNA renderer hardware box that has nothing to do with JRiver, JRiver can advertise itself as a DLNA compliant server so that the renderer can pull content, or JRiver can work as a controller to push content to the box.  On the other hand if you have a DLNA controller or server on your NAS, for example, JRiver can function as a DLNA-compliant renderer too.  If you're only using JRiver software and JRiver apps, you might not need the DLNA options as much.