Back to Home / #mythtv / 2002 / 10 / Prev Day | Next Day
#mythtv IRC Logs for 2002-10-05

00:08-!-gtaylor [~gtaylor@picante.ne.client2.attbi.com] has joined #mythtv
00:09-!-gtaylor [] has quit [Client Quit]
00:10<Chutt>heh
00:10<Chutt>people join, people quit
00:27-!-gtaylor [~gtaylor@picante.ne.client2.attbi.com] has joined #mythtv
00:27<gtaylor>Isaac, still here?
00:27<Chutt>yeah
00:27<Chutt>hi
00:28<gtaylor>Chutt, obviously ;)
00:28<Chutt>yup
00:28<gtaylor>So I poked at the code, and got myself confuse dbetween chanid and channum etc; but then I guess it's working for you, so I dunno what gives...
00:28<Chutt>well
00:28<Chutt>what type of recording?
00:28<gtaylor>allrecord.
00:29<Chutt>yeah, do a cvs update
00:29<Chutt>that was broken until about a half hour ago
00:29<gtaylor>since two hours ago?
00:29<gtaylor>ah, ok, that's easy ;)
00:29<Chutt>it was trying to change channels to the category name
00:29<Chutt>didn't _quite_ work =)
00:30<gtaylor>ah-ha. might be good to check returns on some fo these, or easier in c++, throw stuff up ;)
00:30<Chutt>well
00:30<Chutt>it would've worked if i had finished the code, too
00:30<gtaylor>hehe ;)
00:30<Chutt>it's just like 90% done
00:31<gtaylor>OK, so that's cool;. I still wish I could figure out why my system seems so marginal performance-wise. VIA PCI can't be *that* much slower or they'd have had a recall.
00:31<Chutt>did you ever try increasing the pci latency of the tuner card?
00:32<gtaylor>No, I mainly fiddeld with the PCI bus itself. I recall the buffer thing you suggested, was that in a mail, too?
00:32<Chutt>yeah
00:32<Chutt>but if it's really jittering on the record side, that buffer change won't affect it
00:33<Chutt>i do use the 'latency=248' option to the bttv module when i modprobe it on startup
00:34<Chutt>had some problems earlier with the card not getting enough time on the bus, so frames were incomplete on capture
00:34<gtaylor>ok, I'll try that out. oddly, I can't find your original message about it, but whatever.
00:35<Chutt>it was just to increase the 'usepre' variable in the nuppelvideoplayer.cpp file from 2 to 8 or something like that
00:35<gtaylor>Yes, that message I've got. 'pick' just doesn't find anything else from you with the word latency. Must've deleted it by mistake or something.
00:35<Chutt>heh
00:36<Chutt>might've sent that to someone else off list or whatnot
00:36<Chutt>too many emails to keep track of
00:36<gtaylor>quite! so I'll set for 640x480@rtjpeg and see if I can't get smooth recording and playing with that.
00:37<Chutt>using mpeg4 might be smoother, too
00:37<Chutt>since the amount of compressed data is smaller
00:37<Chutt>so it's a bit lighter on transfers and stuff
00:38<Chutt>lemme know if allrecord is fixed or not, too =)
00:38<Chutt>i think it is, but i haven't actually recorded anything since i fixed it
00:38<gtaylor>mpeg4? always seems like that's a bit marginal on the cpu. what quality/rate settings do you use for it?
00:38<gtaylor>bttv reports no such parameter "latency"
00:39<Chutt>currently, 640x480, bitrate of 2800, max quality 2, min quality 15
00:39<Chutt>what driver version?
00:39<Chutt>err, bitrate of 3300, rather
00:39<Chutt>1.5GB/hour at that resolution
00:41<gtaylor>unclear, you'd think there would be a rcs string or something. it's stock from 2.4.18, i think, although somewhere i may have updated it in the confusion way back when.
00:42<Chutt>weird.
00:42<gtaylor>hmm. doe slarger bitrate and quality range make for more or less codec work?
00:42<Chutt>cpu's about the same as the default bitrate
00:42<Chutt>i'm not sure if the quality range changes much
00:43<Chutt>uses about 35-40% cpu to record only
00:43<Chutt>on my 1800+
00:43<gtaylor>yearh, my bttv is stock 2.4.18. there's a "lat" variable in teh code, but this reads the pci latency out of the bttv config space.
00:47<gtaylor>there'sa "gbuffers" option for bttv, but nothing else that seems like it would have a performance implication
00:48<gtaylor>...and mine is using "2" as opposed to 64 or however many it can do. I assume mythtv uses the mmapped mode? Maybe this would help.
00:49<Chutt>mythtv'll only use 2 buffers
00:50<Chutt>might help to make it do more, though
00:51<gtaylor>if it's a descriptor ring sort of affair, yes. we'll see.
00:51<gtaylor>what bttv version is yours wiht the latency argument?
00:52<Chutt>0.7.96
00:53<gtaylor>ah-ha, I have 0.7.97 sitting around but not being used. It looks much newer, perhaps there are other improvements, as well.
01:01<gtaylor>hmm. with all thoses settings, it's a smidge jittery just watching tv. and the sound cuts out from time to time.
01:02<Chutt>doh
01:02<gtaylor>640x480 3300 picture sure is sharp, though, makes me wish it worked ;)
01:03<gtaylor>do you run a kernel with the low latency patches or anything like that/
01:03<Chutt>nope
01:03<Chutt>i've been meaning to try em and all that, but just haven't gotten around to it
01:04<gtaylor>I guess I'll give that a whirl. If that fails, I'll toss my motherboard for something else.
01:06<gtaylor>oh, I was goign to try rotating cards around to diferent slots, too.
01:06<Chutt>is anything sharing irqs?
01:07<gtaylor>hmm. everything is on irq 11.
01:08<Chutt>i don't have anything sharing on my box
01:09<Chutt>oh, i should respond to your last email to the list and say that bug should be fixed =)
01:09<gtaylor>well, it's something to try. it's all going through screwy apic code anyway, but maybe.
01:16<gtaylor>so just plain recording with those settings is giving a load of 0.65ish.
01:16<Chutt>heh
01:17<Chutt>my system load when doing tv watching is 0.51 or so with those settings
01:18<gtaylor>curious. you said you'd run your memory fast or something? was it just CAS timing of 2 or command rate or what?
01:19<Chutt>cas 2, aggressive timing
01:20<gtaylor>hmm. I wonder if that's it; seems like lots of the codec and dma stuff would benefit from faster memory.
01:20<Chutt>that's about the only things i can modify, memory-wise, in the bios
01:20<Chutt>sharing irqs might be part of it as well
01:20<Chutt>since it has to figure out which device is belonging to each interrupt
01:21<gtaylor>yes, but that should be one reg read in teh irq controller.
01:21<gtaylor>i'll fiddle that and the mem timings and reboot and see what we see.
01:36<gtaylor>ok, i'm back
01:36<gtaylor>so I set cpu clock to 138 from 133
01:36<gtaylor>tried but failed to set all the irq's by hand
01:36<Chutt>heh
01:36<gtaylor>and set the memory to cas 2 command rate 1t.
01:37<Chutt>same stuff?
01:37<gtaylor>and loaded the new bttv without latency arg
01:37<gtaylor>live tv 640x480@3300 is pretty smooth, no audio glitches.
01:37<gtaylor>so that's promising.
01:37<Chutt>cool
01:37<gtaylor>historically, watching one thing while recording another is "harder"
01:37<Chutt>really?
01:37<gtaylor>so we'll have to see after it records something
01:38<Chutt>it seems to be better on my box
01:38<gtaylor>yes, livetv tends to have stuff still buffered, whereas reading one thing and writing antoher tends not to
01:38<gtaylor>anyway, this is where my oversize heatsink+fan and the other four case fans had better pay off.
01:39<gtaylor>no way this memory is rated for cas 2/1t.
01:39<Chutt>hehe
01:39<gtaylor>I don't know if modern chipsets fire nmi or something else for ecc corrections; it would be nice to know.
01:40<gtaylor>(stupid ten-cent PC hardware. wouldn't have all these issues on a proper machine)
01:40<Chutt>heh
01:41<Chutt>and it's linux, too =)
01:41<gtaylor>yes, there's another grab-bag of poorly integrated flaming wild innocation ;)
01:41<gtaylor>innovation.
01:42<gtaylor>all right, I'm going to go and actually *watch* this thing for a while.
01:42<gtaylor>thanks for all your tips etc...
01:42<Chutt>heh
01:42<Chutt>sure thing
01:42-!-gtaylor [] has quit ["Leaving"]
01:43-!-gtaylor [~gtaylor@picante.ne.client2.attbi.com] has joined #mythtv
01:44<Chutt>heh
01:44<gtaylor>so what's the expected ratio of thread cpus? I've got 79% in one and 5-18% in a few others.
01:45<Chutt>'bout right
01:45<gtaylor>seems like lvie tv would have one huge, one less huge, and a smattering.
01:45<Chutt>the biggy's the encoder
01:45<Chutt>next largest would be the decoding work
01:45<gtaylor>hmm. 75% cpu for just encoding?
01:45<Chutt>using top?
01:45<gtaylor>yes, top
01:46<Chutt>heh
01:46<gtaylor>is there much synchronization between threads, as in pthread-posix semaphores/mutexes/etc?
01:46<Chutt>mostly pthread read/write locks
01:46<Chutt>a few pthread mutexes
01:46<gtaylor>do they hit much?
01:46<Chutt>shouldn't
01:46<Chutt>i kept locking down to a minimum
01:47<Chutt>there _is_ a big lock if you're doing 2 encodes of mpeg4 at a time, though
01:47<gtaylor>good. linux threads are godawful hack. the locks use *signals*
01:47<Chutt>the encoder isn't quite threadsafe =)
01:47<gtaylor>...to the *process group* no less...
01:47<Chutt>heh
01:47<Chutt>that should improve soon =)
01:47<Chutt>new pthreads lib in the pipeline
01:48<gtaylor>definetely avoid the "flock fo worker threads" pattern - we did something that way once at work and it was a disaster.
01:48<gtaylor>yes, there are a few competeing kernel-free semaphore implementations out there.
01:48<Chutt>no
01:49<Chutt>this one's by the glibc guys, so it's acutally going to replace the linuxthreads stuff
01:49<Chutt>actually
01:49<Chutt>heh
01:49<gtaylor>well, good luck to them. I'll just stay away from threads, thank you ;)
01:49<Chutt>it was part of the 'start a few hundred thousand threads in 2 seconds' update
01:50<Chutt>iirc
01:50<gtaylor>ah, yes, saw that mentioned somewhere. lots of effort in a bad direction.
01:50<gtaylor>a computer is a state machine. best to write code that way.
01:51<Chutt>ah, one of those anti-threads people =)
01:51<gtaylor>most of us in the networking industry are.
01:52<gtaylor>my box at work runs 500k ppp sessions at once. threads would jsut be laughable.
01:52<Chutt>heh
01:53<gtaylor>so 95% cpu use for live tv seems pretty marginal. I may try to overclock a bit more.
01:53<Chutt>how fast's the cpu at now?
01:53<gtaylor>138MHz for a 1587MHz internal core; uses the normal 1800+XP multiplier and volts.
01:54<Chutt>right
01:54<Chutt>wonder why you're using so much more cpu than i am
01:54<gtaylor>dunno. this is the mystery.
01:54<Chutt>it tops out at 70% or so with those options
01:55<gtaylor>I'm using the nvidia -provided drivers, for agp and X, to an agp 4x slot.
01:55<Chutt>same
01:56<gtaylor>95% user 4% system ... wonder how accurate "system" is. on mips it doesn't include bottom half (ie interrupt handlers, most driver stuff, etc)
01:56<gtaylor>does oprofile work on althons/
01:56<Chutt>top's fairly inaccurate
01:57<Chutt>in general
01:57<Chutt>no idea on oprofile
01:58<gtaylor>this is something of a mystery.
01:59<gtaylor>you aren't running your cpu at 166 or something?
01:59<Chutt>nope
01:59<Chutt>have enough of a heat problem as it is =)
01:59<gtaylor>you have two different bttv cards, which do you normally use?
01:59<Chutt>the hauppauge card is the main one
02:00<Chutt>since it supports stereo
02:00<gtaylor>bt878, modern?
02:00<Chutt>yup
02:00<Chutt>wintv-radio
02:00<Chutt>hm
02:00<Chutt>you don't, by chance, have it compiled for debugging, do you?
02:00<Chutt>i turn that on sometimes and forget about it
02:01<gtaylor>only if that's on by default, where's the -g?
02:01<Chutt>in the settings.pro
02:01<Chutt>top level of the source
02:01<gtaylor>config += release, the debug one is #'d out.
02:02<Chutt>heh
02:02<Chutt>ok, one hypothesis shot down
02:02<gtaylor>ah, gcc 2.95 or 3.x?
02:02<Chutt>2.95
02:02<Chutt>debian hasn't switched to 3.2 yet
02:03<Chutt>if you're using 3.x, might try switching the -mpentiumpro to -mathlon-xp and adding some more of the newer optimization flags to that line in settings.pro
02:03<gtaylor>I've got 2.95.
02:06<gtaylor>would mtrr settings apply to the bttv? I have done nothing with those except note that the nv ones were magicalyl OK.
02:07<Chutt>i haven't touched mine at all
02:12<gtaylor>still looks smooth, at least in livetv mode.
02:13<gtaylor>audio 44100 quality 7?
02:13<gtaylor>and you did say 3300 bitrate for mpeg4?
02:14<Chutt>yeah
02:14<Chutt>but i'm recording at 32000
02:14<Chutt>since i'm using the btaudio stuff
02:14<gtaylor>ah, i wonder if that's way more efficient?
02:14<Chutt>shouldn't be appreciably different
02:15<gtaylor>is it just a sound device on the bt card?
02:15<Chutt>yup
02:15<Chutt>transfers the audio over the pci bus
02:15<gtaylor>hmm. I guess the same as a pci audio card.
02:15<Chutt>no cable to the sound card
02:15<gtaylor>I thought the btaudio device didn't do stereo?
02:15<Chutt>so it's how i'm using two cards at once
02:16<Chutt>the digital dsp does stereo 32000, the analog one does mono 44100
02:16<Chutt>iirc
02:16<Chutt>at least, i'm getting stereo passed through, my receiver thinks its prologic encoded
02:17<gtaylor>hmm. well, it's something to try. I'm using an ensoniq 1371 card, since the onboard via audio is noisy. always been a fine card, so I wouldn't have thought to suspect it.
02:17<Chutt>the 1371? yeah, good little card
02:18<Chutt>i have a box at work with 5 of em in it =)
02:18<gtaylor>but you don't have five ears
02:19<Chutt>was a real cheap way to get 10 channels of recording capability
02:20<gtaylor>hmm. should your mythfrontend binary be any different from mine? I could just run your binary and see fi that churns a lot
02:20<Chutt>it'll be different
02:20<Chutt>all those shared libs and stuff
02:20<Chutt>and the fact that i don't have a working binary at the moment =)
02:21<Chutt>i'm in the middle of adding a 4th recording option
02:21<Chutt>record all on a certain channel
02:21<gtaylor>4th option?
02:21<gtaylor>oh, that would be handy.
02:22<gtaylor>what would also be nice would be "record this title once at some point" for cable movies.
02:22<Chutt>hrm
02:22<Chutt>i think something like that'll come along once i start doing more of the automated recording type stuff
02:23<gtaylor>did you ever have any further thoughts on the ffw/rew hanging bug of mine? has anyone else reported it?
02:23<Chutt>no one else has reported it, i can't reproduce it at all
02:23<Chutt>and i really don't know what else it might be
02:23<Chutt>oh, and i do mean to fix the ff off the end of an in-progress recording one of these days =)
02:23<gtaylor>weird, again. it was still present in recent cvs using lower bitrate mpeg4 and rtjpeg, but I haven't seen ti just now iht livetv at 3300.
02:24<gtaylor>i wonder if it's related to the rest of my mystery somehow?
02:25<Chutt>probably a race condition
02:28<gtaylor>is there much library code from my system (ie not avcodec) that executes in the coder path?
02:28<Chutt>not especially
02:29<gtaylor>are exceptions and rtti turned off or the c compilter used for the codec stuff?
02:30<Chutt>the c compiler's used for libavcodec
02:30<Chutt>exceptions and rtti are on for everything else
02:30<Chutt>i'm not sure what turning them off will do to qt
02:32<gtaylor>hmm. well, a few per frame in your nuppel code shouldn't hurt..
02:37<gtaylor>does NuppleVideo::Initialize run as an early thing in the recording thread? I'd like to start profiling that thread there.
02:37<Chutt>lemme check
02:38<Chutt>actually
02:39<gtaylor>NuppleVideoRecorder::Initialize, I mean.
02:39<Chutt>it gets called before the encoder thread gets spawned
02:39<Chutt>so that might not be the best place to start =)
02:39<gtaylor>ah, where can I put something then?
02:39<Chutt>StartRecording would be where the main encoder thread starts
02:39<Chutt>but all the work is done in another child thread
02:40<Chutt>the main thread just grabs the buffers from the v4l device and copies em to an internal buffer
02:40<Chutt>heh
02:40<gtaylor>ther's an audio thread and a write thread started there, but doest the parent go on to encode?
02:41<Chutt>so compiling with -fno-rtti and -fno-exceptions drops the binary size by over 200KB
02:41<Chutt>the write thread does the actual encoding
02:41<gtaylor>ah.
02:41<Chutt>for both audio and video
02:42<gtaylor>no doubt. rtti won't kill you unless you use it, and exceptions have a per-c++ function overhead, so most of the codec stuff should be immune.
02:42<Chutt>right
02:42<Chutt>everything seems to run ok, so i'll just leave those options in
02:42<Chutt>i was just worried qt might not like it if i did that =)
02:43<gtaylor>does it make it any faster or slower?
02:43<Chutt>doesn't look like it
02:53<Chutt>allright
02:53<Chutt>that's done
02:53<Chutt>new recording option is now in cvs
02:53<Chutt>so, i'm off to bed =)
03:02<gtaylor>ok, bye. profile results in morning, with any luck at all.
03:02-!-gtaylor [] has quit ["Leaving"]
05:50-!-LinuxBTAudio [~LinuxBTAu@0x50c46ceb.arcnxx10.adsl-dhcp.tele.dk] has joined #MythTV
05:51-!-LinuxBTAudio is now known as JensLH
05:51<JensLH>Anyone alive?
09:11<-- JensLH(~LinuxBTAu@0x50c46ceb.arcnxx10.adsl-dhcp.tele.dk) has left #MythTV
09:16<davehunn>h odd thing
09:16<davehunn>the scheduler is not picking up the channel nuber and records everything on the sae channel not good :(
09:17<davehunn>cvs version as off first october
11:19-!-mdz [] has quit [Read error: 110 (Connection timed out)]
11:59<Chutt>davehunn, read the mailing list, perhaps?
14:37-!-davehunn [] has quit [Read error: 104 (Connection reset by peer)]
14:39-!-davehunn [~david@pc1-mars1-4-cust156.mid.cable.ntl.com] has joined #mythtv
14:42<davehunn>arg now i have done a cvs update it segfaults all the time (mythtv) the other bits are ok
14:43<davehunn>[New Thread 1026 (LWP 22975)]
14:43<davehunn>Changing from None to WatchingLiveTV
14:43<davehunn>Program received signal SIGSEGV, Segmentation fault.
14:43<davehunn>[Switching to Thread 1026 (LWP 22975)]
14:43<davehunn>0x4055eb72 in QString::deref () from /usr/lib/libqt-mt.so.3
14:44<Chutt>make clean/edit settings.pro to enable debugging/rebuild
14:44<Chutt>will get you something useful
14:48<Chutt>but, i'm leavin for a bit =)
14:54<davehunn>ahh bolox it runs with debuggin enabled
14:56<davehunn>so to recap with no debbugging mythtv segfaults with debugging it runs fine
14:57<davehunn>g++ --version
14:57<davehunn>2.95.4
14:57<davehunn>2x1.2 duron + 512 ddr ram haupage win tv nicam
15:59<Chutt>it probably was a dependency issue
15:59<Chutt>not compiling everything it needed to with the update
15:59<Chutt>blowing away things to recompile for debugging fixed it
16:18<davehunn>ah could be
16:18<davehunn>yes
16:19<Chutt>probably libmyth that did it
16:19<davehunn>ill try a make after a clean and see if it still works in a bit
16:19<Chutt>it's not very library-like yet, doesn't handle ABI changes at _all_
16:20<davehunn>ok
17:38<davehunn>which file do i incude for int setGeometry ?
17:40<Chutt>qwidget.h?
17:41<davehunn>i a trying to nock together a little view so i can view a file as its being recorded
17:42<davehunn>but i get mythplay.cpp:69: implicit declaration of function `int setGeometry(...)
17:44<davehunn>and the same for setFixedSize and showFullScreen but i dont understand why as i have
17:44<davehunn>#include <qlayout.h> which has these functions in and i should be running with the same ake options as mythfrontend
17:46<Chutt>heh
17:47<Chutt>you do know if you go to 'watch tv' while a recording is going on, it'll ask if you want to watch the recording, right?
17:47<davehunn>no
17:47<davehunn>thats ok then i did not want to break the recording
17:47<davehunn>can i pause etc ?
17:47<Chutt>yup
17:48<Chutt>only thing is you can ff off the end of the recording
17:48<Chutt>and it'll just exit playback
17:48<davehunn>hmm
17:48<davehunn>no can ff of the end
17:48<davehunn>but it didnt start at the beging of the file
17:48<Chutt>as for the undefined things, you're probably not calling it from a child of qwidget or whatnot
17:49<davehunn>oh ok
17:49<davehunn>ill have a look at that in a bit
17:50<davehunn>i was going to use the player as a starting to to write a conversion uil to convert to saller avi ~ 50 eg/half hour
17:54<Chutt>there's half written re-encoding stuff in the nuppelvideoplayer class
17:54<Chutt>but
17:54<Chutt>it still uses the internal format
17:54<Chutt>could be a starting point, though