INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: How to prevent MC clients "stealing" the current zone?  (Read 14282 times)

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
How to prevent MC clients "stealing" the current zone?
« on: October 30, 2016, 12:06:35 pm »

I have an MC22 server that is also used for playback in one room. I have 3 (2 linux, 2 windows, couple of jremote) clients attached to that server and I've noticed that normal activity on those clients (e.g. restarting the client, starting playback) is changing the active zone on the server which is obviously extremely annoying for whoever is watching something on the server (as the display changes & they have to drop back to the MC client, changing the current zone and then go back into the player).

Any idea how to prevent this behaviour? I don't think it used to happen, not sure when it started though.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5241
  • "Linux Merit Badge" Recipient
Re: How to prevent MC clients "stealing" the current zone?
« Reply #1 on: October 30, 2016, 12:13:06 pm »

I've never noticed this behavior, but my server is running in a VM on a headless server, so I obviously don't spend a lot of time watching its zones.  I tried just now and couldn't reproduce it, but I have all my clients set to hide the server's zones; would that work/help in your case?
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #2 on: October 30, 2016, 01:30:50 pm »

I've never noticed this behavior, but my server is running in a VM on a headless server, so I obviously don't spend a lot of time watching its zones.  I tried just now and couldn't reproduce it, but I have all my clients set to hide the server's zones; would that work/help in your case?
That didn't help though I am now seeing it happen intermittently as well.

there is some other odd behaviour as well on one linux client in that it refuses to let go of what is in playing now. For example, I can choose to start an album and then go to stop playback and it refuses to stop, you can see tracks from the album keeping getting added back into playing now after I clear it. It feels like it is related to jremote tbh (which I find annoyingly flaky at controlling a client and my wife just refuses to use)
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5241
  • "Linux Merit Badge" Recipient
Re: How to prevent MC clients "stealing" the current zone?
« Reply #3 on: October 30, 2016, 02:18:13 pm »

That didn't help though I am now seeing it happen intermittently as well.

Not sure what to suggest unfortunately, but it may be related to what I discuss below (you may be able to improve the situation by turning off the DLNA renderer functionality to further sandbox MC instances)

Quote
there is some other odd behaviour as well on one linux client in that it refuses to let go of what is in playing now. For example, I can choose to start an album and then go to stop playback and it refuses to stop, you can see tracks from the album keeping getting added back into playing now after I clear it. It feels like it is related to jremote tbh (which I find annoyingly flaky at controlling a client and my wife just refuses to use)

I've seen what you're describing, and for me it has always been a side effect of DLNA control of JRiver.  If you start playback on an MC renderer via DLNA, attempts to stop playback on the MC instance that's actually playing won't work correctly, playback has to be stopped on the control point that initiated playback.  This is complicated because MC sometimes uses DLNA to communicate to other MC instances, which isn't obvious, and can be a source of confusion.  What I'm describing below is a distillation of some old threads where I got some direct answers from Bob and some experiments I've done about when MC uses DLNA.

The key to understanding it is that if you're controlling an MC instance from it's own UI, it's own webgizmo, or through gizmo/jremote logged into that instance of MC specifically, you're using MC itself or MCWS and everything will work normally. 

If you're controlling an MC instance from another MC instance or from gizmo/jremote logged into a different instance of MC, MC will use DLNA to handle the remote control, which is suboptimal because of the control weirdness.  The only exception is the specific case when a library client controls zones on the library server (but not the reverse), which uses something other than DLNA (Tremote?) as a control mechanism (I don't know very much about Tremote as my server is not used for playback, so I just disable all client control of the zones on the server).

So, a concrete example: if your server is 192.168.0.4 and your client is 192.168.0.5, if you connect to 192.168.0.5 directly with JRemote, because 192.168.0.5 is a library client of 192.168.0.4, you'll see all the media and views from 192.168.0.4, but you'll get local (MCWS) control of the 192.168.0.5 instance because JRemote is talking directly to it.  If you instead connect to 192.168.0.4 with JRemote and use it to control 192.168.0.5 as a zone, you get DLNA control with its attendant weirdness (slow to start or stop, local control is non-intuitive, may transcode based on your settings, etc.)

