Plugin for Livestream.com not working right? exit's quickly for hls and not at all for normal streams

[Junior1544]

I am trying to get a live stream on livestreamer.com to work and i can't get it to play more then about 35 seconds...

When I run this command: streamlink "http://livestream.com/Miraclenet/events/5004281" 270p --fifo --player omxplayer

it gives me an error about an swf being needed. When I run this command: streamlink "http://livestream.com/Miraclenet/events/5004281" 270p_hls --fifo --player omxplayer

it will play the stream but just for about 35 seconds or so... I kinda don't want to have to restart it every 35 seconds to watch this stream... I'd like it to run until I stop it myself...

Any help for this non-python, non-linux guy would be very helpful...

btw, this is running on a Raspberry Pi. Just got a nice little 7 inch lcd for it and set it up on my desk to be able to watch it while I work, but can't get it to play for long at a time...

(edited to correct commands used)

[Junior1544]

A little additional information if it helps...

With the HLS stream, after about 35 seconds and it stops the text output on the command line says that the stream has ended...

[Vangelis66]

... For starters, this is the streamlink issue tracker; your original post commands seem to reference livestreamer:

livestreamer "http://livestream.com/Miraclenet/events/5004281" 270p --fifo --player omxplayer (snip) livestreamer "http://livestream.com/Miraclenet/events/5004281" 270p_hls --fifo --player omxplayer

If those are typos and you indeed meant "streamlink", then this is surely a duplicate of your previous #101 FWIW, I don't own a Pi to test, but on Windows (Vista SP2 x86):

streamlink -o "Miraclenet_270.ts" "http://livestream.com/Miraclenet/events/5004281" 270p =>

[Streamlink for Windows]
[cli][info] Found matching plugin livestream for URL http://livestream.com/Mirac
lenet/events/5004281
[cli][info] Available streams: 270p_hls, 486p_hls, 432p_hls, 270p (worst), 432p,
 486p (best)
[cli][info] Opening stream: 270p (akamaihd)
[cli][error] Could not open stream: A SWF URL is required to create session token

so this must be an issue with the plugin itself; the SWF URL on that page is: https://cdn.livestream.com/swf/LSPlayer.swf The POST request on my browser is: https://livestream-f.akamaihd.net/control/18265544_5004281_lsi8gash3zeu6woo8ja_1_678@25357?cmd=sendingNewToken&v=3.8.0.52&r=CVLHK&g=GPGJOYRSKNUS&lvl1=0,10,0.75,0,0,NaN,0,0,1,678,0,1479661942.435,0,0,0,0,5955,NaN,0,0,0,4628,u,false&swf=https%3A//cdn.livestream.com/swf/LSPlayer.swf Unless the non-hls streams are fixed by a dev in the know, switch to the hls ones, as suggested to you... Using latest streamlink code snapshot (git-96c0bfa), 270p_hls variant is dumped without interruptions: streamlink -o "Miraclenet_270.ts" "http://livestream.com/Miraclenet/events/5004281" 270p_hls =>

[Streamlink for Windows]
[cli][info] Found matching plugin livestream for URL http://livestream.com/Mirac
lenet/events/5004281
[cli][info] Available streams: 486p_hls, 270p_hls, 432p_hls, 270p (worst), 432p,
 486p (best)
[cli][info] Opening stream: 270p_hls (hls)
File Miraclenet_270.ts already exists! Overwrite it? [y/N] y
[download][Miraclenet_270.ts] Written 6.3 MB (3m3s @ 30.6 KB/s)

Here it is being played back in a Windows player:

So maybe the stream interruption you observe is related to Raspbian and/or omxplayer... Sorry I couldn't help more...

[Junior1544]

yes, that livestreamer part was a typo because that's what I used to use and I was away for a while taking care of some family business (My mother had past and I had to travel half way around the world almost, to help take care of some things and with one of the memorial services for her)...

and yes, I had closed that previous report because I got it to be playing for a short period of time and that was enough for then (about 35 seconds)... When you play the stream in windows media player with streamlink, how long will it play for? did you use mostly the same command as me but changing the player?

[stevekmcc]

I think this is due to a regression in livestream #1277 - see my updated comment there: https://github.com/chrippa/livestreamer/pull/1277#issuecomment-237193950 It's now been fixed by @intact on livestream (amazingly fast work, beat me to it!), so hopefully will be here soon.

[Vangelis66]

@Junior1544 Very sorry for your loss; my most sincere condolences...

The screenshot I posted was of a player (MPC-BE) playing back a downloaded .ts file - I, mostly, first download and then watch.

