Steam Link

Steam Link

packetdancer, steamlink ssh
test clearly too much text
< >
Showing 1-15 of 25 comments
1970-01-01 01:00:30 INFO - xow v0.5-26-g99100fb ©Severin v. W.
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
1970-01-01 01:00:30 INFO - Waiting for device...
linux_version_check - failed to open /proc/mv88de3010
linux_version_check - app expects linux kernel revision 6154, please manually check current revision
<<<<< CPU-1 OSAL Init
memory map size for cache:0x0C000000, fd_cache:5, ret:0
memory map size for non-cache:0x02000000, fd_noncache:4
MV_SHM_Init OK:
base_virtaddr_cache:0xAA7AB000, size:0x0C000000
base_virtaddr_noncache:0xA87AB000, size:0x02000000
DBG HEALTH {line: 280 (MV_CC_RPCClnt_Call)} 0x7
This was not a silent update
>>>> Starting the CEC manager.
>>>> /home/steam/shell.sh &
linux_version_check - failed to open /proc/mv88de3010
linux_version_check - app expects linux kernel revision 6154, please manually check current revision
<<<<< CPU-1 OSAL Init
memory map size for cache:0x0C000000, fd_cache:4, ret:0
memory map size for non-cache:0x02000000, fd_noncache:3
MV_SHM_Init OK:
base_virtaddr_cache:0xAA706000, size:0x0C000000
base_virtaddr_noncache:0xA8706000, size:0x02000000
DBG HEALTH {line: 280 (MV_CC_RPCClnt_Call)} 0x7
m_bCECIsActiveSource = false
I/validEdid: 1, cecPhyAddr: 0x2000
I/[HdmiCecEvtHandler]EventCode:59
I/MV_PE_VPP_EVENT_CEC_LOG_ADDR_STS:infoID:0, logAddrStsEvtInfo:deviceType:4, logAddrAllocSts:1, logAddr:4
I/[HdmiCecEvtHandler]EventCode:59
I/MV_PE_VPP_EVENT_CEC_MSG_TX_STS:infoID:1, txStatusEvtInfo:txMsgOpcode:84, txStatus:0
I/[HdmiCecEvtHandler]EventCode:59
I/MV_PE_VPP_EVENT_CEC_MSG_TX_STS:infoID:1, txStatusEvtInfo:txMsgOpcode:90, txStatus:0
I/[HdmiCecEvtHandler]EventCode:59
I/MV_PE_VPP_EVENT_CEC_MSG_TX_STS:infoID:1, txStatusEvtInfo:txMsgOpcode:85, txStatus:0
I/[HdmiCecEvtHandler]EventCode:59
I/MV_PE_VPP_EVENT_CEC_MSG_TX_STS:infoID:1, txStatusEvtInfo:txMsgOpcode:47, txStatus:0
CEC initialized
[ 1] mvGetDisplay: enter
linux_version_check - failed to open /proc/mv88de3010
linux_version_check - app expects linux kernel revision 6154, please manually check current revision
<<<<< CPU-1 OSAL Init
memory map size for cache:0x0C000000, fd_cache:4, ret:0
memory map size for non-cache:0x02000000, fd_noncache:3
MV_SHM_Init OK:
base_virtaddr_cache:0xA714C000, size:0x0C000000
base_virtaddr_noncache:0xA514C000, size:0x02000000
DBG HEALTH {line: 280 (MV_CC_RPCClnt_Call)} 0x7
[ 2] mvLoadOptionsFromEnv: set dbg level from 0 to 0
[ 3] mvLoadOptionsFromEnv: set default gfx plane to 0
[ 4] mvLoadOptionsFromEnv: set default disp size to [1280,720]
[ 5] mvLoadOptionsFromEnv: get option=1, set default auto scaling option to 1
[ 6] mvLoadOptionsFromEnv: set default fb number to 3
[ 7] mvInitDisplay: output resolution 26, 1920*1080
[ 8] mvEGL ch3 autoscale (0,0):1280x720 to (0,0):1920x1080
DBG HEALTH {line: 280 (MV_CC_RPCClnt_Call)} 0x7
[ 9] mvInitDisplay: creating 3 fbs, width=1280, height=720, stride = 5120
[ 10] mvInitDisplay: success to create 0 th frame buffer, surface=0x1130, size=3686400
[ 11] mvInitDisplay: success to create 1 th frame buffer, surface=0x2130, size=3686400
[ 12] mvInitDisplay: success to create 2 th frame buffer, surface=0x3130, size=3686400
[ 13] mvInitDisplay: successfully
[ 14] mvGetDisplay: successfully
[ 15] gcoOS_GetDisplayByIndex: set display 0xf87a48's multiBuffer = 3
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
Selecting audio driver: "automatic"
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
Steam Link UI coordinate scale = 1
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
Attribute Qt::AA_ShareOpenGLContexts must be set before QCoreApplication is created.
fts: record v1204 commited @ 0x00966000
Web request https://api.steampowered.com/ISteamApps/GetSDRConfig/v1?appid=353380 failed, CURL error SSL peer certificate or SSH remote key was not OK (60), HTTP error code 0
Web request https://api.steampowered.com/ISteamDirectory/GetCMListForConnect/v1/?cellid=0&cmtype=websockets failed, CURL error SSL peer certificate or SSH remote key was not OK (60), HTTP error code 0
Starting download "http://media.steampowered.com/steamlink/06_2015/public_builds.txt"
Completed download "http://media.steampowered.com/steamlink/06_2015/public_builds.txt"
Starting Streaming
Received authorization proof request, responding with encrypted challenge
Received start streaming response k_ERemoteDeviceStreamingSuccess
[ 16] mvExitDisplay enter, is_mv_shm_init=1
[ 17] mvExitDisplay: exit
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
Initializing player
[ 1] mvSetDisplayOption: set EGL_MVGFX_W*EGL_MVGFX_H from 1280*720 to 1920*1080
linux_version_check - failed to open /proc/mv88de3010
linux_version_check - app expects linux kernel revision 6154, please manually check current revision
<<<<< CPU-1 OSAL Init
memory map size for cache:0x0C000000, fd_cache:9, ret:0
memory map size for non-cache:0x02000000, fd_noncache:8
MV_SHM_Init OK:
base_virtaddr_cache:0xA9F00000, size:0x0C000000
base_virtaddr_noncache:0xA7F00000, size:0x02000000
DBG HEALTH {line: 280 (MV_CC_RPCClnt_Call)} 0x7
[ 2] mvSetDisplayOption: set EGL_MVGFX_AUTOSCALING from 1 to 1
[ 3] mvGetDisplay: enter
[ 4] mvLoadOptionsFromEnv: user will set these options, return directly
[ 5] mvInitDisplay: output resolution 26, 1920*1080
[ 6] mvEGL ch3 autoscale (0,0):1920x1080 to (0,0):1920x1080
DBG HEALTH {line: 280 (MV_CC_RPCClnt_Call)} 0x7
[ 7] mvInitDisplay: creating 3 fbs, width=1920, height=1080, stride = 7680
[ 8] mvInitDisplay: success to create 0 th frame buffer, surface=0x1131, size=8294400
[ 9] mvInitDisplay: success to create 1 th frame buffer, surface=0x2131, size=8294400
[ 10] mvInitDisplay: success to create 2 th frame buffer, surface=0x3131, size=8294400
[ 11] mvInitDisplay: successfully
[ 12] mvGetDisplay: successfully
[ 13] gcoOS_GetDisplayByIndex: set display 0xa9b688's multiBuffer = 3
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Function not implemented
Audio initialized: alsa
Video initialized: vivante
Desktop mode: 1920x1080@1x 59.94Hz
Texture rect: 1920x1080 at 0,0
Video rect: 0x0 at 0,0
Video size: 1920x1080, output size: 1920x1080, overlay size: 1280x256
Texture rect: 1920x1080 at 0,0
Video rect: 1920x1080 at 0,0
Texture rect: 1920x1080 at 0,0
Video rect: 1920x1080 at 0,0
Hardware: ARMv7 Processor rev 0 (v7l)
Initialized player
Server available at address: 192.168.2.4:27031
Connecting to server at 192.168.2.4:27031 using direct UDP
Session state Idle -> Connecting
CStreamTransportClient stopping Remote Client service connection
Video size: 1920x1080, output size: 1920x1080, overlay size: 1280x256
Texture rect: 1920x1080 at 0,0
Video rect: 1920x1080 at 0,0
Texture rect: 1920x1080 at 0,0
Video rect: 1920x1080 at 0,0
Session state Connecting -> Handshake
Session state Handshake -> Authenticating
Got control packet k_EStreamControlServerHandshake
Session state Authenticating -> Negotiating
Got control packet k_EStreamControlAuthenticationResponse
Got control packet k_EStreamControlNegotiationInit
Session state Negotiating -> StreamStarting
Got control packet k_EStreamControlNegotiationSetConfig
Session state StreamStarting -> Streaming
Got control packet k_EStreamControlSetQoS
Got control packet k_EStreamControlSetTargetBitrate
Starting audio stream: frequency=48000, channels=2
Initialized audio decoder: codec=3, sample rate=48000, channels=2
Just F.Y.I Play Audio on host, on or off no difference, changing bitrates all over the place no difference. I have been trying to fix this issue for years.
Hm. Humor me -- go to Settings -> Streaming -> Advanced Options and check if "Audio Streaming" is set to "Enabled" on that screen. If it is, change it from "Enabled" to "Uncompressed" and try again?
ok that pretty much eliminated it.