So the key to getting intuitive results, is to maximize the number of situations where you're using direct MCWS control.  The way I've dealt with it, for example, is to turn off the DLNA renderer option on all my systems (which removes them from the zone listing on other JRiver instances, further confirming that that kind of zone control uses DLNA) and then setup every client instance as a separate "server" in JRemote or Gizmo (even though they're all just clients of one actual server and show the same content).  I then switch "servers" in Gizmo or JRemote when I want to control different clients via gizmo/jremote.  This is much more intuitive in gizmo than in JRemote as gizmo lists all servers and zones in the same menu (and doesn't even really appear to distinguish between them), so you click in the same space to change one as the other; it's tougher in JRemote as you have to retrain yourself to switch servers instead of just switching zones.  It's one of several reasons that my wife prefers Gizmo even though it's not as nice looking as JRemote. 
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #4 on: October 31, 2016, 02:35:20 am »

thanks for the detailed response, I'll give that setup a go
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #5 on: October 31, 2016, 11:21:55 am »

If you're controlling an MC instance from another MC instance or from gizmo/jremote logged into a different instance of MC, MC will use DLNA to handle the remote control, which is suboptimal because of the control weirdness.  The only exception is the specific case when a library client controls zones on the library server (but not the reverse), which uses something other than DLNA (Tremote?) as a control mechanism (I don't know very much about Tremote as my server is not used for playback, so I just disable all client control of the zones on the server).
as an aside, why does MC use DLNA to control other MC instances? seems a bit of an odd choice.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5241
  • "Linux Merit Badge" Recipient
Re: How to prevent MC clients "stealing" the current zone?
« Reply #6 on: October 31, 2016, 06:25:24 pm »

as an aside, why does MC use DLNA to control other MC instances? seems a bit of an odd choice.

I agree and I don't know the answer.  Maybe bob can weigh in on why it was chosen over MCWS.  It does have certain limited advantages (i.e. you can stream content from a computer that has it in it's library to a computer that doesn't have it in it's library), but I feel like the cons outweigh the pros at least with my use cases.
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: How to prevent MC clients "stealing" the current zone?
« Reply #7 on: November 01, 2016, 04:00:37 pm »

mwillems, thanks for your detailed and honest reply.

I have been using MC on Windows for over 10 years.  I used the MediaServer and TRemote functionality and avoided uPnP/DLNA until this year.  I bought an Id and don't think it will be satisfactory.  It works as a renderer but with puzzling glitches (and other glitches on the PC acting as the control point/server.)  I couldn't get Windows 10 to see the shared folders on the NUC.  I finally got the Id to mount a shared folder on my NAS but the import dialog did not show any folders at a lower level.  The import dialog is quite different from that on the Windows version of MC and nothing that I tried worked. The documentation and the Id forum were no help.

I do see the Id's media folder from a Windows PC with the latest Id update.  I'll try mounting the NAS music folder again to see if I can import my music files into a library on the Id.  However, my experience so far is that I'm on very thin ice with the Id.  I have no resources for troubleshooting and the documentation does help.  I'd be foolhardy to trust it to work reliably in the future.

Now I'm trying to figure out what to do next.  Your post strengthens my feeling that I should avoid DLNA and avoid MC on anything but Windows.

Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5241
  • "Linux Merit Badge" Recipient
Re: How to prevent MC clients "stealing" the current zone?
« Reply #8 on: November 01, 2016, 05:24:43 pm »

mwillems, thanks for your detailed and honest reply.

I have been using MC on Windows for over 10 years.  I used the MediaServer and TRemote functionality and avoided uPnP/DLNA until this year.  I bought an Id and don't think it will be satisfactory.  It works as a renderer but with puzzling glitches (and other glitches on the PC acting as the control point/server.)  I couldn't get Windows 10 to see the shared folders on the NUC.  I finally got the Id to mount a shared folder on my NAS but the import dialog did not show any folders at a lower level.  The import dialog is quite different from that on the Windows version of MC and nothing that I tried worked. The documentation and the Id forum were no help.

I do see the Id's media folder from a Windows PC with the latest Id update.  I'll try mounting the NAS music folder again to see if I can import my music files into a library on the Id.  However, my experience so far is that I'm on very thin ice with the Id.  I have no resources for troubleshooting and the documentation does help.  I'd be foolhardy to trust it to work reliably in the future.

Now I'm trying to figure out what to do next.  Your post strengthens my feeling that I should avoid DLNA and avoid MC on anything but Windows.

