Back to Home / #mythtv / 2003 / 06 / Prev Day | Next Day
#mythtv IRC Logs for 2003-06-07

00:58<thor_>Isaac, I'm really on the verge of commiting this: http://www.sigvaldason.com/mvid_tree.png
00:58-!-rkulagow__ [] has quit [Read error: 54 (Connection reset by peer)]
00:58-!-rkulagow__ [~rkulagow@12-206-151-240.client.attbi.com] has joined #mythtv
00:58<thor_>but it's doing weird things when returning from mplayer (ie. I don't understand system() ?)
00:58<thor_>send you a tarball?
01:01<mdz_>thor_: what sort of weird things?
01:01<mdz_>system() is pretty much what it looks like
01:01<thor_>just really sluggish
01:01<thor_>which is odd
01:01<thor_>and top shows X is sometimes grabbing large resources
01:02<thor_>I'm probably just tired
01:03<mdz_>thor_: did you set a breakpoint or anything to see if it's making it back to your code before it goes weird?
01:04<thor_>it's back to my code ... pathetic thing is I have moegreen's code right there beside me which does the same thing (and properly). I think I'll just go to bed. It'll be trivial in the morning
01:05<mdz_>good plan
01:17-!-jrh [] has quit [Read error: 110 (Connection timed out)]
01:59-!-jrh [~jr@ip68-5-230-73.oc.oc.cox.net] has joined #mythtv
01:59-!-Timon [] has quit [Remote closed the connection]
02:07-!-bline [~sbeck@24.84.93.233] has joined #mythtv
02:12-!-PeteCool [] has quit ["Client exiting"]
03:12-!-kiwi_uk [~kiwiuk@pc3-nfds1-6-cust201.nott.cable.ntl.com] has joined #mythtv
03:14-!-kiwi_uk [] has quit [Client Quit]
03:32-!-jrh [] has quit [Read error: 110 (Connection timed out)]
04:00-!-marc [~marc@194.235.194.29] has joined #mythtv
04:04-!-Viddy [] has quit [Remote closed the connection]
04:09-!-marc [] has quit [Read error: 54 (Connection reset by peer)]
04:12-!-jrh [~jr@ip68-5-230-73.oc.oc.cox.net] has joined #mythtv
04:24<-- jrhhas quit ()
04:28-!-marc [~marc@194.235.194.47] has joined #mythtv
04:38<-- marc(~marc@194.235.194.47) has left #mythtv
05:11-!-__inman__ [~dert@dsl092-236-197.phl1.dsl.speakeasy.net] has joined #mythtv
05:22-!-_inman_ [] has quit [Read error: 60 (Operation timed out)]
06:01-!-FryGuy [] has quit [Read error: 54 (Connection reset by peer)]
08:23-!-rkulagow__ [] has quit [Read error: 104 (Connection reset by peer)]
08:24-!-rkulagow__ [~rkulagow@12-206-151-240.client.attbi.com] has joined #mythtv
08:40-!-rkulagow__ [] has quit [kornbluth.freenode.net irc.freenode.net]
08:40-!-sc00p [] has quit [kornbluth.freenode.net irc.freenode.net]
08:40-!-thor_ [] has quit [kornbluth.freenode.net irc.freenode.net]
08:40-!-Captain_Murdoch [] has quit [kornbluth.freenode.net irc.freenode.net]
08:40-!-Cloak [] has quit [kornbluth.freenode.net irc.freenode.net]
08:40-!-dilinger [] has quit [kornbluth.freenode.net irc.freenode.net]
08:41-!-rkulagow__ [~rkulagow@12-206-151-240.client.attbi.com] has joined #mythtv
08:41-!-sc00p [~oldendic@zink-a-dip3.nat.okstate.edu] has joined #mythtv
08:41-!-dilinger [irc@sloth.voxel.net] has joined #mythtv
08:41-!-Cloak [mmen@crackaddict.com] has joined #mythtv
08:41-!-Captain_Murdoch [~buy_more_@ip68-107-147-80.hr.hr.cox.net] has joined #mythtv
08:41-!-thor_ [~thor@208.185.11.34] has joined #mythtv
08:49-!-thor_ [] has quit [Read error: 60 (Operation timed out)]
11:54-!-poptix [] has quit [Read error: 110 (Connection timed out)]
12:00<__inman__>i see the dbschemaver was adopted, finally.
12:00<__inman__>is it useful to resubmit my fixschema applet?
12:01-!-__inman__ is now known as inman
12:10-!-poptix [poptix@precious.net] has joined #mythtv
12:11<yebyen>man, auto commercial skip rocks so much
12:12<yebyen>you notice it more when you don't have it (when I watch tv anywhere else, even on my parents DVR cable box)
12:19-!-just1nux [] has quit [Read error: 60 (Operation timed out)]
12:42-!-_inman_ [~dert@dsl092-236-197.phl1.dsl.speakeasy.net] has joined #mythtv
12:42-!-rkulagow__ [] has quit [Read error: 54 (Connection reset by peer)]
12:43-!-rkulagow__ [~rkulagow@12-206-151-240.client.attbi.com] has joined #mythtv
12:46-!-Ripp [] has quit ["Client exiting"]
12:48-!-Ripp [~ripp@209.194.224.236] has joined #mythtv
12:48-!-hfb [~hfb@pool0166.cvx12-bradley.dialup.earthlink.net] has joined #mythtv
12:57-!-hfb [] has quit [Read error: 104 (Connection reset by peer)]
12:57<Ripp>cool..hehe...just put a slave backend/frontend on my wifi laptop...works OK for shows recorded w/ a good clean signal (smaller files)
12:57-!-hfb [~hfb@pool0183.cvx17-bradley.dialup.earthlink.net] has joined #mythtv
13:07-!-inman [] has quit [Read error: 110 (Connection timed out)]
13:18-!-hfb [] has quit ["Client exiting"]
13:22<Snow-Man>Looks like the GF4MX works alright.
13:24-!-__inman__ [~dert@dsl092-236-197.phl1.dsl.speakeasy.net] has joined #mythtv
13:26-!-kiwi_uk [~kiwiuk@pc3-nfds1-6-cust201.nott.cable.ntl.com] has joined #mythtv
13:33-!-_inman_ [] has quit [Read error: 60 (Operation timed out)]
13:43-!-_inman_ [~dert@dsl092-236-197.phl1.dsl.speakeasy.net] has joined #mythtv
13:43<Ripp>bah mplayer's not starting from the new mythvideo...
13:44<Ripp>well it is but it's hanging up..
13:44<Ripp>on setting up lirc support?
13:48<Ripp>mplayer pisses me off
13:52<Ripp>OK reboot and all is fine :p
13:52<-- rkulagow__(~rkulagow@12-206-151-240.client.attbi.com) has left #mythtv
13:59<Ripp>anyone versed in configuring the new mythvideo stuff?
14:02<Ripp>bah nm...it's not in the code :(
14:07-!-__inman__ [] has quit [Read error: 110 (Connection timed out)]
14:16-!-thor [~thor@208.185.11.34] has joined #mythtv
14:18<Chutt>hey thor
14:18<thor>hey
14:19<thor>you see the screenshot for Video Lists?
14:19<Chutt>yeah
14:19<Chutt>looks nice
14:19<Chutt>going to commit?
14:19<thor>just need to sort out why system() from a slot makes everything really sluggish
14:20<Chutt>send me a tarball?
14:20<Chutt>i'll be happy to take a look
14:20<thor>ok
14:20<thor>it's odd
14:20<thor>hang on a bit, just woke up a little while ago
14:20<thor>missing sleep all week
14:31<thor>Hrm ... database changes
14:31<thor>ah
14:31<Chutt>very slight ones
14:32<thor>yup, and useful ... I should do something to mythmusic startup as well
14:32<Chutt>eh, it's close enough
14:32<Chutt>that'll happen on mythmusic startup, too
14:33<thor>ah ... need more coffee
14:34-!-Cloak [] has quit ["BitchX: No windows left!"]
14:34-!-Cloak [mmen@crackaddict.com] has joined #mythtv
14:43-!-rkulagow__ [~rkulagow@12-206-151-240.client.attbi.com] has joined #mythtv
14:43-!-justin [] has quit [Read error: 104 (Connection reset by peer)]
14:46-!-justin [~justin@H239-211.STATE.RESNET.ALBANY.EDU] has joined #mythtv
14:46<thor>huh
14:46<thor>if that ain't the oddest
14:46<thor>seems to work great now
15:07<thor>moegreen, you around?
15:10<thor>Chutt, that working for you?
15:53-!-yebyen [] has quit [Remote closed the connection]
15:53-!-moegreen [] has quit [Read error: 104 (Connection reset by peer)]
16:01-!-PeteCool [~pete@modemcable019.237-201-24.mtl.mc.videotron.ca] has joined #mythtv
16:02<PeteCool>Chutt: does the code check for sound<->video sync often during recording?
16:03<PeteCool>Chutt: I have a file with a few dropped frames during ~10 minutes, video is behind at least two secs... seems better now, though
16:03<PeteCool>Just wondering
16:13-!-kiwi_uk [] has quit ["Peace and Protection 4.22"]
16:31-!-moegreen [~jdanner@nr4-216-196-152-117.fuse.net] has joined #mythtv
16:44<Snow-Man>mdz; Around?
16:45<mdz_>Snow-Man: yes
16:46<Snow-Man>Have you run into the problem where mythtv-backend attempts to create ~/.qt for root as the user mythtv?
16:46<Snow-Man>Seems like the --chuid is working but mythtv is picking up the wrong directory from somewhere.
16:46<mdz_>it's just some qt brokenness
16:47<mdz_>doesn't cause any problems with mythtv, just an annoying message
16:47<Snow-Man>Ah, well, then the problem must be something else. :)
16:48<Snow-Man>Unknown column 'use_ts' in 'field list'
16:48<Snow-Man>Whoops.
16:48<mdz_>that'll do it
16:48<Snow-Man>mdz: You could fix it by setting HOME to /home/mythtv (or using getent to find the home for the mythtv user) in your init script.
16:48<Snow-Man>If you care anyway. :)
16:50<mdz_>Snow-Man: yes, probably
16:50<mdz_>the backend really doesn't care what its $HOME is, though, thankfully
16:51<Snow-Man>More than probably. Not a big deal though, no.
16:52<mdz_>it's evil for qt to be trying to create things in $HOME anyway
16:53<Snow-Man>Segmentation fault
16:53<Snow-Man>Ouch.
16:53<mdz_>hope you built with -g
16:54<Snow-Man>Dunno.
16:55<Snow-Man>Nope, sorry. :)
16:55<Snow-Man>I think I know the problem anyway.
16:55<Snow-Man>Channel::Open(): Can't open: /dev/video1
16:57<Snow-Man>Damnit.
16:58<Snow-Man>The input connections thing always seems to display 2 entries even when there's only one source.
16:59<mdz_>hmm?
17:00<mdz_>one card, one source, or two cards, one source?
17:01<mdz_>the input connections dialog displays one entry for each card * input
17:01<mdz_>it doesn't care how many sources there are
17:04<mdz_>if you have an input with nothing connected to it, use (None)
17:07-!-Kuwanger [~nana@1Cust157.tnt1.farmland.in.da.uu.net] has joined #mythtv
17:07* Kuwangeris having a weird problem. :/
17:07<Snow-Man>one card, one source
17:08<Snow-Man>Input connections displayed two sources (identical name)
17:08<Kuwanger>"No setting found for this machine's BackendServerIP.
17:08<Kuwanger>Please run setup on this machine and modify the first page
17:08<Kuwanger>of the general settings."
17:08<Snow-Man>It should have only displayed one source because there only is one source.
17:09<Snow-Man>It displayed three inputs off the card, and that's fine.
17:09<Kuwanger>Aha..I think..
17:09<mdz_>are you talking about the dialog that lets you select the input? or the dialog that lets you select the source to connect to that input?
17:10<Snow-Man>I picked 'television', went in, and under sources was 'cox standard' and then 'cox standard' again, and I could choose either.
17:10<Kuwanger>Nope. :(
17:10<mdz_>Kuwanger: follow the instructions it gave you
17:10<Snow-Man>The dialog that selects the source
17:10<Snow-Man>It did that with both the debs and cvs too.
17:11<mdz_>Snow-Man: that code does a straight select from the videosource table in the database
17:11<mdz_>so if you are getting two sources there, you have two sources in the database
17:11<Kuwanger>mdz_: How? :)
17:11<Snow-Man>Well, I'll check the db.
17:11<Kuwanger>Ah, opened the wrong setup, it seems..
17:12<Snow-Man>| sourceid | name | xmltvgrabber | userid |
17:12<Snow-Man>+----------+--------------+--------------+--------+
17:12<Snow-Man>| 2 | cox standard | tv_grab_na | |
17:12<Snow-Man>+----------+--------------+--------------+--------+
17:12<Snow-Man>That's it..
17:15<Kuwanger>Hmm..though it does seem to have magically fixed itself through running the setup I luckily still have.
17:16<Kuwanger>:/
17:18<Kuwanger>Thanks.
17:18<-- Kuwanger(~nana@1Cust157.tnt1.farmland.in.da.uu.net) has left #mythtv
17:20<Snow-Man>Error opening nfs lock file: No such file or directory
17:20<Snow-Man>hrmpf.
17:22<Snow-Man>Heh, it checks that the recordings directory is valid now. :)
17:22<Snow-Man>HOME=`getent passwd mythtv | cut -f6 -d:`
17:23<Snow-Man>There we go, got the backend started at least.
17:24<mdz_>Snow-Man: how come your only source is sourceid 2? that's an autoincrement column
17:24<mdz_>I think you're trying to fool me :-)
17:25<Snow-Man>No, not trying to fool you but I think I did add an entry and then delete one..
17:25<Snow-Man>Not manually but I said 'yes' one time I think.
17:26<Snow-Man>Actually, last time through I said 'yes' to both questions and redid everything.
17:26<Snow-Man>Now, I agree that it *should* have gotten a one then since the table should have been empty but apparently it didn't.
17:27<mdz_>I don't think 'delete from <table>' resets an autoincrement
17:27<mdz_>you need to drop and recreate the table I think
17:27<mdz_>I have no idea why you would get two entries in the list though
17:28<mdz_>though now that I look, I can reproduce the problem
17:28<mdz_>maybe it's getting loaded twice or something
17:28<Snow-Man>See, I'm not on crack. ;)
17:29<Snow-Man>ok, so I'm hopeing there's some way to send commands to mythtv-frontend that don't involve giving it focus in X and letting it use the keyboard.
17:29<mdz_>it's Chutt's fault; he wanted that combo box to be full right away, before the device value was modified :-P
17:30<Snow-Man>haha.
17:30<Snow-Man>I'm all for blameing it on Chutt. :)
17:30<mdz_>hmm, nope, the problem is not what I thought it was
17:30<mdz_>tunercardinput::fillselections clears the current selections before it tries to load new ones
17:31<Snow-Man>Any clue how I make line out, like, work
17:31<Snow-Man>?
17:31<mdz_>er, line out on your sound card?
17:31<Snow-Man>yea. It's sending what I want to go to line out to speaker out atm.
17:32<Snow-Man>Of course, this is probably going to be kind of tricky.
17:32<mdz_>you tried using the mixer already I assume?
17:32<Snow-Man>The mixer doesn't appear to have anything about lineout.. At least, not kmix.
17:32<Snow-Man>Maybe I'm missing something tho.
17:33<Snow-Man>Oh, there we go.
17:33<Chutt>blaming stuff on me?
17:33<Snow-Man>errrr, or not.
17:34<Snow-Man>That was kind of entertaining.
17:34<mdz_>Snow-Man: since you're so hot on that duplicated entry in the combo box, feel free to cvs update and tell me if my change just now fixed it
17:34<mdz_>Chutt: it actually turned out not to be your fault
17:34<mdz_>wrong combo box
17:35-!-just1nux [~jeff@adsl-68-73-113-144.dsl.emhril.ameritech.net] has joined #mythtv
17:35<Snow-Man>I need to work out how to get the debs to be rebuilt without running clean. :)
17:35<Chutt>heh
17:35<Chutt>since it takes forever to compile
17:35<Snow-Man>yeah.
17:35<mdz_>ccache
17:35<mdz_>or dpkg-buildpackage -nc
17:36<mdz_>or better, both
17:36<Chutt>heh
17:36<Snow-Man>ccache?
17:36* Snow-Manfigured there was a way.
17:36<Snow-Man>it would appear that line out isn't coming from PCM or whatever.
17:36<mdz_>Snow-Man: I'd explain ccache, but I'm sure you can apt-cache show with the best of them :-P
17:36<Snow-Man>haha.
17:36-!-bigguy [] has quit [Read error: 113 (No route to host)]
17:37<Snow-Man>I thought it was a dh or something, not a package.
17:37<Snow-Man>That's a cute package tho.
17:38* Snow-Mantries to remember that program to muck with the sblive's internal mixing parameters.
17:38<Chutt>heh
17:40<Snow-Man>Damnit, I know there is one.
17:40<Snow-Man>Of course, I don't know for sure what I can do with it exactly.
17:40<Chutt>heh
17:43<Snow-Man>The real trick will be, eventually, attempting to get mythtv to output to just line out while I play xmms or something else outputting to speaker.
17:43<Snow-Man>pabs was trying to do something like that at one point.
17:43<Snow-Man>Dunno if he ever got it to work.
17:47<mdz_>Snow-Man: I use alsactl
17:47<mdz_>and sometimes alsamixer
17:48<mdz_>I have serious doubts that you can do what you are attempting though
17:48<mdz_>the SB live can do hardware mixing I think, but I do not think it has independent DSPs to output two separate signals
17:48<Snow-Man>That's ok, if I can't, the cards are cheap.
17:49<mdz_>yep
17:49<Snow-Man>No answer about any ability to send commands to mythtv-frontend?
17:49<Snow-Man>Or myth-frontend or whatever.
17:49-!-FryGuy [~fryguy@12-246-43-18.client.attbi.com] has joined #mythtv
17:49<Chutt>needs keyboard focus
17:50<Snow-Man>That pretty much bites ass.
17:50<mdz_>get coding
17:50<Chutt>sorry :p
17:50<Chutt>yup
17:50<mdz_>you could probably have a socket control mechanism going by tomorrow
17:52<Snow-Man>yea, if I had time to work on it. Mebbe I'll take a look at things after dinner.
17:53<mdz_>Chutt: you were hinting at a release for this weekend; still considering it?
17:54<Snow-Man>Damnit, giving the stupid thing focus is kinda hard. :)
17:55<Snow-Man>Blargh, the channel list is still wrong, damnit.
17:56<mdz_>it doesn't get much easier than focus
17:56<mdz_>I find that clicking in the window or cycling windows with the wm both work very well :-P
17:56<Snow-Man>It's because I'm using enlightenment and each of the two screens has an additional 2 virtual desktops
17:57<Snow-Man>This app was compiled against libmyth version: 0.9.06072003-1
17:57<Snow-Man>but the library is version: 0.9.06042003-2
17:57<Snow-Man>heh.
17:58<Snow-Man>Ok, that changed things but not entirely correctly I think.
17:58<Snow-Man>There's only one entry in the dialog box now.
17:58<Snow-Man>But things which I havn't set default to it now instead of being 'none' like they were before. :)
17:59<mdz_>ah, right
17:59<mdz_>try now
18:00<Snow-Man>Damnit, the backend isn't starting anymore again, grr.
18:00<Snow-Man>Recompiling.
18:01<Snow-Man>I need to not strip this stuff.
18:01<mdz_>DEB_BUILD_OPTIONS=nostrip
18:02<Snow-Man>They don't appear to be compiled with -g atm either. :)
18:02<mdz_>that one's your problem for not changing settings.pro
18:02<Snow-Man>yea, yea. :)
18:03<Snow-Man>They're still pointing at the only source there. Lemme make sure the database didn't get changed somehow.
18:04<Snow-Man>Nope, still only one entry in cardinput.
18:04<Snow-Man>| 3 | 2 | 2 | Television | | NULL | N | | 72 |
18:05<mdz_>are you sure you rebuilt everything and are running the new code?
18:05<Snow-Man>Well, I'm pretty sure, I saw it recompile, I installed the debs...
18:05<Snow-Man>And it changed last time I did that. :)
18:05<mdz_>the makefile dependencies are not exactly reliable
18:06<Chutt>mdz, probably monday night
18:06<Chutt>i'm not going to be around tomorrow
18:06<Snow-Man>That's great to know.
18:06<mdz_>thank qmake
18:06<Snow-Man>It recompiled videosource.cpp and moc_videosource.cpp
18:06<Snow-Man>(And the executables)
18:07<mdz_>the change was videosource.h
18:07<mdz_>which is included in several places
18:07<Snow-Man>Alright, alright, I'll rebuild everything, I'm adding debugging symbols anyway.
18:07<mdz_>the one that's causing you problems is backendsettings.cpp I believe
18:07<mdz_>Snow-Man: install ccache
18:07<Snow-Man>Already did.
18:07<mdz_>using it?
18:08<Snow-Man>If you're asking them probably not.
18:08<mdz_>PATH=/usr/lib/ccache:$PATH
18:08<Snow-Man>I have to rebuild everything this time to add debugging symbols anyway.
18:08<Snow-Man>Alright.
18:08<Chutt>what are you building with debugging for?
18:08<Snow-Man>And I changed settings.pro and I didn't get a -g. :(
18:09<mdz_>you need to comment out CONFIG...release and uncomment CONFIG...debug
18:09<Chutt>have to make clean after you swap the build mode
18:09<mdz_>that too
18:09<mdz_>all of my testing has shown that the build flags for mythtv itself don't make a damn bit of difference
18:09<Chutt>mdz, but, but, but that guy wrote in and said that it doubled his performance!!!
18:10<Snow-Man>Weird, I just added to the relase CXX flags thingy a -g and that didn't work, but the debug thing worked so <Shrug>
18:10<mdz_>I think it would be perfectly fine to build with -g by default
18:10<Chutt>snowman, why are you building with debugging on anyway?
18:10<mdz_>-DMMX is probably the only thing in there that makes a difference
18:11<Snow-Man>Chutt: Fix your shitty code? ;)
18:11* Snow-Manducks.
18:11<Chutt>err, what's broken.
18:11<Snow-Man>Chutt: Actually, I did see a segfault earlier in something and debugging symbols would have been nice.
18:11<Snow-Man>It was mythtv-backend with no video things working, iirc.
18:11<Chutt>i really don't care much about segfaults in failure conditions
18:12<Chutt>:p
18:12* Snow-Manshrugs.
18:12<Snow-Man>Wouldn't have hurt to fix it.
18:12<Snow-Man>Not a big deal either, no.
18:14<mdz_>http://dijkstra.csh.rit.edu/~mdz/temp/lime-cpu.png
18:14<mdz_>see if you can spot when I changed the CFLAGS
18:15<mdz_>yeah, me neither
18:15<Chutt>heh
18:16<PeteCool>mdz_: is it during week 22?
18:16<PeteCool>cpu usage got higher ;)
18:17<mdz_>the resolution of the graph is a higher in the last 24 hours so it looks a little different
18:18<mdz_>PeteCool: no, probably watched while recording a bit more than usual that week
18:19<mdz_>it was 3 days ago
18:20<mdz_>and recording alone is still perfectly flat at 35%
18:20<mdz_>just like last week, and the week before
18:20<Snow-Man>Ahhhh, fuck.
18:20<Snow-Man>/dev/hda8 8.1G 7.7G 0 100% /home
18:20<Snow-Man>hate that shit.
18:21<PeteCool>Snow-Man: what filesystem are you using?
18:21<Snow-Man>ext2
18:21<PeteCool>with -T largefile/largefile4 ?
18:21<mdz_>Snow-Man: you probably want to ccache -M in that case
18:21<Snow-Man>eh? Probably not.
18:22<Snow-Man>I've got lots of crap that I can nuke.
18:22<mdz_>largefile4 would be a poor choice for home directories
18:22<Snow-Man>/dev/hda8 8.1G 7.4G 320M 96% /home
18:23<Snow-Man>There, that's better.
18:23<Snow-Man>Whoah, damn, shit goes a hell of alot faster with that ccache shiat.
18:24<Snow-Man>Give the m68k buildd an assload of disk space and it might manage pretty good if it could ccache everything.
18:24<Snow-Man>:)
18:24<mdz_>I brought up that idea the last time m68k was fucking me
18:24<mdz_>and it was pointed out that the architectures which have tiny CPUs also tend to have tiny disks
18:24<PeteCool>hmm, would distcc work fine with myth compiles?
18:25<mdz_>and they would need enormous disks to get any hits as a buildd
18:25<Snow-Man>mdz_: Only because they're not used for dick else. It's not like it couldn't support a larger disk.
18:25<PeteCool>you'd need to make -j(x>2) it too
18:25<Snow-Man>That is probably true.
18:25<mdz_>Snow-Man: I'd like to see you try with m68k :-)
18:26-!-yebyen [yebyen@gripz.com] has joined #mythtv
18:26<mdz_>PeteCool: make -j requires tight makefile dependencies
18:26<Snow-Man>mdz_: What, larger disks or enough ccache space for a buildd? :)
18:26<mdz_>Snow-Man: both
18:26<Snow-Man>I doubt I've got the disk space and I know I don't have it in scsi. :)
18:26<mdz_>yep
18:27<Snow-Man>Alright, that fixed it.
18:27<Snow-Man>Now to see why the backend isn't starting anymore.
18:27<mdz_>scsi gets expensive fast
18:27<Snow-Man>yes, yes it does.
18:27<Snow-Man>Your current database schema version is: 0
18:27<Snow-Man>but this application requires version 900 or higher.
18:27<Snow-Man>uh-huh.
18:27<mdz_>hehe
18:27<mdz_>bmarkey's new feature
18:27<mdz_>requires a database schema update
18:28<Snow-Man>Alright, there we go.
18:28<Snow-Man>I should modify the postinst to run cvs.sql :)
18:29<mdz_>that'd be bad, unless you checked whether it actually needed it
18:30<Snow-Man>Hrmpf, didn't seem to bother anything just now..
18:32<Snow-Man>Any suggestion on what to increase the mpeg-4 compression thingy to? I've got it at like 3004 atm.
18:32<mdz_>I think I'm using 3300 at the moment
18:33<mdz_>does anyone have a solid idea why it takes so much more CPU to record+playback simultaneously than the sum of either alone?
18:33<mdz_>my top guesses are memory bandwidth and cache misses
18:34<mdz_>on my system, recording on an otherwise idle system is about 35% reliably, and playback is almost free (around 1%)
18:34<mdz_>but both together is over 50%, sometimes much higher
18:34<thor>any sign of moegreen?
18:39<Chutt>mdz, i'm fairly sure that that's the reason
18:40<Ripp>yeah I want to ask him a q on mythweather
18:46<Ripp>run it with --debug it just claims 'TIMEOUT' instantly and does the same thing 10 times and will not connect
18:49<Ripp>even adding www.msnbc.com to /etc/hosts doesn't work
18:53-!-Telpar [~none@pa-coudersport3c-2-30.cdp.adelphia.net] has joined #mythtv
18:56-!-bigman [~bigman@h81.44.102.166.ip.alltel.net] has joined #mythtv
18:56-!-bigman is now known as bigguy
19:04-!-bigguy [] has quit ["bbl"]
19:07<-- Telpar(~none@pa-coudersport3c-2-30.cdp.adelphia.net) has left #mythtv
19:11-!-Viddy [david@visp194-179.visp.co.nz] has joined #mythtv
19:24<PeteCool>mdz_: more context switches (or whatever the exact term is) probably have an impact too
19:38<Ripp>there is a bug in how mythweather is handling its aggressive levels
19:38<Ripp>I just changed the value to 100 in the database and it seems to work fine now...
19:38<Ripp>beauty...
19:39<Ripp>not sure if it's a really a bug or just not accounting for slow dialup connections though.
19:45<Ripp>the new mythmusic is excellent so far btw
19:50<Ripp>if (timeout_cnt > (int)(5*aggressiveness) && getIntStatus() == 1)
19:51<Ripp>I'm no C++ wiz but isn't the right side of that always going to be 1 or 0? being a logical expression?
19:52<mdz_>the right side of what? the integer comparison or the boolean AND?
19:52<Ripp>after the >
19:52<mdz_>> has a higher precedence than &&
19:52<Ripp>ah
19:53* Rippforgets which comes first
19:53<mdz_>so it's the same as ( (foo > bar) && (baz) )
19:53<Ripp>() are good. more people should use them.
19:55<Snow-Man>What you guys do about the kernel blanking?
19:55<Ripp>usleep() waits in msecs?
19:56<mdz_>setterm -blank 0
19:56<Ripp>m=milli
19:56<mdz_>Ripp: man usleep
19:56<mdz_>microseconds, not milliseconds
19:56* Ripp's brain isn't firing on all cylinders today. :p
19:57<Chutt>usleep for a short period of time waits for at least 1 scheduling time period
19:57<Chutt>which is usually 10ms
19:58<Ripp>trying to figure out in mythweather exactly how long it's waiting to do each part of it's retrieve
19:59<Ripp>so then usleep(50) should wait...50*10ms? or 50 usecs?
19:59<Chutt>it'll most likely wait for 10ms
20:01<Ripp>so even on aggressive level 15 its only waiting for 3/4 sec. for each portion to finish before it resets the connection...
20:02<Ripp>2.5 seconds for the entire transaction to complete...no wonder...
20:05<Ripp>when you've got 150-250ms ping times like me that's not long enough! :)
20:10<Chutt>mdz, http://lists.snowman.net/pipermail/mythtv-users/2003-June/006063.html
20:10-!-Ripp [] has quit ["Client exiting"]
20:10<Chutt>mdz, you fixed that, right?
20:11<mdz_>er
20:11<mdz_>doesn't look familiar
20:11<Chutt>it's the can't open the video dev because of the channel changing script bug
20:11-!-itsame [trilluser@rdu74-170-244.nc.rr.com] has joined #mythtv
20:11<Chutt>or whatnot
20:12<mdz_>oh, the file descirptor thing
20:12<Chutt>right
20:12-!-itsame [] has quit [Client Quit]
20:12<Chutt>fixed, right?
20:12-!-Ripp [~ripp@209.194.224.236] has joined #mythtv
20:13<mdz_>yep
20:13<mdz_>just checked
20:13<Chutt>ok
20:14<Chutt>just wanted to verify that before sending off a response
20:14<mdz_>it closes all FDs 3 and up after forking
20:14<Chutt>'course, that's the same guy that didn't read the error messages mythbackend prints out, and sent half a dozen whiney emails about how it couldn't record anything
20:15<Chutt>so i doubt he'll pay attention to any email i send
20:15-!-Ripp [] has quit [Remote closed the connection]
20:16<thor>Chutt, you have any problems with the tarball/commit
20:16<thor>?
20:16<Chutt>nope
20:16<Chutt>looks good to me
20:16-!-Ripp [~ripp@209.194.224.236] has joined #mythtv
20:16<thor>yup ... don't know what was going on last night
20:22-!-justin [] has quit [Remote closed the connection]
20:25-!-justin [~justin@H239-211.STATE.resnet.albany.edu] has joined #mythtv
20:25-!-rkulagow__ [] has quit [Read error: 54 (Connection reset by peer)]
20:26-!-rkulagow__ [~rkulagow@12-206-151-240.client.attbi.com] has joined #mythtv
20:31-!-bigguy [bigman@h81.44.102.166.ip.alltel.net] has joined #mythtv
20:44-!-Ripp [] has quit [Remote closed the connection]
20:45-!-Ripp [~ripp@209.194.224.236] has joined #mythtv
21:08<just1nux>Chutt, any idea why mysql might be spiking to 30% or more of CPU usage at the time mythbackend starts to record something? This coupled with and immediate jump to 70 to 80% of CPU usage by mythbackend at the same moment is causing a temporary interuption in playback of anything that the frontend is playing. Has anyone else been experiencing this? (running CVS from friday) Shortly after this everything levels out and mythbackend s
21:22<just1nux>Anyone know the SQL to check all of the tables in a database at one time? I know its CHECK TABLE 'blah' for each one... but how can i do them all?
21:32<FryGuy>do a `show tables` first?
21:33<FryGuy>i think you can do: CHECK TABLE table1, table2, table3, ..., tablen
21:34<just1nux>ok, i was hoping not to have to put together a long list of tables. itd be easier just to check each one.
21:34<FryGuy>or maybe even CHECK TABLE database.*
21:35<just1nux>doesnt seem to like that.
21:35<FryGuy>well, it was worth a try
21:35<just1nux>i tried about every combination i could think of. oh well.
21:36-!-sc00p [] has quit ["Client exiting"]
21:38-!-sc00p [~oldendic@zink-a-dip3.nat.okstate.edu] has joined #mythtv
21:52-!-iamsodrunk [~unknown@dopez.xs4all.nl] has joined #mythtv
22:12-!-iamsodrunk is now known as dopez
22:36<thor>what the hell is rpciod and why do I have to kill it to do an nfs mount?
22:37<Ripp>remote procedure call i/o daemon I would guess
22:38<Ripp>why you'd have to kill it I dunno
22:39<thor>locate rpciod -> nothing, info rpciod -> nothing, man rpciod -> nothing .... sheesh
22:41<mdz_>thor: it's a kernel thread
22:41<thor>ah ...
22:41<mdz_>and I wouldn't expect that you would be able to kill it
22:41<thor>kill -KILL
22:42<thor>goes away, nfs volume mounts
22:43<dopez>im getting allot of dropped frames with a bttv card and using the nuppel codec, anyone have a idea what could be wrong?, the cpu memory and hd are fast enough (p4 2.8ghz 512mb memory and hd can do 30mb/s)
22:43<mdz_>buggy kernel, I assume
22:43<mdz_>dopez: why aren't you using MPEG-4 with all that CPU?
22:44<dopez>i want to reencode it to svcd/mpeg4 later, i thought nuppel was lossloss
22:44<dopez>but mpeg4 has the same problems tho
22:44<dopez>(using cvs versions and the 0.8)
22:45<thor>dopez, on a 2.8 ghz P4, that doesn't sound right at all .... something is out of whack ... what resolution(s) ?
22:46<dopez>i tryed lower the resolution, even at 384x288 it still looks like its dropping frames (checked with avidemux)
22:47<dopez>but usualy i capture at 480x576)
22:47<thor>hrm
22:47<mdz_>dopez: RTjpeg is nothing even approaching lossless
22:48<mdz_>dopez: just use MPEG-4
22:48<dopez>(but i also use the pc for other things, kde and some konqueror webbrowsers, but mendoder doenst have any problems with that
22:48<mdz_>why are you capturing at such a low resolution? you should be able to do 640x480 without breaking a sweat with that CPU
22:49<dopez>i'm using PAL, but just using low resolution to save some space, i dont need high quality (i've only got analog cable here, so 480x576 or 786x576 , it really doesnt mather)
22:50<thor>RTJpeg is *really* sensitive to signal quality, use MPEG-4
22:51<dopez>i'll give that another try, avidemux had some trouble opening those files tho (so i cant really check for dropped frames)
22:52<dopez>but since i'm about the only one with this kinda problem, it must be either a hardware problem, or a user problem, i've checked the mailing list for a while ;)
22:52<dopez>be/me
22:53<dopez>damn, i'm to drunk, dont pay to much attention to me ;)
22:56<dopez>but i'll try mpeg4 tomorrow, perhaps it doesnt drop as much frames as nuppel codec,
23:04<mdz_>are you sure it's actually dropping frames?
23:04<mdz_>in all likelihood it could be an avidemux problem
23:06<dopez>i'm pretty sure, i also see it when using livetv
23:06<mdz_>you _see_ it?
23:06<mdz_>it would have to be dropping quite a lot of frames
23:06<dopez>yeah, and also with avidemux, and also when using 'rewind' in mythtv
23:07<dopez>it's usually just one frame is droppes
23:08<dopez>(but allot on average, and random)
23:10<mdz_>what do you see in mythtv that tells you a frame was dropped?
23:11<dopez>i ussualy see allot of rebuffering messages
23:11<dopez>but i just started up mythtv and didn't notice any dropped frames
23:11<dopez>(yet)
23:12<mdz_>paste the exact error message that you get
23:12<mdz_>if it is "rebuffering, audio data lost" or such, that means a sound card problem, not a video capture problem
23:13<dopez>k, i'm checking the latest compile (of about 4 hours ago)
23:14<dopez>(i did upgrade mainboard 1 day ago, but only from a i845 p4 2.4ghz to a i785 p4 2.8ghz)
23:15<dopez>i doubt that fixed it tho
23:16<dopez>i875..
23:26<dopez>i could upload a sample somewhere, it has the dropped frames, about 3-4 dropped frames in the sample
23:26<dopez>(nuppel codec converted to avi with avidemux2)
23:30<dopez>(mythbackend or mythfrontend didnt give an error this time)
23:35<dopez>i'll try a asking this again when i'm sober ;)
23:35-!-dopez [] has quit ["zzz...."]