Arbitrarily, Lua throws `a nil value` and ceases message generation about mpv-twitch-chat

[CrendKing]

Seems like the "multiple sub tracks" bug was fixed by the test branch, but not the ignored config, but thanks anyway :)

Are you referring to #16 (comment)? I have no problem configuring the script. I suggest give a read of the doc.

although subtitles still stop generating for the remainder of the stream.

You need to do a seek to re-trigger the loading function.

---

I suppose the issue is "fixed" by itself. I added the error handling to the master branch.

[CrendKing]

I suspect it's due to network issue, either on Twitch server side or your client side. I can't reproduce the issue.

Anyways, I found an issue related to seeking and posted a fix. Try it.

[ZaptorZap]

I got the updated main.lua and bumped up fetch_aot to 20. While sid is definitely staying at 1 now, I think fetch_aot caused it to throw a nil value much faster. In fact, trying a value of 100 caused it to near-immediately break. I tried 0.5 but frankly I have no idea if decimals are supported or rounded. Either way it still didn't work out.

[CrendKing]

Still can't make the error show up. I'm pretty sure it's either your network being unstable sometimes, or Twitch just throttles you. fetch_aot is not meant to be too high, or you risk setting it above the duration of a segment and thus causing it to flood Twitch, which could get you throttled. However, fetch_aot should have no effect on seeking, because every seek causes the script to download a new segment immediately. So if you do want to seek a lot for a while, hide the subtitle first or you might flood Twitch.

BTW, does the issue happen only on specific channels (like with lots of chat messages) or all channels even with low number of chats?

[ZaptorZap]

Well, T+23 minutes into a much smaller streamer and it still errored out, so the rate of chat messages doesn't seem to have anything to do with it—besides making what seems like an eventuality come much later.

I've been on the other end of this network conversation so I'll keep this brief. Geographically I'm relatively close to Twitch's HQ in San Francisco and I use an Ethernet connection with pretty high speeds.(197.8Mbps Down/202.8Mbps Up | Google, same-city test) In the past, I've had little trouble with livestreaming to or from Twitch, so if it's a network issue, I'm convinced it's an API one.

Totally understand if you can't fix this. I guess the solution to the issue would be better error handling here. Perhaps logging the entire response Twitch serves up would help? Totally fine to keep verbosity to stdout, but it seems unmitigated as-is.

[CrendKing]

Sure. I just added some debugging messages to the new test branch. You can try it with mpv --log-file to see the curl response. Also, if the response is incorrect, you can find the curl command the script used and try yourself in terminal, see if you can get the same result.

[ZaptorZap]

Sure thing. The request is identical across both mpv's log and a manually reconstructed curl. The request:

curl --request POST --header 'Client-ID: {REDACTED}' --data '{"operationName":"VideoCommentsByOffsetOrCursor","variables":{"videoID":"1870054397","cursor":"eyJpZCI6ImRjOTE0YzFmLWMwMDUtNDhlNC05OGMyLWExOGNmZDliYTE1MCIsImhrIjoiYnJvYWRjYXN0OjQ4ODQ2Njc3ODUzIiwic2siOiJBQUFJUGtpM3prQVhjVFJRNWZsZlFBIn0"},"extensions":{"persistedQuery":{"version":1,"sha256Hash":"b70a3591ff0f4e0313d126c6a1502d79a1c02baebb288227c582044aa76adf6a"}}}' --silent https://gql.twitch.tv/gql

and the response:

{"errors":[{"message":"failed integrity check","path":["video","comments"]}],"data":{"video":{"id":"1870054397","creator":{"id":"112295341","channel":{"id":"112295341","__typename":"Channel"},"__typename":"User"},"comments":null,"__typename":"Video"}},"extensions":{"challenge":{"type":"integrity"},"durationMilliseconds":67,"operationName":"VideoCommentsByOffsetOrCursor","requestID":"01H5YD1X3QCRRH068B226QG6MF"}}

So it seems I'm failing "integrity checks". Could this have something to do with my extremely legitimate Client-ID perhaps?

[CrendKing]

As I mentioned in #16 (comment), currently you do not have to supply your own client ID to get it working. Have you tried removing your own ID?

Now I see how an error could be returned, I could add some logic to handle this error.

See if the latest commit would properly show you the error instead of crashing.

[Tallefer]

Seems like the "multiple sub tracks" bug was fixed by the test branch, but not the ignored config, but thanks anyway :)

[ZaptorZap]

I removed the client ID and it seems to be working A-OK now. Popping it back in after syncing to the latest commit shows the error nicely shown, although subtitles still stop generating for the remainder of the stream.