MistInBuffer Error

[Peter Griggs]

Hello,

if my stream gets disconnected, when I reconnect I get lots of [2015-06-03 20:54:38] WARN: MistInBuffer|2128||Received packets for track 1 in wrong order (11165 < 27693) - ignoring! in the logs and the stream plays just before it gets cut off and goes no further.

I am wanting to use this to stream my wedding in a couple of weeks and worried this will ruin the stream, please help!

Cheers

Peter

[Jaron Vietor]

Hello Peter,

This happens when you reconnect before the old connection times out (in the open source edition), if the time difference between the new and old connections is less than double the buffer duration (30 seconds by default - so you must have been streaming for less than ~1-2 minutes).

Waiting ~15 seconds or longer in between the reconnects will make everything work again, or you can wait until the timestamps sync back up again (in this case, ~16 seconds after this message was printed), which under the default configuration is at most two minutes.

In other words: this is the kind of problem you usually only have for a short while, and only when you're rapidly setting up new connections.

In pratical situations this rarely (if ever) happens. I'd advice you to try a longer duration stream (at least a few minutes before you reconnect) and you'll see the system works much better then.

Regards,

Jaron Viëtor

CTO, DDVTech

--
You received this message because you are subscribed to the Google Groups "Mistserver.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mistserver+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Griggs]

Hi Jaron,

I will be attempting to do this from a cruise ship where the latency is going to be hit and miss, this is for close family that can't make it.

Is there anyway of lowering this difference?

Best Wishes.
Peter

[Peter Griggs]

Hi Jaron,

Also getting this alot on my website:

On Wednesday, 3 June 2015 20:56:44 UTC+1, Peter Griggs wrote:

[Jaron Vietor]

Hello Peter,

Your last error is because HDS requires a fair amount of data to be present before the stream will work, and HDS is the default streamout method when Flash player is installed.

If you disable/remove the HDS output in the protocols section of the configuration page, that should resolve your problem as it will fall back to other streaming methods then.

Bad latency shouldn't be a problem, as long as you can sustain the bandwidth long-term.

If you cannot sustain the bandwidth for your stream, it's best to use a method that stays connected but drops frames when throughput goes down. Most RTMP push clients will do this for you automatically already, with the exception of FMLE which does not.

Lowering the timeouts altogether can be done by lowering the buffer size (eg: 10000 ms instead of the default of 50000 ms) and segment size (eg: 2000 ms instead of the default of 5000 ms) while lowering your source keyframe interval (a keyframe once every 1-2 seconds is usually a good value). Do note that this has a side effect of increasing the bandwidth usage slightly.

Hope that helps!

- Jaron

--

[Peter Griggs]

Hi Jaron,

Thanks for this .... I am also seeing:

[2015-06-03 21:29:08] FAIL: MistOutHDS|2287||Timeout while waiting for requested page. Aborting.

Which results in Error: No protocols found on the display page on my wedding website.

Any ideas?

[Jaron Vietor]

Hello Peter,

That error usually means the stream is not currently active/broadcasting.

If it is in fact active already, try again in a few seconds and it should work.

- Jaron

[Peter Griggs]

Hi Jaron,

Will give it ago...Maybe I should try something rather than FMLE ....Any suggestions?

[Jaron Vietor]

Hello Peter,

It depends on what kind of system you're using:

Under Linux or Mac, ffmpeg is usually the best solution, though it is command-line software and thus takes some practice to work with correctly.

Under Windows (or if you prefer a GUI on Linux/Mac), XSplit and OBS (Open Broadcaster Software) are commonly chosen alternatives.

- Jaron

[Peter Griggs]

Hi Jaron,

I have just been streaming for the last 20 mins... the player now just says "buffering" any idea?

Sorry for being a pain just trying to get everything perfect for the big day!

[Jaron Vietor]

Hello Peter,

The client saying "buffering" can mean almost anything. Unfortunately clients aren't very precise in printing error messages.

To get more information about the system, try setting the debug level of the server to 8 and checking the logs. That should give you a little more insight.

Level 4 is what we usually use for development purposes, and level 8 for in-depth debugging and fault analysis. You may want to try 4 first if you find 8 too spammy.

(Run the controller as "MistController --debug 8", for example)

- Jaron

[Peter Griggs]

Hello,

Getting:

[2015-06-03 22:31:40] INFO: MistOutHDS|2674||Received request /dynamic/weddinglive/1-Seg1-Frag2

[2015-06-03 22:32:04] INFO: MistOutRTMP|2670||We should go to next page now, transition from 1 to 11

[2015-06-03 22:32:04] INFO: MistOutRTMP|2670||Succesfully registered page 1 on the metaPage of track 12~>1.

[2015-06-03 22:32:04] INFO: MistOutRTMP|2670||Start buffering page 11 on track 12~>1 successful

Player gets stuck on buffering at last event, tried from PC and Mobile.

[Jaron Vietor]

Hello Peter,

That all looks fine and should be working, actually.

However, you do still have HDS enabled - have you tried disabling that yet? Protocols -> HDS -> Remove/delete, in the interface.

- Jaron