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

Livestreamer + Omxplayer Help! #234

Closed
imu1254 opened this Issue Dec 7, 2013 · 13 comments

Comments

Projects
None yet
3 participants
@imu1254

imu1254 commented Dec 7, 2013

Ok,here is the thing. After few days of exercising with Omxplayer+Livestreamer I ran into some issues though.
In my case it's Youtube. (live tv works like a charm) [Centos 6.5 & Raspbian-wheezy]
1.)
#!/bin/bash clip=$(xclip -o) ssh -t pi@192.168.1.149 screen livestreamerecho $clipbest -np omxplayer

above script works and I can manipulate volume etc. but screen terminates video a while before actual end of it which in case of short clips means failure.It doesn't happen though while playing one of live streams eg. Al jazeera.

2.)
#!/bin/bash clip=$(xclip -o) ssh -t pi@192.168.1.149 nohup livestreamerecho $clipbest -np omxplayer

this one works but then I have no control over Omxplayer so the effect is basically the same as with the following:

3.)
#!/bin/bash clip=$(xclip -o) ssh pi@192.168.1.149 livestreamerecho $clipbest -np omxplayer

Now,when I do the casting thing from my laptop's video folder with SimpleHTTPServer running on:
4.)
#!/bin/bash clip=$(xclip -o) ssh -t pi@192.168.1.149 screen omxplayerecho $clip`

all work well, screen doesn't terminate early and I have control over Omxplayer.

I just had to edit BaseHTTPServer.py and add my laptop's ip to it.

Could you guys help me to understand what I'm doing wrong and why screen terminates in 1.) case and works well in 4.) ?

I suppose it has something to do with Livestreamer killing player after stream ends but adding --player-no-close argument changes nothing :(

@chrippa

This comment has been minimized.

Show comment
Hide comment
@chrippa

chrippa Dec 7, 2013

Owner

I'm not sure if this will help your issues, but you may want to try using the --player-no-close option. By default Livestreamer will close the player when the stream is over, but if the player has cached a decent amount the stream may seem to end abruptly.

This behaviour has been around since the first version of Livestreamer since I wanted to close the VLC GUI after the stream was over. But I realize this is not very optimal for VOD content and I will consider changing it in the future.

Owner

chrippa commented Dec 7, 2013

I'm not sure if this will help your issues, but you may want to try using the --player-no-close option. By default Livestreamer will close the player when the stream is over, but if the player has cached a decent amount the stream may seem to end abruptly.

This behaviour has been around since the first version of Livestreamer since I wanted to close the VLC GUI after the stream was over. But I realize this is not very optimal for VOD content and I will consider changing it in the future.

@imu1254

This comment has been minimized.

Show comment
Hide comment
@imu1254

imu1254 Dec 7, 2013

Thanks for fast response :) I see you have skipped my last sentence above :)
I don't know if this brings any help but I'm running Raspberry without X as Omxplayer has no UI anyway.

Thanks again and kudos for great work :) plus can you label this as discussion or you want me to close this?

imu1254 commented Dec 7, 2013

Thanks for fast response :) I see you have skipped my last sentence above :)
I don't know if this brings any help but I'm running Raspberry without X as Omxplayer has no UI anyway.

Thanks again and kudos for great work :) plus can you label this as discussion or you want me to close this?

@chrippa

This comment has been minimized.

Show comment
Hide comment
@chrippa

chrippa Dec 7, 2013

Owner

Ah, I see. I don't know if omxplayer prints any output, but if you run with --verbose-player you can see it and it might help finding out whats going wrong.

Owner

chrippa commented Dec 7, 2013

Ah, I see. I don't know if omxplayer prints any output, but if you run with --verbose-player you can see it and it might help finding out whats going wrong.

@imu1254

This comment has been minimized.

Show comment
Hide comment
@imu1254

imu1254 Dec 7, 2013

