DTTV pid stats logging

In ,
Richard Kettlewell wrote:

Jim Lesurf writes:
Here's an example of the kind of code that *doesn't* work!

sprintf(commandstring,"exec xterm -fn 10x20 -sb -rightbar -sl 200 -e tzap
-rpc %s '%s' 2&1 | tee %s/%s_signal_log
&\0",listname,chname,outdirname,timestring);

printf("Tzap Command = %s\n",commandstring);

system(commandstring);

This command redirects the output of xterm itself, not of the command
executed by xterm. You want something along the lines of:
xterm -e 'tzap 2&1 | tee'
Be careful with quoting (see the Bash man page if you're not sure how it
works).

AIUI that 2&1 still won't do what Jim wants because it redirects stderr
to where stdout is currently being saved/piped then redirects stdout to
pipe into tee. This leaves stderr still going only to the terminal. I
don't know of any simple syntax that would allow stderr to be redirected
to stdout after stdout has been redirected to the tee pipe.

--
TH * http://www.realh.co.uk

Jim Lesurf wrote:
I'll tidy up the programs and put up better versions for anyone interest.

It's worth noting that the PIDs in the mux I looked at this morning
ranged in value up to 2010, but the PID table in dvbtraffic only allows
for 2000 values. Since I used the same size of table, bytes were being
modified in memory where they should have been left alone...

The theoretical maximum for the (unsigned) 13-bit PID field in the TS
packet is 8191 or 0x1FFF.

Tony Houghton writes:
AIUI that 2&1 still won't do what Jim wants because it redirects stderr
to where stdout is currently being saved/piped then redirects stdout to
pipe into tee. This leaves stderr still going only to the terminal.

That's not right. | happens first, then other redirections from left to
right.

chymax$ touch /does/not/exist 2&1 | tee spong
touch: /does/not/exist: No such file or directory
chymax$ cat spong
touch: /does/not/exist: No such file or directory

--
http://www.greenend.org.uk/rjk/

In article ,
Jim Lesurf wrote:

Also, what are you trying to achieve with the "\0" at the end of the
string?

Just my habit to make sure the string really ends with a zero char in case
some junk was already present in the memory space allocated to the string.
I tend to re-use a string like this during a program.

That won't work. You added an extra nul at the end of the literal string.
You can't "reuse" the literal string itself. And the sprintf() won't
copy it to commandstring, because it stops at the first null.

A side issue is that piping to a command rather than having the output
go direct to the terminal will cause the output to be block buffered by
default, so messages may not appear immediately. But presumably you are
getting enough output that this doesn't matter.

tzap just prints out one line of about 60 chars per second. Don't know what
level of pause you'd expect from the above. But a second or two won't be a
problem so far as I'm concerned.

If it is buffered, it will be buffered in some fixed size blocks,
quite likely 4096 bytes. That would be more than a minute. If the
messages are in fact coming from stderr instead of stdout, it should
not be buffered. If it turns out to be a problem, you can put a call
to fflush(stdout) after each printf() in tzap. Of course, they may
have anticipated this problem already. You can test it by running
"tzap | cat".

-- Richard

In article ,
Tony Houghton wrote:

Ah, so tzap is outputting to stderr instead of stdout. It would be nice
if you could use 2| to pipe stderr, but the authors of bash etc seem to
have overlooked that.

That's why pipes are done first. You can do

command 2&1 | something

which connects stdout to the pipe, then redirects standard error to
what stdout now is (i.e. the pipe).

To redirect stderr to a pipe while leaving stdout unchanged is, to say
the least, tedious.

-- Richard

Richard Kettlewell wrote:
Jim Lesurf writes:
In article , Dave Gibson
wrote:

snprintf (commandstring, sizeof(commandstring), "xterm -fn 10x20 -sb
-rightbar -sl 200 -e " "sh -c \"exec tzap -rpc %s '%s' 2&1 | tee
%s/%s_signal_log\" &", listname, chname, outdirname, timestring);

Yes! Thanks. That works fine. Excellent! :-))

I'm now puzzled/curious as to how and why. Is the sh -c changing or
nesting the shell?

Yes.


Nesting, but it's redundant here; xterm runs the -e command in a new
shell anyway.

Xterm tries to run everything following '-e' as-is. If that fails and
there is one argument the argument will be given to $SHELL via -c. If
there is more than one argument xterm will start an interactive shell
with an error message.

Succeed:

$ xterm -e '/bin/echo hello 2&1 | cat ; sleep 2'

Fail, interact with error, type exit to quit:

$ xterm -e '/bin/echo hello 2&1 | cat ; sleep 2' uh-oh

Succeed:

$ xterm -e sh -c '/bin/echo hello 2&1 | cat ; sleep 2'

Succeed:

$ xterm -e sh -c '/bin/echo hello 2&1 | cat ; sleep 2' uh-oh

The first two forms fail when prefixed with SHELL=/bin/csh due to the
sh redirection syntax.

Arguably it's slightly harmful since it adds another
layer of quoting that you have to get right.

Even if (as seems likely) the OP is using sh-as-$SHELL, the arguments
to -e would have to be crowbarred into a single string so the quoting
issue exists anyway:

system("xterm -e \"tzap 'channel name' 2&1 | tee signal_log\" &");

In ,
John Legon wrote:

Jim Lesurf wrote:
I'll tidy up the programs and put up better versions for anyone interest.

It's worth noting that the PIDs in the mux I looked at this morning
ranged in value up to 2010, but the PID table in dvbtraffic only allows
for 2000 values. Since I used the same size of table, bytes were being
modified in memory where they should have been left alone...

The theoretical maximum for the (unsigned) 13-bit PID field in the TS
packet is 8191 or 0x1FFF.

Someone typed 2000 when they meant 0x2000?

--
TH * http://www.realh.co.uk

Jim Lesurf wrote:


OK. No knowledge of that. Perhaps someone else can compare it with the 290e
I am using.

I can get the 290e to initially produce some TE flagged packets if I
start a (modified to report TE) dvbtraffic before tzap.

What I do see during logging is occasional sections where there is a
burst of many 'rare' PID values. At present I have no idea what causes
these, and if it they are real metadata, or the symptom of an error
like a brief desynch.

That's interesting. I've seen some unexpected values which could be
metadata, but will need to write some more code to be sure.

I was thinking of using dvbsnoop to pick these up once I had more idea of
what to look for.

Some of the initial errors above resulted in bogus pids showing.

Tony Houghton wrote:
In ,
John Legon wrote:

Jim Lesurf wrote:
I'll tidy up the programs and put up better versions for anyone interest.
It's worth noting that the PIDs in the mux I looked at this morning
ranged in value up to 2010, but the PID table in dvbtraffic only allows
for 2000 values. Since I used the same size of table, bytes were being
modified in memory where they should have been left alone...

The theoretical maximum for the (unsigned) 13-bit PID field in the TS
packet is 8191 or 0x1FFF.

Someone typed 2000 when they meant 0x2000?

Yes, it was me!! Sorry about that...

John Legon wrote:

The theoretical maximum for the (unsigned) 13-bit PID field in the TS
packet is 8191 or 0x1FFF.

And 0x1FFF is used for null packets. :-)