"Send close" command to a remote source after 30s?

  • Hi guys,
    I'm having some trouble integrating my Samsung TV running HyperTizen as a Remote Control Source for Hyperion.

    Digging through the dev's Discord I managed to add the TV as a Remote Source launching these commands:

    Code
    const ws = new WebSocket('ws://your-tvs-ip:8086');
    ws.send(JSON.stringify({ event: 0, key: 'rpcServer', value: 'ws://hyperion-server-ip:8090' }));
    ws.send(JSON.stringify({ event: 0, key: 'enabled', value: 'true' }));

    but once added it only show a pitch black image as Live Video preview.

    395343846-bf0b248b-2204-40d7-9f5e-774a8e226d09.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzQxMDAyNDMsIm5iZiI6MTczNDA5OTk0MywicGF0aCI6Ii8yMzEzODkyOS8zOTUzNDM4NDYtYmYwYjI0OGItMjIwNC00MGQ3LTlmNWUtNzc0YThlMjI2ZDA5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDEyMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQxMjEzVDE0MjU0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTI4MmRkMjExMjBhMWRiZmIxN2Y0YmEyMWFjNDFjMzdlM2UwOGVlMjljNjY2NDM4NTcwM2I1ZGVhNjg1NDUxNjgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.XHzwS0h3Ejx8aRcPd7KDtXi4ycki3OtAdnIaJZLuYBw

    Nonetheless, if I re-run the second command (ws.send(JSON.stringify({ event: 0, key: 'rpcServer', value: 'ws://hyperion-server-ip:8090' }));) it will start showing coherent leds preview and the leds would actually works, but the preview would still remain pitch black.

    My setup is composed by:

    After 30s the Hyperion server will send a Send close command to the TV which freeze the system once again.

    Here's a log dump of a single run:

    Code
    2024-12-12T21:50:16.908Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:30:WebSocketClient()) New connection from ::ffff:172.23.0.1
    2024-12-12T21:50:16.966Z [WEBSOCKET] (DEBUG) (JsonAPI.cpp:154:handleInstanceSwitch()) Client '::ffff:172.23.0.1' switch to Hyperion instance 0
    2024-12-12T21:50:17.205Z [WEBSOCKET] (DEBUG) (JsonAPI.cpp:1232:handleLoggingCommand()) log streaming activated for client ::ffff:172.23.0.1
    2024-12-12T21:50:44.855Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:30:WebSocketClient()) New connection from ::ffff:192.168.1.[TV]
    2024-12-12T21:50:44.873Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Reuse input 'HyperTizen@::ffff:192.168.1.[TV]/IMAGE' (HyperTizen Data) with priority 99
    2024-12-12T21:50:47.214Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Previous line repeats 10 times
    2024-12-12T21:50:47.214Z [IMAGETOLED|First LED Hardware instance] (DEBUG) (ImageToLedsMap.cpp:112:ImageToLedsMap()) Total index number is: 800 (memory: 800). Reduced pixel set factor: 0, Accuracy level: 0, Image size: 64 x 48, LED areas: 6
    2024-12-12T21:50:47.448Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Reuse input 'HyperTizen@::ffff:192.168.1.[TV]/IMAGE' (HyperTizen Data) with priority 99
    2024-12-12T21:51:14.861Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:213:sendClose()) Send close to ::ffff:192.168.1.[TV]: 1000 

    Any suggestions on how to fix the black preview or at least disable the 30s auto-shutoff?
    Thank you for your time.

  • @Lord-Grey sorry to bother,

    but I saw you active in this sub of the forum: are you in any way able to help me? Thank you for your time.

    I tried to install Hyperion locally on my Windows partition also, but unfortunately same output.

    I also realized that those 3 commands aren't required as the TV would connect automatically when turned on, but I didn't noticed it before because, as for the manual connection, this is disconnected after 30s.

    However, the startup error message appears to be a bit more comprehensive:

    Code
    2024-12-15T16:48:29.848Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:30:WebSocketClient::WebSocketClient()) New connection from ::ffff:192.168.1.[TV]
    2024-12-15T16:48:32.113Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:178:PriorityMuxer::registerInput()) Register new input 'HyperTizen@::ffff:192.168.1.[TV]/IMAGE' (HyperTizen Data) with priority 99 as inactive
    2024-12-15T16:48:32.113Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:422:PriorityMuxer::updatePriorities()) Set visible priority to 99
    2024-12-15T16:48:32.114Z [IMAGETOLED|First LED Hardware instance] (WARNING) Mapping LED/light [0]. The current mapping area contains 6688 pixels which is huge. Therefore every 2 pixels will be skipped. You can enable reduced processing to hide that warning.
    2024-12-15T16:48:32.114Z [IMAGETOLED|First LED Hardware instance] (DEBUG) (ImageToLedsMap.cpp:113:hyperion::ImageToLedsMap::ImageToLedsMap()) Total index number is: 1672 (memory: 6688). Reduced pixel set factor: 0, Accuracy level: 0, Image size: 304 x 272, LED areas: 1
    2024-12-15T16:48:32.114Z [HYPERION|First LED Hardware instance] (DEBUG) (Hyperion.cpp:654:Hyperion::handleSourceAvailability()) new source available -> Resume output processing and switch LED-Device on
    2024-12-15T16:48:33.792Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:182:PriorityMuxer::registerInput()) Reuse input 'HyperTizen@::ffff:192.168.1.[TV]/IMAGE' (HyperTizen Data) with priority 99
    2024-12-15T16:48:59.887Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:213:WebSocketClient::sendClose()) Send close to ::ffff:192.168.1.[TV]: 1000 
    • Could The current mapping area contains 6688 pixels which is huge. be a usefull hint? Not sure on how the script handle screenshots, but as far as I understand it seems to return way too much data(?)
    • Register new input [...] as inactive: the only reason I could think that make sense to me as to consider the source inactive is that the script is providing a stream in some format Hyperion doesn't like. This would also explain the Send close command from Hyperion: the source is considered inactive, so it shut off the leds. Can you confirm this theory? I cannot find anything in docs that document that command (when it run and why it's being runned).
  • Register new input [...] as inactive: the only reason I could think that make sense to me as to consider the source inactive is that the script is providing a stream in some format Hyperion doesn't like.

    If the image is not ok, the registration would not be reached…

    hyperion.ng/libsrc/api/API.cpp at 3e7bc78449f09982ccc5af0bed211d0cda3cf68a · hyperion-project/hyperion.ng
    The successor to Hyperion aka Hyperion Next Generation - hyperion-project/hyperion.ng
    github.com

    Nevertheless, are any responses from Hyperion logged at the HyperTizen site?

    Send close command from Hyperion

    For me it looks like as the Close was requested from remote site and was not triggered by Hyperion.

    Could The current mapping area contains 6688 pixels which is huge. be a usefull hint?

    That messages relates to your Layout Definition. It looks like you define a big area mapped to individual LEDs. This is a warning that you might want to revisit your layout as the current one will be high on resource consumption.

    It will start showing coherent leds preview and the leds would actually works, but the preview would still remain pitch black.

    Can you check, if any updates on images are received at the browser?

    Go to Inspect->Network->WS

    Do Page refresh

    Then enable show image in the preview

    Maybe you can share a screenshot of the traffic plus an image message.

    PS: I currently cannot do a screenshot for reference, as I am on my mobile.

  • Quote

    For me it looks like as the Close was requested from remote site and was not triggered by Hyperion.

    Any clue on what might trigger this behavior?

    Nevertheless, are any responses from Hyperion logged at the HyperTizen site?

    Not sure, unfortunately the project is quite fresh and docs leave a lot to be desired. I'll try to dig a bit through the Tizen SDK as soon as I'll understand where should I look fro the logs I need.

    That messages relates to your Layout Definition. It looks like you define a big area mapped to individual LEDs. This is a warning that you might want to revisit your layout as the current one will be high on resource consumption.

    This make sense, I'm currently testing with just 6 leds (2 on top, 2 on bottom,1 left, 1 right) due to power constraints.

    Can you check, if any updates on images are received at the browser?

    Go to Inspect->Network->WS

    Do Page refresh


    Then enable show image in the preview

    After the handshake it receive hundreds of packets like this one:
    {"command":"ledcolors-ledstream-update","result":{"leds":[192,192,187,192,192,192,247,244,221,207,178,133,209,193,161,255,255,250]},"success":true,"tan":1}

    (the live visualization window is not being captured by my screenshot tool for some reason).

    AeJZEfl.jpeg

  • Quote

    After the handshake it receive hundreds of packets like this one:


    Sorry, I missed to mention that you should switch off the LED updates....

    If you just select Live Video, you should see updates like those in the screenshot after the imagestream-start command

  • If you just select Live Video, you should see updates like those in the screenshot after the imagestream-start command

    After the handshake you can see the ~30s of data preceding the Send close command I mentioned before from log.

    Here's the imagestream-start command content:

    {"command":"ledcolors-imagestream-start","instance":0,"success":true,"tan":1}

    Here's the first imagestream-update content:

    Code
    {"command":"ledcolors-imagestream-update","result":{"image":"data:image/jpg;base64,/9j/4AAQSkZJRgABAQEAZABkAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAEQATADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2miiius+eCiiigAooooAKKKKACiiigAooooAKKKKACiiigDWooorkPoTNooorpPDGUUUVRAlFFFBIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHwtRRRXIfQhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB900UUV1nzwUUUUAfC1FFFch9CFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3TRRRXWfPBRRRQB8LUUUVyH0IUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfdNFFFdZ88FFFFAHwtRRRXIfQhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB900UUV1nzwUUUUAfC1FFFch9CFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3TRRRXWfPBRRRQB8LUUUVyH0IUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfdNFFFdZ88FFFFAHwtRRRXIfQhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB900UUV1nzwUUUUAfC1FFFch9CFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3TRRRXWfPBRRRQB8LUUUVyH0IUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfdNFFFdZ88FFFFAHwtRRRXIfQhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB900UUV1nzwUUUUAfC1FFFch9CFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3TRRRXWfPBRRRQB8LUUUVyH0IUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfdNFFFdZ88FFFFAHwtRRRXIfQhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB900UUV1nzwUUUUAfC1FFFch9CFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3TRRRXWfPBRRRQB8LUV6v8A8M++K/8AoIaL/wB/pf8A43R/wz74r/6CGi/9/pf/AI3XNyS7Ht/WKX8x5RRXq/8Awz74r/6CGi/9/pf/AI3R/wAM++K/+ghov/f6X/43RyS7B9YpfzHlFFer/wDDPviv/oIaL/3+l/8AjdH/AAz74r/6CGi/9/pf/jdHJLsH1il/MeUUV6v/AMM++K/+ghov/f6X/wCN0f8ADPviv/oIaL/3+l/+N0ckuwfWKX8x5RRXq/8Awz74r/6CGi/9/pf/AI3R/wAM++K/+ghov/f6X/43RyS7B9YpfzHlFFer/wDDPviv/oIaL/3+l/8AjdH/AAz74r/6CGi/9/pf/jdHJLsH1il/MeUUV6v/AMM++K/+ghov/f6X/wCN0f8ADPviv/oIaL/3+l/+N0ckuwfWKX8x5RRXq/8Awz74r/6CGi/9/pf/AI3R/wAM++K/+ghov/f6X/43RyS7B9YpfzHlFFer/wDDPviv/oIaL/3+l/8AjdH/AAz74r/6CGi/9/pf/jdHJLsH1il/MeUUV6v/AMM++K/+ghov/f6X/wCN0f8ADPviv/oIaL/3+l/+N0ckuwfWKX8x5RRXq/8Awz74r/6CGi/9/pf/AI3R/wAM++K/+ghov/f6X/43RyS7B9YpfzHlFFer/wDDPviv/oIaL/3+l/8AjdH/AAz74r/6CGi/9/pf/jdHJLsH1il/MeUUV6v/AMM++K/+ghov/f6X/wCN0f8ADPviv/oIaL/3+l/+N0ckuwfWKX8x5RRXq/8Awz74r/6CGi/9/pf/AI3R/wAM++K/+ghov/f6X/43RyS7B9YpfzHlFFer/wDDPviv/oIaL/3+l/8AjdH/AAz74r/6CGi/9/pf/jdHJLsH1il/MeUUV6v/AMM++K/+ghov/f6X/wCN0f8ADPviv/oIaL/3+l/+N0ckuwfWKX8x5RRXq/8Awz74r/6CGi/9/pf/AI3R/wAM++K/+ghov/f6X/43RyS7B9YpfzH0lRRRXSeIFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//2Q=="},"success":true,"tan":1}

    Here's the last imagestream-update content:

    Code
    {"command":"ledcolors-imagestream-update","result":{"image":"data:image/jpg;base64,/9j/4AAQSkZJRgABAQEAZABkAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAEQATADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDjKKKK9Q8A2KKKK+pPnjQooorgOw+iqKKK+RPtDwuiiivoj8nPEKKKK8Q/TDtqKKK+TP3o7Oiiiu0+eNKiiitzwzgKKKK8o+5Pqeiiivpj8VPM6KKK+mPw08oooorzT+2QoooqgPP6KKK4D8MNCiiitznPr2iiioOI5+iiiuo5j5eooorI9M6WiiitDnPMqKKK8s98KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAN+iiiuw8s66iiiug5DzKiiivLPfCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDcooorc4zdoooroOQ4aiiiuA9cKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKANyiiitzjOxooortPMPMqKKK8s98KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKANyiiitzjOxooortPMPMqKKK8s98KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKANyiiitzjOxooortPMPMqKKK8s98KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKANyiiitzjPuOiiisDsPgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA3KKKK3OM9LooorsPPPGKKKK8w9wKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKANyiiitzjPuOiiisDsPgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA3KKKK3OM+46KKKwOw+AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDcooorc4z61ooorzz5c+LqKKK6T7QKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKANyiiitzjPuOiiisDsPgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA3KKKK3OM+46KKKwOw+AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDcooorc4z7jooorA7D4AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKANyiiitzjPuOiiisDsPgCirX9ny/3k/M/4Uf2fL/eT8z/AIU+Vk88e5Voq1/Z8v8AeT8z/hR/Z8v95PzP+FHKw549yrRVr+z5f7yfmf8ACj+z5f7yfmf8KOVhzx7lWirX9ny/3k/M/wCFH9ny/wB5PzP+FHKw549yrRVr+z5f7yfmf8KP7Pl/vJ+Z/wAKOVhzx7lWirX9ny/3k/M/4Uf2fL/eT8z/AIUcrDnj3KtFWv7Pl/vJ+Z/wo/s+X+8n5n/CjlYc8e5Vord/4RS+/wCett/303+FH/CKX3/PW2/76b/Cr9lPsZ/WKX8xhUVu/wDCKX3/AD1tv++m/wAKP+EUvv8Anrbf99N/hR7KfYPrFL+YwqK3f+EUvv8Anrbf99N/hR/wil9/z1tv++m/wo9lPsH1il/MYVFbv/CKX3/PW2/76b/Cj/hFL7/nrbf99N/hR7KfYPrFL+YwqK3f+EUvv+ett/303+FH/CKX3/PW2/76b/Cj2U+wfWKX8xhUVu/8Ipff89bb/vpv8KP+EUvv+ett/wB9N/hR7KfYPrFL+YwqK3f+EUvv+ett/wB9N/hR/wAIpff89bb/AL6b/Cj2U+wfWKX8xhUVu/8ACKX3/PW2/wC+m/wo/wCEUvv+ett/303+FHsp9g+sUv5jCord/wCEUvv+ett/303+FH/CKX3/AD1tv++m/wAKPZT7B9YpfzGFRW7/AMIpff8APW2/76b/AAo/4RS+/wCett/303+FHsp9g+sUv5hKKKKsxPuOiiisDsPhyiiitzjCiiigAooooAKKKKACiiigAooooAKKKKAOxooortPMCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOOoooriPTP/Z"},"success":true,"tan":1}

    I'm able to convert the base64 files to jpeg with online platforms such as this one, which contains exactly what I'm seeing in the preview: pitch black background, but coherent LEDs output.

    T78ICb6.jpeg

  • PPaul Might be the best, if I create a special developer version which logs the incoming messages.

    Then we can further investigate what is sent and replay for turtles investigation.

    Alternatively, create a Python script that creates a web-socket listening to port 8090 (hyperion stopped) and dumps incoming messages.

  • PPaul Might be the best, if I create a special developer version which logs the incoming messages.

    My server is running on an immutable distro, so I'm unable to test anything that is not dockerized on that.

    Alternatively I'm able to run a local version on the Windows partition.

    Alternatively, create a Python script that creates a web-socket listening to port 8090 (hyperion stopped) and dumps incoming messages.

    This might be a better solution for me, as given the dependencies I'll be able to dockerize it quite easily.

  • Alternatively, create a Python script that creates a web-socket listening to port 8090 (hyperion stopped) and dumps incoming messages.

    I managed to cook a script with the help of ChatGPT:

    That I containerized using this docker-compose:

    And here's the logs it spitted out(sorry for the pastebin, but it's >10k chars).

    Websockets are definitely out of my skillset tho, so I'm missing the expertise to analyze the errors and try to fix them/return useful info to the dev.

    Any help?


    The HyperTizen dev provided me with this NodeJS script:

    that has been dockerized by me:

    I'll attach the full log of the script (web-socket.txt) and the ~150 images converted from base64 to jpeg (frame_.zip) : still no preview, but it worked for more than the 30s of Hyperion.

    Edited 2 times, last by PPaul: Merged a post created by PPaul into this post. (December 20, 2024 at 1:49 PM).

  • Developer here. Someone else who is also running HyperTizen on Tizen 6.5 (OP also has a Tizen 6.5 device) had the same issue and when we got the RPC responses from Hyperion, there were no errors. All there was success messages. It seems to disconnect for no reason after 30s. This doesn't happen for other users running on T7/8 and only 2 T6.5 users right now. I don't know if it affects T6.5 users only or only those two users. I cannot test myself as I don't have the required hardware (still with a T3 device).

  • Reis Looks like I did not see the web-socket.txt which was provided after I read the initial post.

    I can see that valid images are provided.

    which contains exactly what I'm seeing in the preview: pitch black background, but coherent LEDs output.

    PPaul You see pitch black background, as the middle part of the images is provied with transparent color.
    Reis only creates a frame of color pointes captured, I assume to streamline processing.
    HyperTizien does not send an image of the screen, but a 16 picked colour for each side, i.e. do not expect an image!


    Here is one sample image that was part of your log.



    I am further investigating on the close issue

  • PPaul Could you try running the following python script against Hyperion, please?
    (You can also run it on your windows machine; Just change the url in the script)

    It tries to send images with 20fps for 60 seconds (you can change the parameters easily).
    Every 10 images it alternates to another one, so you should see updates in the preview.

    At my test installation the Websocket fails after ~20 seconds.
    It it a know issue that the Websocket has a problem with many updates, but I did not expect it as bad as this...
    This would require further investigations. Happy, if you file an issue....

  • PPaul Could you try running the following python script against Hyperion, please?

    All code indentations have been deleted, I'm not sure what should be executed at what height: could you attach the script as a file or as a code block?

  • Quote


    At my test installation the Websocket fails after ~20 seconds.

    Can confirm that Hyperion seems to crash every 192 or 193 images or ~20s, but it seems able to reset itself with this script:

    Code
    2024-12-21T21:44:45.300Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:30:WebSocketClient()) New connection from ::ffff:172.28.0.1
    2024-12-21T21:44:46.041Z [MUXER|Tizen LEDS] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Previous line repeats 200 times
    2024-12-21T21:45:05.360Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:213:sendClose()) Send close to ::ffff:172.28.0.1: 1000 2024-12-21T21:45:11.408Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:30:WebSocketClient()) New connection from ::ffff:172.28.0.1
    2024-12-21T21:45:13.078Z [MUXER|Tizen LEDS] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Previous line repeats 200 times
    2024-12-21T21:45:31.472Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:213:sendClose()) Send close to ::ffff:172.28.0.1: 1000 2024-12-21T21:45:35.438Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:30:WebSocketClient()) New connection from ::ffff:172.28.0.1
    2024-12-21T21:45:38.067Z [MUXER|Tizen LEDS] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Previous line repeats 200 times
    2024-12-21T21:45:55.513Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:213:sendClose()) Send close to ::ffff:172.28.0.1: 1000 2024-12-21T21:45:59.467Z [WEBSOCKET] (DEBUG) (WebSocketClient.cpp:30:WebSocketClient()) New connection from ::ffff:172.28.0.1

    Every 192/193 images this is the error that the websocket is spitting out:

    Code
    [2024-12-21 21:47:08.095] [192] Command sent: image
    [2024-12-21 21:47:08.100] [192] Response: {"command":"image","instance":0,"success":true,"tan":0}
    [2024-12-21 21:47:08.201] WebSocket connection closed unexpectedly: sent 1002 (protocol error) fragmented control frame; no close frame received
    [2024-12-21 21:47:08.201] WebSocket closed. Total time elapsed: 20.202 seconds.
    WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager, possibly rendering your system unusable.It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv. Use the --root-user-action option if you know what you are doing and want to suppress this warning.
    Requirement already satisfied: websockets in /usr/local/lib/python3.13/site-packages (14.1)

    I'll open an issue on Git citing this thread.

    Edited once, last by PPaul (December 21, 2024 at 10:52 PM).

  • Reis & PPaul It looks like that the WebSocket Implementation in Hyperion does not handle the WS Heartbeat (PING/PONG) correctly. That is why the HyperTizien client closes the websocket. It looks like the Heartbeat Intervall is 30s and that is the reason why we see always after that timeframe a connection issue.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!