Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> pchdtvr 1.0-rc11 Goto page Previous  1, 2, 3  Next
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
Re: config T-line example
PostPosted: Sun Mar 05, 2006 5:32 pm Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




cheema wrote:
Ideally this information should be part of the software distribution tarball. Maybe a timers.txt file.


I doesn't need to be in a seperate file, it can be in the conf file with the other examples. But in general documentation is needed.

Also needed: A way to turn off the excessive colorization and/or a way to reverse the video colors, like the bittorrent curses client.

BTW if I set up a timer for two VC on one channel at the same time can pchdtvr write two files from one incoming stream? How can I watch the second stream from a full stream ts file?
View user's profile Send private message Visit poster's website
Re: config T-line example
PostPosted: Sun Mar 05, 2006 9:51 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Hey y'all,

I can flesh out the conf.sample file with some real examples to illustrate it better. README is the top 1600 lines of the source file. Will work on making it a sub-dir tarball instead of current directory.

Excessive colorization complaint was already addressed under reducing bandwidth for remote ssh control.

Look at Makefile and add pchdtvr-ssh to list of PROGS. However, each color means something and it is not quite as informative-at-a-glance without them.

If you want the video reversed, use this:

# -T -n set the title and mini-title, -e executes
xterm -fg white -bg black -T pchdtvr -n pchdtvr -e pchdtvr

It only works right with xterm. It is designed for kernel vga=ask 132x60 console, so that's why. Try "man console_codes" to see what I'm using.

Known working terminal types are:
TERM="linux"
TERM="xterm"
TERM="rxvt"

Terminal type "linux" on a real console is the only one I can say works like I wanted it to, but the other two seem to work well enough with limitations on size. rxvt is what ssh uses. All three use the same console_codes.

xterm only seems to draw correctly for 132x30, so that's the terminal resize limit you should keep in mind when you're dragging the corner of the xterm. One day I'll find the termio ioctl that fixes it.

If you want two virtual channels from the same physical channel, you can do a full capture and use atscut (or any other tool) to extract each virtual channel PID stream. These hex PIDS are typically 0000=PAT 0030=PMT 0031=VID 0034=AUD for first virtual channel.

[v] key in pchdtvr tells you the video and audio, but you still have to get PAT + PMT if you want to play it back later without a lot of bother.

Alternately, if you have xine-hd 0.7 you can use -c x.3 for program 3 of the full stream. xine-hd 0.8 has option -C for same effect. mplayer lets you select the PIDS to use from the full stream, too.