I use MC for linux daily and while it's not yet as featureful as windows, I find it every bit as useful and stable.  I can't speak to the Id as I don't have one, but if it works the same as MC for linux you don't need to rely on DLNA control. You should be able to directly control your Id (via MCWS) using jremote, webgizmo, or gizmo, just like I described above.  If you take that route you should be able to get more or less frictionless control. 

And DLNA can work fine if you only control a given system from a single control point; it's just an issue when you want to interact with a player both locally and remotely (i.e. two control points).

Linux file shares in general take a little getting used to; if you haven't posted your share problems over on the Id/Linux boards I'd suggest you do so and see if the devs or we Linux users can't help you.

Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #9 on: November 01, 2016, 05:58:28 pm »

This doesn't help directly but your problems sound like me (Linux only, at home at any rate, for many years until being an MC user) in reverse :) time can be a great healer in this situation!
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: How to prevent MC clients "stealing" the current zone?
« Reply #10 on: November 01, 2016, 10:51:15 pm »

I use MC for linux daily and while it's not yet as featureful as windows, I find it every bit as useful and stable.  I can't speak to the Id as I don't have one, but if it works the same as MC for linux you don't need to rely on DLNA control. You should be able to directly control your Id (via MCWS) using jremote, webgizmo, or gizmo, just like I described above.  If you take that route you should be able to get more or less frictionless control. 

And DLNA can work fine if you only control a given system from a single control point; it's just an issue when you want to interact with a player both locally and remotely (i.e. two control points).

Linux file shares in general take a little getting used to; if you haven't posted your share problems over on the Id/Linux boards I'd suggest you do so and see if the devs or we Linux users can't help you.

The 10/28 Id update seems to have fixed the shares problem as far as I know so far.

The problem that I described with external devices has not been resolved.

I tried restoring a library backup from a backup file on the NAS

You asked about my use of MC.  Here is my current arrangement:

---
NAS with my music files

My personal PC (6th gen. i5 NUC) runs MC as a server with a library indexing the files on the NAS.
   USB DAC to play music in this room (home office)
   USB wireless DAC to play music in another room (living room)

My wife uses MC with TRemote on her PC to play music in the home office through a DAC on my personal PC

ID in the libary as DLNA renderer

Smartphone running WebRemote in the browser connected to MC on my personal PC. I select the ID as output device and select music using WebRemote.

---
As far as I know, I'm only using DLNA between my personal PC and the Id.


Apology: I keep hitting some control key that posts my message before I finish.  The control key may be sticking but I have pinched nerves in my neck that make typing very difficult, slow and error prone.




Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72548
  • Where did I put my teeth?
Re: How to prevent MC clients "stealing" the current zone?
« Reply #11 on: November 02, 2016, 05:31:03 am »

So you are using the Id (not ID) as a DLNA Renderer.

Then why bother adding a drive to it?  It isn't needed, as far as I can tell.
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: How to prevent MC clients "stealing" the current zone?
« Reply #12 on: November 02, 2016, 11:31:36 am »

So you are using the Id (not ID) as a DLNA Renderer.

Then why bother adding a drive to it?  It isn't needed, as far as I can tell.

At present, I have been using the Id as a renderer.

In another thread, you posted a very similar message yesterday.  I provided a very detailed explanation of my efforts to explore the Id functionality so that I could decide how to use it.  You replied

"You have a right to expect everything to work.  We'll do our best not to disappoint you.

It also works as a server or as a stand-alone player (which is how I use it).  But that requires more to set up."

And I have been exploring the individual actions needed to use the Id in various ways.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72548
  • Where did I put my teeth?
Re: How to prevent MC clients "stealing" the current zone?
« Reply #13 on: November 02, 2016, 12:16:02 pm »

So, your next goal is to add a USB drive and import from it?  Is that correct?
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: How to prevent MC clients "stealing" the current zone?
« Reply #14 on: November 02, 2016, 01:35:49 pm »

So, your next goal is to add a USB drive and import from it?  Is that correct?

No.  I tried to access a backup file on a thumb drive and was unable to navigate down to the folder containing the backup file.  I think was clear on that.  There is no point in my pursuing accessing music files on an external drive until I get some help from JRiver.  You seem to be more interested in questioning why I need to use some functionality than in offering any assistance.

I have been exploring other Id functionality and have turned up three more problems.  I will post about those in  the Id forum.



Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #15 on: November 02, 2016, 01:52:21 pm »

You seem to be more interested in questioning why I need to use some functionality than in offering any assistance.
It might not feel like it but that is a good thing, if someone knows *why* you want to do something as opposed *how* you want to do it then there is more chance you will get a functional solution to your actual requirement
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72548
  • Where did I put my teeth?
