huggaounce's community posts

I'm using RU server 2.6.0.3 and Host/Viewer 6.8.0.1

I found when configuring a host to use Custom Server Security, the capitalization of the username matters.  For example, logging on with username "johndoe" will fail if the username on the server is "JohnDoe".  Also, the logon will fail silently, in that after the "signing in" message, no messages or dialogues will show indicating the logon failed.  The assumption is that it succeeds but no permissions dialog shows either.

A failed logon from a viewer does say "invalid username or password" as an Address Book Error, but that is a little misleading to the user who may not remember the case sensitivity of their username and think the address book just didn't sync.

If case-sensitivity is by design, more clarity is needed through the documentation and app dialogues to remind users.

My suggestions:

1) Usernames should not be case-sensitive, since typically they are not in Windows.  
2) Unsuccessful logons should be prefixed by something more meaningful, eg "RU Server Authorization Failed"

I read this thread with interest but I don't quite understand the particulars of the problem.  I'm putting together some in-house training for a team and would like to know what might change in the next beta.

if a user manages to get the IP address for the remote utilities relay server and they know the port, the can directly just connect straight through.

I'm not sure what this means, what are the steps to reproduce this issue?  As far as I can work out it's not possible to connect to any hosts without a host password or a relay logon.  I'd like to understand so I can incorporate any procedure changes in my training.  

Thanks!

Hi all

I'm not sure if this is a bug or a feature request so I've posted here.  Viewer & Host versions 6.8.0.1

If you set "Lock Workstation on Disconnect" in the additional properties of a connection, the Host screen will also lock when using View Only mode.

By my definition, View Mode should not have any control over the desktop, so should not lock the screen on disconnect if set in the properties, since it is an action of control.

If this is by design, it should be given a suboption to not lock for View mode sessions.  Take for example, a user wants to show you something on screen while on the phone.  You connect with View mode, discuss with the user, then disconnect.  Their screen will lock and they will have to unlock it.  Inconvenient for the user and unnecessary.  

Does anyone else have this trouble?

Marty

Petar

Did you happen to see my post Can't get reliable sound capture ?

I wonder if what you are experiencing is similar to me, in that sound seems not to work depending on the upload speed.  Are you on a LAN or internet connection?

Marty

Thank you Conrad,

I've tried all kinds of combinations for colour, FPS, and economy etc but there's very little if any difference.

Sorry, I probably should have explained that I understand how a RU Server would benefit, but I was just testing for raw performance and a direct connection through a port forward would be the same as a local RU server with Internet-ID (please correct me if I am wrong).

I did some performance monitoring on 6.8.0.1 on the host in question and noted the following in Windows Resource Monitor during audio capture:

During normal activity, network interface traffic was averaging about 50Kbps
Begin playing a local MP3 file, the interface traffic jumps 10x to between 400Kbps and 800Kbps (to me seems a lot)
During this time, no audio comes through
Stop the MP3, about 15 seconds later, no audio still, traffic still high and remains high
Eventually some audio will come through in bursts, and complete in around 1 or 2 minutes.
When the last of the 15 seconds of audio is finished playing, the interface traffic drops back down to "normal"

Since my uplink is only around 400Kbps, I'm assuming either the line is getting saturated, or the RU service is topping out at the maximum available speed, which is not enough to sustain the throughput.  I don't know what audio quality is trying to be sent, but maybe there needs to be an option to transmit low quality (eg 22Khz) or UDP be used.

To verify, I run the same test with "capture sound" off, and interface traffic does not jump.  Turn it on while audio is playing and traffic jumps, and the symptoms above are the same, but I can't turn off the capture until the transmission of the audio is completed

Anyway, I grabbed a screen recording to help demonstrate and I would be very happy to supply any additional logs to you to help improve the next beta!

Hi and thanks for the replies.

Firstly, I tried the Beta as suggested and whilst the screen updates were noticeably better, audio was the same.  

I also tried port forwarding and callback for testing direct connection (which I believe is the same as setting up RU Server), and sound was slightly improved but nowhere near usable.  Even Windows system sounds were non-existent.

Of a minute's worth of MP3 audio, sometimes I would get a few seconds worth, delayed about 15 seconds after the audio should have started.  Sometimes I got seemingly nothing, so stopped playback and left the computer idle and patchy sound would come through a couple of minutes later.  Sometimes, while playback was stopped, previous audio would randomly "repeat" like a buffered block was being retransmitted.  

I suspect RU just doesn't do sound very well over slow connections.  Whilst we are on ADSL, it is a very congested network and I'm only getting 0.4Mbps upload despite having a 1Mbps sync speed.  I also have a 1920x1080 resolution which is unchangeable so there's little more I can do to reduce the data.

I like RU so far, but competitor products handle audio very well in comparison.  They use UDP whereas RU appears to only use TCP according to knowledgebase, and I think is why audio is better on the same host.  I suspect audio packets are getting lost over the bad connection and are having to be retransmitted, but RU is prioritizing sending screen packets first?  This is why I wondered if there were any tweaks I could apply, as I would prefer that audio get priority particularly when very little is happening on screen.  Low quality audio should consume relatively little bandwidth and is why I am surprised it's behaving this way.

I'm confident with a better connection I'll have no issue in recommending RU for our site, but a better connection is some time away and audio has some weight in our product choice until then :(

I very much appreciate any other thoughts you might have.

Hi

I'm trialling RU 6.8.0.1 for a small non-profit organisation who used to use  [censored] with sound capture to listen to 1-2 minute snippets of audio through an app.

Connections are over the internet ADSL speeds using Windows 7 hosts.

I'm really impressed with the great range of features RU provides, and whilst I am disappointed screen responsiveness isn't quite as good as  [censored] in my initial tests, what I am struggling with is the sound capture.

On an internal LAN it works pretty well with only about 2 second delay which is fine for our needs, but over the internet (where it's primary use will be), it is either horribly delayed by a minute or more or not even working at all, even for system sounds.  

The hosts uses a Behringer USB sound device and I wonder if it is part of the problem?  Are there any "under the hood" tweaks I can change to give RU sound packets a higher priority and see if that helps?  Changing the settings to try and increase throughput doesn't seem to help in the case of audio.

We are looking at getting a better router and QoS but it's some time away, and I'm not that keen just yet to spend time configuring RDP because it messes with screen resolution which makes the audio app unhappy.  

I hope you have some advice!