Omxplayer has command line args but unfortunately none of them seems to work with Livestreamer neither directly or trough .livestreamerrc :( I was yesterday trying to run it with --genlog but no luck.
I also ran Livestreamer with -e but there was no logs at all. I'll try -v and see what happens.

imu1254 commented Dec 7, 2013

Omxplayer has command line args but unfortunately none of them seems to work with Livestreamer neither directly or trough .livestreamerrc :( I was yesterday trying to run it with --genlog but no luck.
I also ran Livestreamer with -e but there was no logs at all. I'll try -v and see what happens.

@imu1254

This comment has been minimized.

Show comment
Hide comment
@imu1254

imu1254 Dec 7, 2013

I did it but no luck though so I got nothing.
You know,, when I run it without screen it plays to the end even if Livestreamer ends earlier but then I have zero control over Omxplayer.If I only knew how to keep screen alive that would be great.I thought nohup but that doesn't do it either :(

imu1254 commented Dec 7, 2013

I did it but no luck though so I got nothing.
You know,, when I run it without screen it plays to the end even if Livestreamer ends earlier but then I have zero control over Omxplayer.If I only knew how to keep screen alive that would be great.I thought nohup but that doesn't do it either :(

@vadmium

This comment has been minimized.

Show comment
Hide comment
@vadmium

vadmium Dec 7, 2013

So “--player-no-close” didn’t help. I think even with that option, Livestreamer exits without waiting for the player process to close, so the player ends up continuing “in the background”. I don’t fully understand the situation with screen and nohup, but maybe it would help if Livestreamer waited for the player process to finish before exiting.

This early exiting has affected me in another case. When using M Player and/or MPV, in one scenario (--verbose-player and/or early player quit; can’t remember), the player would briefly continue to run in the background while Bash and Readline were resuming, resulting in screwing the terminal settings up. I had a patch in mind for a new option to wait for the player process to be done, which would solve this, but I never got round to it.

BTW @chrippa, please do consider changing the player closing behaviour :). Perhaps try using “vlc --play-and-exit {filename}” or “vlc {filename} vlc://quit” instead.

vadmium commented Dec 7, 2013

So “--player-no-close” didn’t help. I think even with that option, Livestreamer exits without waiting for the player process to close, so the player ends up continuing “in the background”. I don’t fully understand the situation with screen and nohup, but maybe it would help if Livestreamer waited for the player process to finish before exiting.

This early exiting has affected me in another case. When using M Player and/or MPV, in one scenario (--verbose-player and/or early player quit; can’t remember), the player would briefly continue to run in the background while Bash and Readline were resuming, resulting in screwing the terminal settings up. I had a patch in mind for a new option to wait for the player process to be done, which would solve this, but I never got round to it.

BTW @chrippa, please do consider changing the player closing behaviour :). Perhaps try using “vlc --play-and-exit {filename}” or “vlc {filename} vlc://quit” instead.

@imu1254

This comment has been minimized.

Show comment
Hide comment
@imu1254

imu1254 Dec 8, 2013

Ok,I found it : ) In my case the following script does just exactly what I was looking for :

#!/bin/bash clip=$(xclip -o) ssh -t user@host screen omxplayer \$\(youtube-dl -f 18 -g $clip\)

Hopefully it will soon be possible with Livestreamer as well :)

Kudos for Prillan.

imu1254 commented Dec 8, 2013

Ok,I found it : ) In my case the following script does just exactly what I was looking for :

#!/bin/bash clip=$(xclip -o) ssh -t user@host screen omxplayer \$\(youtube-dl -f 18 -g $clip\)

Hopefully it will soon be possible with Livestreamer as well :)

Kudos for Prillan.

@vadmium

This comment has been minimized.

Show comment
Hide comment
@vadmium

vadmium Dec 8, 2013

@imu1254, if you think my theory about the background process might be right and you are up to it, you could try my branch called “wait” at https://github.com/vadmium/livestreamer/tree/wait, where I added a “--player-wait” option. The equivalent command would probably be

ssh -t pi@192.168.1.149 screen livestreamer "$clip" best -np omxplayer --player-wait

vadmium commented Dec 8, 2013

@imu1254, if you think my theory about the background process might be right and you are up to it, you could try my branch called “wait” at https://github.com/vadmium/livestreamer/tree/wait, where I added a “--player-wait” option. The equivalent command would probably be

ssh -t pi@192.168.1.149 screen livestreamer "$clip" best -np omxplayer --player-wait

@chrippa

This comment has been minimized.

Show comment
Hide comment
@chrippa

chrippa Dec 8, 2013

Owner

@vadmium is there any downside to always do the wait call? Seems like the sensible thing to do even if we send a kill signal first.

Owner

chrippa commented Dec 8, 2013

@vadmium is there any downside to always do the wait call? Seems like the sensible thing to do even if we send a kill signal first.

@vadmium

This comment has been minimized.

Show comment
Hide comment
@vadmium