Re: How to prevent MC clients "stealing" the current zone?
« Reply #16 on: November 02, 2016, 03:13:19 pm »

Moving a backup file would be easier over the network.  You should see the Id under Windows > Network in Explorer.
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: How to prevent MC clients "stealing" the current zone?
« Reply #17 on: November 02, 2016, 10:46:33 pm »

It might not feel like it but that is a good thing, if someone knows *why* you want to do something as opposed *how* you want to do it then there is more chance you will get a functional solution to your actual requirement

Mattkhan,  I have been talking to Jim on two threads.  I started a thread on the Id forum titled "can't restore a library backup from a thumb drive".

I described what I had done in detail and the problem that I found. 

If I try to navigate to a folder on a USB thumb drive, I find that the file open dialog won't let me get below the device level.  That's a concrete problem.  Maybe I am missing something or doing something wrong but I need help from JRiver and I'm not getting it.

In answer to a question from Jim, I made an attempt to explain that I was exploring Id functionality.   Jim keeps asking the same question over and over.  He has made no effort to address the problem that I clearly described.

File open dialogs often use common code through a program.  The same sort of problem might be present in other file open uses too. 

Moving a backup file would be easier over the network.  You should see the Id under Windows > Network in Explorer.

In the "Can't restore..." thread on the Id forum, mwillems suggested that I put the backup file on the NAS.  I did that and was able to access the backup file and restore the user fields and views on the Id's main library.  I then imported the music files for that library from the NAS. (I found some different problems.)

At this point, I don't need a workaround for using the library backup file.  I'd like to know how to access files on a USB storage device.

---
Since it was possible that I missed something, I had tried to discuss the file open dialog problem in a separate thread before I filed a bug report but this discussion and the other thread are getting me nowhere.  I installed the 11/1 Id update and rechecked one of the problems.  I filed a bug report on that problem. I may pursue other problems that I have found.  Or maybe not.
 



Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72548
  • Where did I put my teeth?
Re: How to prevent MC clients "stealing" the current zone?
« Reply #18 on: November 03, 2016, 05:46:59 am »

Listener,
Sometimes, I ask more than once because it isn't clear what you want to do.

It's not reasonable to expect me to re-read every post you've made every time I post.  I try to keep track of many conversations, but sometimes I don't remember what has been said before.  If you would rather have no help from me, I understand.

Jim
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: How to prevent MC clients "stealing" the current zone?
« Reply #19 on: November 04, 2016, 12:31:47 pm »

If you needed further details from me, you should have asked specific questions in the context of what I said before.

For the record, I have been exploring three ways to use the Id to supply audio to my main system in our library room:

1. use the Id as a renderer only.  Use Webremote on a smartphone to control MC running n my personal PC.  I select the Id as the output device and then browse my library and select music to play.  Advantages: I've gotten this approach working. Disadvantages: requires having MC running on my personal PC when I want to play music in our library room. Getting MC on my personal PC to see the Id is uncertain.  Sometimes that recognition happens promptly; sometimes it takes a while; sometimes I have to restart MC n my personal PC several times.

2. Use the Id with a local library database.  Import my music files from the NAS where they are stored. Control the Id directly with Webremote to browse and select music to play.  This has the disadvantage of creating a separate database on the Id but I am making very few changes these days and buying little music so I can manage the syncing manually.  The advantage is that I don't need to access MC on my personal PC.  I am part way through the process of using this method.

3. Use the TRemote functionality from the Id as a client to access the library database on MC on my personal PC as the server).  I would control the Id with webremote and play audio from the Id to an audio device attached to the Id.  Advantages: I've use TRemote functionality on a laptop for years.  Disadvantages: I have not used TRemote functionality to play music on the client.  On Wednesday, I tried connecting from the Id as TRemote client to MC as server on my personal PC and failed.  I tried using the access key for MC on my personal PC and using that PC's IP address and port 52199.
Logged

fitbrit

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4889
Re: How to prevent MC clients "stealing" the current zone?
« Reply #20 on: November 07, 2016, 12:10:25 am »

I'm seeing what appears to be the same issue as mattkhan.

