Tvheadend

--trace parser : https://tvheadend.org/projects/tvheadend/wiki/Traces , use latest

Full trace log, one channel start .. 30 seconds .. stop.

I forgot to mention that this is very intermittent and for example now I do not see these messages in the tvh log. I can not even figure out if this is related to particular channel, because I do not see any related channel name or ID anywhere.

So before if I do those 30 seconds, I need to figure out when it is happening and with what channel(s), otherwise you would not see anything useful in there.

New observation in relation to this issue. See picture below.

1 - As you can see subscriber number 1 is not receiving any htsp data (tvh/ffmpeg not outputting anything just receiving) and tvh log shows lots of "DTS and PCR diff is very big" messages.

2 - When I open very same stream during this happening, everything works just fine. Subscription is 2 receiving htsp data properly.

If I than restart the channel (disable and re-enable channel under channels tab) both htsp clients start receiving stream without "DTS and PCR diff is very big" messages.

After adding "tprofile" in HTS Tvheadend 4.3-1233~g4fe0af0 this issue is occuring with much lower frequency, but still occurs time to time.

I'll monitor it and post further observations.

I've noticed today, that these "DTS and PCR diff is very big" messages start to occur if there is an internet connection speed reduction on the user side (client download speed).

You can easily reproduce this issue with upload bandwidth throttling.

Shouldn't be parser stability resistant or rather independent from client internet download speed fluctuations?

M3U8 streams are received by ffmpeg properly as there is no internet speed fluctuation on the reception side (server download).

kodiaq kodiaq wrote:

I've noticed today, that these "DTS and PCR diff is very big" messages start to occur if there is an internet connection speed reduction on the user side (client download speed).

You can easily reproduce this issue with upload bandwidth throttling.

Shouldn't be parser stability resistant or rather independent from client internet download speed fluctuations?

M3U8 streams are received by ffmpeg properly as there is no internet speed fluctuation on the reception side (server download).

I had similar problems, after a connection speed reduction in the client (tvheadend) stream is never recovered, receiving (in my case) constant continuity errors until restarting the stream.

kodiaq kodiaq wrote:

M3U8 streams are received by ffmpeg properly as there is no internet speed fluctuation on the reception side (server download).

there is no such ting as M3U8 stream
there is a HLS streams they are no so Live streams usually they are 10 seconds behind

HTTP-TS stream used by TVH is continuous stream but some players can't handle temporary "lag by speed" events and need to restart stream to synchronise
so it is problem of player not of server
Same can be seen with Infomir MAG devices

saen acro wrote:

kodiaq kodiaq wrote:

M3U8 streams are received by ffmpeg properly as there is no internet speed fluctuation on the reception side (server download).

there is no such ting as M3U8 stream
there is a HLS streams they are no so Live streams usually they are 10 seconds behind

HTTP-TS stream used by TVH is continuous stream but some players can't handle temporary "lag by speed" events and need to restart stream to synchronise
so it is problem of player not of server
Same can be seen with Infomir MAG devices

Then, TVHEADEND as client also has this problem.

The problem is in FFMPEG.
TVH use FFMPEG

kodiaq kodiaq kodiaq: I think that there's lowlatency switch for ffmpeg which might help in this. It seems that ffmpeg does own buffering (thus those sines in graph).

The PCR/DTS diff around 1878356 means that there's 20 seconds diference which is obviously wrong. Again, show the parser trace logs for one channel to analyze.