I must say that option is damn fricking hidden... and I have gone over all of them numerous times...

Never in my mind I would have thought this enabled/disabled option had one extra, esp since none of the others have it.
I am *extremely* glad that was able to fix it for you!

...but yeah, it's perhaps not the most intuitive option. :)
whomp whomp it is back starting to think its time related now.....
Well the longer the device runs the more prominent the problem gets...

So clearly rebooting the device to enable SSH was the reason it seemed gone.

Obviously I have tested the com.valvesoftware.steamlink, retropie and phone for a too short of time to ensure it is isolated to the hardware.

I shall run a long time test with retropie and the flatpak to ensure it is not global.
Originally posted by AUTHPLAYERLOGINSTATE:
Well the longer the device runs the more prominent the problem gets...

Question: by "the longer it runs" do you mean specifically the longer it is *powered on*, or do you mean the longer it is *streaming*? If specifically streaming -- if stopping the stream and restarting fixes the audio -- that gives some detail on where to look.

I *suspect* it's going to be hardware-specific in the end, though; this device is a decade old, which is practically a senior citizen given how quickly embedded device hardware advances. And with computers now able to just generally push MORE stuff down a streaming pipeline, the poor little Link can run closer to CPU starvation than is ideal.

So I would not be surprised if the RPi, for instance, does not show this; think of the RPi as what would functionally be a "Steam Link v2" in terms of the hardware in it.
Originally posted by Packetdancer:
Originally posted by AUTHPLAYERLOGINSTATE:
Well the longer the device runs the more prominent the problem gets...