But I did try to use the "-p" switch to feed the stream in real time to VLC.exe and (although VLC did not display stream duration) the stream managed to play continuously for at least 5min, when I exited the player... (BTW, when MPC-HC 1.7.10, latest stable release, was tried, only the audio part of the stream was played back, with no video at all!). So, I guess, the hls streams look OK here...

EDIT: I managed to pipe the hls live stream to MPC-BE (that shows played stream duration), as you can see it was at 02:24 when the screenshot was taken:

[stevekmcc]

I just manually applied @intact's livestreamer changes (mentioned above) to streamlink's livestream.py, and can confirm @intact's fix works on streamlink too for non-HLS streams (thanks!). HLS streams stop after a minute or so still.

[beardypig]

@intact do you mind if we pull your patch for livestreamer in to streamlink?

[Junior1544]

I just did the code changes in my livestream.py that was in @intact's patch, and it seems to be working at about 4 minutes now... so much better then the 35 seconds I was getting before... I'm hoping it'll run for at least half an hour before stopping because that I can deal with!

I really hope this can be put into the next releases of the code base here because it'll make it so much easier to update to the next release of streamlink...

If I knew how, push the code in here myself, but i'm just barely learning the github system here and really don't know linux much yet... still very much a newbie here!

Thank you all for all your help and i'll post again once I have a better idea of how long this will run for before stopping on it's own... --James

[Junior1544]

ok, it's been running for almost 3 hours now without problem!

Thank you guys for pointing me to the right solution for this problem! maybe there can be an hls solution somewhere, but this is working great for me!

Thank you! --James

[Vangelis66]

Since no-one in this thread felt the need to comment, despite me posting screenshots, does any of the developers have any clue as to why the livestream hls stream seems to function properly here (no interruptions), whereas both the original poster (@Junior1544) and @stevekmcc experience sudden terminations (the former after 35secs, the latter after 1min or so)? Does streamlink (or the embedded Python 3.5.2) behave differently on Windows 32bit?

BTW, in one other experiment, I left the "MiracleNet" stream going on, it was still strong at 02h03min56sec when the following shot was taken:

Just being curious, that's all :smile:

[Junior1544]

Well, I'm using this on a raspberry pi and it's using python 2.7 i believe...

I don't know if that'll make any difference but just wanted to let you know...

[stevekmcc]

raspberry pi B+, Raspbian Jessie up to date, python 2.7, omxplayer. HLS streams probably haven't worked for months (at least they didn't in April nor now). I've attached debug output for an HLS run,with time logged at the start and end. hls.txt

[ghost]

I can't reproduce the '35 seconds bug' in both Python 2.7 and Python 3.5.2 maybe it depends on OS or Player (like @Vangelis66 say) ? In my case im using Windows 10

[stevekmcc]

Should we reopen this for the HLS bug when running on Raspberry Pi, or open a new issue for that? Or can an issue be split, so we could keep my HLS log and Vangelis66's screenshots? Also, to my understanding this issue should be labelled as a bug not a question.

[gravyboat]

@stevekmcc Did the PR that @beardypig made not work for you?

[stevekmcc]

@gravyboat The PR that @beardypig made was simply the fix by @impact that I mention in my first comment above. As my second comment says, manually applying that fix corrected non-HLS streams as expected, but did nothing for the HLS stream cutting out after 35-70 seconds - hence my third comment with debug output showing what happens when an HLS stream cuts out.

Similarly, in the comment where @Junior1544 says he manually integrated @impact's fix, he says non-HLS streams (the default) worked fine, and in his next comment he says HLS streams still fail. We're both on Raspberry Pi.

[beardypig]

There are two issues, the HLS streams were also reported as not working.

@Junior1544 @stevekmcc do any HLS streams work, or is it just livestream that fails?

Edit: fixed the words.

[Junior1544]

I've not tried other hls streams as I was only interested in the one livestream.com one.. I'd be happy to test others if given a url to try?

[stevekmcc]

@Junior1544 Which Raspberry Pi model do you have? Mine are both single core (Model 1 B and B+), which could be a factor in multi-threaded download of HLS segments - but easily ruled out if you have a Model 2 or 3.

Also, we are both using omxplayer and named pipes (--fifo), so we could try varying that. My full command line is:

streamlink  http://livestream.com/jklvapis/$TAIL \
    best -l debug --retry-open 10 --no-version-check --http-no-ssl-verify \
    -np 'omxplayer -o local --no-boost-on-downmix --amp 3000 --win "44 20 694 560"'

"-np ..." is just "--fifo -p ...", and "-o local" just tells omxplayer to use analogue not HDMI for audio.

[Junior1544]

@stevekmcc Hiya! Great to run into another Pi user 👍