All instances of MC are on Windows PCs. I also use JRemote from iOs devices using iOS9 and iOS10, and have several DLNA renderers on the network. Here's what happens:
  • Someone is playing a video on the Library Server HTPC
  • I launch JRemote, which had been used to play media on a zone different to the server or on This Device
  • The Library Server immediately switches to the zone that had been playing on JRemote, interrupting the video and displaying cover art on the screen
  • My 7 year old or wife hate me: Wife asks why we can't just play discs; daughter wants to watch SpongeBob on YouTube instead of on MC

Note that the mere act of launching JRemote can cause this. Or it can happen if I change the zone on JRemote.
Logged

tyler69

  • Citizen of the Universe
  • *****
  • Posts: 946
Re: How to prevent MC clients "stealing" the current zone?
« Reply #21 on: November 07, 2016, 03:44:27 am »

I can see those effects also. I thought this is due to bad settings/wrong usage, but never found out how to make it work so I just lived with this behaviour but it's nice to see somebody else notices this.
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #22 on: November 07, 2016, 03:56:01 am »

Note that the mere act of launching JRemote can cause this. Or it can happen if I change the zone on JRemote.
I had that problem as well (and also the problem of family having confused and angry looks) :)

The workaround suggested by mwillems seems to do the job (albeit slightly tedious to implement as you have to go on tour round each client to set it up properly)
Logged

fitbrit

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4889
Re: How to prevent MC clients "stealing" the current zone?
« Reply #23 on: November 07, 2016, 10:57:07 am »

I had that problem as well (and also the problem of family having confused and angry looks) :)

The workaround suggested by mwillems seems to do the job (albeit slightly tedious to implement as you have to go on tour round each client to set it up properly)

I don't think that will work for me, as I often have to start movies playing for the family, at the server, from various other nodes in the house.
The best solution for me would be to have the Linux version of MC dockerised, so that I could run it on my unraid server. That would alleviate the need to ever use media on the server itself. Still, I would have thought that this was part of the MC's basic functionality, and if I am not mistaken this behaviour is fairly new, or I have only begun to encounter it recently.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13943
Re: How to prevent MC clients "stealing" the current zone?
« Reply #24 on: November 07, 2016, 11:54:21 am »

I use MC for linux daily and while it's not yet as featureful as windows, I find it every bit as useful and stable.  I can't speak to the Id as I don't have one, but if it works the same as MC for linux you don't need to rely on DLNA control. You should be able to directly control your Id (via MCWS) using jremote, webgizmo, or gizmo, just like I described above.  If you take that route you should be able to get more or less frictionless control. 

And DLNA can work fine if you only control a given system from a single control point; it's just an issue when you want to interact with a player both locally and remotely (i.e. two control points).

Linux file shares in general take a little getting used to; if you haven't posted your share problems over on the Id/Linux boards I'd suggest you do so and see if the devs or we Linux users can't help you.
DLNA isn't designed to allow multiple control points to be in charge at the same time.
The way MC tries to handle this is to assume that it's the active control point if the DLNA zone being controlled is current AND MC issued the play command.
Otherwise if the zone is current, MC just monitors the current state of playback.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13943
Re: How to prevent MC clients "stealing" the current zone?
« Reply #25 on: November 07, 2016, 12:01:10 pm »

I'm seeing what appears to be the same issue as mattkhan.

All instances of MC are on Windows PCs. I also use JRemote from iOs devices using iOS9 and iOS10, and have several DLNA renderers on the network. Here's what happens:
  • Someone is playing a video on the Library Server HTPC
  • I launch JRemote, which had been used to play media on a zone different to the server or on This Device
  • The Library Server immediately switches to the zone that had been playing on JRemote, interrupting the video and displaying cover art on the screen
  • My 7 year old or wife hate me: Wife asks why we can't just play discs; daughter wants to watch SpongeBob on YouTube instead of on MC

Note that the mere act of launching JRemote can cause this. Or it can happen if I change the zone on JRemote.
JRemote has options settings which are off by default for zone following.
On mine, the following options are off and I can't reproduce the behavior you see.
Server follows app zone changes
App follows server zone changes

We also tried to reproduce this using Gizmo and another PC connecting to the MC's server's library server and sending tracks to different zones, at no point did the zone on the server MC change from the zone it was playing tracks in.

The only time I could get it to switch zones was with webremote.
Webremote doesn't store zone state so it needs to switch the zone when you choose one for playback.
If you use the newer Panel (updated WebGizmo) you will not get the zone changing.
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #26 on: November 07, 2016, 12:03:51 pm »

