KMoney00

For any others who encounter the issue of camera/mic options greyed out on Chrome when accessing via local IP address (e.g. 192.168.1.XXX:8000) , I found this page that cleared it up for me. Essentially, it's a default behavior of Chrome to disallow camera/mic to any non-https site except specifically 'localhost'. So, I had to whitelist my server's ip address (port included) to get it to behave as we'd expect. https://medium.com/@Carmichaelize/enabling-the-microphone-camera-in-chrome-for-local-unsecure-origins-9c90c3149339 Also, just to add my 2 cents to the mix, I got Jitsi working thanks to SpaceInvader's awesome guide (Thank you!) and it seems to be working as advertised. Ports forwarded: 80 to LetsEncrypt (Already had LetsEncrypt setup also based on SpaceInvader's guide.) 443 to LetsEncrypt (Already had LetsEncrypt setup also based on SpaceInvader's guide.) 10000/UDP to Unraid IP Some observations of what I encountered that may/may not help others during their own troubleshooting: Chrome really likes to cache web pages so it's a PITA trying to get it to realize I changed something and that it should really, REALLY reload the page. I ended up using multiple browsers, devices, and a lot of patience to deal with that. Before I had realized I needed to forward 10000/UDP, I was able to connect to Jitsi both locally and via the subdomain using my local PC, but it was even odds if it asked me for auth to create a room or if it just let me do it. During this period, though, I could also connect to Jitsi using the app on my phone (using cellular, not wifi) via the subdomain but was unable to join or create any rooms (network reconnecting error or infinite circle of loading). Fixing the 10000/UDP fixed both issues for me. Once it was all set up and working, to test it I connected via my pc, then connected via my phone app over cellular, and it worked great. However, changing nothing except moving the phone to wifi made the phone unable to join the meeting. I suspect some kind of collision with two different instances of jitsi from the same network vying for the same port/resource but wiser folks than me would probably know. Doesn't really impact my use-case though so it's just notable if you're using this type of setup for troubleshooting. It seemed to take a few restarts of Jitsi and LetsEncrypt before everything started to play nicely. I suspect there's an appropriate order they should start in so that updates are flowed down the daisy chain and it just took a few cycles for those to populate, but this is just a gut feel. Jitsi seems a bit...fragile? Particularly when using its screensharing (couldn't get youtube sharing to work at all but that's a total non-issue). It shares perfectly fine, but when disengaging the share it would more often than not cause some type of graphical issue (e.g. full black screen, window all black but hover still shows buttons exist, tessellated triangles of white all over the screen in a fractal pattern) unless I was a little careful about how I went about it (e.g. no quick successive actions. Just single, deliberate, measured clicks). I could get back on track by closing that window of chrome, going to my history, re-opening the recently closed window, and it put me right back into the meeting good-as-new. So it was annoying but survivable.

Thanks for updating! It seems the version wasn't the root cause though as the problem still persists

With MQTT I've been getting intermittent disconnects the past few days with the below error. It's causing most of my home automation to fail since it's not getting my location updated. From Googling I see some references to this being related to version 1.4.8 but that's quite a bit out of my wheelhouse so I can't be sure. 1491447158: Socket error on client topic/myphone, disconnecting.