I'm using a raspberry pi 3, it's also connecting to the internet via wifi (which is why i choose to use the lowest quality stream available)... i'm also showing the stream on the raspberry pi 7 inch lcd screen (which is also part of why i use a low quality stream, i don't need high qual for such a small screen)...

My full command line is: streamlink "http://livestream.com/Miraclenet/events/5004281" 270p --fifo --player omxplayer

Also, I did the pip upgrade so am using the most current pip available version of Streamlink and it's still playing the normal stream's fine... I'd be happy to check anything for you guys to try to get HLS working but I need directions because I barely know how to do what I want on it, am not a linux person and am learning slowly as I go...

--James

[beardypig]

@Junior1544 that would be very useful. Any twitch live stream should be hls...

[Junior1544]

just ran this command: streamlink "https://www.twitch.tv/cincinbear" medium --fifo --player omxplayer and the stream has been running for 5 minutes without problem... The initial response from streamlink said that it's an hls stream...

[beardypig]

Cool. Must be something specific to livestream HLS streams.. Probably best to reopen this as it has all the discussion for the HLS issue.

[Junior1544]

I wish I knew more about python so i'd be able to step through the code to find the problem...

[gravyboat]

@Junior1544 Everyone has to start somewhere! If you really want to dive into it this isn't a terrible project to start with, it has some complexities, but they aren't TOO bad. One of the things you might want to investigate first is using strace which allows you to see what system calls are occurring when you run a command like livestreamer that isn't directly a Python command, if you want to investigate this check out https://aboutthebird.wordpress.com/2013/03/02/interpreting-the-output-of-strace-line-by-line/ which while old goes over example strace output.

[stevekmcc]

So, the HLS bug requires any livestream HLS stream AND any Raspberry Pi. Given my hls.txt debug log above, a good place to start looking would be the data in err in streamlink_cli/main.py line 306 at the end here:

            try:
                output.write(data)
            except IOError as err:
                if is_player and err.errno in ACCEPTABLE_ERRNO:
                    console.logger.info("Player closed")

If the error is simply that omxplayer has already died at that point, then we should look at trying a different player, and/or debugging omxplayer with strace. (I presume that's what @gravyboat meant: omxplayer isn't a Python command, but livestreamer is, right?)

[Junior1544]

I don't have the time currently to dive into linux dev so much...

but, I would be happy to follow directions on what to do, or even allow someone to use teamviewer to control my pc to ssh into my pi to run some stuff yourself...

--James

[beardypig]

We can do a bit more experimentation before jumping in to the code or stracing. Does it work when saving to a file?

streamlink "http://livestream.com/Miraclenet/events/5004281" 270p_hls -o livestreamtest.ts

Or as @stevekmcc suggested, does it work in a different player using a fifo, it's been a while since I used my Pi so I don't know what players are available...

[stevekmcc]

We could both add -g to our omxplayer command line (--player 'omxplayer -g'), to make it write omxplayer.log, and then post that here. I'll try debugging the Python too...

[beardypig]

You should be able to pass -v to streamlink to get the console output of omxplayer :-)

[stevekmcc]

Thanks - good to have that too. I believe -g is more in-depth, omxplayer stdout/stderr is pretty quiet by default IIRC, and tends to die with just "Have a nice day" :)

[beardypig]

Haha. Might be useful to see when that occurs :-)

[beardypig]

I'd try saving the steam to a file, if it works then trying to play back the file with omxplayer and see if omxplayer quits are 35 seconds or not?

[stevekmcc]

Looks like adding --timeout 20 to the omxplayer command line should fix the problem, according to a StackOverflow post So: --player 'omxplayer --timeout 20' I'll test this evening when I'm back at my Pi.

[beardypig]

Interesting, wonder what the root cause is... Would be good to see if it saves to a file still.

[Vangelis66]

@beardypig wrote:

Does it work when saving to a file?

streamlink "http://livestream.com/Miraclenet/events/5004281" 270p -o livestreamtest.ts

... Just a heads-up; quality variant "270p" IS NOT a hls stream, it's an akamaihd stream, fixed by the recent PR mentioned earlier in this thread; and, FWIW, the file dumped to disk is in the FLV container (file extension .flv), not MPEG-TS (the default container for AppleHLS streams).

What @Junior1544 should try is:

streamlink -o "livestreamtest_270p.ts" "http://livestream.com/Miraclenet/events/5004281" 270p_hls