vadmium Dec 8, 2013

On 08/12/2013, Christopher Rosell notifications@github.com wrote:

@vadmium is there any downside to always do the wait call? Seems like the
sensible thing to do even if we send a kill signal first.

Yeah calling wait after calling kill is probably the right thing to do.

Or do you mean calling wait in all cases, and dropping the behaviour
of letting the player run in the background? There was an issue with a
deadlock that I already solved by explicitly closing a pipe
beforehand. Other than that I can’t think of any issues off the top of
my head, but I don’t know how this stuff works on Windows, haven’t
looked at all the HTTP, named pipe, etc modes. I thought there might
be a reason it was that way originally :)

vadmium commented Dec 8, 2013

On 08/12/2013, Christopher Rosell notifications@github.com wrote:

@vadmium is there any downside to always do the wait call? Seems like the
sensible thing to do even if we send a kill signal first.

Yeah calling wait after calling kill is probably the right thing to do.

Or do you mean calling wait in all cases, and dropping the behaviour
of letting the player run in the background? There was an issue with a
deadlock that I already solved by explicitly closing a pipe
beforehand. Other than that I can’t think of any issues off the top of
my head, but I don’t know how this stuff works on Windows, haven’t
looked at all the HTTP, named pipe, etc modes. I thought there might
be a reason it was that way originally :)

@chrippa

This comment has been minimized.

Show comment
Hide comment
@chrippa

chrippa Dec 8, 2013

Owner

Or do you mean calling wait in all cases, and dropping the behaviour of letting the player run in the background?

I'm pretty sure we always need to have the player as a background process unless we want to use a thread for the stream IO. But I meant that we probably don't need another command line option and can just do the wait call in all cases.

It was a while since I wrote the original player code, but I don't think there was any reason that I left the wait out. So I think as long as we close the input before waiting it should be fine.

Owner

chrippa commented Dec 8, 2013

Or do you mean calling wait in all cases, and dropping the behaviour of letting the player run in the background?

I'm pretty sure we always need to have the player as a background process unless we want to use a thread for the stream IO. But I meant that we probably don't need another command line option and can just do the wait call in all cases.

It was a while since I wrote the original player code, but I don't think there was any reason that I left the wait out. So I think as long as we close the input before waiting it should be fine.

@imu1254

This comment has been minimized.

Show comment
Hide comment
@imu1254

imu1254 Dec 8, 2013

@vadmium Ok,I was being stupid :) I made changes on laptop and forgot to do it on Raspberry Pi so after I correct myself it seems that --player-wait fixed youtube issue :) well done Vadium.I've tested it on 1-minute clips and they play entirely.

imu1254 commented Dec 8, 2013

@vadmium Ok,I was being stupid :) I made changes on laptop and forgot to do it on Raspberry Pi so after I correct myself it seems that --player-wait fixed youtube issue :) well done Vadium.I've tested it on 1-minute clips and they play entirely.

@imu1254

This comment has been minimized.

Show comment
Hide comment
@imu1254

imu1254 Dec 8, 2013

@chrippa do you remember I said that omxplayer didn't get any args?Now I know why.. that was cos I've been manipulating with switches locally but they being read from remote machine so since I made changes in .livestreamerrc on Raspberry all is just perfect :) so I don't even have to include player in my ssh command. Silly me.

imu1254 commented Dec 8, 2013

@chrippa do you remember I said that omxplayer didn't get any args?Now I know why.. that was cos I've been manipulating with switches locally but they being read from remote machine so since I made changes in .livestreamerrc on Raspberry all is just perfect :) so I don't even have to include player in my ssh command. Silly me.

vadmium pushed a commit to vadmium/livestreamer that referenced this issue Dec 9, 2013

Martin Panter
cli: Always wait for the player process to exit.
The “--player-no-close” option would previously let the player continue to
run when Livestreamer exited. This meant that control could return to the
shell with the player still running in a background process. When
Livestreamer has finished sending the stream, it now blocks until the player
exits.

This avoids awkward behaviours with M Player and MPV, which do not work well
in some cases when running as a background process. I noticed that if their
standard input was _not_ used to stream the media (e.g. “--player-http”
mode), then they would change the terminal settings after Livestreamer
exited. This would interfere with Bash and Readline.

Apparently also fixes #234, avoiding a Screen session from terminating too
early.

@chrippa chrippa closed this in c38d020 Dec 9, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment