Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Twitch GUI doesn't always detect finished streams #954

Closed
4 tasks done
Sneakpeakcss opened this issue Feb 26, 2023 · 1 comment
Closed
4 tasks done

Twitch GUI doesn't always detect finished streams #954

Sneakpeakcss opened this issue Feb 26, 2023 · 1 comment
Labels

Comments

@Sneakpeakcss
Copy link

Checklist

Streamlink Twitch GUI version

v2.2.0

Streamlink version

5.1.2

Operating system, environment and configuration details

Windows 10 21H2

Description

Streams that ended and closed automatically are sometimes detected as online by Twitch GUI in "You're Watching" panel and still count the online time, until either manually closed from You're Watching window or the stream comes back online again and is closed from the usual prompt that shows up when trying to launch already opened stream.

This appears to happen only(?) on streams that have been launched for few hours, streams that end quickly (1h~) after launch don't seem to have this problem or at least it's less prevalent.

Closing the player manually seems to be always detected properly no matter how long the stream was turned on for.

gui

When this happens Debug Log always outputs this at the end:

[2023-02-25T14:44:51.491Z][error][Application]
unhandledrejection: Error: Missing data while normalizing single response
{}

[2023-02-25T14:44:58.208Z][error][StreamingService]
Error: error: Error when reading from stream: Read timeout, exiting

First error shows even when Twich GUI properly detects that stream finished, but none of them are present when player is closed manually.

I've found second error referenced previously as 'normal / expected' [#1] [#2] on Streamlink repository, so at this point i'm not completely sure if this more of a Streamlink based problem or if there's additional detection on Twitch GUI side that isn't working correctly in certain scenarios.

Full Debug Log
[2023-02-25T08:24:29.138Z][debug][Application]
Parameters
{
    "_": [],
    "tray": false,
    "hide": false,
    "hidden": false,
    "max": false,
    "maximize": false,
    "maximized": false,
    "min": false,
    "minimize": false,
    "minimized": false,
    "reset-window": false,
    "versioncheck": true,
    "version-check": true,
    "logfile": true,
    "disable-gpu": true,
    "l": "debug",
    "loglevel": "debug",
    "launch": "",
    "goto": ""
}

[2023-02-25T12:31:43.145Z][debug][StreamingService]
Preparing to launch stream
{
    "id": "70880222",
    "quality": "source",
    "low_latency": true,
    "disable_ads": false,
    "chat_open": false,
    "started": "2023-02-25T12:31:43.127Z",
    "stream": "70880222",
    "user": "70880222"
}

[2023-02-25T12:31:43.148Z][debug][StreamingService]
Resolving player
{
    "player": "mpc",
    "playerUserData": {
        "instance": true,
        "close": true,
        "exec": "",
        "args": null,
        "type": "settings-streaming-player-mpc"
    }
}

[2023-02-25T12:31:43.154Z][debug][StreamingService]
Resolved player
{
    "exec": "C:\\Program Files (x86)\\K-Lite Codec Pack\\MPC-HC64\\mpc-hc64.exe",
    "params": "/new /play /close",
    "env": null
}

[2023-02-25T12:31:43.182Z][debug][StreamingService]
Spawning process
{
    "exec": "C:\\Program Files\\Streamlink\\bin\\streamlinkw.exe",
    "params": [
        "--twitch-api-header=Authorization=OAuth redacted",
        "--twitch-low-latency",
        "--player",
        "C:\\Program Files (x86)\\K-Lite Codec Pack\\MPC-HC64\\mpc-hc64.exe",
        "--player-args",
        "/new /play /close",
        "--hls-live-edge",
        "1",
        "--stream-segment-threads",
        "2",
        "--retry-open",
        "2",
        "--retry-streams",
        "3",
        "twitch.tv/smoke",
        "best"
    ],
    "env": null
}

[2023-02-25T14:44:51.491Z][error][Application]
unhandledrejection: Error: Missing data while normalizing single response
{}

[2023-02-25T14:44:58.208Z][error][StreamingService]
Error: error: Error when reading from stream: Read timeout, exiting
{
    "id": "70880222",
    "quality": "source",
    "low_latency": true,
    "disable_ads": false,
    "chat_open": false,
    "started": "2023-02-25T12:31:43.127Z",
    "stream": "70880222",
    "user": "70880222"
}

Debug log

No response

@bastimeyer
Copy link
Member

It's a known bug that existed for a couple of years now. I can't find the original thread right now because I believe it was just a regular comment in another thread. I've tried reproducing it back at the time, but wasn't able to, so it was never fixed and then forgotten about. Since it's a rather rare occurrence, it's not super important.

This has something to do with the Stream record's state after the Streamlink process has terminated, which doesn't get set correctly by either the StreamingService implementation or the Stream record implementation. I can have another look at this some time, but my motivation isn't particularly high right now when dealing with minor issues in Streamlink Twitch GUI because I'm much more invested with Streamlink nowadays.


The error: Error when reading from stream: Read timeout, exiting message is just the stdout message from the Streamlink process which gets written when streams don't end gracefully and result in the ringbuffer not being filled for 60 seconds (default value). This is a known issue with Twitch streams. Twitch should indicate in the HLS playlist that the stream has ended by setting the EXT-X-ENDLIST HLS tag, but they don't, so Streamlink's HLSStreamWorker keeps polling the HLS playlist, waiting for new segments to be added to the HLSStreamWriter, which then causes the timeout eventually. See the relevant issue here:
streamlink/streamlink#2198

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants