Project

General

Profile

This project is closed and read-only.

Actions
Copy link

Bug #1903

closed

errors on status page only counting when client is htsp

Bug #1903: errors on status page only counting when client is htsp

Added by danny skjodt over 12 years ago. Updated over 12 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2013-12-31
Due date:
% Done:

0%

Estimated time:
Found in version:
last master from git
Affected Versions:

Description

Another easy one, only when client is htsp does errors on the status page update, example add a dvr a http and a htsp of the same channel, introduce some lag, and only the htsp client will get a number of errors besides it, the other 2 will have 0.

Updated by Adam Sutton over 12 years ago Actions
Copy link
 #1

  • Status changed from New to Need feedback

What is your default recording format? If its TS (passthru) then that makes sense.

Currently the subscription error field reports errors detected during parsing of the A/V packets. Which does not happen for passthru.

Adam

Updated by danny skjodt over 12 years ago Actions
Copy link
 #2

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

Updated by Adam Sutton over 12 years ago Actions
Copy link
 #3

  • Status changed from Need feedback to Rejected

Updated by danny skjodt over 12 years ago Actions
Copy link
 #4

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 :)

Updated by Adam Sutton over 12 years ago Actions
Copy link
 #5

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

Updated by danny skjodt over 12 years ago Actions
Copy link
 #6

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 ?

Updated by Adam Sutton over 12 years ago Actions
Copy link
 #7

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

Adam

Updated by danny skjodt over 12 years ago Actions
Copy link
 #8

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.

Updated by Adam Sutton over 12 years ago Actions
Copy link
 #9

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

Updated by danny skjodt over 12 years ago Actions
Copy link
 #10

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 =)

Actions
Copy link

Also available in: PDF Atom