I have actually managed to play both streams simultaneously from the full capture, but the machine was too slow to decode both HD and SD in a timely manner. [Two SD's from same full stream file worked fine, as well as two different SD single VC caps. Might be able to get 4 at once!]

A faster machine with dual DVI overlays, like Nvidia 66600GT might be able to drive a dual head video setup.

Since you can see them both, the problem then becomes to which one do you listen?


Hope that helps,

-ink




tupari wrote:
cheema wrote:
Ideally this information should be part of the software distribution tarball. Maybe a timers.txt file.


I doesn't need to be in a seperate file, it can be in the conf file with the other examples. But in general documentation is needed.

Also needed: A way to turn off the excessive colorization and/or a way to reverse the video colors, like the bittorrent curses client.

BTW if I set up a timer for two VC on one channel at the same time can pchdtvr write two files from one incoming stream? How can I watch the second stream from a full stream ts file?


Last edited by inkling on Tue Mar 07, 2006 2:30 am; edited 1 time in total
View user's profile Send private message
Re: config T-line example
PostPosted: Sun Mar 05, 2006 10:53 pm Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




inkling wrote:
Hey y'all,


If you want two virtual channels from the same physical channel, you can do a full capture and use atscut (or any other tool) to extract each virtual channel PID stream. These hex PIDS are typically 0000=PAT 0030=PMT 0031=VID 0034=AUD for first virtual channel.

So what exactly are the arguments to atscut? And what does this output mean?

Code:
atscut 0.9.8 Copyright (C) 2004-2005 inkling@nop.org
Released under the GNU General Public License Version 2
Using /mnt/usb-hdd/StargateAtlantis-0226-1700.0.ts for input name
Using 0.329968 for xine time scale, inverse 3.030598
Using 12898.145000 for given packet rate
Input file size 6,349,299,936
Input file packets 33,772,872
Input file calc seconds 2618.43

ATSC timebase Sun Jan  6 00:00:00 1980: unix diff 315982800 TZ diff -18000
Testing packets in /mnt/usb-hdd/StargateAtlantis-0226-1700.0.ts
EOF in 0 bytes

Blocks 33,772,873: Packets 33,772,872, PES packet 33,719,190, Errors 211
Transport Errors: 0: Sync 0 Scrambled 0 Continuity 211
ATSC____ _____MGT _____VCT _____EIT _____ETT _____RRT
       0        0        0        0        0        0
ATSC CRC        0        0        0        0        0
MPEG____ _____PAT _____CAT _____PMT _____VID _____AUD
33772872    35728        0    35908 33158207   560983
MPEG CRC        0        0        0        0        0

ATSC PID counts:

MPEG PID counts:

    0000 #    35728
    0030 #    17954    0031 # 33158207    0034 #   560983

processed 6,349,299,936 bytes in 533 seconds, 11MB/s
MPEG Stream Elapsed 1078174 89886/90000 Seconds from AFC PCR

inkling wrote:

Alternately, if you have xine-hd 0.7 you can use -c x.3 for program 3 of the full stream. xine-hd 0.8 has option -C for same effect. mplayer lets you select the PIDS to use from the full stream, too.

I never got xine-hd to work. I have a working xine install and I'm not going to mess it up. I just want to take a raw ts file and output 2 ts files.
Code:
View user's profile Send private message Visit poster's website
atscut
PostPosted: Mon Mar 06, 2006 4:49 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




It looks like I accidentally broke the -k extract in atscut. [in my latest test version, fixed now]

If this doesn't work [should be OK on the nop.org version]:

file1:
$ atscut -k0 -k30 -k31 -k34 fullcap.ts 0 99999
$ cp fullcap-00.ts file1.ts

file2:
$ atscut -k0 -k40 -k41 -k44 fullcap.ts 0 99999
$ cp fullcap-00.ts file2.ts

then try dtvstream or dvbstream to extract by program #.

[atscut cut by time is removed in favor of xtscut code now, so no need for 0 99999 with the next version.]

-ink
View user's profile Send private message
PostPosted: Wed Mar 08, 2006 7:43 pm Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




BTW How come SIG% doesn't change while a program is recording?
View user's profile Send private message Visit poster's website
Why SIG% doesn't change during capture
PostPosted: Wed Mar 08, 2006 8:42 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




tupari wrote:
BTW How come SIG% doesn't change while a program is recording?


Back in the early days of the driver, trying to read the signal strength during capture would cause the stream to glitch.

I have been meaning to try it again. Maybe the i2c hardware fix will allow it to work without glitching.

Did you try the [s] key statistics and the [f] key capture log?

-ink
View user's profile Send private message
PostPosted: Mon Mar 13, 2006 10:19 pm Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




I keep getting core dumps. How do I build it with debug symbols so I can give you a backtrace?
View user's profile Send private message Visit poster's website
PostPosted: Tue Mar 14, 2006 12:24 am Reply with quote
dieter
 
Joined: 20 Jan 2005
Posts: 43
Location: US




tupari wrote:
I keep getting core dumps. How do I build it with debug symbols so I can give you a backtrace?


Add -g ?
View user's profile Send private message
PostPosted: Tue Mar 14, 2006 9:21 am Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




dieter wrote:
tupari wrote:
I keep getting core dumps. How do I build it with debug symbols so I can give you a backtrace?


Add -g ?


That doesn't work, I'm still not getting symbols in the backtrace.

Code:
]# gdb - core.18467
GNU gdb Red Hat Linux (6.1post-1.20040607.43.0.1rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
welcome to change it and/or distribute copies of it under certain conditi
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for detail
This GDB was configured as "i386-redhat-linux-gnu"...-: No such file or d
y.

Reading symbols from shared object read from target memory...(no debuggin
ls found)...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
Loaded system supplied DSO at 0xb7fec000
Core was generated by `pchdtvr -W'.
Program terminated with signal 11, Segmentation fault.
#0  0x08049a67 in ?? ()
(gdb) bt
#0  0x08049a67 in ?? ()
#1  0x0807b1e0 in ?? ()
#2  0xeaf9c906 in ?? ()
#3  0x00000002 in ?? ()
#4  0x00000006 in ?? ()
#5  0x0000007e in ?? ()
#6  0x0807b3e0 in ?? ()
#7  0xa0a00001 in ?? ()
#8  0x00028280 in ?? ()
#9  0xb6b25358 in ?? ()
#10 0x08060dc8 in ?? ()
#11 0x08b29705 in ?? ()
#12 0x09098f45 in ?? ()
#13 0x000001e8 in ?? ()
#14 0x00000023 in ?? ()
#15 0x00000002 in ?? ()
#16 0x09098f30 in ?? ()
#17 0x08b296ee in ?? ()
#18 0x00676e65 in ?? ()
#19 0x00000000 in ?? ()
(gdb) quit
View user's profile Send private message Visit poster's website
PostPosted: Tue Mar 14, 2006 12:27 pm Reply with quote
GrepTar
 
Joined: 10 Jan 2005
Posts: 51




I thought you were supposed to type:
gdb ./pchdtvr core.18467
View user's profile Send private message
PostPosted: Tue Mar 14, 2006 1:34 pm Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




GrepTar wrote:
I thought you were supposed to type:
gdb ./pchdtvr core.18467


Alright that gives me:
Code:
]# gdb `which pchdtvr` -c core.18467
GNU gdb Red Hat Linux (6.1post-1.20040607.43.0.1rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xb7fec000
Core was generated by `pchdtvr -W'.
Program terminated with signal 11, Segmentation fault.

warning: svr4_current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/librt.so.1...done.
Loaded symbols for /lib/tls/librt.so.1
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
#0  0x08049a67 in huffman_decode (d=0x8b29705 "",
    s=0x9098f45 "���\222c\035����\202\202��ܥ/e�L@\235\003o\237\017�001ɠod\207\212�\236x�\206!I\005�H׻��(�\234�O�2052\003ڸb\205c�020\030}�[\b\225���z�=�)\227@�rq", dlen=488, slen=35, comp=2) at pchdtvr.c:5335
5335            o = co[ to + (o << 1) + b ]; /* tree root offset is anchor for branches */
(gdb) bt
#0  0x08049a67 in huffman_decode (d=0x8b29705 "",
    s=0x9098f45 "���\222c\035����\202\202��ܥ/e�L@\235\003o\237\017�001ɠod\207\212�\236x�\206!I\005�H׻��(�\234�O�2052\003ڸb\205c�020\030}�[\b\225���z�=�)\227@�rq", dlen=488, slen=35, comp=2) at pchdtvr.c:5335
#1  0x08060dc8 in parse_ett_mss (
    r=0x9098f45 "���\222c\035����\202\202��ܥ/e�L@\235\003o\237\017�001ɠod\207\212�\236x�\206!I\005�H׻��(�\234�O�2052\003ڸb\205c�020\030}�[\b\225���z�=�)\227@�rq", n=40, etmid=197450, pgo=321) at pchdtvr.c:17413
#2  0x080614dd in parse_ett_packet (p=0x807dc00 "GRK\027", n=40) at pchdtvr.c:17637
#3  0x0806417d in test_mg_ttpid_packet (p=0x807dc00 "GRK\027", pid=4683) at pchdtvr.c:19185
#4  0x08064d7f in test_packet (p=0x807dc00 "GRK\027") at pchdtvr.c:19778
#5  0x08064d95 in test_packet_stats (p=0x807dc00 "GRK\027") at pchdtvr.c:19788
#6  0x080657f8 in fifo_output_loop (arg=0x0) at pchdtvr.c:20390
#7  0xb7fae341 in start_thread () from /lib/tls/libpthread.so.0
#8  0xb7f306fe in clone () from /lib/tls/libc.so.6
View user's profile Send private message Visit poster's website
yikes!
PostPosted: Wed Mar 15, 2006 4:56 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




