No Active - No Connected about vscode-deck HOT 17 CLOSED

I figured that considering that when Elgato Stream Deck automatically updates the VSCode extension; the settings.ini file is missing and needs to be recreated on macos that the websocket server accordingly is not starting up with the correct host/port settings. As such, I restarted Stream Deck app and then I see the following in the Debug Output:

[6/8/2020, 2:05:58 AM] Message received, ActiveSessionChangedMessage.: {"id":"ActiveSessionChangedMessage","data":"{\"sessionId\":\"e5564f1a-003f-41bf-be74-0b4ee7a72b871591594958666\"}"}

However, when I press a button, it reverts back to the dysfunctional state I am complaining about in this issue :)

Concerning the matter that on macos the settings.ini file is missing, I would guess that is on account of the directory to be incorrect:

~/Library/Application Support/com.elgato.StreamDeck/Plugins/com.nicollasr.streamdeckvsc.mac.sdPlugin/settings.ini

There is no space between the words ApplicationSupport, thus the correct directory is rather:
~/Library/ApplicationSupport/com.elgato.StreamDeck/Plugins/com.nicollasr.streamdeckvsc.mac.sdPlugin

I assume that this is something that you most likely copy pasted from the official website.
Is it possible that you have hardcoded the directory accordingly in the VSCode Plugin and thus it is trying to write the settings.ini file to a non existing directory? I am taking a random guess here as I was not able to find anything hardcoded like that in the other repo. Also, you have hardcoded the default settings: https://github.com/nicollasricas/streamdeckvsc/blob/master/StreamDeckVSC/Configuration.cs so why would there be a need for settings.ini with those same default settings?

from vscode-deck.

I figured that considering that when Elgato Stream Deck automatically updates the VSCode extension; the settings.ini file is missing and needs to be recreated on macos that the websocket server accordingly is not starting up with the correct host/port settings. As such, I restarted Stream Deck app and then I see the following in the Debug Output:

I notice this today when testing a connection with WSL in Linux. Elgato update process deletes the whole folder before extracting the files from the .streamdeckPlugin file which is just a zip file.

In a case where the host or port was changed, the update process will mess with the settings.

However, in your case, It should use the default settings even when the file doesn't exist.

Could you rename the settings.ini, restart the Stream Deck Software and send me the pluginlog.log?

~/Library/ApplicationSupport/com.elgato.StreamDeck/Plugins/com.nicollasr.streamdeckvsc.mac.sdPlugin/pluginlog.log

There's a line on this file that shows the location from the message server.

2020-06-08 07:46:57.1764|INFO|BarRaider.SdTools.Logger|Starting server ws://127.0.0.1:48969

from vscode-deck.

I renamed the file, restarted the Elgato service and in VSCode it shows Deck | Connected | Active. I proceed to press a button on the device and it changes to: Deck | Connecting indicating it disconnected.
This is the contents of the log file as you requested:

