[Question] HTTP Live Streaming Issues (1 Viewer)

[jwdempsey]

I am working on a Plex channel that integrates with MediaPortal using the WSS API. I am having some troubles with the HTTP Live streaming profiles though. Essentially, in each Plex client the first .ts segment loads succesfully but nothing after that. I've check the playlist file and new .ts files are being added. I actually installed aMPDroid a few nights ago and noticed the exact same issue (or at least it seemed similar). The first 5-7 seconds will play but then error out after that. I am attaching my log files in the hopes that someone might be able to help me out. Let me know if any more information is needed. Thanks!

Plex Channel on Github

 

[Oxan]

There doesn't sem to be anything strange in the log files. Can you try to stream a movie or something instead of live TV? Does your video player give some kind of error or message about why it stops playing?

 

[jwdempsey]

There doesn't sem to be anything strange in the log files. Can you try to stream a movie or something instead of live TV? Does your video player give some kind of error or message about why it stops playing?

I don't have any movies stored in MediaPortal because I don't use the MP client. I will try and set that up soon for testing purposes. As far as errors go I don't get any in Plex. The android client simply stops and goes back to the list of channels. The web client uses JW Player which does handle HTTP Live Streams normally. I do get an error on the screen in aMPdroid though.

It says this:
MEDIA_ERROR_UNKNOWN, extra:-1007

I have noticed that most other HTTP Live Streams will remove previously requested segments. Could that be whats going on here? I'm wondering if aMPdroid and Plex will look at the first segment in the playlist and see that its never updated and think the video has completed?

 

[Oxan]

You can also try with a recording. It's about ruling out the live TV code, which seems to give some minor errors in your logs

The aMPdroid error is interesting. I'm not sure, but I think it implies that it can't find the file it wants to download. That might indicate that it tries to download a segment that's not available yet. @DieBagger?

Regarding deleting segments, we also do that, but we keep the last five (or ten, don't remember exactly) segments. That shouldn't cause any problems.

 

[jwdempsey]

I tried streaming a recording this afternoon and it worked really well.

 

[Oxan]

Hmm, that's interesting. I can't find anything bad in your logs though... does streaming live TV with a non-HLS profile work?

 

[jwdempsey]

Hmm, that's interesting. I can't find anything bad in your logs though... does streaming live TV with a non-HLS profile work?

No, both FFmpeg and VLC both stop after 3-5 seconds. I see the following error on screen in aMPdroid:
MEDIA_ERROR_SERVER_DIED, extra:0

I am attaching my latest logs. What does the "pipe is broken" error mean?

 

[Oxan]

No, both FFmpeg and VLC both stop after 3-5 seconds. I see the following error on screen in aMPdroid:
MEDIA_ERROR_SERVER_DIED, extra:0

The MEDIA_ERROR_SERVER_DIED error usually indicates that the codec has encountered a bug and crashed, and shouldn't be related to problems in the video stream.

I am attaching my latest logs. What does the "pipe is broken" error mean?

MPExtended uses pipes to write the original video stream to the transcoder (ffmpeg/VLC) and to get the transcoded stream back. The error means that a process has closed one of the pipes, and that a subsequent read or write failed. However, that's a totally normal situation when the stream should be stopped. MPExtended kills the transcoder, which closes the pipes before it exits. MPExtended is still copying input data to the pipe and reading output data from the pipe, so it gives an error. It would be a bit neater if we could stop copying the input data and reading the output data before we kill the transcoder, but that'd require some complicated code in the streaming service. This works too, and doesn't hurt anything.

If you look closely, you'll see that those errors always happen immediately after a FinishStream call. They're not related to your problem.

It's a bit problematic for me to debug your problem, as I can't reproduce it on my system, and there aren't any errors in your logs either. I suspect it might have something to do with the transcoder speed: the transcoder isn't finished with the next segment before the client requests it. I don't have any proof for that though, and it's quite hard to prove without manually inspecting the stream in real-time. The fact that streaming recordings works fine seems to oppose this theory too.

It could also be useful to (manually, probably) try a Direct stream of the live TV. If streaming that (i.e. maybe it doesn't playback, but MPExtended keeps sending data) doesn't work either, it's for sure that the problem is in the TsBuffer reading code. However, I'd really expect some more errors in your logs then.

 

[jwdempsey]

No, both FFmpeg and VLC both stop after 3-5 seconds. I see the following error on screen in aMPdroid:
MEDIA_ERROR_SERVER_DIED, extra:0

The MEDIA_ERROR_SERVER_DIED error usually indicates that the codec has encountered a bug and crashed, and shouldn't be related to problems in the video stream.

I am attaching my latest logs. What does the "pipe is broken" error mean?

MPExtended uses pipes to write the original video stream to the transcoder (ffmpeg/VLC) and to get the transcoded stream back. The error means that a process has closed one of the pipes, and that a subsequent read or write failed. However, that's a totally normal situation when the stream should be stopped. MPExtended kills the transcoder, which closes the pipes before it exits. MPExtended is still copying input data to the pipe and reading output data from the pipe, so it gives an error. It would be a bit neater if we could stop copying the input data and reading the output data before we kill the transcoder, but that'd require some complicated code in the streaming service. This works too, and doesn't hurt anything.

If you look closely, you'll see that those errors always happen immediately after a FinishStream call. They're not related to your problem.

It's a bit problematic for me to debug your problem, as I can't reproduce it on my system, and there aren't any errors in your logs either. I suspect it might have something to do with the transcoder speed: the transcoder isn't finished with the next segment before the client requests it. I don't have any proof for that though, and it's quite hard to prove without manually inspecting the stream in real-time. The fact that streaming recordings works fine seems to oppose this theory too.

It could also be useful to (manually, probably) try a Direct stream of the live TV. If streaming that (i.e. maybe it doesn't playback, but MPExtended keeps sending data) doesn't work either, it's for sure that the problem is in the TsBuffer reading code. However, I'd really expect some more errors in your logs then.

I apologize for not mentioning this earlier but the direct stream option works really well. I've used that many times for several hours straight without any issues whatsoever.

To test your theory I can delay the completion of the stream request by calling a sleep() method. I'm wondering if that might give the transcoder a few extra seconds to finish a another segment or two. Is it possible to set a config flag someplace to make each segment a little longer?

Do you think this might be a hardware issue on my end? I don't have the latest processor but it is dual core.

 

[Oxan]

I apologize for not mentioning this earlier but the direct stream option works really well. I've used that many times for several hours straight without any issues whatsoever.

Ok, great, it's probably related to the transcoder then.

To test your theory I can delay the completion of the stream request by calling a sleep() method. I'm wondering if that might give the transcoder a few extra seconds to finish a another segment or two. Is it possible to set a config flag someplace to make each segment a little longer?

You can change the segment length by replacing seglen=7 with seglen=10 (for example) in the relevant profile in C:\ProgramData\MPExtended\StreamingProfiles.xml. Note that VLC generally makes the segments a bit shorter than specified.

Do you think this might be a hardware issue on my end? I don't have the latest processor but it is dual core.

It could be, doesn't have to be.