There does seem to be some confusion amongst the broadcasters about the proper byte to set for the Huffman compression mode. I'm only using the compression mode bytes that indicate the Huffman tables in the A/65b Appendices.

I'm fairly certain they are too, but they have the wrong byte set for the compression mode, assuming this is a broadcast stream we're talking about, and not a cable stream.

They're binary trees, so the compressed data needs to match what the branch and leaf offsets are in the table or else Bad Things will occur.

I saw no less than 4 different incorrect compression mode bytes for the various spanish stations here, yet all the Huffman encoded text follows A/65b EIT+ETT tables once I forced the values.

Edit huffman_decode() and stick a return right after all the variable definitions. It looks like the destination is already null, so it'll return null. The rest of the code should be able to handle the null string it if I did it right, and hopefully won't crash anywhere else that broadcaster is using Huffman with the wrong compression mode set.

It could also be they do have the right compression mode set, only it's for a Huffman table that is NOT in A/65b. Unless I can find the tables for those compression modes, I wouldn't be able to do much in that particular scenario.

If you haven't already, check Makefile, add -g to CFLAGS if not there.

Try without HyperThreading or SMP, if that's an option. I don't really suspect that's the culprit but you never know.

I'll go check and see if any local broadcasters have cleaned up their Huffman act since last time, and if not, figure out a way around the latest problems I find. Not that it would help you much if your broadcasters are broken in a different way.

Also, please take the time to do a full capture of the station for 5 minutes and then use "atscut -kmgt file.ts 0 900" on the capture to extract only the PSIP. It's repetitive so it compresses very well with bzip2. Please email that .bz2 to me so I may properly analyze the bits that are killing my program.



Thanks for the feedback. Apologies for any wasted time.

-ink





tupari wrote:
GrepTar wrote:
I thought you were supposed to type:
gdb ./pchdtvr core.18467


