mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #212] OSX as client Error #172
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#172
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @BananaAcid on GitHub (Dec 28, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/212
Operating Systems
Server: Win 10
Client: OSX 10.13.6
Error in Log:
.. it will not connect as a client. But works as a server.
Barrier Version
2.1.0
@wilsonic commented on GitHub (Jan 13, 2019):
I'm having the same issue.
@AdrianKoshka commented on GitHub (Jan 14, 2019):
Did you open the port on the windows firewall?
I'm going to assume you've added Barrier in the windows firewall.
@BananaAcid commented on GitHub (Jan 16, 2019):
Sure, Firewall was turned of completely for testing.
As the error states, it is an error stating you should not use a background thread: ' ... is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!'
The error happens, regardless of the Server OS used.
This might be of help: https://indiestack.com/2018/08/let-it-rip/
@k4lim commented on GitHub (Feb 21, 2019):
I got the same problem.
macOS v10.14.3 as client
Windows 10 as server
Windows log when I'm trying to use OSX as server:
@einSelbst commented on GitHub (Feb 25, 2019):
Just want to add, I also have barrier running on MacOS (10.13.6 as server, 10.14.3 as client, I think it also works the other way around) and it's running fine. However, I do see the logs mentioned above:
So I think the TIS/TSM issue is a general issue and not related to Barrier not working correctly on Mac.
TWIMC people say the error might be because something like "...trying to translate key events to characters on a background thread"
https://forums.developer.apple.com/thread/105244
@earthsound commented on GitHub (Apr 22, 2019):
I was running 2.1.0 on Windows 7 (server) and MacOS 10.13.x (client) with no problems for months until a recent Windows 7 update/reboot. I started getting the same timeout error as in the OP.
Using TCPView on Windows, I saw that barrier wasn't listening on the port the client was trying to connect to.
When I updated the Windows 7 version to 2.2.0 and started barrier, the MacOS 2.1.0 client connected immediately. I didn't change the configuration, edit the firewall settings (they were already set up from a previous barrier installation), or change anything on the client side, either.
@nielmistry commented on GitHub (Apr 24, 2019):
I also get the TIM/TSM issue, and it seems to be a common Java problem. Processing also had the issue but decided to suppress warnings because it wasn't affecting anything but freaking out users: https://github.com/processing/processing/issues/5462
I'm also running MacOS as a client and Windows 10 as a server, and although I get the TIM/TSM issue the connection works fine!
@AdrianKoshka commented on GitHub (Apr 24, 2019):
There is zero java in barrier to my knowledge.
@noisyshape commented on GitHub (Apr 24, 2019):
The TIS/TSM message is a warning, not an error. Maybe the warning should be suppressed and an issue opened for it. I don't think it's relevant to this issue in any case.
@AdrianKoshka commented on GitHub (Apr 24, 2019):
Ah.
@earthsound commented on GitHub (Apr 24, 2019):
How Jalkut debugged this same error and resolved it in his app: https://indiestack.com/2018/08/let-it-rip/
@antonioaltamura commented on GitHub (May 1, 2019):
I've started to face this issue few days ago.. is there a solution?
@reancool commented on GitHub (Jul 19, 2019):
is there a solution?
@zacharycoon commented on GitHub (Aug 29, 2019):
I had the same problem as the original user. What ended up being wrong for me was that I was that I was connecting to a different network via VPN on my Mac.
Interestingly, if I start Barrier before I connect to the VPN, and then connect to my VPN, Barrier will work just fine until my computer falls asleep, then it starts having this issue above. Also, like the user above, I can use my Mac as a server even when I'm connected to my VPN.
My guess is that you may have a similar networking issue.
@sgon00 commented on GitHub (May 11, 2020):
I am meeting the same error message. But as a server. This year 2020. The bug is opened at 2018. .. I am wondering if I should open another issue...
@simons-public commented on GitHub (May 12, 2020):
@sgon00 That error message has nothing to do with connectivity. It's from TIS/TSM which is Text Input Services/Text Services manager because the barrier server or client runs as a different thread than the main GUI process.
@shymega I put in #653 which fixes this but I think it'll keep popping up in the issues until there's a new release posted. There's been a decent amount of improvements on the MacOS GUI (retina support, high-res icons, etc) there any plans for a 2.3.3 in the near future?
@sgon00 commented on GitHub (May 12, 2020):
@simons-public yeah, you're right. Thanks a lot for your reply. My situation: I started and used barrier for two days without any problems. But after wifi network changes multiple times (not sure if this is the cause), the barrier server stopped. I was unable to start barrier server. It was just starting/hanging forever. I tried to quit the app and re-launch the app, but no luck. But after I changed the log level from
ErrortoInfoand quit and re-launch the app again, it can be started successfully. I have no ideas if the log level is the cause or not. That is just weird. Maybe the cause is something else. I don't know. Because there is NO useful log to determine why it was starting and hanging there forever except this issue's error message. So I solved the issue blindly for now.@simons-public commented on GitHub (May 12, 2020):
@sgon00 No worries, glad it started working for you again. I just got a troubleshooting guide added to the wiki if the issue crops up again, maybe it will be helpful. It sounds like it could have been an orphaned process. The GUI actually starts either a
barrierc(client) orbarriers(server) process in the background and if the GUI is closed or killed the sometimes it can happen where the background process keeps running and ties up the port.@sgon00 commented on GitHub (May 12, 2020):
@simons-public Are there any other processes will block barrier to start successfully? I am a developer, so at the time it didn't work and quit the app, I did run
ps -ef | grep -i barrierto check if there are any frozen processes or not and if so, thenkill -9. But I didn't find any processes which contains the charsbarrier. So I didn't need to kill. The problem must be something else.The changes I did to barrier after installation are:
(1) change log level from 'Info' to 'Error'
(2) Porvide a path for
Log to file(3) add a new screen
(4) add two hotkeys.
So that's why I tried to change log level back to
Info, and surprisingly, that makes the server started. But it doesn't make sense that solved the problem though.@simons-public commented on GitHub (May 12, 2020):
@sgon00 I don't know of any other processes off the top of my head, but anything binding to 24800 would prevent it from working but not from starting (which hopefully will be an error instead of a warning soon #655).
Actually I just saw that the ERROR level of logging doesn't show the NOTE text
started server, which is used to trigger the GUI status, which also makes me realize I was somehow missing that part of the puzzle with what @plessbd was talking about in #516.I think the
barrierscommand needs to be changed to outputstarted serverto stdout regardless of the log level.Did you set the log level in the text of the config file? I haven't been able to find it in the GUI anywhere and I'm wondering if that was left off the GUI because of the hack there to detect the status.
@sgon00 commented on GitHub (May 12, 2020):
@simons-public I am new to barrier, so I didn't use any config files yet. I configure everything in GUI for now. Restart barrier app will continue to use my old config (it must be stored somewhere).
To configure log level in GUI at MacOS:
Top left system panel > Barrier > Change Settings, you will find Logging level and Log to file options.Last time when I met the issue, I forgot to test if the port is occupied or not. If I meet the issue next time, I will test the port status with
telnet localhost 24800.Thanks.
@simons-public commented on GitHub (May 12, 2020):
@sgon00 Thanks, I've been using barrier for years and can't believe I never noticed the logging setting there 👍.
I just made a pull request #664 if you want to see if that fixes the issue for you when logging is set to warning.
@sgon00 commented on GitHub (May 12, 2020):
@simons-public Got it, thanks a lot for all your help. 😀👍🙏
@shymega commented on GitHub (May 12, 2020):
@sgon00 Please don't open another issue - it just adds to the list, and we're aware of this bug 👍
@simons-public I'll need to discuss it with the maintainers, but I'm happy to make another release - we've had a fair few merges since the last release, so the time is "ripe"..
@hhstore commented on GitHub (Aug 8, 2020):
@all
@antonioaltamura
@reancool