Question: by "the longer it runs" do you mean specifically the longer it is *powered on*, or do you mean the longer it is *streaming*? If specifically streaming -- if stopping the stream and restarting fixes the audio -- that gives some detail on where to look.

I *suspect* it's going to be hardware-specific in the end, though; this device is a decade old, which is practically a senior citizen given how quickly embedded device hardware advances. And with computers now able to just generally push MORE stuff down a streaming pipeline, the poor little Link can run closer to CPU starvation than is ideal.

So I would not be surprised if the RPi, for instance, does not show this; think of the RPi as what would functionally be a "Steam Link v2" in terms of the hardware in it.

I have before and specifically today stopped streaming several times (back to the pc select screen and press play again).

It has not been powered off (as in no electricity) since the ssh enable reboot but has been soft powered off.
BTW the sole reason I use it is to stream my webbrowser (using a mouse) and play VLC movies I do not game with it. So it can't be a high demand thing...?
Originally posted by Packetdancer:
Originally posted by AUTHPLAYERLOGINSTATE:
Well the longer the device runs the more prominent the problem gets...

Question: by "the longer it runs" do you mean specifically the longer it is *powered on*, or do you mean the longer it is *streaming*? If specifically streaming -- if stopping the stream and restarting fixes the audio -- that gives some detail on where to look.

I *suspect* it's going to be hardware-specific in the end, though; this device is a decade old, which is practically a senior citizen given how quickly embedded device hardware advances. And with computers now able to just generally push MORE stuff down a streaming pipeline, the poor little Link can run closer to CPU starvation than is ideal.

So I would not be surprised if the RPi, for instance, does not show this; think of the RPi as what would functionally be a "Steam Link v2" in terms of the hardware in it.

I will just replace it with a PI, lol I already have 4 anyways, I probably should have done this a long time ago, I don't know I have the controller I have the link it just whatever.

Fact that I can SSH to it and have the SDK makes it interesting and no longer trash.

I actually have seen a lot of threads about moonlight being so much better but I couldn't be bothered with all the hassle and again I basically stream 1080p video only.

But thank you for trying.
For the sake of more data (and my sanity)... if you were to reboot the device (you can ssh in and just type "shutdown -r now" to force a reboot without needing to power-cycle), does the pop/crackle go away?
Originally posted by Packetdancer:
For the sake of more data (and my sanity)... if you were to reboot the device (you can ssh in and just type "shutdown -r now" to force a reboot without needing to power-cycle), does the pop/crackle go away?

You are lucky I dabble in the world of STM32 and programming lol I shall give this a try for your sanity of course!
Originally posted by AUTHPLAYERLOGINSTATE:
I will just replace it with a PI, lol I already have 4 anyways, I probably should have done this a long time ago, I don't know I have the controller I have the link it just whatever.

Yeah... the Link's been a faithful little device, but it's a decade old and kinda the embedded Linux equivalent of a senior citizen at this point. It still does stuff very well for many people, but it's definitely showing its age.

The RPi is honestly the major reason there *isn't* a Steam Link 2 -- the Pi hardware is basically what a Link 2 would've been, and making the Steam Link a software solution (e.g. the flatpak) means folks have freedom to set it up in a wider variety of situations and scenarios than they would with just another dedicated box.

So I can't say it's even a bad idea to just move to the Pi, especially if you (like many of us tinkerers) have several sitting around. :)
< >
Showing 1-15 of 25 comments
Per page: 1530 50