2020-06-08 20:20:15.5790|DEBUG|BarRaider.SdTools.Logger|Logger Initialized
2020-06-08 20:20:15.6298|INFO|BarRaider.SdTools.Logger|Starting server ws://127.0.0.1:48969
2020-06-08 20:20:15.6761|INFO|BarRaider.SdTools.Logger|Plugin Loading - 6 Actions Found
2020-06-08 20:20:16.0387|INFO|BarRaider.SdTools.Logger|Plugin version: 5.1.2
2020-06-08 20:20:16.0387|INFO|BarRaider.SdTools.Logger|Connecting to Stream Deck
2020-06-08 20:20:16.0726|INFO|BarRaider.SdTools.Logger|Connected to Stream Deck
2020-06-08 20:20:16.0731|INFO|BarRaider.SdTools.Logger|GlobalSettingsManager initialized
2020-06-08 20:20:31.8350|INFO|BarRaider.SdTools.Logger|{"id":"ChangeActiveSessionMessage","data":"{\"sessionId\":\"e5564f1a-003f-41bf-be74-0b4ee7a72b871591594958666\"}"}
2020-06-08 20:20:31.9424|INFO|BarRaider.SdTools.Logger|{"id":"ChangeActiveSessionMessage","data":"{\"sessionId\":\"e5564f1a-003f-41bf-be74-0b4ee7a72b871591594958666\"}"}
2020-06-08 20:20:36.5423|INFO|BarRaider.SdTools.Logger|{"id":"ChangeActiveSessionMessage","data":"{\"sessionId\":\"e5564f1a-003f-41bf-be74-0b4ee7a72b871591594958666\"}"}
2020-06-08 20:20:51.8407|INFO|BarRaider.SdTools.Logger|{"id":"ChangeActiveSessionMessage","data":"{\"sessionId\":\"e5564f1a-003f-41bf-be74-0b4ee7a72b871591594958666\"}"}
2020-06-08 20:20:53.0670|INFO|BarRaider.SdTools.Logger|Disconnect event received
2020-06-08 20:20:53.0676|INFO|BarRaider.SdTools.Logger|Plugin Disconnected - Exiting

It confirms that the standard settings are used:
2020-06-08 20:20:15.6298|INFO|BarRaider.SdTools.Logger|Starting server ws://127.0.0.1:48969

from vscode-deck.

Please try with this update and let me know if it's working.

I noticed that you are using an insider version, could you send the info showed at Help->About in VS Code?

vscode-streamdeck-4.1.5.zip

from vscode-deck.

These are the settings for insider edition:

After manually installing from vix, VSCode shows Deck | Connected only. When I click on it, it does not change status to Active. When I restart Stream Deck, VSCode again only shows Deck | Connected. When I press a button it loses connection stating: Deck | Connecting

The log shows:

2020-06-08 22:46:02.6206|DEBUG|BarRaider.SdTools.Logger|Logger Initialized
2020-06-08 22:46:02.6702|INFO|BarRaider.SdTools.Logger|Starting server ws://127.0.0.1:48969
2020-06-08 22:46:02.7114|INFO|BarRaider.SdTools.Logger|Plugin Loading - 6 Actions Found
2020-06-08 22:46:03.0730|INFO|BarRaider.SdTools.Logger|Plugin version: 5.1.2
2020-06-08 22:46:03.0730|INFO|BarRaider.SdTools.Logger|Connecting to Stream Deck
2020-06-08 22:46:03.1249|INFO|BarRaider.SdTools.Logger|Connected to Stream Deck
2020-06-08 22:46:03.1249|INFO|BarRaider.SdTools.Logger|GlobalSettingsManager initialized
2020-06-08 22:46:08.9204|INFO|BarRaider.SdTools.Logger|{"id":"ChangeActiveSessionMessage","data":"{\"sessionId\":\"2a4342ed-42df-430f-80f1-23aa30e539ba1591670715435\"}"}
2020-06-08 22:46:19.6299|INFO|BarRaider.SdTools.Logger|Disconnect event received
2020-06-08 22:46:19.6304|INFO|BarRaider.SdTools.Logger|Plugin Disconnected - Exiting

When I check in Debug Output this time something more tangible shows up:

[ERROR] Error: connect ECONNREFUSED 127.0.0.1:48969
[6/8/2020, 10:49:46 PM] Disconnected from Stream Deck.
[6/8/2020, 10:49:46 PM] Connecting to Stream Deck
[ERROR] Error: connect ECONNREFUSED 127.0.0.1:48969
[6/8/2020, 10:49:46 PM] Disconnected from Stream Deck.
[6/8/2020, 10:49:46 PM] Connecting to Stream Deck
[ERROR] Error: connect ECONNREFUSED 127.0.0.1:48969
[6/8/2020, 10:49:46 PM] Disconnected from Stream Deck.
[6/8/2020, 10:49:46 PM] Connecting to Stream Deck
[ERROR] Error: connect ECONNREFUSED 127.0.0.1:48969
[6/8/2020, 10:49:46 PM] Disconnected from Stream Deck.
[6/8/2020, 10:49:46 PM] Connecting to Stream Deck

