Livestreamer + Omxplayer Help!

[imu1254]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

@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]

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]

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]

@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]

@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.