Internal error

[marcorinck]

Unfortunately I can't start any stream with livestreamer-twitch-gui. I only get this message when starting the stream (other functions do work, I have successfully logged in, f.i.):

Error: Couldn't launch the stream

Internal error

When I use livestreamer from the command line with the same stream, it does work without any problem.

When I start livestreamer-twitch-gui from the command line I get this message:

[6286:0802/090735:ERROR:nw_shell.cc(335)] TypeError: Cannot read property 'kill' of null
    at Socket.c (app://livestreamer-twitch-gui/app/main.js:90:19751)
    at emitOne (events.js:75:13)
    at Socket.emit (events.js:150:7)
    at readableAddChunk (_stream_readable.js:146:16)
    at Socket.Readable.push (_stream_readable.js:109:10)
    at Pipe.onread (net.js:510:20)
[6286:0802/090735:INFO:CONSOLE(90)] "Uncaught TypeError: Cannot read property 'kill' of null", source: app://livestreamer-twitch-gui/app/main.js (90)

iMac 5k, GPU: M290X, OSX Yosemite (fresh installation, only 2 days old), No flash installed (I don't intend to on this machine at all)

[bastimeyer]

Thanks for reporting the issue...
It's this line which is throwing the error.

Could you please run livestreamer --version --no-version-check from your shell and see if this causes any errors? That's what the GUI is doing first when you're launching any stream. It's checking the livestreamer version and then it's starting a second livestreamer process with all the stream parameters, etc...

The internal error message needs to be fixed, though...

[marcorinck]

The command runs just fine:

Marcos-iMac:~ marco$ livestreamer --version --no-version-check
livestreamer 1.12.2

[marcorinck]

ah and btw, as you seem to be doing some "sophisticated" logic to find out the executable path, livestreamer is placed in /usr/local/bin/livestreamer in macos.

Marcos-iMac:~ marco$ which livestreamer
/usr/local/bin/livestreamer
Marcos-iMac:~ marco$ ls -l /usr/local/bin/livestreamer 
-rwxr-xr-x  1 root  wheel  329 Aug  2 08:57 /usr/local/bin/livestreamer

[bastimeyer]

you seem to be doing some "sophisticated" logic to find out the executable path

Yeah, it's a necessity on OSX, because of #55.

Could you please debug the application for me real quick? Infos can be found in CONTRIBUTING.md...
Set a breakpoint at this line and please tell me the value of the variable exec... Thanks!

Edit
Maybe also here (value of data)... Just curious if livestreamer is returning the version string in multiple chunks (which it shouldn't)

[marcorinck]

exec seems to be correct too: "/usr/local/bin/livestreamer"

On Sun, Aug 2, 2015 at 9:01 PM, Sebastian Meyer notifications@github.com
wrote:

you seem to be doing some "sophisticated" logic to find out the executable
path

Yeah, it's a necessity on OSX, because of #55
#55.

Could you please debug the application for me real quick? Infos can be
found in CONTRIBUTING.md
https://github.com/bastimeyer/livestreamer-twitch-gui/blob/v0.9.2/CONTRIBUTING.md#developing-and-building
...
Set a breakpoint at this line
https://github.com/bastimeyer/livestreamer-twitch-gui/blob/v0.9.2/src/app/controllers/LivestreamerController.js#L272
and please tell me the value of the variable exec... Thanks!

—
Reply to this email directly or view it on GitHub
#121 (comment)
.

[marcorinck]

there is even a match in onData method, but "spawn" variable is null ...

On Sun, Aug 2, 2015 at 9:11 PM, Marco Rinck romulus23@gmail.com wrote:

exec seems to be correct too: "/usr/local/bin/livestreamer"

On Sun, Aug 2, 2015 at 9:01 PM, Sebastian Meyer notifications@github.com
wrote:

you seem to be doing some "sophisticated" logic to find out the
executable path

Yeah, it's a necessity on OSX, because of #55
#55.

Could you please debug the application for me real quick? Infos can be
found in CONTRIBUTING.md
https://github.com/bastimeyer/livestreamer-twitch-gui/blob/v0.9.2/CONTRIBUTING.md#developing-and-building
...
Set a breakpoint at this line
https://github.com/bastimeyer/livestreamer-twitch-gui/blob/v0.9.2/src/app/controllers/LivestreamerController.js#L272
and please tell me the value of the variable exec... Thanks!

—
Reply to this email directly or view it on GitHub
#121 (comment)
.

[marcorinck]

oh I see, the failed method is getting called with error code 0. Hmm.

So, it seems to be all ok, but because you are setting spawn to null, version check is failing later.

[marcorinck]

maybe the problem is, that you are defining failed as an exit handler?

[marcorinck]

yes, that is the problem. Ignoring "error" code 0 in failed method is fixing this problem. Stream is basically working after that.

[bastimeyer]

oh I see, the failed method is getting called with error code 0. Hmm.

Well, it must either be the onTimeout function, or the error/exit callbacks... Is the validation taking a bit of time? I'd like to know the call stack of the failed call (you may need to check the async button)...

but because you are setting spawn to null, version check is failing later.

Yeah, it's been fixed by 4ed2d06 now...

maybe the problem is, that you are defining failed as an exit handler?

The promise should resolve before executing the exit callback, so it doesn't matter... Binding failed to exit is just another precaution if something unexpected happened...

[marcorinck]

timeout handler is not getting called, failed is directly getting called from event.js of EventEmitter
EventEmitter.emitTwo, line 85.

And that is happening before! onData method.

[bastimeyer]

And that is happening before! onData method.

Well, that's not supposed to be happening. Thanks for taking the time finding the cause of this issue! 👍

I don't know why NW.js is triggering the exit event before triggering the stdOut/stdErr data callbacks. I haven't seen this before... I guess adding a short delay before rejecting the promise will fix this. Let me see...

[marcorinck]

It was fun, had no nw.js experience whatsoever before. Its an impressive framework though.

However, adding delays so that callback handlers are getting called in the "right" order seems to be very fragile to me. Why are you not splitting up error and exit handler? Or get rid of the exit handler at all, you don't need it really, don't you?

[bastimeyer]

@marcorinck could you please tell me if 07ecb5d has fixed your issue?

[marcorinck]

yes, its fixed now.

[bastimeyer]

Awesome, thanks

[Caf]

The latest OS X release (not source, full DL) is not fixed yet right? (I still have the issue ;) )

[marcorinck]

yes, you need the source as long as basti does not make a new release.

[bastimeyer]

To be honest, I'm a little bit surprised about the appearance of this bug. It's been working like that for over a year now and hasn't been changed in the latest release, so I'm wondering why this is happening all of a sudden now.
I thought this was just an edge case here, but maybe another hotfix needs to be released. Could this be related to a newer OSX version, maybe? I'm using v10.10.1 in my VM...

[Caf]

I'm under 10.10.4 BUT it's working perfectly fine on my Mac Mini. I'm not sure but I think it's related to python and / or how it's installed (old OSX stuff, new release, brew release...) Livestreamer was unhappy too on my MacBook Pro until I fixed Python / updated / etc. BUT it was working with your GUI since I watched A LOT of stuff with it lately. The update broke it for some reason. :/

[bastimeyer]

Yeah, I think I'm going to release a hotfix tomorrow then... Thanks for the infos

[mfpierre]

I can confirm the issue in 10.10.4.
I just upgraded to v0.9.2 and I got the error, everything is fine under v0.9.1 waiting for the hotfix 👍

[bastimeyer]

v0.9.3 released

[Caf]

And all is fine in the world again. ;) THX a LOT for that fix. <3 <3