Alright that gives me:
Code:
]# gdb `which pchdtvr` -c core.18467
GNU gdb Red Hat Linux (6.1post-1.20040607.43.0.1rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xb7fec000
Core was generated by `pchdtvr -W'.
Program terminated with signal 11, Segmentation fault.

warning: svr4_current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/librt.so.1...done.
Loaded symbols for /lib/tls/librt.so.1
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
#0  0x08049a67 in huffman_decode (d=0x8b29705 "",
    s=0x9098f45 "���\222c\035����\202\202��ܥ/e�L@\235\003o\237\017�001ɠod\207\212�\236x�\206!I\005�H׻��(�\234�O�2052\003ڸb\205c�020\030}�[\b\225���z�=�)\227@�rq", dlen=488, slen=35, comp=2) at pchdtvr.c:5335
5335            o = co[ to + (o << 1) + b ]; /* tree root offset is anchor for branches */
(gdb) bt
#0  0x08049a67 in huffman_decode (d=0x8b29705 "",
    s=0x9098f45 "���\222c\035����\202\202��ܥ/e�L@\235\003o\237\017�001ɠod\207\212�\236x�\206!I\005�H׻��(�\234�O�2052\003ڸb\205c�020\030}�[\b\225���z�=�)\227@�rq", dlen=488, slen=35, comp=2) at pchdtvr.c:5335
#1  0x08060dc8 in parse_ett_mss (
    r=0x9098f45 "���\222c\035����\202\202��ܥ/e�L@\235\003o\237\017�001ɠod\207\212�\236x�\206!I\005�H׻��(�\234�O�2052\003ڸb\205c�020\030}�[\b\225���z�=�)\227@�rq", n=40, etmid=197450, pgo=321) at pchdtvr.c:17413
#2  0x080614dd in parse_ett_packet (p=0x807dc00 "GRK\027", n=40) at pchdtvr.c:17637
#3  0x0806417d in test_mg_ttpid_packet (p=0x807dc00 "GRK\027", pid=4683) at pchdtvr.c:19185
#4  0x08064d7f in test_packet (p=0x807dc00 "GRK\027") at pchdtvr.c:19778
#5  0x08064d95 in test_packet_stats (p=0x807dc00 "GRK\027") at pchdtvr.c:19788
#6  0x080657f8 in fifo_output_loop (arg=0x0) at pchdtvr.c:20390
#7  0xb7fae341 in start_thread () from /lib/tls/libpthread.so.0
#8  0xb7f306fe in clone () from /lib/tls/libc.so.6
View user's profile Send private message
Re: yikes!
PostPosted: Wed Mar 15, 2006 9:12 am Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




inkling wrote:

I'm fairly certain they are too, but they have the wrong byte set for the compression mode, assuming this is a broadcast stream we're talking about, and not a cable stream.

Yes, this is broadcast.
inkling wrote:

Edit huffman_decode() and stick a return right after all the variable definitions. It looks like the destination is already null, so it'll return null. The rest of the code should be able to handle the null string it if I did it right, and hopefully won't crash anywhere else that broadcaster is using Huffman with the wrong compression mode set.

You mean edit the function so it doesn't do anything? That won't break anything?
inkling wrote:

If you haven't already, check Makefile, add -g to CFLAGS if not there.

I did that.
inkling wrote:

Try without HyperThreading or SMP, if that's an option. I don't really suspect that's the culprit but you never know.

This is a single processor machine without HT.

inkling wrote:

Also, please take the time to do a full capture of the station for 5 minutes and then use "atscut -kmgt file.ts 0 900" on the capture to extract only the PSIP. It's repetitive so it compresses very well with bzip2. Please email that .bz2 to me so I may properly analyze the bits that are killing my program.

I'm still not sure which station is causing this problem. Is this something that only occurs during program guide loading?
View user's profile Send private message Visit poster's website
PostPosted: Wed Mar 15, 2006 9:24 am Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




OK I think the problem station is WPIX. At least I got the crash to occur while loading the program guide for it. I hit return to start recording it and it crashed after about 10 seconds. I tried hitting \ to get the full stream but pchdtvr didn't do anything.

Could this be caused by signal noise? The sig strength is only 62%-64% for that station
View user's profile Send private message Visit poster's website
Re: yikes!
PostPosted: Wed Mar 15, 2006 9:31 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Making huffman_deocde do nothing should be OK. For the day or so it took me to write it, it did nothing and was OK.

There are some other places besides Program Guide that it might be used, but they SHOULD all handle blank strings.

You can turn off each station Auto-Program-Guide load by either setting config file GTO field to 0 for each channel, or using [TAB} key to go to channel list and hit [a] key after hotkeying each channel to select off the magenta color that indicates it will auto-update.

This will allow you to hotkey each channel and load the guide for each of them manually, one by one, until you find the one that crashes it.

Then you can do a 5 minute full capture (with some other tool since it's pole-axing pchdtvr) to generate a file that you can put through "atscut -kmgt file.ts 0 900" that you can send to me, if you want me to find out if it can be fixed or if your station is hopeless.

Without that crucial PSIP data, I'm powerless to help fix it.

bzip2 the extracted PSIP file or else it'll take me a month to receive it and longer to reply with my 300 baud modem.

Good luck!

-ink




tupari wrote:
inkling wrote:

I'm fairly certain they are too, but they have the wrong byte set for the compression mode, assuming this is a broadcast stream we're talking about, and not a cable stream.

Yes, this is broadcast.
inkling wrote:

Edit huffman_decode() and stick a return right after all the variable definitions. It looks like the destination is already null, so it'll return null. The rest of the code should be able to handle the null string it if I did it right, and hopefully won't crash anywhere else that broadcaster is using Huffman with the wrong compression mode set.

You mean edit the function so it doesn't do anything? That won't break anything?
inkling wrote:

If you haven't already, check Makefile, add -g to CFLAGS if not there.

I did that.
inkling wrote:

Try without HyperThreading or SMP, if that's an option. I don't really suspect that's the culprit but you never know.

This is a single processor machine without HT.

inkling wrote:

Also, please take the time to do a full capture of the station for 5 minutes and then use "atscut -kmgt file.ts 0 900" on the capture to extract only the PSIP. It's repetitive so it compresses very well with bzip2. Please email that .bz2 to me so I may properly analyze the bits that are killing my program.

I'm still not sure which station is causing this problem. Is this something that only occurs during program guide loading?
View user's profile Send private message
pchdtvr 1.0-rc11
  pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 2 of 3  
Goto page Previous  1, 2, 3  Next
  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin