Tvheadend

Ahh yes ofcause, ill test with matroska, but I think you can close this one.

It makes no sence to me that we do not wana count cc errors if the client is using mux pass.
The freaking errors is spammed in the logfile when using mux pass, its just not counting, but whatever

Danny, you said close it, I closed it.

Counting errors is fine, but passthru generally doesn't see any errors since they're parsing errors (passthru doesn't parse). If it's not logging HTTP/MKV errors, then sure it could probably be changed. But I'm not in the habit of asking questions, getting no definitive answer (other than a vague statement to close) and then leaving stuff open.

Adam

Youre right, part of that was due to my stupidity at that time, not understanding what was going on, and im sorry for that.

Even if the client is http pass this is logged :

2014-04-09 17:48:47.138 TS: 11785H/Trace Urban HD: H264 #1353: Continuity counter error, 9 duplicate log lines suppressed
2014-04-09 17:48:48.227 TS: 11785H/Trace Urban HD: H264 #1353: Continuity counter error, 18 duplicate log lines suppressed
2014-04-09 17:48:49.875 TS: 11785H/Trace Urban HD: H264 #1353: Continuity counter error, 24 duplicate log lines suppressed
2014-04-09 17:48:50.328 TS: 11785H/Trace Urban HD: H264 #1353: Continuity counter error, 27 duplicate log lines suppressed

Not having considered the consequences, I would say its smarter to make the subscription error field count those, instead of from parsing the a/v packets ?

I think things like TE and CC should probably be logged, but in separate fields.

Adam

But will there ever be a/v parsing errors without TE or CC ? Whats the idea of not just counting the most basic error indicators.

Mostly it would be a result of the TE/CC errors, however it could be a result of a failed decryption or a failed parser (bug). So worth tracking them as well I think.

Adam

I see it made it to master, nice job, and you made it NOT reset the TE / CC counter when a stream is stopped and started again, thats sweet =)