(though not sure where exactly within the Pi folder structure that recorded file is to be found; possibly at $HOME, I'm sure he knows best...).

[beardypig]

Yeah, that, @Vangelis66

[stevekmcc]

--player 'omxplayer --timeout 20' does indeed solve the problem: 10 minutes and no problems. So, not really a bug in either tool, just a difference in options needed depending on the stream type. (Edit: Adding --timeout 20 doesn't seem to harm non-HLS streams either.)

For the record, changing line 306 in streamlink_cli/main.py to : {0}", err) showed "Player closed: [Errno 32] Broken pipe". That might be a worthwhile change, but I'll leave it to someone more familiar with the code base. Adding -v to streamlink arguments did indeed just show omxplayer saying "have a nice day ;)" - here's the output at the end without --timeout 20:

[stream.hls][debug] Download of segment 147984720 to queue
[cli][info] Player closed: [Errno 32] Broken pipe
[stream.hls][debug] Closing worker thread
[stream.hls][debug] Closing writer thread
have a nice day ;)
[cli][info] Stream ended

In omxplayer.log without --timeout 20, you can see what I believe is the amount of audio and video left to play decreasing in the second A: and V: values on each DEBUG line, until it gets to zero. The last lines (omitting timestamps) are:

DEBUG: Normal M: 39869268 (A:39923544 V:39933000) P:0 A:0.05 V:0.06/T:0.20 (1,1,,0,0) A:0% V:0% (-0.46,9.32) 
INFO: COMXVideo::IsEOS
INFO: COMXAudio::IsEOS
DEBUG: OMXClock::OMXStop
DEBUG: OMXThread::Run - Exited thread with  id -1346165728
DEBUG: OMXThread::StopThread - Thread stopped
DEBUG: OMXThread::Run - Exited thread with  id -1337777120
DEBUG: OMXThread::StopThread - Thread stopped

and so on, shutting down.

[stevekmcc]

@Junior1544 could you confirm that --player 'omxplayer --timeout 20' solves the HLS stream problems for you too? Then the moderators can close this issue.

[beardypig]

If the timeout option that @stevekmcc has suggested is a sufficient fix for everyone we can update the players page in the docs and close this issue.

[Junior1544]

Okey, I ran it for several hours with the --timeout 20 option for omxplayer, and it looks to be working about equally as well as the normal akamai player now!

I'm extreemly happy with streamlink now as I was so frustrated with livestreamer for some time!

I'd love for there to be a way for me to donate to the head people here, just a few bux to buy you guys a coffee or something :)

[beardypig]

Excellent, thanks @Junior1544!

Can either of you @Junior1544 or @stevekmcc test streamlink with omxplayer using the --player-http option. eg.

streamlink -p "omxplayer" --player-http "http://livestream.com/Miraclenet/events/5004281" 270p_hls

I'm updating the docs and want to know if omxplayer will work with the --player-http option :)

[Junior1544]

@beardypig I just put that command into my pi and it started playing but it looks like it just plays for a short time, about the same as the hls stream without the --timeout 20 option in it.

I tried it with the --timeout 20 option and it looks like it doesn't play at all, it finds the stream and all, but nothing comes on the screen at all...

Now, this is on the Raspberry pi 3 with the latest Raspian software...

Hope that helps!

[Junior1544]

OH!

I had put the command like you asked into my player script, and it started looping (I do this so that every time it stops, it just starts back up)... It just decided to start playing the video with the command you gave me! it must have taken 10 times trying it before it started so I would call it unstable, but there ya go, i guess it can work sometimes...

--James

[beardypig]

Thanks, unless someone knows the correct command line options I guess we'll mark it as not working for --player-http. I'll try and get my Pi setup this weekend and give it a go...

[stevekmcc]

Ha, both of us are testing at the same time! With and without --timeout 20 that --player-http command drops in less than a minute (Raspberry Pi model 1 B). I'm SSHing in, so I can't see whether the video or a blank screen was displayed.

[beardypig]

Cool! Maybe one of you can try --player-continuous-http? Bit of a long shot though :-)

[Junior1544]

Using this command: streamlink "http://livestream.com/Miraclenet/events/5004281" 270p_hls --fifo --player-continuous-http --player 'omxplayer --timeout 20'

The stream started right up and has been playing for over 1 minute so far but i will let it keep going and update you shortly...

[beardypig]

What did it say in the logs? Cos you have --fifo in the command which might have precedence over the http option.

[stevekmcc]

There may (or may not) have been some problem on my Pi before in the trial with --player-http - it said 'opening omxplayer' but nothing after that until dropping the stream; at the end of the session I found several streamlink and omxplayer processes running. Let's ignore my results for that (sorry, can't test further on that Pi just now).

Now with --player-continuous-http it shows normal streamlink output about the stream after the 'opening omxplayer' message, and plays correctly. Without omxplayer --timeout 20 it drops after less than a minute, with the increased timeout it continues playing fine.