Print

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

[cassfras21]

hello,

JRiver has a strange behavior with ZoneSwitch.

I have got a new DAC, it is DSD capable so I set 2 audio playback zones. One for my PCM files and one for DSD files with bitstreaming enable.

So I have 3 zones in jriver. Two for audio playback (to the same DAC) and one for video files (to HDMI output).

Zoneswitchs rules are as follow:

DSD zone   [Media Type]=[Audio] [File Type]=[sacd]
PCM zone   [Media Type]=[Audio]
Video        [Media Type]=[Video]


With that setup, no matter my current zone, if I start playback with an audio flac file, the zone will switch to PCM zone as expected.
So it's working fine that way.

Now if I choose to enable the option to stop playback. Rules now are:

DSD zone   [Media Type]=[Audio] [File Type]=[sacd]      Stop PCM zone
PCM zone   [Media Type]=[Audio]                               Stop DSD zone
Video        [Media Type]=[Video]

With that setup, if my current zone is Video and I start to play an audio flac file, the zone won't change and will play on my current zone. It's like if rule was ignored.
Instead if my current zone is DSD zone, it will switch to PCM zone.

Something goes wrong. Can you help please?

[mwillems]

Mutual stop playback rules create closed groups of zones.  If you want to switch between zones automatically, you need to have every zone stop playback in every other zone, or have none of them stop playback.  It's a feature that allows you to create multiple "groups" for switching.

[cassfras21]

Mutual stop playback rules create closed groups of zones.  If you want to switch between zones automatically, you need to have every zone stop playback in every other zone, or have none of them stop playback.  It's a feature that allows you to create multiple "groups" for switching.

I stoped playback in every other zone and now it is working as expected.

Thank you for help and your quick answer.

[csimon]

For completeness, if you wanted to be able to send audio to one of the first two zones while not interrupting video that might be playing in zone 3, how could this be achieved?

[cassfras21]

For completeness, if you wanted to be able to send audio to one of the first two zones while not interrupting video that might be playing in zone 3, how could this be achieved?

I might be wrong but I guess there's no way to achieve this if the current zone is the video zone.
If I understand well, switch occurs if the current zone and the target zone are members of the same group made by ZoneSwitch feature.

[mwillems]

For completeness, if you wanted to be able to send audio to one of the first two zones while not interrupting video that might be playing in zone 3, how could this be achieved?

If you want content to be routed automatically between all three zones, and want the two audio zones to stop each other, there is no way I know of to reliably do that.  Mutual stop playback rules create a "closed ecosystem" and zones outside of that ecosystem do not get routed to or from.  

My recollection is that you can get strange results if you have non-mutual stop playback rules, and you might be able to "game" those to get part of what you want.  Specifically, in the example above, if his two audio zones stop each other but not the video zone, but the video zone stops both other zones, my recollection is that routing will work either to or from the video zone, but not both.  I don't have a system in front of me to test right now, but it was one or the other.

Bottom line, with the current implementation, if there are any stop playback rules, then all zones that you want to automatically switch need to have mutual stop playback rules.  If there are no stop playback rules, then routing works normally, but nothing gets stopped.

Some folks have requested the ability to specify grouping for auto-switching separately from stop playback rules (my recollection is that 623 requested the feature a while back).  For my part, I'm pretty happy with the current functionality because it works very well for the traditional "room-as-zone" idea.  There just some edge cases that it doesn't handle well.

[csimon]

Yep, I've requested changes some time ago, just re-emphasising the point that there are flaws!

It's not just rooms-as-zones, grouping, and separation of audio settings from physical locations, but you have to set up zone switch to do something like the above in order to get round MC's inability to play video to a remote instance of MC. That limitation was deliberately introduced so that it is possible to play to one zone without interrupting playback in another zone. But ironically, that workaround means that it is no longer possible to play to one zone while not interrupting playback in another!

Also, it is not possible to set up two zones for normal use as the OP has described (for perfectly fine reasons - to be able to provess different typs of file differently, automatically- that's what zones do) and then have an optional third zone for, say, volume levelling, that you only want to use occasionally and on-demand.

I know JRiver says that all requests are listened to, but this is another one of those fundamental usability issues that has been reported a very long time ago by several people and there is no indication that it has been taken onboard so you don't know whethe you have to keep bumping it.  I wish dev resources would go towards fixing these first rather than new initiatives like Doctor Who which, as far as I can recall, hasn't actually been requested by anyone, certainly not every few days like a lot of other things.

[mwillems]

Also, it is not possible to set up two zones for normal use as the OP has described (for perfectly fine reasons - to be able to provess different typs of file differently, automatically- that's what zones do) and then have an optional third zone for, say, volume levelling, that you only want to use occasionally and on-demand.

This is entirely possible right now, you just have mutual stop playback rules for the first two zones, and leave the third zone out of it.  The third zone will work whenever you select it, on demand, but otherwise isn't involved.  

[csimon]

This is entirely possible right now, you just have mutual stop playback rules for the first two zones, and leave the third zone out of it.  The third zone will work whenever you select it, on demand, but otherwise isn't involved.  

Not at home at the moment to test, but I don't think it works remotely, as it's the same issue as not being able to send video remotely - you are unable to change the active zone remotely. It works locally because you can click on the zone to change to it. It just needs the addition of a new rule type in zone switch - switch to this zone if it is targetted by a play command.

Also, it probably won't work if the third zone uses the same output device as one of the two other zones.

[mwillems]

Not at home at the moment to test, but I don't think it works remotely, as it's the same issue as not being able to send video remotely - you are unable to change the active zone remotely. It works locally because you can click on the zone to change to it. It just needs the addition of a new rule type in zone switch - switch to this zone if it is targetted by a play command.

You didn't mention "remote" in your problem description for that issue (you mentioned it in connection with Video, but not with respect to special purpose zones), so it wasn't clear to me that that's what you were interested in.  I have no idea whether it works remotely or not (or exactly what you mean by "remotely").  I can confirm it works when you're interacting with the program directly, and I can confirm that it works with JRemote or Gizmo.  

I don't know whether it works when controlling one instance of MC from another (whether using Tremote or DLNA), because I don't use that functionality very much (I almost always directly control remote JRiver instances/zones using Gizmo or JRemote). I'm recalling some previous discussions we've had about these issues now, and my recollection is that you're averse to directly controlling instances of JRiver with Gizmo or JRemote and prefer the DLNA client-to-client communication for some reason?  Am I remembering that right?

Also, it probably won't work if the third zone uses the same output device as one of the two other zones.

It will work if you're starting from silence or press stop first.  Since you have to manually select the zone, it doesn't seem like a lot of overhead to stop what was previously playing too.

[csimon]

my recollection is that you're averse to directly controlling instances of JRiver with Gizmo or JRemote and prefer the DLNA client-to-client communication for some reason?  Am I remembering that right?

No.  I don't mind what I use as long as it actually works.  Just looking for a tablet solution that's all, which is a remote to a server instance of MC.  I keep switching from one technology to the other but I keep coming up against brick walls in one form or another, there's always some design issue or limitation in MC that throws a spanner in the works. (I'm starting to favour DLNA for controlling zones on multiple MC clients around the house becuase you only need to connect to one server and you can see all its DLNA zones. If using any other MC client you also have to set up ALL the clients as servers and then disconnect and reconnect between them in order to control them, because of MC's inability to remotely control another client).

Gizmo, Web Gizmo, MC Client, and all DLNA controllers all have exactly the same problem. So they don't work properly with multiple zones.  Although that is unfair. The remotes are fine, it's the server they're connected to that doesn't work properly with multiple zones.

eos works, because when the issue was pointed out to the author it was promptly programmed to have an easy-to-use zone screen where you can choose to select a zone as a target and/or change the active zone depending on your whim.  But it's not the client remote that needed changing.

I cannot run JRemote any more as its capabilites and requirements have far surpassed my lowly iPad Gen 1.  But the buggy and incomplete version of JRemote that remains on it also doesn't handle multiple zones very well.

[mwillems]

Gizmo, Web Gizmo, MC Client, and all DLNA controllers all have exactly the same problem. So they don't work properly with multiple zones.  Although that is unfair. The remotes are fine, it's the server they're connected to that doesn't work properly with multiple zones.

This is the part that always confuses me, as I routinely use Gizmo, Eos, and JRemote to directly control an instance of MC, and can play back video with zoneswitch and everything switches correctly.  I also have special "on-demand" zones outside of mutual stop playback rules, and those also work perfectly.  I have experienced no issues with changing zones, zoneswitch, selecting a specific zone, or playing video, provided that I am controlling the given instance of MC directly with Gizmo, Eos, or JRemote (i.e. am logged directly into that instance as a "server").  

For example, on one machine I have three mutually exclusive zones, and two special on-demand zones.  If I play video to one of the mutually exclusive zones, it winds up in the "video" zone and everything plays nicely.  If I instead send content to one of the on-demand zones it plays there instead.  I have another machine with three zones, two mutually exclusive, one special purpose, and those also work fine with Gizmo, etc., provided I switch "servers" to control it directly.

I do get your issues when trying to use DLNA or Tremote for remote control, which is why I generally don't recommend using DLNA for remote control (except when you need to link zones, as it's the only way to do that). When I use Gizmo to log into a given instance/server of MC directly, everything just works exactly as though I were sitting in front of it.  

I keep thinking we must be talking past each other somehow, or that we just have vastly different needs/expectations.  

No.  I don't mind what I use as long as it actually works.  Just looking for a tablet solution that's all, which is a remote to a server instance of MC.  I keep switching from one technology to the other but I keep coming up against brick walls in one form or another, there's always some design issue or limitation in MC that throws a spanner in the works. (I'm starting to favour DLNA for controlling zones on multiple MC clients around the house becuase you only need to connect to one server and you can see all its DLNA zones. If using any other MC client you also have to set up ALL the clients as servers and then disconnect and reconnect between them in order to control them, because of MC's inability to remotely control another client).

Setting up all the clients only needs to be done once and solves virtually all the problems you're describing above (at least for me).  Also try using Gizmo: changing servers is easy in Gizmo because all of the servers are at the bottom of the zones view so switching "servers" is exactly as easy as switching zones.  It's one of the reasons I don't use eos or JRemote more, as they make switching servers harder than it needs to be.

[csimon]

For example, on one machine I have three mutually exclusive zones, and two special on-demand zones.  If I play video to one of the mutually exclusive zones, it winds up in the "video" zone and everything plays nicely.  If I instead send content to one of the on-demand zones it plays there instead.  I have another machine with three zones, two mutually exclusive, one special purpose, and those also work fine with Gizmo, etc., provided I switch "servers" to control it directly.

It doesn't work for me. If I have zones set up as follows:

1 - 5.1
2 - 2.0
3 - 5.1 Volume Levelling

Suppose there are no zone switch rules to start with.

Using Gizmo I can select Zone 1 and play something there and it works fine. Zone 1 is currently the active zone on the server. I then stop playback, switch to Zone 3 on Gizmo and send video there. It doesn't work. Why? Because for video to play it has to be in the active zone on the server and Gizmo doesn't change the active zone.

In order to change the active zone, you need to set up Zone Switch. But what rule could I possibly set that could recognise that I want to play a video in Zone 3?

I can try setting Zone 1 and Zone 2 to be mutually exclusive with stop rules, with no actual selection rule as there is nothing I can use to determine what file I want to play in which zone.  Then do the same experiment again and it still doesn't work. Because neither Gizmo nor zone Switch changes the active zone.

I then add Zone 3 to the Zone Switch rules and make all zones mutually exclusive.  I then select zone 3 in Gizmo and play a video and indeed it does play, but it has sent the video to Zone 1 instead, which is the current active zone.

Are you saying that the active zone is being changed on the server for you?  If so, what is doing that and how do you get it to do it?  If it's the Zone Switch rules that's doing it, then it should also work via DLNA or TRemote as it's under the control of the server.  But nothing I've tried will change the active zone.  There are no Zone Switch rules that I can specify to do it, and the clients (Gizmo included) don't either.

[mwillems]

When I select a zone with mutually exclusive stop playback rules, playback starts in the "correct" zone regardless of which of the zones in the closed loop is active (as expected).  When I select an "on-demand" zone content appears to play in that zone just as if I'd started it directly on the server.  

I'll try replicating your specific setup at some point soon and see if I can repeat your issues.

[csimon]

It could well be that there is some setting that will allow video to play in a zone that is not current, but I don't know what that could be.

Note that playback does start in the correct zone but Display View doesn't kick in so you only get the audio of the video that's playing.  Display View only works for the currently active zone, so to get it to work the active zone has to be changed.

[csimon]

PS. I don't understand the distinction you're making between direct control and remote control! As far as I'm aware, Gizmo, Web Gizmo, eos, JRemote, TRemote, VixCommando,  all use MCWS, whch is a client/server command protocol, so they are all remote controllers. DLNA is a different protocol but it works in the same way. i don't know if internally MC uses MCWS to talk to itself in the same instance, but when I talk about a remote controller it means using an application that is not the same instance of the application you're trying to control.

[mwillems]

PS. I don't understand the distinction you're making between direct control and remote control! As far as I'm aware, Gizmo, Web Gizmo, eos, JRemote, TRemote, VixCommando,  all use MCWS, whch is a client/server command protocol, so they are all remote controllers.

The distinction I'm making is between using Gizmo to control an instance of MC when you are logged directly into that instance of MC as a server as opposed to using Gizmo to control an instance of MC "through" another instance of MC (which uses DLNA or Tremote). I'm familiar with MCWS, I've done some scripting with it and it's very different than DLNA control.

Gizmo is obviously always a remote control, but I wanted to make a distinction between using Gizmo to log directly into the instance of MC being controlled as opposed to controlling an instance of MC through Gizmo controlling another instance of MC.  

Gizmo --MCWS--> Instance
vice
Gizmo --MCWS--> Instance A --DLNA--> Instance B

DLNA is a different protocol but it works in the same way. i don't know if internally MC uses MCWS to talk to itself in the same instance, but when I talk about a remote controller it means using an application that is not the same instance of the application you're trying to control.

Bob has indicated in the past that client to client communications (i.e. inter-mc communication other than client-to-server Tremote) use DLNA.  And I can confirm that DLNA does not "work the same way" as MCWS.  MCWS can do many more things than DLNA can (a relevant example: changing zones). DLNA has distinct limitations and is not functionally identical to MCWS.

That's why I'm suggesting it might be worth your time to make sure you're testing with a direct MCWS connection rather than a less direct connection.

[csimon]

The distinction I'm making is between using Gizmo to control an instance of MC when you are logged directly into that instance of MC as a server as opposed to using Gizmo to control an instance of MC "through" another instance of MC (which uses DLNA or Tremote).

Ah, well in that case all my remotes are "direct" control!  In my usual setup there is only one server, and all of Gizmo, MC Client, JRemote, eos, and Voxcommando connect to it and control it directly, there isn't a second "nested" server anywhere. And all remotes have the same multizone problem when playing video (apart from eos which has specifically coded around it).

Bob has indicated in the past that client to client communications (i.e. inter-mc communication other than client-to-server Tremote) use DLNA.  And I can confirm that DLNA does not "work the same way" as MCWS.  MCWS can do many more things than DLNA can (a relevant example: changing zones). DLNA has distinct limitations and is not functionally identical to MCWS.

They are both client/server command protocls, that's what I meant.  No, DLNA cannot change zones, which is why active zone changing absolutely must happen on the server, not built-in specifically to each client.  MCWS can, but none of the clients (apart from eos, and JRemote in limited ways) have made use of it.

[mwillems]

Are all of your playback zones local to the server box?  If so, we're talking the same language and are on the same page.  

If you're controlling any remote MC zones from your server, you don't have a direct MCWS connection to any of those zones and that's the issue I'm talking about.

[csimon]

Are all of your playback zones local to the server?  If so, we're talking the same language and are on the same page.

Yes.

I've been experimenting with multiple PCs and zones with a view to whole house mediia, but the whole thing just doesn't work so I've not invested in it.  There are just too many problems, re: remote control, zoning, synched playing, zone grouping, maintaining the library from clients...

[csimon]

From earlier:

Setting up all the clients only needs to be done once and solves virtually all the problems you're describing above (at least for me).  Also try using Gizmo: changing servers is easy in Gizmo because all of the servers are at the bottom of the zones view so switching "servers" is exactly as easy as switching zones.  It's one of the reasons I don't use eos or JRemote more, as they make switching servers harder than it needs to be.

Here is a very hastily and untidily drawn diagram.  The top one is the situation as it stands today with multiple clients that you have to turn into servers. You can only connect to one at a time and so you can only see one set of zones at a time. You may find it easy to switch servers whgn you want to, but the point is that you shouldn't have to in a networked client/server environment and,as you say, it is sometimes not actually easy to do it anyway in particular clients. Especially in Theater View, which isn't even a client.

The bottom image is how I envisage it shold work. Only one server, you only need to connect to one and keep the connection, all clients are clients and not servers too, you can see all zones at the same time, you can group multiple zones from different clients if you want to (if synched playback worked).

I can see no advantage in the top one, in fact it only has disadvantages.

[mwillems]

Ok I just tested and I see your issue when playing to an on-demand zone.  Zones in a mutually exclusive zoneswitch relationship still work correctly, but something's definitely off with on-demand zones (or when zoneswitch is off).  Thanks for the reproduction steps.  

The reason I missed your issue is that I only ever have one video zone (all my other zones are audio focused), and if I'm controlling things via Gizmo (as opposed to a literal IR remote) it's usually because I'm not actually looking at the screen.  I suspected I might be missing something when you mentioned that playback does start in the correct zone.

Now that I've grokked the issue, I agree that it's very odd that MC will play video, and jump to display view, but to display view in the wrong zone.  Matt suggested in the other thread that this might be intended behavior to prevent disruptions, but I wonder if there was a misunderstanding of what you were describing (I only just now "got" it after exactly replicating your setup).  The reason I wonder is that this can't be intended behavior: it interrupts whatever was happening, but not in a way that actually shows the video, so it's the worst of both worlds.

I'm going to try posting this as a bug to one of the build threads (because I think it is) with specific repro steps and see if I can get a sense of whether this is intended behavior or not.

[csimon]

OK, thanks for confirming.

Difficult as to whether to class it as a bug or not, as I see it it is just functionality that hasn't been implemented in Zone Switch. It's deliberately intended that remote (or direct!) plays to a zone don't change the active zone, but there should be some other way of being able to control it, if we take it that the current behaviour of Display View is correct.  There aren't different "paths" to playing video as there are with audio so Display View can indeed only show one zone at a time, and changing the active zone on zone switch when playing audio to another zone will indeed disrupt any video that's currently playing.

eos takes control of the situation by allowing you to choose whether to change the active zone or not.

JRemote has a similar thing but (at least in the old version) makes it less accessible in that the choice is made in the iOS Settings app, not in JRemote itself on the fly.  It also makes you choose between mutually-exclusive settings of "Change zone on server when zone is changed in JRemote" and "Change zone in JRemote when zone changes on server", when in fact you'd want both.

But at least if there was a Zone Switch rule to say "Make this zone active if a file with certain attributes (e.g. a video file) is started in this zone" would allow us to program the functionality in for those of us that want/need it, and it would work with all clients, including DLNA.

The whole mutally-exclusive-groups thing in Zone Switch though is confusing and doesn't seem to behave consistently or in the way you'd expect, as has been pointed out before there are cases where it just doesn't work, so perhaps this also exacerbates the problem with remote video.

[mwillems]

I don't see this as a zone switch problem because if you have multiple zones with zoneswitch disabled, it still has this strange behavior.   With zoneswitch enabled and mutually exclusive zones everything actually works as expected, so it seems to me like a more basic problem.

I just can't imagine that having the interface launch into display view in the wrong zone on a play command from Gizmo is intended behavior.  It should either switch to the Gizmo selected zone and jump to display view, or just do nothing to the UI at all.  The current behavior seems like too much and not enough at the same time.

[csimon]

I don't see this as a zone switch problem because if you have multiple zones with zoneswitch disabled, it still has this strange behavior.   With zoneswitch enabled and mutually exclusive zones everything actually works as expected, so it seems to me like a more basic problem.

Well, I don't know lol!  Before Zone Switch, there was no way to control the active zone apart from changing it manually, locally on the server. Remotes were not considered. Zone Switch was introduced as a way to automate the changing of the active zone, but it only has rules that do it based on file type, not what the targetted zone is. The mutually exclusive rules don't work if you have no file selection rules - see my repro steps above. They only work if you've got rules that send specific files to specific zones.  My zones are all "on demand" even if they're mutually exclusive as they've got no pre-determined file-based rules. I send both audio and video to all zones with no way to pre-determine which files go to which zones.

I just can't imagine that having the interface launch into display view in the wrong zone on a play command from Gizmo is intended behavior.  It should either switch to the Gizmo selected zone and jump to display view, or just do nothing to the UI at all.

I suspect it could also be solved by changing the functionality of the general setting "Jump to display view on play video", whereby it would also switch to the correct zone.  But I think other people have also requested the Zone Switch rule method, not sure if the general setting would solve their own particualr situations.

[csimon]

Hmm, the other side of the coin (after reading back something I said above) is that if you have two audio zones with zoneswitch rules, as the OP outlined initially, and you are currently playing video in another zone but someone then remotely plays audio intending it to play in the background, won't zoneswitch then change the active zone and therefore disrupt the display view of the video that's playing?

It's a bit of a minefield.

[mwillems]

Hmm, the other side of the coin (after reading back something I said above) is that if you have two audio zones with zoneswitch rules, as the OP outlined initially, and you are currently playing video in another zone but someone then remotely plays audio intending it to play in the background, won't zoneswitch then change the active zone and therefore disrupt the display view of the video that's playing?

It's a bit of a minefield.

With the current behavior your case would still potentially interrupt the folks watching video depending on what your "jump on play" settings are. If it's set to jump to playing now for audio (which I think is the default), it would disrupt video playback just the same, and folks would be left looking at the video zone' "now playing" instead of display view.

That's what I mean about the current behavior being a bug with or without zoneswitch; either remote play actions to a zone should work exactly like a local play actions to a zone, or they should be "backgrounded" so that "jump on play" actions don't trigger in the wrong zone.

Personally, I'm not sure how common the use case is of someone trying to play music in the background while someone else is watching video on the same computer (that literally couldn't happen in my setup, but I know people have lots of different configs).  Maybe that's a common use case?  

FWIW I use Gizmo to start video playback daily, and I feel like being able to actually select zones for video playback from the remote is more important than simultaneously playing back different things on the same computer.  It just seems counter-intuitive to send video to a zone and have nothing show up with no explanation and no workaround.  

I can see arguments either way, but the current behavior serves neither goal very well.

[csimon]

With the current behavior your case would still potentially interrupt the folks watching video depending on what your "jump on play" settings are. If it's set to jump to playing now for audio (which I think is the default), it would disrupt video playback just the same, and folks would be left looking at the video zone' "now playing" instead of display view.

Even if there is no Jump setting enabled, the act of Zone Switch changing the active zone means that the current Display View gets broken, as Display View only works on the current active zone.  I do find it ironic that there is a deliberate effort made to prevent remote plays from disrupting current activity but Zone Switch does exactly that!

Personally, I'm not sure how common the use case is of someone trying to play music in the background while someone else is watching video on the same computer (that literally couldn't happen in my setup, but I know people have lots of different configs).  Maybe that's a common use case?

If it never or rarely happens, why bother having multizone capability at all?  Or is it intended that if you introduce video into the equation JRiver only supports it if on a separate PC from the audio zones? I had made the point before that this problem needs to be fixed before the ID is touted as an audio AND video renderer, as playing video to it just aint gonna work (if you have multiple zones on it). But perhaps it's intended to be cheap enough that you can buy one per video zone...

I can well imagine that you could have multiple audio zones off a central PC, delivering audio to multiple rooms while delivering video to the PC's screen.  But as touched on in other posts above, this is the difference bewteen having one central server that you can see all zones on (and being able to flexibly cross-link them) and having each room isolated in control terms.  As you pointed out, the flexible structure is only possible using DLNA, which has a limited set of capabilities. So things like zone switching need to be server-side, and JRiver really need to get DLNA synched playback sorted out.

[csimon]

It should either switch to the Gizmo selected zone and jump to display view, or just do nothing to the UI at all.

Actually, I'd already suggested that this should happen this last September, as an afterthought to my original request of July!  http://yabb.jriver.com/interact/index.php?topic=90662.msg634413;topicseen#msg634413

[csimon]

Is this issue going to be fixed in the foreseeable future, or is video playing on a multizone server when started from an external (remote) controller officially unsupported?

[csimon]

<bump>

Oirignally reported in June 2014 here http://yabb.jriver.com/interact/index.php?topic=89754.0

[csimon]

<bump>

[Hendrik]

You don't need to bump the same thread twice on the same day, or even the same week really. Its not going to get it any more attention, only annoy us poor developers that try to at least read everything, even if we don't have anything to say at this time.

[csimon]

Well try acknowledging it then and answering the question then, because it seems this issue has been completely misudenrstood for 18 months and without any statement of what's happening or that anyone's even seen it. I'm not a mindreader.

[JimH]

We can't acknowledge every post.  We do read them.

Closing this now.