Download

Streamer disconnected: 1006 (Pixel Streaming)

I’m testing Pixel Streaming using my pc as server.
It worked fine at first time. Next day, cirrus log started displaying this message suddenly.

Streamer disconnected: 1006
Streamer connected
Streamer disconnected: 1006
Streamer connected
Streamer disconnected: 1006
Streamer connected

I didn’t change anything.

Why isn’t there a forum section to talk about Pixel Streaming? I am only a 3D modeler. I have no idea of networks, IPs, ports, cloud servers… I can not react when an error message appears related to those areas. I am managing to stream after many weeks looking for information (practical cases) beyond from Epic docs.

I also observed when it worked the first time, that my friends were connecting from their phones with no problem, but when any one connected with “huawei” phone, SignallizingServer stopped working. We repeat the test with those models a few times. No problems with the rest of the smartphones.

Here you can see the log when it’s happens:

18:29:49.863 <- player 101: iceCandidate
18:29:49.933 <- Streamer: {“type”:“disconnectPlayer”,“playerId”:101,“reason”:“Failed to set remote offer sdp: Failed to set remote video description send parameters.”}
C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer
ode_modules\ws\lib\sender.js:108
throw new TypeError(‘First argument must be a valid error code number’);
^

TypeError: First argument must be a valid error code number
at Sender.close (C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer
ode_modules\ws\lib\sender.js:108:13)
at WebSocket.close (C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer
ode_modules\ws\lib\websocket.js:228:18)
at WebSocket.onStreamerMessage (C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer\cirrus.js:295:14)
at WebSocket.emit (events.js:311:20)
at Receiver.receiverOnMessage (C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer
ode_modules\ws\lib\websocket.js:800:20)
at Receiver.emit (events.js:311:20)
at Receiver.dataMessage (C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer
ode_modules\ws\lib\receiver.js:422:14)
at Receiver.getData (C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer
ode_modules\ws\lib\receiver.js:352:17)
at Receiver.startLoop (C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer
ode_modules\ws\lib\receiver.js:138:22)
at Receiver._write (C:\Users\DANZZA\Desktop\streaming\WindowsNoEditor\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer
ode_modules\ws\lib\receiver.js:74:10)
Press a key to continue . . .

Thank you.

I got the same issue, when I reconnect through firefox after about one hour, I got the message below:
15:45:04.046 <- player 102: iceCandidate
streamer disconnected: 1006 -
15:45:22.950 player 102 connection closed: 1005 -

Can someone help me with the issue?

Same error here… no solution yet. Seems to happen inconsistently, but mostly when logging in with a second device.

So, when using the SignallingServer from UE4.25 I figured out that it doesn’t crash anymore. Still gives the message:

but without resulting in the closing of the SignallingServer with the second half of the message:

Same issue, same error on 4.24, been successfully using PixelStreaming on Azure with 4.22 builds, and could connect dozens of devices without any crashes for days. Now, with 4.24 it works one time only, meaning whenever same device connects again, or different device connects as a second connection, powershell script throws errors mentioned above, and you have to re-run the turn bat.

I’m gonna try with 4.25 and report back.

Ninja Edit:

It seems that apart from more streamlined approach to setting up whole server/webrtc logic, user disconnection has also been changed or rather overhauled. Cirrus.js file is no where the same as pre 4.24, and since I cannot tell exactly what’s happening in there (lack of js experience), I’m stuck. Still trying 4.25 on my TODO list.

Double post to bump up this issue.

Done 4.25 p7 build and same problem occurs with not connecting users, although cmd doesn’t crash anymore it is still unable to connect users after few connection attempts.

I have the same problem. It does not work at all on mobile devices, it crashes when a second device is connected. An urgent solution is needed, or at least a temporary one!

That is correct. Apparently changes to the plugin made in 4.24 have made Pixel Streaming unreliable. What I managed to observe was that randomly either npm and/or app running offscreen crashed, although logs does not show any critical/crash errors, just logs that it closes the application since a function to close the app been called (why though, no idea).

All above refer to 4.25 p7, since on 4.24 npm crashes and prompts to close the window, with 4.25 server is running even though it somewhat crashed, so you can still access player.html by going to public ip setup for pixel streaming.

To me it seems like there’s something weird happening under the hood as far as pixel streaming plugin goes. The whole cirrus.js/*.bat files setup and config is only streamlined to a point where you need to run one *.bat and an app shortcut versus four *.bats and a shortcut in 4.23 and lower.

Crashes were finished with 4.25 version. But there are many mobile models that still cannot access. I think it may be cause for net protocols.

can you tell me how to resolve it ,thank you

Hey all, for me the streamer just randomly disconnects after few minutes. The app is still running without error. It seems like it just stops communicating after a certain amount of time.
Could it be a timeout? Anyone know if we can reconnect to cirrus through blueprints or something?

Hi, I have the same Problem with UE 4.26. Any news how to fix it?
Thanks in advance, solarisx

It seems it depends on the browser and its version. In my case it only works with Chrome 88.0.4324. With Chrome 89 it crashes with “…player connection closed”! Other browsers like the current Firefox or edge do not work too.

Greets solarisx

The same issue on 4.26.1. The following is the log and error report.

17:36:22.764 Streamer connected: ::1
17:37:22.799 <- Streamer: {“type”:“ping”,“time”:1615973842}
17:38:22.801 <- Streamer: {“type”:“ping”,“time”:1615973902}
17:39:22.802 <- Streamer: {“type”:“ping”,“time”:1615973962}
17:40:22.826 <- Streamer: {“type”:“ping”,“time”:1615974022}
17:41:22.828 <- Streamer: {“type”:“ping”,“time”:1615974082}
17:42:22.792 <- Streamer: {“type”:“ping”,“time”:1615974142}
17:43:22.797 <- Streamer: {“type”:“ping”,“time”:1615974202}
17:44:22.821 <- Streamer: {“type”:“ping”,“time”:1615974262}
17:44:37.095 player 102 (::1) connected
17:44:37.110 <- player 102: {“type”:“offer”,“sdp”:"v=0
o=- 8238381644098549600 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 2
a=extmap-allow-mixed
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:eBfY
a=ice-pwd:Bm35wzUQkZoZQAgJXyvIDSbp
a=ice-options:trickle
a=fingerprint:sha-256 EA:00:ED:68:6B:3A:A8:CD:D1:09:C8:A5:74:E3:9B:65:6B:7F:CA:9F:66:3A:2B:55:33:64:EB:4F:BA:B3:74:06
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 122 102 121 127 120 125 107 108 109 124 119 123 118 114 115 116 35
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:eBfY
a=ice-pwd:Bm35wzUQkZoZQAgJXyvIDSbp
a=ice-options:trickle
a=fingerprint:sha-256 EA:00:ED:68:6B:3A:A8:CD:D1:09:C8:A5:74:E3:9B:65:6B:7F:CA:9F:66:3A:2B:55:33:64:EB:4F:BA:B3:74:06
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:122 VP9/90000
a=rtcp-fb:122 goog-remb
a=rtcp-fb:122 transport-cc
a=rtcp-fb:122 ccm fir
a=rtcp-fb:122 nack
a=rtcp-fb:122 nack pli
a=fmtp:122 profile-id=1
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f;x-google-start-bitrate=10000;x-google-max-bitrate=20000
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=102
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f;x-google-start-bitrate=10000;x-google-max-bitrate=20000
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f;x-google-start-bitrate=10000;x-google-max-bitrate=20000
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f;x-google-start-bitrate=10000;x-google-max-bitrate=20000
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f;x-google-start-bitrate=10000;x-google-max-bitrate=20000
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=124
a=rtpmap:123 H264/90000
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f;x-google-start-bitrate=10000;x-google-max-bitrate=20000
a=rtpmap:118 rtx/90000
a=fmtp:118 apt=123
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 ulpfec/90000
a=rtpmap:35 flexfec-03/90000
a=rtcp-fb:35 goog-remb
a=rtcp-fb:35 transport-cc
a=fmtp:35 repair-window=10000000
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:eBfY
a=ice-pwd:Bm35wzUQkZoZQAgJXyvIDSbp
a=ice-options:trickle
a=fingerprint:sha-256 EA:00:ED:68:6B:3A:A8:CD:D1:09:C8:A5:74:E3:9B:65:6B:7F:CA:9F:66:3A:2B:55:33:64:EB:4F:BA:B3:74:06
a=setup:actpass
a=mid:2
a=sctp-port:5000
a=max-message-size:262144
"}
17:44:37.111 <- player 102: offer
17:44:37.117 <- player 102: {“type”:“iceCandidate”,“candidate”:{“candidate”:“candidate:1170922303 1 udp 2113937151 84e4deaf-9ef8-42a5-be9b-482eece194b7.local 50450 typ host generation 0 ufrag eBfY network-cost 999”,“sdpMid”:“0”,“sdpMLineIndex”:0}}
17:44:37.118 <- player 102: iceCandidate
17:44:37.119 <- player 102: {“type”:“iceCandidate”,“candidate”:{“candidate”:“candidate:1170922303 1 udp 2113937151 84e4deaf-9ef8-42a5-be9b-482eece194b7.local 50452 typ host generation 0 ufrag eBfY network-cost 999”,“sdpMid”:“1”,“sdpMLineIndex”:1}}
17:44:37.119 <- player 102: iceCandidate
17:44:37.119 <- player 102: {“type”:“iceCandidate”,“candidate”:{“candidate”:“candidate:1170922303 1 udp 2113937151 84e4deaf-9ef8-42a5-be9b-482eece194b7.local 50454 typ host generation 0 ufrag eBfY network-cost 999”,“sdpMid”:“2”,“sdpMLineIndex”:2}}
17:44:37.120 <- player 102: iceCandidate
streamer disconnected: 4000 - Failed to parse answer’s SDP
v=0
o=- 8238381644098549600 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 2
a=extmap-al
17:44:37.198 player 102 connection closed: 1005 -

================================

Assertion failed: Player [File:D:/Build/++UE4/Sync/Engine/Plugins/Media/PixelStreaming/Source/PixelStreaming/Private/Streamer.cpp] [Line: 173] player 102 not found

UE4Editor_Core
UE4Editor_Core
UE4Editor_PixelStreaming
UE4Editor_PixelStreaming
UE4Editor_PixelStreaming
UE4Editor_PixelStreaming
UE4Editor_PixelStreaming
UE4Editor_WebSockets
UE4Editor_WebSockets
UE4Editor_Core
UE4Editor_Core
UE4Editor_Core
UE4Editor_Core
UE4Editor
UE4Editor
UE4Editor
UE4Editor
UE4Editor
kernel32
ntdll

I’m hit by the same issue.

it used to work for me, however after upgrading to 4.26, I started to see this problem

I finally found a solution to my problem in Chinese though

link UE4.23/4.26像素流插件PixelStreaming使用Chrome访问时的Crash问题 - 知乎

translation:

add this line

this.cfg.offerExtmapAllowMixed = false;

to line 61 of …\Engine\Source\Programs\PixelStreaming\WebServers\SignallingWebServer\scripts

webRtcPlayer.js

this.video = createWebRtcVideo();

this.cfg.offerExtmapAllowMixed = false;

onsignalingstatechange = function(state) {
console.info(‘signaling state change:’, state)
};

https://www.chromestatus.com/feature/6269234631933952

Thanks!

This fixed the issue in Chrome

This works perfectly in Chrome. You’re awesome @StewieYan