JRemote has options settings which are off by default for zone following.
On mine, the following options are off and I can't reproduce the behavior you see.
Server follows app zone changes
App follows server zone changes
my jremote settings are as per defaults
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13943
Re: How to prevent MC clients "stealing" the current zone?
« Reply #27 on: November 07, 2016, 12:43:40 pm »

my jremote settings are as per defaults
You just checked and both of those settings are off?
I simply can't duplicate this behavior with anything other than WebRemote.
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #28 on: November 07, 2016, 01:15:20 pm »

You just checked and both of those settings are off?
I simply can't duplicate this behavior with anything other than WebRemote.

that is correct, both settings are off.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13943
Re: How to prevent MC clients "stealing" the current zone?
« Reply #29 on: November 07, 2016, 01:39:25 pm »

that is correct, both settings are off.
Simply can't make this happen.
I've played a video in MC 22 and connected to it with JRemote, Gizmo, WebGizmo and another MC client PC. Played stuff to 3 zones simultaneously with MC still playing that video without a hiccup...
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #30 on: November 07, 2016, 01:46:36 pm »

Simply can't make this happen.
I've played a video in MC 22 and connected to it with JRemote, Gizmo, WebGizmo and another MC client PC. Played stuff to 3 zones simultaneously with MC still playing that video without a hiccup...

I'm not sure if this is the same setup as mine, just to be clear my case is

MC server (windows), default media network options (all 3 DLNA options ticked)
MC client (linux), connects to the windows server, checkbox for showing the server zones is ticked
jremote on android, connects to the windows server, MC client (linux) is selected as the target zone

MC server is playing a film, zoneswitch is on which directs playback to a video zone
jremote tells MC client to play a radio station
current zone on MC server switches to the cover art of the radio station, film playback continues in the background

fix = go to server and change current zone

now switch jremote to play to this device
jremote plays a film streamed from the server to this device
current zone on MC server switches to the cover art of the film being played on jremote, MC server film playbcak continues in the background

Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13943
Re: How to prevent MC clients "stealing" the current zone?
« Reply #31 on: November 07, 2016, 02:15:18 pm »

I'm not sure if this is the same setup as mine, just to be clear my case is

MC server (windows), default media network options (all 3 DLNA options ticked)
MC client (linux), connects to the windows server, checkbox for showing the server zones is ticked
jremote on android, connects to the windows server, MC client (linux) is selected as the target zone

MC server is playing a film, zoneswitch is on which directs playback to a video zone
jremote tells MC client to play a radio station
current zone on MC server switches to the cover art of the radio station, film playback continues in the background

fix = go to server and change current zone

now switch jremote to play to this device
jremote plays a film streamed from the server to this device
current zone on MC server switches to the cover art of the film being played on jremote, MC server film playbcak continues in the background
Perhaps it's specific to JRemote android.
Can you try Gizmo on Android with the same setup?
Logged

mojave

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3732
  • Requires "iTunes or better" so I installed JRiver
Re: How to prevent MC clients "stealing" the current zone?
« Reply #32 on: November 07, 2016, 02:36:32 pm »

I had this same issue with someone I was helping a while ago. He was using JRemote for iOS. He would start playback of his living room zone and then the cover art would show up in his theater zone. We fixed the issue, but I'm having a hard time remembering what caused it.

It might have been that the sample rate of the zones was different or that a Zoneswitch rule needed to be added or changed.
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #33 on: November 07, 2016, 03:02:52 pm »

Perhaps it's specific to JRemote android.
Can you try Gizmo on Android with the same setup?
I will try and recreate it. It might take me a few days before I get a chance to reconfigure the setup back to how it was though.
Logged

fitbrit

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4889
Re: How to prevent MC clients "stealing" the current zone?
« Reply #34 on: November 07, 2016, 08:28:22 pm »

Thanks for the input, Bob and mojave. I'll see if I can figure out a way to consistently reproduce it, and will try to document it via video.

Just to be sure:
I am using iOS for JRemote.
On my iPhone, at least, the Server follows app zone changes was ON; logically, that could have been the issue in my case. We'll see.
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4275
Re: How to prevent MC clients "stealing" the current zone?
« Reply #35 on: November 08, 2016, 02:29:50 am »

I reconfigured to how (I think) it was configured previously and can't recreate the problem. I did notice a bug in jremote while I was at it though :) see http://yabb.jriver.com/interact/index.php/topic,107833.msg748286.html for details
Logged
Pages: [1]   Go Up