ECONNREFUSED would indicate to me it is trying to start a websocket server on a port that is already assigned. I am kinda puzzled how it would be possible for this to occur when I have restarted both VSCode as well as Stream Deck. Is it possible that multiple windows are trying to start up the server at the same time?

I then proceeded doing:

~/Library/ApplicationSupport/com.elgato.StreamDeck/Plugins/com.nicollasr.streamdeckvsc.mac.sdPlugin$ lsof -nP -iTCP:$PORT
COMMAND     PID         USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
Code\x20- 44829 ...   39u  IPv4 0x99f374003132bc43      0t0  TCP 127.0.0.1:63746->127.0.0.1:48969 (SYN_SENT)
Code\x20- 44830 ...   42u  IPv4 0x99f374002f74b9e3      0t0  TCP 127.0.0.1:63745->127.0.0.1:48969 (SYN_SENT)
Code\x20- 44831 ...   41u  IPv4 0x99f374002f894163      0t0  TCP 127.0.0.1:63747->127.0.0.1:48969 (SYN_SENT)

The meaning of SYN_SENT is that of:

a normal client TCP socket state that is entered after a client issues a connect to a server socket. If acknowledged by the server, the client socket state will proceed to ESTABLISHED

from vscode-deck.

ECONNREFUSED would indicate to me it is trying to start a websocket server on a port that is already assigned. I am kinda puzzled how it would be possible for this to occur when I have restarted both VSCode as well as Stream Deck. Is it possible that multiple windows are trying to start up the server at the same time?

The only way I can imagine that this would happen is when you close the stream deck, it doesn't kill the plugin process leaving opened connection.

Could you try to change the port? I will install the insider version tomorrow in my VM and run the test script.

Although the connection from the client (vs code) to the server (stream deck) wasn't possible, the plugin started with no errors.

Try to update the plugin on stream deck. I forced some initialization logs from the plugin host.

https://1drv.ms/u/s!Agq8DfGl4Hpxil_I8Bxbk_dbCUpY

from vscode-deck.

I tried changing the port and I tried the custom plugin for Stream Deck you shared in the last comment to no avail. The behaviour as reported above remains in both cases.

When I restart stream deck, I can confirm that the websocket server comes online, ready to listen for client connections:

$ lsof -nP -iTCP:$PORT
COMMAND     PID         USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
Code\x20- 64410 ...   40u  IPv4 0x99f374002fc62da3      0t0  TCP 127.0.0.1:51465->127.0.0.1:48969 (ESTABLISHED)
com.nicol 65183 ...   72u  IPv4 0x99f374003137c623      0t0  TCP 127.0.0.1:48969 (LISTEN)
com.nicol 65183 ...  128u  IPv4 0x99f37400313f7623      0t0  TCP 127.0.0.1:48969->127.0.0.1:51465 (ESTABLISHED)

There is one client with PID: 64410(Code\x20) and one running websocket server with PID 65183 (com.nicol)

Doing a simple curl command like below confirms that the websocket server is listening on the default port:

$ curl 127.0.0.1:48969
curl: (52) Empty reply from server

When I press a button on the Stream Deck; the server crashes.
Only the client remains as can be seen below:

$ lsof -nP -iTCP:$PORT
COMMAND     PID         USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
Code\x20- 64410 ...   40u  IPv4 0x99f374002f8549e3      0t0  TCP 127.0.0.1:52254->127.0.0.1:48969 (SYN_SENT)

Trying to communicate with the websocket server manually now results in:

$ curl 127.0.0.1:48969
curl: (7) Failed to connect to 127.0.0.1 port 48969: Connection refused

So the state of ECONNREFUSED in this context means that the websocket server is no longer running because it crashed somehow; which is exactly what the error message was saying:

ERROR] WebSocket is not open: readyState 0 (CONNECTING), Stack: Error: WebSocket is not open: readyState 0 (CONNECTING)

To clarify the behaviour; this only occurs when I press the folder in which resides VSCode relate buttons. It seems that merely loading them causes the server to crash.

from vscode-deck.

Which stream deck action are you trying? Execute command? Terminal command?

from vscode-deck.

Which stream deck action are you trying? Execute command? Terminal command?

None of them.
Inside Stream Deck, I have a dedicated folder for VSCode in which resides all the various actions that I use.
Merely pressing that folder button makes it crash. I am not able to use any specific action.

from vscode-deck.

Try adding a new terminal command action with any text as command outside that folder in Stream Deck home page and press it.

from vscode-deck.

Try adding a new terminal command action with any text as command outside that folder in Stream Deck home page and press it.

I tried doing so but consistent with the above the server crashes when that button is loaded. I do not even have the chance to press it.
I also tried to localize the problem to a specific action; to see if it is only one specific command that trips up the server or if it is all of them. After three different actions(Execute Terminal Command, Execute Command and Open Folder) crashing the server I conclude that the problem extends to all of them.

Extra clarification: In addition to having that button being present outside the folder, I also created a dummy folder in which I created one button. When I restart Stream Deck, all is fine. The server is listening on the default port. The moment I press that dummy folder, the server crashes. In addition to that, I also tested this with VSCode(the IDE) turned off. The same applies.
This should provide enough of a baseline to establish that your plugin websocket server crashes on the mere loading of any of the Visual Studio Code plugin related buttons on Stream Deck.

Question: Is there anything special that gets done when these buttons are loaded? Is it possible to introduce a dummy button that does absolutely nothing?

from vscode-deck.

To create this plugin I've been using the streamdeck-tools which handle all communication between stream deck, property inspector and the plugin.

There are two web servers one from the Stream Deck and one from my plugin. The plugin message server does nothing until you press an action, so if it is crashing when you open the folder it should be a communication problem between the Stream Deck and the "streamdeck-tools" or in the property inspector.

In the last update, I updated the dependencies to create a new feature that I'm working on, your issue came after that.

Try with this version:
https://1drv.ms/u/s!Agq8DfGl4HpximAKcC6a2ZWhkgoY

If still not working follow this procedure to enable debugging.
https://developer.elgato.com/documentation/stream-deck/sdk/create-your-own-plugin/#debugging

After you run the terminal command and open the debug URL you should see a list of inspectable pages, inspect them before opening the folder.

Thank you for helping out with this issue as I mentioned before I do have a coverage script running on Windows and Linux, but my macOS VM doesn't boot anymore and since I don't own one your help is very appreciated.

from vscode-deck.

Thank you for helping out with this issue as I mentioned before I do have a coverage script running on Windows and Linux, but my macOS VM doesn't boot anymore and since I don't own one your help is very appreciated.

I would not mind testing new releases on my local before you push them out.

Try with this version:

I tried the old version and it is working as before. Server is no longer crashing.

from vscode-deck.

Whenever you have time could you enable the debugging and inspect the pages? I will report the error to the BarRaider author of the https://github.com/BarRaider/streamdeck-tools.

from vscode-deck.

Whenever you have time could you enable the debugging and inspect the pages? I will report the error to the BarRaider author of the https://github.com/BarRaider/streamdeck-tools.

I will try to do soon.

from vscode-deck.

I'm also seeing this same 'connecting error' in vscode on mac osx. Built a workaround by changing to the hotkey action and shortcuts for the time being which works ok for key needs (mostly running tests!)

If I can help with additional debug logs or anything let me know (I'm not super strong on VScode stuff, but happy to assist if I can!)

from vscode-deck.

Update sent to Elgato wait or download manually here.

from vscode-deck.