Back to Home / #mythtv / 2003 / 09 / Prev Day | Next Day
#mythtv IRC Logs for 2003-09-16

---Logopened Tue Sep 16 00:00:01 2003
---Daychanged Tue Sep 16 2003
00:00-!-dopez [] has quit [Remote closed the connection]
00:04<DJHaCK>is there a way to start the backend with Video sources ? (just to get record+pause live tv feature) xmltv's server having problem
00:08-!-phar0e [] has joined #mythtv
00:24-!-hfb_ [] has joined #mythtv
00:26-!-ChaosExiguum [] has joined #mythtv
00:32-!-hfb__ [] has joined #mythtv
00:32-!-hfb [] has quit [Read error: 60 (Operation timed out)]
00:42-!-phar0e [] has quit [Read error: 110 (Connection timed out)]
00:42-!-hfb_ [] has quit [Read error: 104 (Connection reset by peer)]
00:48-!-linagee_ is now known as linagee
00:49-!-ChaosExiguum [] has quit ["Leaving"]
01:01-!-hfb_ [] has joined #mythtv
01:12-!-kja [] has quit ["..."]
01:18-!-hfb__ [] has quit [Read error: 110 (Connection timed out)]
01:29-!-tmk [] has quit []
01:42-!-courtlr [~trillian@] has joined #mythtv
01:44-!-courtlr [~trillian@] has left #mythtv []
02:17-!-Markos [] has joined #mythtv
02:23-!-tmk [] has joined #mythtv
02:23<tmk>you still up chutt?
02:24-!-TheWildgoose [] has joined #mythtv
02:27<bline>hi tmk
02:31-!-_kch_ [] has joined #mythtv
03:03-!-tmk [] has quit []
03:06-!-meth [] has quit [" |"]
03:17-!-FryGuy [] has quit [Read error: 104 (Connection reset by peer)]
03:32-!-KikoV [] has quit ["Client exiting"]
03:55-!-choenig [] has joined #mythtv
04:09-!-hfb_ [] has quit ["Client exiting"]
06:45-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
06:46-!-linagee [] has joined #mythtv
07:46-!-jkolb [] has joined #mythtv
08:03-!-activelow [] has quit ["Client exiting"]
08:18-!-linagee_ [] has joined #mythtv
08:19-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
08:25-!-Netsplit <-> quits: robbie
08:26-!-Netsplit over, joins: robbie
08:26-!-ServerMode/#mythtv [+b *!*mythtv@*] by
08:36-!-Cal [] has joined #mythtv
09:18-!-m0j0 [~m0j0@] has joined #mythtv
09:27-!-DJHaCK [] has quit [Read error: 113 (No route to host)]
09:30-!-Cal [] has quit ["Client exiting"]
09:37-!-Netsplit <-> quits: robbie
09:38-!-Netsplit over, joins: robbie
09:38-!-ServerMode/#mythtv [+b *!*mythtv@*] by
09:44-!-fr33 [] has joined #mythtv
09:46-!-fr33 [] has quit [Client Quit]
09:52-!-Netsplit <-> quits: robbie
09:52-!-Netsplit over, joins: robbie
09:52-!-ServerMode/#mythtv [+b *!*mythtv@*] by
10:00-!-DeliLLama [] has joined #mythtv
10:06-!-Netsplit <-> quits: robbie
10:08-!-Netsplit over, joins: robbie
10:08-!-ServerMode/#mythtv [+b *!*mythtv@*] by
10:09-!-sc00p [] has joined #mythtv
10:23-!-kja [] has joined #mythtv
10:24-!-mecraw [] has quit ["Trillian ("]
10:40-!-robbie [] has quit [Read error: 110 (Connection timed out)]
10:41-!-jkolb [] has quit [Read error: 104 (Connection reset by peer)]
10:43-!-KikoV [] has joined #mythtv
10:44-!-jkolb [] has joined #mythtv
10:45-!-dwmurphy [] has joined #mythtv
10:51-!-sfr [] has joined #mythtv
10:56-!-Justin_ [] has quit ["moving irc"]
10:56-!-Justin__ [~justin@] has joined #mythtv
10:56-!-Justin__ is now known as Justin_
10:59-!-KikoV [] has quit [Read error: 54 (Connection reset by peer)]
11:06-!-DeliLLama [] has quit []
11:09-!-KikoV [] has joined #mythtv
11:20-!-mecraw [~mecraw@] has joined #mythtv
11:21-!-schultmc [] has joined #mythtv
11:29-!-_kch_ [] has quit ["Terminando cliente"]
11:34-!-robbie [] has joined #mythtv
11:47-!-o_cee [] has joined #mythtv
11:47<o_cee>kja: there?
11:48<o_cee>"Changes committed by bjm" who's that? thanks for those commits, i think my rebuffering problems are fixed now
11:49<sfr>o_cee: just compiling it. i'm hoping for the best.
11:49-!-activelow [] has joined #mythtv
11:52-!-Drikus [] has joined #mythtv
11:52<o_cee>will try it more later tonight
11:52<o_cee>but it seemed good
11:53<dwmurphy>what problems were those?
11:54<o_cee>dunno, but i got audio glitches and rebuffering messages
11:54-!-o_cee is now known as o_cee\afk
11:55<dwmurphy>ew :(
12:03<kja>o_cee: here
12:23-!-StarHeart [] has joined #mythtv
12:28-!-ChaosExiguus_ [] has joined #mythtv
12:30-!-dopez [] has joined #mythtv
12:34-!-steelep [~signwatch@] has joined #mythtv
12:41-!-ChaosExiguus [] has quit [Read error: 110 (Connection timed out)]
12:41-!-o_cee\afk [] has quit [Read error: 110 (Connection timed out)]
12:50<hadees>how well does mythvideo handle playing over nfs, i know it is just a front end but which player would be the best for playing over nfs
12:52<steelep>I had better luck with samba
12:53<steelep>nfs was fine with one frontend, but not 2
12:54<steelep>probably was my setting, but samba has been rock steady
13:11-!-ChaosExiguus__ [] has joined #mythtv
13:18-!-dakeyrus [] has joined #mythtv
13:29-!-ChaosExiguus_ [] has quit [Read error: 110 (Connection timed out)]
13:38-!-dja [] has quit [Remote closed the connection]
13:43-!-activelow [] has quit [Read error: 60 (Operation timed out)]
13:46-!-poo [] has quit [Read error: 104 (Connection reset by peer)]
13:47<_rkulagow>chutt: well, looks like the bug i opened on those SIG32's in gdb for mandrake actually got a response. turns out that it's the way they compiled glibc. is there a way to see if it's also fixed the "incomplete thread information" issue that's come up before? i haven't actually had a SEGFAULT in a long long time.
13:49<Chutt>i dunno
13:49<Chutt>you can try to compile for debugging
13:49<Chutt>then play something back
13:50<Chutt>and hit ctl-c during that, and see if gdb has information on all the thrads
13:51<_rkulagow>ok, i'll give that a try.
13:51-!-hadees [] has quit [Remote closed the connection]
13:54-!-tmk [] has joined #mythtv
13:54<tmk>guten morgen
13:55-!-poo [] has joined #mythtv
13:56-!-poptix- [] has joined #mythtv
14:08-!-activelow [] has joined #mythtv
14:12-!-omegahamlet [] has joined #mythtv
14:12-!-dakeyrus [] has quit [Read error: 104 (Connection reset by peer)]
14:13<davipt>hi. something's wrong with mythtv site :(
14:14<Chutt>i hadn't noticed.
14:14<davipt>index.php returns an error and 302
14:14<davipt>to itself
14:15<Chutt>stuff's being upgraded on the machine.
14:15<davipt>oh, ok
14:19-!-ahbritto [] has joined #mythtv
14:32-!-dopez [] has quit [Remote closed the connection]
14:41-!-dopez [] has joined #mythtv
14:57<Snow-Man>It should all be good now.
15:00-!-activelow [] has quit ["Client Exiting"]
15:07-!-WD [] has joined #mythtv
15:08<WD>I've got a gdb session open with a mythfrontend segfault that I just posted to mythtv-dev. While I have it open, is there anything useful that can be extracted from it, aside from the backtrace that I posted?
15:13-!-ahbritto [] has quit [Client Quit]
15:14-!-poptix- [] has quit ["leaving"]
15:30-!-hadees [] has joined #mythtv
15:36-!-hfb [] has joined #mythtv
15:41-!-WD [] has quit ["ChatZilla 0.9.28 [Mozilla rv:1.5b/20030912]"]
15:42-!-TheWildgoose [] has quit [Read error: 104 (Connection reset by peer)]
15:44-!-TheWildgoose [] has joined #mythtv
15:47-!-TheWildgoose [] has quit [Remote closed the connection]
15:48-!-TheWildgoose [] has joined #mythtv
15:51-!-racer [] has joined #mythtv
15:51<racer>cvs down?
15:51-!-Drikus [] has quit ["toedeledoki"]
15:51-!-lmatter_work [] has joined #mythtv
15:53-!-TheWildgoose [] has quit [Remote closed the connection]
15:56-!-racer [] has quit []
15:58-!-TheWildgoose [] has joined #mythtv
16:00-!-TheWildgoose [] has quit [Remote closed the connection]
16:01-!-TheWildgoose [] has joined #mythtv
16:02-!-sc00p_ [] has joined #mythtv
16:05-!-jkolb [] has quit []
16:08-!-Netsplit <-> quits: steelep, jwhite, mdz_, moegreen, bline, TheWildgoose, schultmc, hfb, _rkulagow, knight-, (+16 more, use /NETSPLIT to show all of them)
16:08-!-Netsplit <-> quits: Edgan, ChaosExiguus__, GreyFoxx, Morph, choenig, linagee_, hadees, sc00p, echo, dwmurphy, (+9 more, use /NETSPLIT to show all of them)
16:10-!-Netsplit over, joins: sc00p_, TheWildgoose, lmatter_work, hfb, steelep, StarHeart, schultmc, Justin_, sfr, m0j0 (+15 more)
16:10-!-ServerMode/#mythtv [+b *!*mythtv@*] by
16:11-!-Netsplit over, joins: Edgan
16:11-!-ServerMode/#mythtv [+b *!*mythtv@*] by
16:11-!-Netsplit over, joins: kja
16:11-!-ServerMode/#mythtv [+b *!*mythtv@*] by
16:11-!-Netsplit over, joins: dopez, tmk, ChaosExiguus__, dwmurphy, linagee_, dja__, Viddy, Captain_Murdoch, Morph, GreyFoxx
16:11-!-ServerMode/#mythtv [+b *!*mythtv@*] by
16:12-!-Netsplit over, joins: hadees, sc00p, choenig, Jerry, Ripp, paulproteus, echo, Snow-Man
16:12-!-ServerMode/#mythtv [+b *!*mythtv@*] by
16:20-!-sc00p [] has quit [Read error: 110 (Connection timed out)]
17:04-!-hfb [] has quit ["Client exiting"]
17:05<Chutt>rkulagow, hey
17:05<Chutt>is the binary stripped?
17:06<_rkulagow>you mean that test case i emailed? i don't think so. make distcleaned and made sure that had DEBUG then make installed.
17:07<_rkulagow>wait, you know what, i replaced glibc, but the "old" version may still be resident?
17:10<tmk>hey chutt, next time you feel like crashing your box, could you try something out for me?
17:11<Chutt>rkulagow, i dunno, but i'd make sure it wasn't stripped
17:11<_rkulagow>wait, are we talking about the myth binary, or the glibc?
17:11<Chutt>the myth binary
17:12<_rkulagow>hrmm. is there anything in the standard myth way of doing things that would cause it to get stripped? because i know that i haven't been doing it manually.
17:12<tmk>make install seems to strip
17:13-!-o_cee [] has joined #mythtv
17:13<Chutt>depends on who made the qt libs
17:13<Chutt>debian doesn't strip in debug mode
17:15-!-o_cee is now known as o_cee\zZz
17:34-!-hfb [] has joined #mythtv
17:37<_rkulagow>chutt: mandrake has a seperate glibc-debug version, but there doesn't seem to be any packaged "qt-debug". if i were to open another bug for qt, what's the quick version of what the issue is?
17:39<Chutt>rkulagow, no, is the mythtv binary being stripped on installation
17:39<Chutt>that's what i'm asking :p
17:42-!-dja [] has joined #mythtv
17:42-!-hfb [] has quit [Read error: 104 (Connection reset by peer)]
17:48-!-y [] has joined #mythtv
17:49-!-y [] has quit [Client Quit]
17:54<_rkulagow>hrmm: ####### Install
17:54<_rkulagow> @$(CHK_DIR_EXISTS) "$(INSTALL_ROOT)/usr/local/bin/" || $(MKDIR) "$(INSTALL_ROOT)/usr/local/bin/"
17:54<_rkulagow> -$(COPY) "$(QMAKE_TARGET)" "$(INSTALL_ROOT)/usr/local/bin/$(QMAKE_TARGET)"
17:54<_rkulagow> -strip "$(INSTALL_ROOT)/usr/local/bin/$(QMAKE_TARGET)"
17:54<_rkulagow>this is for mythfrontend.
17:54<_rkulagow>Makefile generated by qmake
17:55<_rkulagow>chutt: is that what you were talking about?
17:56<_rkulagow>ok, so that helps. but there's no man page for qmake on my box. in your opinion, are they taking a wrong default, or are they actually doing something broken?
17:58-!-jkolb [] has joined #mythtv
17:59<Chutt>qmake is probably broken
18:00<Chutt>and debian has patched it a little
18:00<Chutt>i don't know, though
18:00-!-linagee_ is now known as linagee
18:14-!-hfb [] has joined #mythtv
18:17<mikegrb>heh I did the same thing... make a short little playlist on my desktop so I would find it again
18:21-!-monkeyBox [] has joined #mythtv
18:21<monkeyBox>does anyone here have the Morex Cubid 3688 Mini-ITX case??
18:27<robbie>hey im about to buy a pvr-250, are they about as good a card as i can get for this type of stuff ?
18:27<robbie>being its nearly $400 here in .au
18:28-!-jkolb [] has quit [Read error: 104 (Connection reset by peer)]
18:29-!-jkolb [] has joined #mythtv
18:36-!-sfr [] has quit ["Client exiting"]
18:37-!-zzo [] has joined #mythtv
18:47-!-hfb [] has quit ["Client exiting"]
18:50-!-zzo [] has quit ["Leaving"]
18:50-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
18:51-!-linagee [] has joined #mythtv
18:52<tmk>robbie: what are you planning on doing with it
18:53<tmk>what system specs also
18:54-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
18:55-!-linagee [] has joined #mythtv
18:57<robbie>tmk:celeron 2200 1/2Gb ram, recording tv
18:58-!-WD [] has joined #mythtv
19:01-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
19:02-!-FryGuy [] has joined #mythtv
19:02-!-linagee [] has joined #mythtv
19:05-!-schultmc [] has quit ["Client exiting"]
19:05-!-_rkulagow [] has quit [Read error: 104 (Connection reset by peer)]
19:05-!-_rkulagow [] has joined #mythtv
19:05-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
19:05<WD>I recently posted to mythtv-dev about a mythfrontend segfault. Does anybody know what the problem might be? Or is there any more information I can provide?
19:07-!-linagee [] has joined #mythtv
19:07-!-warlord [me@DOGBERT.IHTFP.ORG] has joined #mythtv
19:08<warlord>Hiya. I've been setting up 0.11 on a new box and I've run into a few bugs. Anyone around who might be able to help?
19:10-!-linagee_ [] has joined #mythtv
19:10<WD>warlord: ask
19:11-!-linagee_ [] has quit [Read error: 54 (Connection reset by peer)]
19:13-!-linagee_ [] has joined #mythtv
19:13<tmk>robbie: do you want to archive shows or anything
19:13<tmk>or just record/watch
19:16<warlord>Ok, a couple of things. First, mythbackend seems to periodically crash. I'm on RH9. I can't run under gdb (if I try it will crash gdb as soon as I try to enter the EPG)...
19:16<warlord>[Thread 1209214656 (LWP 5344) exited]
19:16<warlord>Couldn't get registers: No such process.
19:16<warlord>(gdb) where
19:16<warlord>Cannot fetch general-purpose registers for thread 1175660736: generic error
19:16-!-linagee [] has quit [Read error: 60 (Operation timed out)]
19:17<warlord>Problem #2: If I'm in the EPG and I page-up or page-down multiple times before it finishs redrawing, when I finally stop it will redraw the EPG incorrectly.
19:17<warlord>For example, I got the guide into a state where it was displaying channels 54, 49, 39, 57, 58, and 59 (cursor was on 58).
19:18<warlord>If I wait for the redraw to finish before hitting page-up or page-down again it doesn't seem to happen.
19:18<warlord>Bug #3: if the backend DOES crash, the frontend apparantely doesn't reconnect -- it just hangs. (or maybe I'm just not patient enough?)
19:19-!-linagee_ [] has quit [Read error: 54 (Connection reset by peer)]
19:19* warlord is done kvetching now and is hoping for some insightful comments from you wonderful people :)
19:21-!-linagee_ [] has joined #mythtv
19:26<warlord>WD: was that enough information?
19:27<WD>warlord: I'm not really the person to ask
19:27-!-linagee [] has joined #mythtv
19:27<WD>in my experience, bad things happen when you try to do stuff too quickly with mythtv, though
19:28<warlord>WD: ahh, who is the right person? Or should I expect to wait a while. Also, is there a bug database to see what bugs others have found, or some appropriate way to report these kinds of things?
19:29<warlord>Yea, my wife noticed when she was alpha-testing my new unit ;) She crashed it about a half-dozen times in different ways. :(
19:29-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
19:29-!-linagee_ [] has quit [Read error: 60 (Operation timed out)]
19:30<WD>warlord: Well, tmk is the mastermind behind mythtv. I asked a question here earlier and am still waiting to hear anything back
19:30<WD>If I change channels too fast, mythfrontend crashes
19:30<warlord>Yea, I've noticed that... but sometimes the backend does, too.
19:31-!-linagee [] has joined #mythtv
19:31<WD>I've submitted a stack trace to mythtv-dev, so I guess all I can do at this point is wait...
19:32<choenig>WD: what is the 'mastermind' in you opinion?
19:32<tmk>wd eh?
19:32<tmk>i do ivtv
19:32<WD>warlord: Yeah, a bugzilla for mythtv would be cool
19:32<WD>Oh, Oops... heh
19:32<WD>I'm on both mailing lists, and must've gotten the two mixed up! :)
19:33<warlord>The ivtv part seems to be working really well (hi again, tmk ;)
19:34<WD>Isaac is the MythTV guy. Not sure what handle he uses, or if he's online
19:34<warlord>Oh, another (user) question -- is there some documentation that explains all the different 'keypress' functions on each of the different main pages? I've come up with an experimental list but a comprehensive user guide would be useful.
19:34<tmk>he's chutt
19:34<warlord>ahh, well, hopefully Chutt will respond :)
19:34<tmk>in the mythtv dir
19:35<warlord>Cool. Now if only there were an easy way to remap them, so the same keys on the remote could do different things on different "pages"...
19:36<WD>While there's chatter in here... is there anything more than a stack trace that would be helpful to troubleshooting a segfault? i.e., since I've got gdb open, is there anything else I can do to help?
19:38<warlord>uh, stack trace is about the best thing.. maybe print out a few variables.. not sure what chutt will need.
19:40<warlord>what version of gdb are you using? when I try to run the backend under gdb it crashes gdb.
19:40-!-linagee_ [] has joined #mythtv
19:41<WD>warlord: gdb-5.3 under Gentoo
19:41<WD>I've not tried running mythbackend under gdb, though. Just mythfrontend
19:41<warlord>AHH.. ok.
19:41<warlord>I haven't tried the frontend.
19:41<warlord>Anyways, gotta run to dinner. Hopefully someone will respond while I'm gone.
19:41-!-warlord is now known as warlord-dinner
19:43<tmk>WD: usually it's the backend that crashes
19:43-!-linagee_ [] has quit [Read error: 104 (Connection reset by peer)]
19:43<WD>tmk: With my fast-channel-change crasher, it's the frontend. Backend remains running just fine
19:44-!-linagee_ [] has joined #mythtv
19:44<WD>I wonder as a workaround if there's a way to have mythfrontend respawn if it terminates?
19:44<Chutt>or you could, you know, fix the bug as a workaround.
19:44<Chutt>instead of whining about it.
19:45-!-jkolb [] has quit [Read error: 113 (No route to host)]
19:46<choenig>btw, Chutt, did you have a look at my tiny patch?
19:46<WD>Yeah, I'll get right on that
19:46<Chutt>choenig, yeah, i've got it in my local tree
19:46<Chutt>i've been extremely busy recently, though, so i haven't checked anything in yet
19:46<choenig>Chutt: fine :-)
19:47<schwin97>I have some questions about the ringbuffer and was wondering if anyone would mind helping me with some answers
19:48-!-linagee__ [] has joined #mythtv
19:49<schwin97>if you had 2 hours in the buffer, is it possible to grab what is in the buffer and write it out as if it were a 'normal' recording?
19:50-!-linagee__ [] has quit [Read error: 104 (Connection reset by peer)]
19:50<tmk>Chutt: what does the 'toggle recording' button do in 'watching live tv'
19:50<tmk>start recording from 'now'?
19:50<tmk>oh :<
19:50<schwin97>I'm guessing that must be an issue with the structure of the ringbuffer
19:50<tmk>what if i just copied the .nuv file in /media/store/buffers
19:51<Chutt>tmk, if and only if you haven't ringed around
19:51<WD>schwin97: What I do is: 1) mv <recodring.nuv> <output.nuv> 2) Exit from watching TV 3) Start watching again
19:51<tmk>if i haven't exceeded the length of my buffer size
19:51-!-linagee__ [] has joined #mythtv
19:51-!-linagee [] has quit [Read error: 110 (Connection timed out)]
19:53-!-linagee__ [] has quit [Read error: 104 (Connection reset by peer)]
19:56-!-StarHeart [] has quit ["Client exiting"]
19:57<schwin97>so what is it about ringing around that stops the ability to copy the information in the buffer to a file?
19:57<Chutt>the file header's no longer there?
19:58-!-linagee [] has joined #mythtv
19:58<schwin97>that is what I was curious about... is the file header matched up with the information in the beginning of the file, or is it static with respect to any information in the buffer?
19:59<Chutt>beginning of the file
20:00<schwin97>something tells me you have already gone down this road...?
20:00<Chutt>it could be done, but it's not trivial
20:00-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
20:00<Chutt>and i don't see a need for it
20:00-!-linagee [] has joined #mythtv
20:00-!-mecraw [~mecraw@] has quit ["Trillian ("]
20:01<schwin97>understand... I was just thinking it would be interesting to be able to pull out video/audio from a recording (either from the buffer or not)
20:01-!-linagee_ [] has quit [Read error: 110 (Connection timed out)]
20:04-!-linagee_ [] has joined #mythtv
20:07-!-steelep [~signwatch@] has quit ["me is bugging out"]
20:07<lmatter_work>schwin97: There was a thread on the maillist a while ago
20:08<lmatter_work>Regarding watching a show for a few minutes, and deciding to record it.
20:08<schwin97>I will go search and see what everyone else found
20:08-!-linagee__ [] has joined #mythtv
20:08<lmatter_work>would be nice if the ringbuffer was saved to the beginning of the recording.
20:08<lmatter_work>I'm guessing noone ever made a patch
20:09-!-linagee__ [] has quit [Read error: 104 (Connection reset by peer)]
20:14-!-linagee__ [] has joined #mythtv
20:14-!-choenig [] has quit [Remote closed the connection]
20:16-!-tmk is now known as tmk\soccer
20:16-!-linagee__ [] has quit [Read error: 104 (Connection reset by peer)]
20:19-!-linagee [] has quit [Read error: 110 (Connection timed out)]
20:25-!-linagee_ [] has quit [Read error: 110 (Connection timed out)]
20:27-!-linagee [] has joined #mythtv
20:27-!-lmatter_work [] has quit ["Client Exiting"]
20:31-!-linagee [] has quit [Read error: 54 (Connection reset by peer)]
20:31-!-linagee [] has joined #mythtv
20:33-!-activelow [] has joined #mythtv
20:37<hadees>where is msp3400 in menuconfig?
20:45-!-linagee [] has quit [Read error: 60 (Operation timed out)]
20:45-!-linagee_ [] has joined #mythtv
20:52-!-linagee [] has joined #mythtv
20:52<WD>Hey Chutt, can you think of any reason why NuppelvideoPlayer::Pause() should *not* wait for more than 1000 ? I tried increasing the value to 10000 and the mythfrontend crash disappeared for me
20:54<WD>It's just a guess, but it looks like if you attempt a rapid channel change, and if the time taken to pause the video to change channels takes more than one second, there will be a segmentation fault
20:54<echo>what's the best quality I can expect to get and not drop frames using mythtv on a 1.4Ghz t-bird? Which encoders should I use? RTJPEG or MPEG-4? What quality settings?
20:55<Chutt>it should probably just print an error and retry it
20:55<Chutt>which is what i was going to do
20:56<Chutt>make it like the other waits
20:57<vektor>Chutt: tvtime is finally in debian, btw.
20:57-!-linagee [] has quit [Read error: 104 (Connection reset by peer)]
20:58<WD>Chutt: Would you like me to give a shot at a patch to have it do retries?
21:00-!-linagee [] has joined #mythtv
21:01<Chutt>vektor, i saw
21:01<Chutt>wd, naw, it's very minor
21:01<vektor>Chutt: Seems that mythtv still isn't :)
21:01<Chutt>mythtv can't be.
21:01<vektor>Bullshit, really?
21:02<WD>Chutt: Ok, cool. I'll give it a shot on my machine with retries to see how well it works.
21:02<Chutt>unless you want to disable all the good encoding methods
21:02<Chutt>wd, all you have to do is change the if to a while
21:02<vektor>Wow, I had no idea. I guess for the same reason lame isn't there.
21:02<Chutt>that too
21:02<Chutt>libmp3lame's also a dependency
21:03<WD>Chutt: Yup. That's what I've got. I wonder if there is any reason to limit the number of retries, though?
21:03<Chutt>wd, naw
21:03-!-linagee__ [] has joined #mythtv
21:05<echo>hey, where does mythtv store it's transcoded files?
21:06<echo>in the recordings dir all I see are .nuv fils.
21:06<echo>er. files.
21:06-!-linagee_ [] has quit [Read error: 110 (Connection timed out)]
21:06-!-warlord-dinner is now known as warlord
21:07<Chutt>it makes new .nuv files.
21:07<warlord>Chutt: did you get the chance to read my bugs from about 1.5 hours ago?
21:07<echo>how would I convert that to .avi ?
21:07<Chutt>use an external program.
21:07<Chutt>warlord, not really, no.
21:08<echo>"MythTV doesn't use standard Nupplevideo files, which is why you MPlayer complains if you try to view them."
21:08<echo>teh suck.
21:08<warlord>Chutt: can you page back or shall I retype?
21:10<Chutt>i'm really not interested in bug reports if they don't come with a backtrace.
21:10<Chutt>or a patch fixing the issue, of course.
21:10-!-linagee_ [] has joined #mythtv
21:10<warlord>note that bug != crash (in all cases)
21:10<warlord>you're not at all interested in a re-draw failure?
21:11<Chutt>if you bothered to search the mailing list, you'd see that particular issue was already discussed
21:11<Chutt>and that i can't reproduce it
21:11<Chutt>and since i can't reproduce it, i can't fix it.
21:11<warlord>Yea, I know that feeling...
21:11<warlord>I'll search the mailing list to see what they said, but I can (mostly) reliably reproduce it...
21:12<Chutt>start codin, then. =)
21:12<warlord>(by hiting page-up or page-down a few times in rapid succession and then stopping and waiting for the EPG to catch up)
21:12<Chutt>there was a patch posted recently that changes how the program guide draws slightly
21:13<warlord>Well, there *IS* a crash in mythbackend which is hard to fix because whenever I try to run the backend under gdb, GDB crashes...
21:13<Chutt>you could try that, or wait for me to get it committed to cvs.
21:13<Chutt>that's because redhat shipped a distro without a working gdb for threaded programs
21:14<warlord>Heh. Yea Red Hat. Does the standard gdb work, or does it need some thread-safe patch?
21:14<Chutt>it needs updated to the new threading system that redhat's using.
21:14-!-WD [] has quit ["ChatZilla 0.9.28 [Mozilla rv:1.5b/20030912]"]
21:14<Chutt>i'm not aware if that's been done yet.
21:14<warlord>OH. :(
21:14<warlord>So I'm SOL, then.
21:14<warlord>that makes life harder.
21:15<Chutt>slightly :p
21:15<kja>hmm, my redhat9 gdb works fine..
21:15<warlord>kja: have you tried running mythbackend under gdb?
21:15<Chutt>kja, heh, it doesn't work for anyone else
21:16<kja>they must be broken then :)
21:16<warlord>kja: are you using RH's gdb?
21:16<warlord>and how did you compile mythtv?
21:16<warlord>Chutt: I must say that in general I'm extremely impressed...
21:16<warlord>my wife, however, is annoyed that she was able to crash the system a half-dozen times in under 30 minutes. :(
21:16<kja>redhat9 gdb 5.3 standard, compiled myth with debuggin
21:17<warlord>kja: hmm, me too.. it dont work for me.
21:17<kja>strange..i'm using vanilla 2.4.22 though
21:18<kja>not rh kernels
21:19<warlord>AHHH... *THAT* is probably the difference.
21:19-!-linagee [] has quit [Read error: 110 (Connection timed out)]
21:20<kja>try compile a vanilla kernel, and report back the results then?
21:21<warlord>kja: that would be a PITA, but I'll consider it. It would require me to build way too may additional drivers.
21:21-!-jkolb [] has joined #mythtv
21:22<kja>he, that should be simple...had to import the nforce2 ethernet (nvnet) into kernel to get nfsroot working
21:23-!-linagee__ [] has quit [Connection timed out]
21:23<warlord>Yea, I need to nforce2 ethernet as well ;)
21:25-!-DJHaCK [] has joined #mythtv
21:25<warlord>Hmm, there appears to have been a glibc-2.2.4 problem with Red Hat and debugging multi-threaded apps... But that doesn't seem to apply to RH9.
21:25<kja>would anyone know if a startcode in a mpeg2 ps pkt is allowed to span across two pkts?
21:26<kja>getting frequent drop by one compared to keyframedist in that seek fix patch
21:26<jkolb>kja: You mean can you have 00 00 in one packet and 01 b3 in the next?
21:27<jkolb>Yes, you can.
21:27<kja>k, thanks a lot jkolb, going to fix that now :)
21:28<jkolb>The PTS/DTS go in the packet that contains the first byte of the start code.
21:29-!-linagee_ [] has quit [Read error: 110 (Connection timed out)]
21:29<kja>ok, need to have a look at how avformatdecoder handles that as well then.
21:29<warlord>Chutt: feature questions for you -- I'm interested in coding up two features and wanted to discuss UI with you. #1: adding "repeat" status to the EPG, and #2 is being able to record only non-repeat showings of a program. #1 looks like it would require some amount of rototilling the UI apis. What say you?
21:29-!-daralc [~flsdakfja@] has joined #mythtv
21:30<daralc>what does this problem sound like: myth runs fine, when i go to watch tv changing channels is really really slow and almost unresponsive, pulling up the guide is real slow while watching tv
21:30<daralc>1400mhz tbird, 512mb ddr
21:30* kja thinks linagee is having some connection trouble today
21:30<daralc>not sure if bttv tuner card can handle it or something?
21:31<jkolb>kja: Do you have a copy of the ISO docs for mpeg?
21:31<kja>no, i don't, why?
21:32<jkolb>It covers all of this.
21:32<kja>ahh, but have to pay for them, no?
21:33<kja>searched the iso site, but only pay-per-view :)
21:33<jkolb>I think there's a copy on the ivtv site or something. At least, I recall someone saying they'd provide a copy back when Kevin first started writing the driver.
21:33<kja>hmm, i'll have a look over there then
21:37<jkolb>Hm. One of the guys said he'd make them available, but didn't post them up.
21:41<Chutt>i have them somewhere
21:41<jkolb>I have them at work, but I'm not there.
21:41<Chutt>i probably won't be able to find em easily, though =)
21:41<Chutt>warlord, adding a (repeat) to the end of the description would be the easiest way to handle that
21:42<jkolb>Hm. Lemme see if I left my machine on at work.
21:42<Chutt>the only problem is that the zap2it data doesn't always contain the repeat flag for everything that _is_ a repeat
21:46<warlord>Chutt: Well, I was debating whether to add it to the program name, or the program title in the upper-left window, or perhaps an (R) in the grid display and (Repeat) in the program info display...
21:46<warlord>Chutt: is the EPG scroll patch you mentioned?
21:47<warlord>ok, I'll apply that to my 0.11 and see if it helps, ty.
21:47<warlord>Any opinion on the repeat ui placement? (I'd like to have a decent chance of actually getting a patch accepted ;)
21:47<Chutt>doesn't really matter to me
21:48<Chutt>i just never bothered to do anything with it since the source data wasn't reliable
21:48<warlord>ok. leaves a lot of leeway. :)
21:48<warlord>sure, but if the data is THERE it would be nice to use it..
21:48<daralc>if the cable looks shitty, like kinda fuzzy, could it be the cable signal itself or the hardwre?
21:48<warlord>you may get false negatives but never a false positive
21:48<warlord>daralc: i would guess signal.
21:49<warlord>i've got a channel playing right now that's a bit fuzzy, but an hour ago a different channel was perfectly clear.
21:50<daralc>fucking on campus cable
21:50<daralc>suck a dick clemson
21:52<daralc>is there a way to reset my databases?
21:52<kja>yea, no more off-by-one keyframedist autod., at least for now :)
21:52<jkolb>kja: They're all there now. 11172 isn't OCRed, and it's just audio anyway, so you may not need it.
21:53<daralc>i got extra channels in program guide, like 3,3,4,4,5,5,6,6,7,7
21:53<daralc>and i tried to DROP TABLE and recreate for videommetadata
21:53<daralc>but now it can't add in the shits to it right
21:53<kja>jkolb: on ivtv site?
21:53<Chutt>'channel' is the proper table.
21:53<jkolb>kja: No, at the url I /msged to you.
21:54<kja>aha, thnx ...
21:56<warlord>Chutt: FYI, the way I reproduce the EPG display problem: go to the EPG, press page-down about 5 times in succession, about two presses per second. Stop, and watch the guide (incorrectly) catch up.
21:58<warlord>(note page down, not down arrow)
22:11<kja>Chutt, have you looked at the patch i mailed you, or are you still extremly busy? :)
22:11-!-DJHaCK [] has quit [Read error: 104 (Connection reset by peer)]
22:12<Chutt>kja, very, very briefly
22:12<Chutt>i want to get the profile stuff in cvs first
22:12<Chutt>before i'd apply that setup patch
22:13<jkolb>Does linux have support for fibers? Made writing my parser really easy on 2k.
22:13<Chutt>kja, so, how stable is your dvb patch #5?
22:13<Chutt>like, can i commit that?
22:14<kja>mount everest stable :)
22:14<kja>want to get simple diseqc stuff in first
22:15<kja>but i guess i could do that in cvs too
22:18<kja>and i've done some changes/cleanups in my local tree
22:18-!-jkolb [] has quit []
22:22<Chutt>oh wow
22:22<Chutt>read -users
22:23<Chutt>most recent message.
22:25<warlord>"I hate when this happens?"
22:25* warlord reads the group via pipermail archive
22:25<Chutt>'Sound ok when functioning as PC'
22:25<Chutt>pipermail archives by the local time on the machine when the message was sent
22:26<Chutt>obviously doesn't work in more than one timezone.
22:26<warlord>Yea, it stores send-time as opposed to arrival time..
22:26<kja>my sound wanders through the air from my pc to my amplifyer, doesn't yours?
22:26<warlord>but yea, WOW.. ;)
22:27<warlord>Now I dont feel so stupid asking my questions -- at least mine are (usually) well thought out (even if I havent drunk the code yet)
22:27-!-daralc [~flsdakfja@] has quit [Read error: 104 (Connection reset by peer)]
22:28<kja>Chutt, should I send you a copy of my local dvb tree?
22:28<Chutt>kja, not yet, no
22:29<Chutt>i'm not going to be able to get started on the profile stuff until tomorrow
22:29<kja>i'll play some more then
22:33* warlord takes it that Chutt still can't reproduce the EPG redraw problem?
22:36<warlord>what happens if you page-down 5 times in rapid succession?
22:36<warlord>for me, the channel numbers/names are wrong in a couple of entries..
22:36<warlord>(I'm configured 6x4)
22:38<Chutt>everything's right.
22:38<kja>works perfectly here too, so you better do some debugging
22:38<warlord>i presume you're running cvs and not 0.11?
22:38<Chutt>nothing's changed in cvs.
22:38<Chutt>in that area
22:38<Chutt>you _should_ just try the patch i pointed out.
22:38<warlord>Yea, I will..
22:40<warlord>but what it looks like is going on is that the EPG queues a redraw for the grid but the redraw doesn't finish before the grid "changes" again -- so when it catches up it flushes the redraws and the channel numbers are wrong (from the older redraw events).
22:40<warlord>Unfortunately I'm more of a gnome hacker than a qt hacker (never touched qt before)
22:40<Chutt>prepare to be, well, amazed, then :p
22:40<Chutt>the api actually makes sense
22:40<Chutt>and <gasp> it's documented!
22:40<warlord>gtk+ makes sense to me.
22:41<warlord>and it's fairly well documented, too..
22:41<warlord>but this is not the place for this discussion.
22:41* warlord really isn't looking for a relgious argument, or even technical argument, on gnome v. qt
22:43<warlord>but -- i'll try that patch and see if it helps.. if not, well, i'll try some debugging of the frontend -- is that multithreaded, too?
22:43<Chutt>not really
22:43<Chutt>at times it is, at times it isn't
22:43<warlord>so I should be able to debug it on RH9?
22:43<Chutt>oh, no
22:43<Chutt>everything threaded
22:43<Chutt>the gui isn't always, though
22:44<Chutt>which is what i meant
22:44* warlord sighs
22:44<warlord>how... frustrating.
22:44<Chutt>your choice of distributions :p
22:45<warlord>hey, there was no warning! "WARNING: using RH9 means you wont be able to use gdb."
22:45<tmk\soccer>sup chutt
22:45<tmk\soccer>you still busy?
22:45-!-tmk\soccer is now known as tmk
22:45* thor_ wonders why s-video cables have all those pins in them
22:45<Chutt>working on something for real work
22:45<tmk>yeah i figured
22:46-!-tmk [] has quit ["Client exiting"]
22:48-!-sc00p_ [] has quit ["Client exiting"]
22:56<warlord>Cool, that seems to fix the problem! :)
22:58-!-Markos [] has quit ["Client exiting"]
22:59<warlord>now to cause the backend crash and try to track that down for ya...
23:01<warlord>Hmm, there appears to be a deadlock issue in mythfrontend.
23:01<warlord>Chutt: how would you like the gdb stack trace, and what other info can I provide?
23:01-!-Markos [] has joined #mythtv
23:20<warlord>ok, stack trace sent to -dev
23:21-!-Markos [] has quit ["Client exiting"]
23:21-!-dopez [] has quit [Remote closed the connection]
23:26-!-Markos [] has joined #mythtv
23:31-!-billytwowilly [] has joined #mythtv
23:31-!-kja [] has quit ["..."]
23:36-!-billytwowilly [] has quit ["Client exiting"]
23:47-!-bbeattie [] has joined #mythtv
23:50-!-Markos [] has quit ["Client exiting"]
23:58-!-DJHaCK [] has joined #mythtv
23:58-!-tmk [] has joined #mythtv
---Logclosed Wed Sep 17 00:00:24 2003