Date
1 - 20 of 26
OFF TOPIC - remote PC & TeamViewer Home Use version - Times out
|
Michael Buxton
I use TightVNC and it is free. TV is my backup. It is a good alternative and it does not timeout. It requires some knowledge with port forwarding if you have a firewall though.
Mike
Sent from my Verizon Wireless 4G LTE smartphone
|
|
|
|
Joe Zeglinski
Thanks Mike,
I may have to eventually go with VNC, if this
TeamViewer connection “randomness” doesn’t get resolved.
VNC is probably the second most common remote support package out there,
and indeed the TeamViewer website “compares itself (briefly) to VNC – claiming
only that TV doesn’t have the need for “port forwarding”, so it is easier to
configure.
I also thank Ray, for suggesting RADMIN. Can’t beat the
$49 (version) lifetime license, compared to over $800 for a Commercial
(non-timeout plagued version) of TeamViewer. As I recall from RADMIN
website, the standard version is for 3 client connections, which should suffice
the average telescope setup from a couple of PC’s. Besides, can’t get better
recommendation, than its being used by Ray Gralak. I may dedicate RADMIN
for astronomy, and continue wit TeamViewer for more mundane family PC remote
support.
I would prefer that TeamViewer would not have the
“randomness” – I could just about live with the 3-hour cut-off, for the free
version. TV is nice for quick and easy support of remote family and friend
computers, since they can download and install it themselves, without any
technical “port forwarding” expertise. It is probably why many or most,
large computer software companies use it and have customers download TV to solve
a problem, with them on-line. Of course, these software companies will have
their own TV name “rebranded” versions for the download, but it is still
TeamViewer inside, something every user can become comfortable using themselves.
It is also easy to download at say, a friend’s house, and immediately log into
one’s, already running telescope session, just to check up on CCD imaging
progress, while away on a dinner visit, for example.
*******
BTW:
For those using TeamViewer, (in EXTRAS->log
files) the “Connections_incoming.txt” log file is interesting – a log
listing the incoming host PC name, its TV ID-number, and Session
connect/disconnect times.
Unfortunately this log seems to use UT-Time, while the other, far more
detailed and complex, “TeamViewer11.log” activity file uses Local
Time, so beware of the difference. They should have just used a single time
standard for all logs to sync up the activities reports. The connections log is
helpful in examining, perhaps by importing into a spreadsheet and its
graphing, to see just how long a session lasted, before being shut down or
lost, over weeks or months of telescope use.
********
Last night – strictly JUST for “fun” – while debugging
my TeamViewer system, I wanted to see how many client connections could be
“CASCADED” to each other, connecting sessions to the Scope PC. So, I
connected as client from one home (client) laptop to my Scope (host) PC. Then I
went to a second PC, and connected to the first “client PC” which was already
operating the scope remotely. I was surprised that I now saw the Scope window
inside the first client window, on my (second) client PC window – “a picture, in
a picture, in a picture”, if you like.
Next, I wondered if this client - remoting
the former two - could actually still “CONTROL” the Scope PC (via the initial
client). Sure enough, my mouse controlled the Scope PC mouse position – I still
had control, two client PC’s down the lane. In fact, I was even more surprised,
that this second client’s Windows clipboard was also connected to the Scope PC
clipboard. I could copy something saved to my distant client clipboard, and
paste it directly, on the remote Scope PC screen (file name, text into a WordPad
doc. etc). Wow !
*****
Going for broke ... I clicked on the TeamViewer icon on
that Scope window and made yet a THIRD connection ... “Right back to
myself”, the second client – a Closed Loop connection. Talk about “Screen
Art” – there was suddenly a cascade of hundreds of copies of ALL the
client screens, ever decreasing in size into a “naked singularity”. The effect
was like viewing an object set between two mirrors facing each other – infinite
number of projections. At first I thought I really broke my PC graphics
card this time, and would need to Shutdown Windows – but the effect was easy to
close, by simply clicking the red-X on the “outermost” TV session window, to
disconnect from the first client PC session.
As I said ... just for fun – and to see just how
tolerant TeamViewer software could be. ... Very Powerful program !
Normally I might “DIRECTLY” log into the Scope control PC, from a second
client – but I wonder how the APCC would know where commands are coming from,
the first or second client simultaneous session, and would the AP Mount’s CPx
controller get muddled by two dual access sources. But that is for another day.
******
So ... Right now I am still desperately trying to
resolve the simple host/client connection problem. Possibilities include:
-----
I have learned a lot about choosing and
using a remote app, during these conversations. Sorry if this thread has lasted longer than perhaps some
expected. Thanks for your patience with this OT posting. But, I feel the choice of an easy to use, common, reliable
and inexpensive Remote session application program, is important to
operating our Astro-Physics mounts, safely. My thanks to Joel, Mike, and Ray, for your added
information and advice thus far. Back to debugging. Joe Z.
|
|
|
|
Michael
I will offer a different suggestion to try - I use Splashtop Personal. It's free and has worked well for me for years. I can control my observatory computer from the house with my office PC, iPad, or iPhone. I don't leave it running all night, but just pop on and off as needed to see how the observatory computer is doing. It doesn't log off the observatory computer so it purrs happily, but I can control the computer if needed. Mike
|
|
|
|
Joe Zeglinski
Thanks Mike –
Does “SPLASHTOP PERSONAL” ... keep both local and
remote screens etc., fully and simultaneously displayed ?
Microsoft Remote Desktop (RDP) always required the user to log back into
the running session on Windows Pro and higher. It acts as if a “Switch User”
command has been initiated, with the initial session then moved to running in
background, but hidden and inaccessible until switching back with a login. You
would think Microsoft, with all its in-house smarts, would have fixed that,
decades ago.
I need to be able to get to the session screen without
the delays of fumbling in the dark, logging in again, just to see the active
session screen, when there is a panic situation with my AP mount about to
collide.
Joe
|
|
|
|
John Gleason
I have been using the Teamviewer free version for about 3 years with few disconnection problems. That's remote from California to Australia. Where in Australia we have a less than optimal connections via satellite. (A possum once chewed though a connection). TV hardly ever drops out compared to Logmein which wants to drop about every 2 to 3 hours or so. Sometimes LMI drops frequently. I will fine TV fully functional in those cases. We are sometimes limited by bandpass, so if I run at maximum screen resolutions to look at fine data, both TV and LMI will kick out pretty quickly. Mainly just monitor at lowest color res after initial setup. No experience with the others, but much I think depends on the connection and the service at the remote PC in my personal experience. Neither TV or LMI has any problem when managing the PC at the telescope in my backyard.
|
|
|
|
Michael
Joe The remote computer will be unchanged (although a little message bubble comes up saying that it's now being controlled by another window). There is a setting in Splashtop where you can choose to have it log out (like a switch user) but I turn that off. I don't need to fumble with anything. It's a nice little package. Mike
|
|
|
|
Joe Zeglinski
Hi (dvj),
That’s interesting – I wonder why TeamViewer sometimes
“forgets” that it is running the FREE version - limited to 3 hour connection
before forcing a disconnect. I think that has also happened to me, once or
twice. I think the first run after install doesn’t setup the 3 hour cut-off, in
its parameters, until that initial session has ended.
Please see (below) the email I received from TeamViewer
confirming this whole issue of how long a free session keeps its
connection.
Joe
**** From TeamViewer *****
Dear Sir or Madam,
Thank you very much for your message. The FREE version of TeamViewer has a “three-hour limit” on its connections. This means each session will be disconnected
after three hours. However you can always establish a new connection again
immediately afterwards.
Please note that “LICENSED versions” of TeamViewer do NOT have any time limit on their connections. If you have a need for unlimited connections,
please consider purchasing a license. We will be happy to discuss our licensing
options with you and give you a personalized quotation.
If you have any further questions about TeamViewer, please feel free to contact us again. Best regards, Ryan Zhang ---------------------------------------------------------- TeamViewer Pty Ltd * www.teamviewer.com Asia Pacific Headquarters, Adelaide, AUSTRALIA
|
|
|
|
ayiomamitis
Gents,
toggle quoted messageShow quoted text
I have been following this thread with great interest. Speaking of TeamViewer, it is something I tried a few years ago when I wanted to transfer a few gig of data from one laptop to another. It was interesting to note that I had my ability for file transfers immediately cut thereafter and, I suspect, the 10 Gb of data involved in the transfer did me in. As an aside, FileZilla is one incredible piece of software for such matters involving a local network (it is also freeware). Question for the group: of the various pieces of software suggested in this thread, which one has the least overhead with respect to slowing down the remote computer due to CPU, RAM etc when the software is active on it? Anthony.
On 5/3/2016 18:28, 'Joseph Zeglinski'
J.Zeglinski@... [ap-gto] wrote:
|
|
|
|
Stuart Heggie <stuart.j.heggie@...>
Anthony, I too am watching this thread with great interest. It seems to me that an early version of TV blocked file-transfer for the free version but this is no longer the case. I routinely use TV to move a gig or more of data from the field behind our farmhouse to the computer IN the farmhouse via a range extender connected to the router and sitting at the back of our deck (in a weather proof plastic box). Stuart
On Tue, May 3, 2016 at 3:52 PM, Anthony Ayiomamitis ayiomami@... [ap-gto] <ap-gto@...> wrote:
--
Stuart Heggie
|
|
|
|
Joe Zeglinski
Anthony,
If you have the Free TeamViewer version, do a sample
file transfer, and check the worst case slowest transfer speed. Then multiply by
(3 x 3600) to approximate your file size limit to can transfer min that 3 hour
session limit.
Or, buy the Commercial license for nearly a $1K, and not
have a limit. But, that price is unrealistic, unless you are Microsoft
Tech Support (one of TV’s clients, evidently).
Joe
|
|
|
|
ayiomamitis
Joe,
toggle quoted messageShow quoted text
File transfers stopped being an issue when I started to use FileZilla. It is a great piece of software and which I highly recommend. Anthony.
On 5/4/2016 01:09, 'Joseph Zeglinski'
J.Zeglinski@... [ap-gto] wrote:
|
|
|
|
Michael
Anthony I don't know about Splashtop's resource requirements, but I haven't had an issue with any of the software running on it. I also run Box on the laptop - I save each image in a directory that Box will sync which allows me to pull the files onto my home computer without worrying about transfers, etc. Never had a problem doing that (I've also used Dropbox, but have found that the Dropbox software gets a little wonky from time to time with Windows 10) and I never worry about having to remember to move files. Mike
|
|
|
|
kentdegroff@...
Except for the paid version, TeamViewer 11 and above have a periodic disconnect built into them on purpose. I use TV 10 and don't have that problem; went back from 11 after having the problem and finding that out. I find it is faster than RealVNC.
Regards, Kent
|
|
|
|
Stuart Heggie <stuart.j.heggie@...>
Kent, not doubting you but at least in my case, all versions of TV have had the periodic disconnect for me and my use. Stuart
On Wed, May 4, 2016 at 9:54 PM, kentdegroff@... [ap-gto] <ap-gto@...> wrote:
--
Stuart Heggie
|
|
|
|
Lance McCartney <macshome@...>
Kent, how did you go back to version 10?
Thanks,
Lance
From: mailto:ap-gto@...
Sent: Wednesday, May 04, 2016 6:54 PM
To: ap-gto@...
Subject: [ap-gto] Re: OFF TOPIC - remote PC & TeamViewer Home
Use version - Times out Except for the paid version, TeamViewer 11 and above have a periodic
disconnect built into them on purpose. I use TV 10 and don't have that problem;
went back from 11 after having the problem and finding that out. I find it is
faster than RealVNC.
|
|
|
|
Joe Zeglinski
Kent,
Before posting this thread about the TC-11 timeout, I
went back to TV –10 and TV-9, and all three (free) versions have the same
“random” timeout. By any chance was your TV-10 a “paid” Commercial version,
which of course, doesn’t have the timer set for 3 hours? Seems Stuart and I are
seeing the same problem – as are very many others on the web, if you Google
“TeamViewer disconnects”
Yesterday, in pursuing this issue with TeamViewer’s Tech
Support, they suggested trying to UNCHECK the option in “Advanced Network
Settings ... Use UDP (Recommended)” in the Extras-Options-Advanced. Well, the
first run timed out in the first few minutes. But, the second session, continued
to run for hours. After the 3-hour (free) time limit had passed, I decided to
move the optional Timeout slider from 8 hours (max), back down to “OFF”
(No timeout) ... and the strange thing is that it was still running just fine
after 10.5 hours – when I finally decided to stop the session, as it was then
obvious that it was going to run forever. Somehow the “non-UDP network” option,
seemed to confuse TV-11 to ignore the built-in kill switch , for Home users.
That, at first, seemed like an enticing bonus for not using UDP, so I will
continue with it, as it gives fewer random session disconnects. Hopefully
TeamViewer will eventually discover the cause, after so many versions of their
software.
Then I switched to another host laptop, expecting this
was perhaps a quirk using Win-XP on the host laptop, but the same
thing happened on a Win-10 host laptop – Session aborted after a few minutes,
and the rerun session bombed out after 1 hour 52 minutes, far short of the
built-in 3-hour limit.
My tests are currently indoors, with the option set to
“Accept LAN” connections – so there is no chance of ISP modem blips or internet
traffic jams. However, I suspect TV still uses its internet link – perhaps for
monitoring, even as it is running a session with the in-house LAN, ... and the
two laptops just 10 inches apart on the table !
TeamViewer session – using any Home User version -
is unpredictable.
When it runs, its great, but when it randomly disconnects, its a royal
pain. Still, it is useful, since you can login again. I find it takes 7 to 8
minutes before it accepts a re-login ... while it says it is “Trying to
reconnect”. But, if you just CLOSE the session window, you can login again
... in just a few seconds. I find I might as well do that, since it has
“never” managed to reconnect on its own, no matter how hard it is trying. I
thought it was a Windows Security issue – not allowing it to login – but XP
didn’t have security, and as the host (scope system) PC, it too still failed the
same way.
Joe
|
|
|
|
kentdegroff@...
Hi Joe,
I must confess I have had occasional random disconnects - very occasional, though, and stuff like that happens with wireless communications from time to time anyway, but the connection is solid, overall. That's from my wireless house desktop through the router to my wireless desktop in the observatory. It's even pretty solid over the internet/laptop from 300 miles away. The biggest bummer would be if a file transfer got interrupted. Probably safer to use Filezilla if random disconnects are a concern. FYI, in my observatory, I am using Free TeamViewer Version 10.0.47484, "Use UDP" is checked, incoming LAN connections set, strangely, to "deactivated" (I just discovered). But I know it's using the LAN as it is quite fast and my ISP is horribly slow in this rural area (frequently below 1 Mbps). I'll have to check into this one. I found some interesting threads on the subject (you probably have too). Here's a couple: http://teamviewerforums.com/index.php?topic=3190.0 http://www.techsupportforum.com/forums/f10/teamviewer-1089178.html
Regards, Kent
|
|
|
|
Stuart Heggie <stuart.j.heggie@...>
Joe, Kent, ... I just wanted to report that as of now I have had a LAN connection of TV 11 running from a 32-bit W7 machine to a 32-bit XP Home machine for about 3 days without interruption. Weird. Stuart
On Thu, May 5, 2016 at 2:46 AM, 'Joseph Zeglinski' J.Zeglinski@... [ap-gto] <ap-gto@...> wrote:
--
Stuart Heggie
|
|
|
|
Joe Zeglinski
Thanks for that update, Kent.
Reading through the forums you provided link to, it is
surprising to see the range of (free) session timeouts experience 1, 2 or 3
hours. I suspect some of these are likely loss of WiFi or direct connect
router/modem signal, since TeamViewer tech support FINALLY admitted to the 3
hour limit, if all else works. I wonder if the company will finally post that on
their web, or in the next version update.
By any chance is your observatory (host) PC running
Win-XP?
I found I can get pretty much undisrupted connection to
my XP laptop (using any Windows client OS) – with the Session Timeout option,
set to OFF - compared to the random disconnects when talking to my two
Win-10 and the Win-7 Pro systems as hosts, all PC’s in the very same room. That
imbedded (non-disclosed) 3-hour limit kill switch doesn’t seem to trigger in XP
hosted PC’s. Win-XP wasn’t encumbered by all the later Microsoft security
routines, so TV runs far simpler as a host at the telescope.
Also, Win-XP only used IPv4 to handle communications.
Win-7 (and later), automatically re-links all existing IPv4 calls (during
boot), to the new IPv6 module, which I suspect may account for some of the
“premature” disconnects on weak WiFi and direct connect router signals. I have
run a couple of XP hosted sessions, for well over 10 hours each, and 3
hours at most, on Win-7 and later host side TeamViewer systems. I wonder if IPv6
sensitivity to signal dips has been responsible for cases when it started and
aborted a session lasting only a few seconds, in a string of a dozen sequential
restarts, before it finally stayed connected for a while.
As for your setting the option for option -
“Incoming LAN” ... Deactivate” – that is indeed odd, though from what I have
seen, now in weeks of daylong tests, it is not unexpected. TeamViewer (any
version) isn’t consistent and sometimes looks like it ignores its own User
settings. Some settings, based on comments in the log, can’t actually be
activated, depending if it is running on Win-XP, versus the later Windows
systems with their security lockouts.
Click on the TV Log files option in EXTRAS, and
read through the list of sessions in TeamViewer-11_log.txt (requires to be run
only with Notepad). You will see lots of system calls, possibly to mostly its
own command modules, which fail or produce errors. The date/time tag in that
file is your “Local Time”.
Also, have a look at the file “Connections_incoming.txt”
– also on the host TeamViewer – to see the start and stop times recorded at the
end of each session. Note that the date stamp is in Universal Time (not local
time, as in the former log file), which makes comparing events to sessions
confusing.
Finally, I repeat, do NOT wait for TV to actually
reconnect, after aborting a session – probably more so in Win-7 and later TV
host-side, systems. I don’t think the security features in later Windows, permit
it to do that, so it wastes time and your patience. Just click the red-X and
close the session Window, even as TV is saying it is “Trying to reconnect” –
that’s Bogus ... and it will take 8 minutes before it finally hangs. Closing the
session window right away and clicking on the TV start icon, only takes a blink
of the eye to resume without loss of the former host screen.
From the troubles I have seen, it almost seems like
TeamViewer is simply written as a huge JAVA Script, rather than a well
programmed compiler or even assembler based program.
Joe
|
|
|
|
Joe Zeglinski
Stuart,
Just as I suspected – XP on the telescope side, as host,
will run as long as there is a decent signal, no Timeout.
As a further test, try what I did. Reverse the
TeamViewer roles – go to the observatory “Win-XP” computer, and log into
the Win-7 or 10 PC in the house which then becomes the TV host. I suspect
your XP (or any other Win O/S as client), will timeout at the 3 hour mark, or
sooner if the IPv6 comms. driver doesn’t like signal quality. The
house Win-7/10 system will continue running, oblivious of the disconnect, other
than a note in Connections_incoming.txt (on the host side’s TeamViewer) log
file.
Bottom line, it seems that only TeamViewer XP-based
“hosts” will not time out.
Joe
|
|
|