TheGrebs.com:IRC Logs:#mythtv:2002:11:20

00:00	<Markie>	yep got it. thanks
00:01	<Markie>	ohhh..
00:01	<Markie>	ok..i was just deleting the icon (from the code in the destructor)
00:02	<Markie>	but not delete the button element
00:02	-!-	bigguy [bigman@h100.44.102.166.ip.alltel.net] has joined #mythtv
00:02	<Markie>	so it must have tried to redraw, went throug the list, and the pixmaps were null
00:03	<Chutt>	right
00:03	<Markie>	bingo. i added the .clear after removing the icons and all is good
00:03	<Markie>	probably want to add the .clear in the destructor ?
00:03	<Chutt>	doesn't matter
00:04	<Chutt>	it's cleared when the object's deleted
00:05	<Markie>	gotchya
00:05	<Markie>	ok..good night!
00:05	<Chutt>	g
00:05	<Chutt>	erk
00:05	<Chutt>	g'nite
00:45	-!-	_shad [] has quit [Read error: 104 (Connection reset by peer)]
01:16	<-- aw	(~awilliam@12-252-52-131.client.attbi.com) has left #mythtv ("Client Exiting")
01:40	-!-	Tuscany [~username@user-11faahf.dsl.mindspring.com] has joined #mythtv
02:22	-!-	bigguy [] has quit ["Sleep Owned Me"]
04:09	-!-	nevertheless [~chris@p50858C74.dip.t-dialin.net] has joined #mythtv
09:56	-!-	Tinaral [~Yeah@6532175hfc29.tampabay.rr.com] has joined #mythtv
09:56	-!-	Tinaral [] has quit [Remote closed the connection]
10:17	-!-	Universe [~Yeah@6532175hfc29.tampabay.rr.com] has joined #mythtv
10:20	-!-	Tuscany [] has quit ["Trillian (http://www.ceruleanstudios.com)"]
11:13	-!-	tuscany [~ctalbot@66.54.186.1] has joined #mythtv
11:14	<lichen>	holy crap xmltv requires like 33994378
11:14	<lichen>	can you use debian's apt-get for perl modules too?
11:14	<lichen>	or else that would take forever :)
11:16	<Universe>	its not really that bad getting the perl modules for xmltv
11:18	<lichen>	well aside from getting thme one by one from CPAN, including all the modules and the modules those modules depend on.. how else would you do it?
11:21	<Universe>	thats what I did
11:21	<Universe>	it doesn't that bad
11:33	<Markie>	you can get the modules and install them on the command line
11:33	<Markie>	in perl
11:34	<Markie>	perl -MCPANE -e shell
11:34	<Markie>	perl -MCPAN -e shell
11:34	<Markie>	then "install XML::Twig" ...etc..
11:34	<Markie>	it'll downlaod, and install it.
11:37	<Chutt>	lichen, all the perl modules that xmltv needs are also .debs
11:39	lichen	lichen_ Nov 20 11:39:33 <mdz> lichen: apt-get install libxmltv-perl
11:39	lichen	lichen_ Nov 20 11:39:48 <mdz> lichen: or better, apt-get install mythtv and you will get xmltv automatically
11:40	<Chutt>	mdz, oh, i lied
11:40	<Chutt>	that patch doesn't work with editing =)
11:40	<mdz>	Chutt: crap, why not?
11:40	<Chutt>	seeking's semi-broken
11:40	<Chutt>	i have it mostly fixed
11:40	<Chutt>	everything except for one frame seeks
11:41	<mdz>	so it's just the seeking that breaks editing, and not something editing-related?
11:41	<Chutt>	right
11:43	<mdz>	I wasn't finished with it when you took it away, you know :-P
11:43	<Chutt>	i know
11:43	<Chutt>	but what this needs is a way to tell avcodec 'here's a buffer, use it as the previous frame data'
11:44	<mdz>	hey, it's C, everything's public :-)
11:44	<mdz>	I'm sure it's in the avcodec context somewhere
11:44	<Chutt>	it's in the mpegvideoconected
11:44	<Chutt>	context
11:44	<Chutt>	or something like that
11:44	<Chutt>	it's essentially private :p
11:50	<Chutt>	current cvs also breaks a/v sync for old recordings
11:51	<mdz>	hmm, I wonder what last_dr_opaque and next_dr_opaque are used for
11:51	<mdz>	I wonder if they are passed when it is asking for the old buffer
11:51	<mdz>	then we could do that
11:51	<Chutt>	i don't think it asks for the old buffer
11:51	<mdz>	why would it keep the last dr_opaque around, then?
11:52	<Chutt>	silliness
11:54	<mdz>	yep, apparently
11:54	<mdz>	what broke a/v sync?
11:54	<Chutt>	john moved the timestamps to the end of a frame instead of the beginning
11:55	<Chutt>	so the audio calculations are slightly off for recorded files
11:56	<-- Universe	has quit ()
11:59	<Chutt>	ok, some guy sent me a patch to 'optimize' some things in nuppelvideorecorder
12:00	<Chutt>	basically removing some if statements, and replacing it all with math operations
12:00	<Chutt>	i ask if it actually changes anything, and he's like 'those statements are 5% faster now!'
12:00	<Chutt>	and gets all defensive
12:02	<tuscany>	hey guys, i just posted an email to the myth-dev list re: my /dev/video "busy" problem. it appears i'm having an inherited file descriptor issue.
12:02	<Chutt>	yeah, i see
12:02	<Chutt>	i don't do perl, though
12:02	<Chutt>	so i don't know how to tell you to close the descriptor
12:04	<tuscany>	ahh...is there any way of closing it within bourne shell? the main script is a shell file that forks off the perl script
12:05	<Chutt>	same answer =)
12:06	<tuscany>	:) i have a question then. Is there a way the /dev/video file can be opened so it can be shared by child processes?
12:06	<Chutt>	nope
12:09	<Chutt>	hrm
12:09	<Chutt>	what _could_ be done, on the other hand
12:09	<Chutt>	hrm
12:09	<Chutt>	no, nm
12:23	<Markie>	that doesnt make sense..
12:23	<Markie>	it's not re-opening the file.
12:23	<Markie>	it's just passing the file descriptor
12:24	<Chutt>	the parent closes it, aftewards
12:24	<Chutt>	he's still got it open
12:24	<Markie>	it's no different than passing the file descriptor in a function in one program
12:24	<Chutt>	it can't be reopened.
12:24	<Markie>	ohhh
12:24	<Markie>	didnt know the parent closed it..sorry just jumped in here :^)
12:25	<zytah>	_test_
12:26	<Markie>	tuscany: are you using fork?
12:32	<Chutt>	tuscany, so, just iterate over all fds from 3 to 255 and close em
12:45	<tuscany>	sorry, stepped away. here's the shell script:
12:45	<tuscany>	#!/bin/sh
12:45	<tuscany>	echo "changing to $1"
12:45	<tuscany>	/usr/local/bin/channel.pl $1 &
12:45	<tuscany>	exit 0
12:45	<tuscany>	notice the ampersand at the end
12:46	<tuscany>	i can try the iteration. using lsof I was able to determin /dev/video was file descriptor 16, but there's no guarantee it'll be the same each time, correct?
12:47	<Chutt>	right
12:48	-!-	Universe [~Yeah@pwc2-hs-nk.bbnplanet.com] has joined #mythtv
13:13	-!-	chris__ [~chris@p508591A1.dip.t-dialin.net] has joined #mythtv
13:13	<mdz>	either close all of the file descriptors before exec, or set them close-on-exec
13:14	<tuscany>	how do you set close-on-exec?
13:15	<mdz>	with fcntl
13:15	<tuscany>	ok
13:20	-!-	nevertheless [] has quit [Read error: 60 (Operation timed out)]
13:27	-!-	chris__ is now known as nevertheless
13:35	<tuscany>	another idea might be to use a csh script instead of a bash script. Apparently csh closes all inherited file descriptors upon execution: http://groups.google.com/groups?q=csh+inherit+close+file+descriptors&hl=en&lr=&ie=UTF-8&selm=p5lmm79f30.fsf%40lemming.engeast.baynetworks.com&rnum=1
13:41	<mdz>	tuscany: google for "csh programming considered harmful"
13:48	<Chutt>	hrm
13:48	<Chutt>	fixed the 1 frame seeks
13:48	<Chutt>	now just have to figure out some other oddness
14:04	-!-	Markie [] has quit ["Client Exiting"]
14:06	-!-	Markie [~mmusone@pool-141-149-139-252.buff.east.verizon.net] has joined #mythtv
14:19	<witten>	what codec and quality settings to people use?
14:22	<Universe>	I have a P3 700... I use 352x240 rtjpeg at its highest quality setting...
14:23	<Universe>	I could do better but I have other things running on that system that need cpu time
14:45	<lichen>	how many hours per gig would you get at a quality like that?
14:45	<lichen>	im gonna be building this machine on a 1ghz machine with 512megs .. im wondering how well its gonna handle it all
14:47	<Chutt>	mdz, hey, you able to test something?
14:54	<mdz>	Chutt: depends
14:54	<mdz>	Chutt: I have no capture card at work
14:55	<mdz>	(which is where I am)
14:55	<Chutt>	ah
14:55	<Chutt>	well
14:55	<Chutt>	i think i have everything working now
14:55	<Chutt>	modified that ip_buffer_count to 100
14:55	<Chutt>	which disables that small optimization of not copying certain frames
14:56	<Chutt>	certain small bits
14:56	<Chutt>	i couldn't get it to work after seeking
14:56	<Chutt>	be a little corruption however i messed with it
14:56	<Chutt>	and everything else seems to work great now
14:57	<Chutt>	cpu usage drops to under 50% at times with deinterlacing and audio compression off =)
14:57	<mdz>	very nice
14:58	<Chutt>	it does still spike up at 60, 65%, though
14:58	<Chutt>	but that's fairly normal
14:58	<Chutt>	i'll send you a new diff, and if you get a chance to test it, that'd be great
14:59	<mdz>	I didn't really check out that ip_buffer_count thoroughly...I don't quite follow what it's supposed to be used for
15:00	<Chutt>	i'm not really sure either =)
15:00	<mdz>	I see that >= 99 bit though
15:00	<Chutt>	right
15:00	<mdz>	it sounds like maybe when we seek, we should set ip_buffer_count down to 2
15:00	<Chutt>	so it might be doing a little more work than it normally would
15:00	<mdz>	or maybe that's backwards
15:01	<Chutt>	i don't get how it's used, though
15:01	<mdz>	the comment in avcodec.h is decidedly not enlightening
15:01	<Chutt>	maybe it is backwards
15:01	<Chutt>	like, on seek, set it to 99
15:01	<mdz>	or some other magic hardcoded number :-P
15:01	<Chutt>	otherwise, set to maxvbuffer
15:01	<Chutt>	i dunno
15:02	<mdz>	mplayer seems to just set it to 2
15:02	<mdz>	with a FIXME comment :-)
15:02	<Chutt>	right
15:02	<Chutt>	but setting it to 2 does bad things here
15:02	<mdz>	yes, dunno why
15:02	<Chutt>	no idea =)
15:03	<mdz>	apiexample.c doesn't use it
15:03	<Chutt>	does apiexample do direct rendering?
15:03	<Chutt>	it's set to 2 internally normally
15:03	<Chutt>	since there's 2 buffers
15:04	<mdz>	apiexample does not do direct rendering
15:09	<mdz>	in fact, I haven't seen anything but mplayer which does
15:09	<Chutt>	heh
15:10	<Chutt>	just over 1000 line diff
15:11	<Chutt>	i just sent it, btw
15:11	<mdz>	intuitively it would seem that it should hold the number of past buffers that are still around
15:11	<mdz>	BufUsed() or whatever
15:12	<Chutt>	yeah, but i don't think setting it to 0 would have the intended effect
15:12	<mdz>	yeah, since clearly it needs at least 1
15:13	<mdz>	probably 2
15:13	<mdz>	but it doesn't work right at 2 :-)
15:13	<Chutt>	right
15:13	<Chutt>	ah well
15:13	<mdz>	I should figure out what it's actually doing at 2 that makes it break
15:17	<mdz>	ah, you added that bit to set the last buffer
15:17	<mdz>	which is naturally kept in next_picture
15:17	<Chutt>	well
15:17	<Markie>	Chutt: so you're ok'ing the settings database, right?
15:17	<Chutt>	on the next read
15:18	<Chutt>	it sets last_picture = next_picture
15:18	<Chutt>	so i have to set next_picture if i want to set last_picture
15:18	<Chutt>	markie, sure, for most of them
15:18	<nevertheless>	its really funny, the mailinglist <--> #mythtv stuff :-)
15:18	<mdz>	next_picture really is supposed to be the previous picture
15:18	<mdz>	it's even documented that way
15:18	<mdz>	UINT8 next_picture[3]; / previous picture (for bidir pred) */
15:19	<Chutt>	well
15:19	<Chutt>	that's for b-frames
15:19	<Chutt>	that actually do go bi-directional
15:19	<mdz>	ah, which we don't use
15:19	<Chutt>	right
15:19	<mdz>	I get it
15:20	<Chutt>	the corruption after a seek was because it'd get the rpos out of sync
15:21	<Chutt>	so i made it pause the output loop while it does the seek
15:21	<Markie>	nevertheless: this is the way i normally crank out code :^)
15:22	<Chutt>	markie, might be prudent to add a last modification timestamp in the db for each of the settings files
15:22	<Chutt>	so it could just re-parse them as needed
15:23	<Markie>	Chutt: good idea
15:23	<Markie>	i decided not to use the "settings" tabe thats already there anyways, so i got plenty of freedom
15:24	<Chutt>	yup
15:24	<Markie>	it's called "mythsettings"
15:24	<Chutt>	heh
15:24	<Chutt>	anyway
15:25	<Markie>	one of these days, when you're done with you optimizing video stuff, i need to ask you one other thing..but the stuff i'm doing is so less important than what you're doing now, it can wait
15:26	<Chutt>	i'm pretty much done, now
15:26	<Markie>	well i'm working on auto-scanning and setting up channels
15:26	<Markie>	and i'm thinking of doing it the way my other digital vcr does,
15:26	<mdz>	hmm, rather than pausing/unpausing during the seek, might it be better to use an rwlock?
15:27	<Chutt>	mdz, another lock?
15:27	<Chutt>	perhaps
15:27	<mdz>	no, change the mutex to an rwlock
15:27	<mdz>	then it wouldn't have to wait for it to pause, wait for it to unpause
15:27	<Markie>	which is that is tunr-scans the channels, and displays all the channels it tuned into. and the user picks what channel they want "active" or "inactive"
15:27	<mdz>	should be fewer context switches and no usleeps
15:27	<Markie>	i.e. every channel has an active/inactive setting
15:27	<Chutt>	mdz, make the mods :p
15:27	<Chutt>	markie, i'd rather not tuner scan the channels
15:27	<Markie>	and i'm sure that thats probably not a trivial change ot a lot of code
15:27	<Chutt>	just use the data that xmltv has
15:28	<Markie>	Chutt: you'r rather not?
15:28	<Markie>	ugh
15:28	<Markie>	ok
15:28	<Chutt>	since the channel db is already present
15:28	<Chutt>	from that
15:28	<Markie>	but it's not the correct channeldb
15:28	<Chutt>	how's it not?
15:28	<Markie>	i.e. i have adelphia cable..but just basic cable
15:28	<Markie>	xmltv returns 100 channels
15:28	<Chutt>	so?
15:28	<Markie>	i only have 2-13
15:28	<mdz>	Chutt: I don't want to conflict with this stuff; let me know when it's in CVS and I'll do it
15:29	<Chutt>	mdz, it'll go into cvs after you say that it all works for you :p
15:29	<Markie>	why list all the channels on the forntend, if you dont really have them.
15:29	<Chutt>	markie, if you want to scan channels as a way to cull out stuff in the xmltv list, sure, that's fine.
15:29	<Markie>	yea..thas what i mean
15:29	<Chutt>	but not as a way to identify channels that aren't in the list.
15:29	<Markie>	chutt:correct. i fully agree
15:29	<Chutt>	disabling channels is easy.
15:30	<Markie>	ok. good :^)
15:30	<Chutt>	all you have to do is modify the xmltv settings files
15:30	<Markie>	ok
15:30	<Chutt>	at least for tv_grab_na
15:30	<Chutt>	but, it'd probably be best to add a 'don't use' id to the channel table
15:35	<nevertheless>	another really bad thing is that it now uses the channum to identify a channel, but here in europe we have channums like "E6" or "SE21" so there's no chance to select via num-input
15:36	<Chutt>	nevertheless, you just need to let it enter letters for channel input
15:36	<Markie>	i'm gonna get back to coding.
15:37	<nevertheless>	hmmm, yeah, that would be a solution, but we do not identify the channels by this channum, we prefer to order our channels like we like to do and then we can select them by num-keying
15:37	<nevertheless>	with 'we' I mean we people from europe :-)
15:40	<nevertheless>	i think, the better idea would be, to additional allow to select a channel by the chanid rather than the channum
15:40	<nevertheless>	or not additionally, but either
15:46	<mdz>	Chutt: playback works great with CVS + your patch
15:47	<Chutt>	ok
15:47	<Chutt>	cool.
15:47	<Chutt>	i'll commit things in a little
15:47	<mdz>	uses 1.2% CPU on this box :-)
15:47	<Chutt>	changing usepre to 3
15:47	<Chutt>	instead of 2
15:47	<Chutt>	gets rid of the initial corruption due to the linear blend filter before the 2nd keyframe
15:47	<Chutt>	at least with live-tv mode
15:48	<mdz>	cache size : 512 KB
15:48	<mdz>	one good thing about this P4
15:49	<mdz>	goes below 1% sometimes
15:49	<zytah>	hmm
15:49	<zytah>	I still can't 'search' for channels.
15:49	<mdz>	a/v sync is right on
15:49	<zytah>	guess I have to read the docs.
15:49	<Chutt>	it's off for me
15:49	<zytah>	:(
15:49	<mdz>	hmm
15:49	<Chutt>	and directly due to the timestamp changes
15:50	<Chutt>	reverting them puts it right on
15:52	<Markie>	yea!! i got the settings reading from the database! :^)
15:52	<mdz>	how much is it off by?
15:52	<Chutt>	just a couple frames
15:52	<mdz>	maybe I just don't notice
15:52	<mdz>	or does it only happen in live tv?
15:53	<mdz>	it sure looks right to me in playback
15:53	<Chutt>	only happens in playback
15:53	<Chutt>	with older files
15:53	<Chutt>	but
15:53	<Chutt>	it depends on how big the soundcard buffers are
15:55	-!-	elsefuderr [] has quit [Ping timeout: 14400 seconds]
15:57	<Chutt>	sweet
15:57	<Chutt>	huffyuv at 640x480 works now
15:57	<Chutt>	before the direct rendering stuff, playback took just a _little_ too much cpu
15:57	<mdz>	I thought huffyuv was inexpensive to encode
15:58	<Chutt>	not really
15:58	<Chutt>	at least
15:58	<Chutt>	not this implementation
15:58	<mdz>	the stats on the guy's web page were impressive
15:58	<mdz>	ah, true
15:59	<paperclip>	mdz: which web page ?
15:59	<Chutt>	it's still picky about the disk usage, though
15:59	<mdz>	the windows implementation apparently does upward of 40fps on a 400mhz Celeron
15:59	<mdz>	paperclip: http://math.berkeley.edu/~benrg/huffyuv.html#Benchmarks
15:59	<paperclip>	danke
15:59	<mdz>	Chutt: disk space usage, or disk I/O bandwidth?
16:00	<Chutt>	bandwidth
16:00	<mdz>	I'm guessing I'm not going to be able to run it over NFS, then
16:01	<Chutt>	that's kinda doubtful =)
16:01	<Chutt>	but, maybe it's a bug with the threadedfilewriter stuff
16:01	<Chutt>	it might not deal with that much data very well
16:02	<mdz>	I should be able to do 320x240
16:03	<mdz>	but what's the point of lossless with tiny frames
16:03	<Chutt>	heh
16:03	<Chutt>	the huffyuv in my cvs tree doesn't have the direct rendering support yet
16:03	<mdz>	I'm thinking my best bet is to just use mpeg4 at 5mbit or something and then transcode down
16:03	<Chutt>	it'll be in my commit with the other dr stuff
16:04	<mdz>	what will? reencoding?
16:04	<mdz>	or the huffyuv direct rendering?
16:04	<Chutt>	the huffyuv stuff
16:04	<mdz>	ah
16:05	<mdz>	I wonder how slow huffyuv decode -> mpeg4 HQ would be on my faster machine
16:05	<mdz>	I should be able to find out with ffmpeg now
16:06	<Chutt>	yup
16:06	<mdz>	huffyuv is signifacntly slower on the decode side
16:06	<mdz>	like, 50%
16:07	<Chutt>	yeah
16:07	<Chutt>	at least with that implementation
16:07	<mdz>	oh lord
16:07	<mdz>	is sourceforge still broken?
16:07	<Chutt>	probably
16:07	<mdz>	ffmpeg.sourceforge.net is broken even in google's cache
16:08	<Chutt>	hrm
16:08	<Chutt>	the website works for me
16:08	<mdz>	interesting
16:08	<mdz>	what IP does it resolve to?
16:08	<Chutt>	just stuff like the mailing list archives are broken
16:08	<mdz>	http://216.239.53.100/search?q=cache:QmoV3L9HI80C:ffmpeg.sourceforge.net/+ffmpeg+cvs&hl=en&ie=UTF-8
16:08	<Chutt>	66.35.250.209
16:08	<mdz>	I get the same, hmm
16:08	<mdz>	you sure you don't have it cached?
16:09	<Chutt>	reasonably sure
16:09	<Chutt>	there's a few new links on there that weren't before
16:09	<mdz>	looks like galeon is caching the redirect, bastard
16:10	<mdz>	but I haven't been there in a long time on this machine
16:31	<Chutt>	geez
16:31	<Chutt>	671 messages to the mailing list this month
16:32	<Chutt>	270 people on the list
16:32	<Chutt>	46 people on the commits list
16:33	<Universe>	wow... thats a big difference from the commit list and mailing list
16:33	<Chutt>	and of course, a
16:33	<Chutt>	erk
16:33	<Chutt>	a @microsoft.com address on both lists =)
16:33	<Universe>	lol
16:33	<Universe>	any tivo.com?
16:33	<Universe>	heh
16:33	<Chutt>	not that i see
16:37	<Chutt>	oops
16:37	<Chutt>	i broke it for rtjpeg again
16:41	<mdz>	damn rtjpeg
16:41	<mdz>	how does it compare to mjpeg in libavcodec?
16:41	<Chutt>	i think it's just trying to use the libavcodec context stuff when it's not initialized
16:41	<Chutt>	probably about the same
16:43	<-- Universe	has quit ()
16:44	<Chutt>	libavcodec's mjpeg stuff looks ok at 640x480 @ 3 gig an hour
16:46	<Chutt>	eww
16:46	<Chutt>	guy on the list is using pc133 with an xp 1700+
16:47	<mdz>	heh
16:47	<mdz>	and I feel bad about using pc133 with my 1.4 tbirt
16:47	<mdz>	bird
16:47	<Chutt>	well, he's going to, at least
16:47	<mdz>	it's so much cheaper
16:47	<mdz>	but for an XP it's a waste
16:48	<Chutt>	ok
16:48	<Chutt>	mjpeg at 8800 bps
16:48	<Chutt>	so 4 gig an hour
16:48	<Chutt>	looks better than rtjpeg at 255 quality
16:48	<Chutt>	i don't know how large that'd be, though
16:48	<zytah>	I have a 266/333 with my XP 1800+
16:48	<lichen>	im using an athlon 1.4
16:49	<Chutt>	uses less cpu than mpeg4
16:49	<Chutt>	but not much
16:49	<Chutt>	well, maybe 15% less
16:50	<Chutt>	actually, hmm
16:50	<Chutt>	rtjpeg looks nicer
16:50	<Chutt>	and it uses a bunch less cpu
16:50	<mdz>	Chutt: I have a request to proxy
16:51	<mdz>	Chutt: would you feel strongly about changing the default action for the TV::LiveTV dialog?
16:51	<Chutt>	to what?
16:51	<mdz>	to something non-destructive
16:51	<mdz>	either cancel, or watch the in-progress recording
16:51	<Chutt>	oh
16:51	<Chutt>	sure
16:51	<mdz>	so that if the user accidentally hits the button twice, they don't lose their recording
16:52	<mdz>	happened to my girlfriend last night :-)
16:52	<Chutt>	yeah, no problem
16:52	<mdz>	great, thanks
16:52	<mdz>	btw, why is that mythdialog stuff all done through an external process?
16:52	<Chutt>	most of its not
16:53	<mdz>	why is that one, then/
16:53	<Chutt>	the one thing that does system it is because i was keeping qt stuff out of that tv.cpp stuff before
16:53	<mdz>	ah, gotcha
16:53	<Chutt>	now it's just legacy code
16:54	<mdz>	want a patch?
16:54	<Chutt>	sure
16:54	<Chutt>	want to make the tv stuff not exec mythepg as well?
16:55	<Chutt>	that's similar reasoning
16:55	<mdz>	depends on whether you would want to get rid of mythepg after that
16:55	<mdz>	because I use mythepg on its own sometimes
16:56	<Chutt>	i wouldn't get rid of it
16:56	<Chutt>	i would get rid of 'mythdialog' as a separate program, though
16:57	<Chutt>	i use the epg on its own a lot, too =)
17:09	-!-	dsfgfdhgfc [sdf@resnet-13-225.dorm.utexas.edu] has joined #mythtv
17:10	-!-	dsfgfdhgfc [] has quit [Client Quit]
17:11	<mdz>	heh, mythtv has a weird following
17:11	<Chutt>	strange people
17:11	<mdz>	it seems like a large percentage of advocates, and people answering others' questions, have not actually used it yet
17:11	<Chutt>	you can't send me patches that you haven't tested :p
17:11	<mdz>	I knew that was coming
17:12	<mdz>	I'll test it tonight when I get home
17:12	<Chutt>	ok
17:12	<mdz>	no capture here
17:14	<mdz>	Chutt: thinking about per-recording capture/encoding settings...do you think they should be duplicated in singlerecord/timeslotrecord/allrecord, or factored out into a recordingparams table?
17:16	<Chutt>	dunno yet
17:16	<Chutt>	i'm more thinking a recordingparams table
17:16	<mdz>	factoring it out seems logical
17:16	<Chutt>	with each recording having a link to it
17:16	<mdz>	then the stuff needed for scheduling is in the current tables, and the stuff needed when recording starts is in recordparams
17:16	<Chutt>	that way, you can have a couple defaults
17:17	<mdz>	and if there's no entry in recordparams, we're ok
17:17	<Chutt>	or change a single entry
17:17	<mdz>	that too
17:17	<Chutt>	well, we'd guarantee one entry in the recordingparams table
17:17	<mdz>	"high quality" "medium quality" etc.
17:17	<Chutt>	ie, 'default'
17:17	<mdz>	I was figuring to fall back on the old global settings, but I guess that stuff has to move into the database at some point anyway
17:18	<Chutt>	yup
17:18	<Chutt>	long as there's something graphical to edit the settings, i don't mind stuff being only in the database
17:21	-!-	Chutt has changed the topic to: http://www.mythtv.org/
17:22	<Markie>	is there an easy way to check if a file exists in C++
17:23	<Chutt>	look at how the settings loader code does it
17:23	<Markie>	oh got itQFileInfo.exists
17:23	<Chutt>	right
17:23	<Chutt>	that's qt, but it's easy
17:26	<mdz>	from keys.txt: The keys 9, 6, 7 and 1 (like a numeric keypad)
17:27	<mdz>	shouldn't that be 9, 3, 7 and 1?
17:27	<Chutt>	andrew wrote that
17:27	<mdz>	well it's wrong
17:28	<Chutt>	yup
17:28	<mdz>	doesn't match the code, or a numeric keypad
17:28	<Chutt>	it is
17:28	<Chutt>	it's 3 in the source, too.
17:30	<Chutt>	changed for when i commit junk
17:31	<mdz>	thanks
17:32	<Chutt>	heh
17:32	<Chutt>	you wouldn't happen to know how to mass delete a bunch of shm segments, would you?
17:33	<mdz>	I use the shell :-)
17:33	<Chutt>	i would
17:33	<Chutt>	but i've got about a thousand
17:33	<mdz>	yeah, me too
17:33	<Chutt>	from all that testing =)
17:33	<Chutt>	where it didn't delete stuff properly
17:34	<mdz>	ipcs \| awk '$5 == 345600 { print $2 }' \| xargs ipcrm
17:34	<mdz>	need a -M in there
17:34	<mdz>	oh, it does it by the key
17:34	-!-	elsefuderr [fabiano@RJ231231.user.veloxzone.com.br] has joined #mythtv
17:35	<Chutt>	you need ipcrm -m
17:35	<Chutt>	and ipcs -m helps, too
17:35	<mdz>	ipcs \| awk '$5 == 345600 { print $2 }' \| xargs -n1 ipcrm -m
17:36	<Chutt>	cool, thanks
17:41	<Markie>	yea yea yea!
17:41	<Markie>	i should send a pathc soon..
17:41	<Markie>	i dont want to give you too much changes
17:43	<paperclip>	interesting that the huffyuv stuff has microsoft code
17:45	<Chutt>	heh
17:45	<Chutt>	640x480 rtjpeg, quality @ 160, 75% free cpu
17:45	<mdz>	Markie: making good progress then?
17:46	<mdz>	Chutt: does the rtjpeg quality go higher->better or lower->better?
17:46	<Chutt>	higher is better
17:48	<Chutt>	mdz, your changes got rid of a full-framesize copy in the rtjpeg stuff, too
17:48	<Chutt>	so, all good =)
17:50	<Chutt>	640x480 rtjpeg, quality 160, no audio compression, no deinterlacing
17:50	<Chutt>	> 85% cpu
17:50	<Chutt>	well, down to 80
17:50	<Chutt>	occasionally
17:52	<mdz>	have you looked at that guy's patch to suck a file into mythfilldatabase?
17:52	<Chutt>	yeah
17:52	<mdz>	I had thought about doing that, it'd be handy
17:52	<Chutt>	i'm going to apply it tonight
17:52	<mdz>	great
17:53	<Chutt>	he just asked me to fix the grammar of his help text =)
17:53	<elsefuderr>	chutt: the patch so you can feed mythfilldatabase directly with an xmltv file?
17:53	<Chutt>	yes
17:53	<elsefuderr>	ok, cool :)
17:54	<Chutt>	anyway, later
17:57	<paperclip>	does rtjpeg have the same drawbacks (jpeginess) that the huffyuv guy talks about..
17:58	<Markie>	mdz: yea, a ton
17:58	<Markie>	got mythtv reading the settings form the DB, got the ability to change themes and other settings o nthe fly
17:59	<Markie>	and i'm just finishing it pulling up the available themes fomr the themese directory, showing an icon for the theme, and being able to choose it
18:01	<Markie>	the real annoying/bad part is the modules are just seperate programs
18:01	<Markie>	so communicating back and forth is a pain
18:01	<Markie>	it'd be soo much better if modules registered functions/callbacks
18:02	<Markie>	and the main mythfrontend dlopened the files as shared libraries and called the functions
18:03	<Markie>	i've been triyng real hard to make the settings module seperate, but since it changes core stuff, it looks like i have to build it right into mythfrontend
18:13	-!-	tuscany [] has quit ["Client Exiting"]
18:14	<paperclip>	ok.. i got a phone call..
18:14	<paperclip>	i meant to say.. does rtjpeg have the same drawbacks that mjpeg has WRT to transcoding to mpeg?
18:22	<Chutt>	bah
18:22	<Chutt>	that guy that wants to get rid of the database is silly.
18:39	-!-	hadees [~blah@pcp01500931pcs.univde01.de.comcast.net] has joined #mythtv
18:40	<hadees>	hello
18:40	<hadees>	anyone get the nvidia driver to work?
18:42	<Chutt>	pretty much everybody.
18:42	<Chutt>	mdz, it's in cvs now, btw
18:45	<hadees>	i am having trouble with the driver
18:45	<hadees>	i installed the kernel but for some reason it isn't loaded
18:46	<Chutt>	this isn't the place to get tech support for it.
18:47	<hadees>	not looking for step by step help, was wondering if anyone encountered the problem
18:47	<-- hadees	has quit ()
19:06	<mdz_>	Chutt: which bits are in CVS now?
19:06	<Chutt>	all the dr stuff
19:07	<mdz_>	ok, I'll just pull CVS and test that then
19:07	<Chutt>	thanks
19:07	<mdz_>	plus my tiny dialog patch
19:10	<mdz_>	grr, conflicts in setup/main.cpp
19:53	-!-	nevertheless [] has quit [saberhagen.freenode.net irc.freenode.net]
20:03	<mdz_>	Chutt: 215 deb downloads from 110 unique IPs
20:53	-!-	Universe [~Yeah@6532175hfc29.tampabay.rr.com] has joined #mythtv
21:09	-!-	Nothingman [~chatzilla@ny-utica7a-405.aburny.adelphia.net] has joined #mythtv
21:09	<Nothingman>	oh, wow
21:09	<Nothingman>	anyone getting just "couldn't open db" when they run setup?
21:10	* Nothingman	listens to crickets chirping
21:11	<mdz_>	Nothingman: that will happen when it can't connect to the database
21:11	<Nothingman>	right
21:11	<Nothingman>	and that would be because...
21:11	<mdz_>	Nothingman: well there's your problem
21:11	<Nothingman>	lol
21:12	<mdz_>	more than likely, you missed one or more of the steps in the installation instructions
21:12	<Nothingman>	should I try restarting mysqld?
21:18	<Markie>	damn damn damn
21:18	<-- Nothingman	has quit ()
21:28	-!-	Tuscany [~username@user-11faahf.dsl.mindspring.com] has joined #mythtv
21:29	-!-	KeyserSoze is now known as Keyser[zzz]
21:29	<-- Keyser[zzz]	has quit ("Client Exiting")
21:36	-!-	hadees [~blah@pcp01500931pcs.univde01.de.comcast.net] has joined #mythtv
21:36	<hadees>	i have a question about usage, anyone use mythtv with dual processers like 600mhz?
21:42	<Markie>	i dont
21:42	<Markie>	but i dont think the dual processors is actually a good thing
21:44	<hadees>	really? i thought i could set it up some how to use one chip to encode
21:45	<mdz_>	hadees: the encoder library is currently not thread-safe, so while you will get some benefit, encoding and decoding will not happen simultaneously
21:46	<mdz_>	hadees: that will hopefully be fixed in the future
21:47	<mdz_>	is David-Georges Vitrant here by any chance?
21:48	-!-	Namapoos [~soopaman@h24-66-52-13.wp.shawcable.net] has joined #mythtv
21:48	<Namapoos>	what's up
21:53	<Tuscany>	anyone try to compile tonight's cvs? it bombs on a an undefined reference error
21:56	<mdz_>	Tuscany: builds fine for me
21:56	<mdz_>	Tuscany: assuming you're talking about mythtv
21:56	<Tuscany>	yep.
21:56	-!-	Nothingman [~chatzilla@ny-utica7a-405.aburny.adelphia.net] has joined #mythtv
21:56	<Tuscany>	here's the output:
21:57	<Tuscany>	g++ -o mythdialog main.o -L/usr/lib/qt3/lib -L/usr/X11R6/lib -lmyth-0.8 -L/usr/local/lib -L../../libs/libmyth -lqt-mt -lpthread -lXext -lX11 -lm
21:57	<Tuscany>	main.o: In function `main':
21:57	<Tuscany>	main.o(.text+0x6e): undefined reference to `MythContext::MythContext[in-charge](bool)'
21:57	<Tuscany>	collect2: ld returned 1 exit status
21:57	<Tuscany>	make[2]: *** [mythdialog] Error 1
21:57	<Tuscany>	make[2]: Leaving directory `/root/myth/cvs/MC/programs/mythdialog'
21:57	<Tuscany>	make[1]: *** [sub-mythdialog] Error 2
21:57	<Nothingman>	any suggestions for a "couldn't open db" error?
21:57	<Tuscany>	make[1]: Leaving directory `/root/myth/cvs/MC/programs'
21:57	<Tuscany>	make: *** [sub-programs] Error 2
21:59	<Chutt>	tuscany, remove your installed libmyth* stuff
21:59	<mdz_>	Tuscany: tsk, tsk, compiling as root
21:59	<Chutt>	i did mention that in the commit message from when i broke that a day or so ago
22:05	<mdz_>	Chutt: I've got current CVS running on my box now
22:05	<mdz_>	Chutt: doing some benchmarking
22:05	<mdz_>	everything works so far
22:05	<Tuscany>	d'oh! that'll do it
22:05	<mdz_>	with 0.7, playback took 25% of my CPU
22:06	<mdz_>	current CVS takes 4-5%
22:07	<mdz_>	heh, I can now watch live TV at 640x480 with deinterlacing and audio compression
22:08	<mdz_>	with just about zero CPU to spare
22:08	<mdz_>	0-5%
22:11	-!-	Candyman [~soopaman@h24-66-52-13.wp.shawcable.net] has joined #mythtv
22:11	<Candyman>	hey hey hey!!
22:12	<Nothingman>	the candyman can...
22:12	<Nothingman>	anyone here have a suggestion?
22:12	<Nothingman>	all I get when I run setup is "couldn't open db"
22:14	<Nothingman>	don't know what happened to the umpteen instances of mysqld I had running
22:15	<Universe>	mdz... what cpu do you have?
22:16	<Nothingman>	...
22:16	<Markie>	does anybody know what this means:
22:16	<Markie>	themesbox.o(.text+0x69): undefined reference to `vtable for ThemesBox'
22:17	<Universe>	no clue Markie..
22:17	<Universe>	sorry Nothingman... I am not a sql person
22:17	<mdz_>	Universe: 1.4GHz Athlon T-bird
22:17	<Universe>	oh..
22:17	<Universe>	hmm... I wonder about my 700...
22:18	<Universe>	maybe I can get 480x480 with the cvs..
22:18	<brtb>	i can only get 352x240 on my 667, 480x480 _almost_ works but not quite
22:18	<Universe>	with the current cvs?
22:19	<brtb>	0.7
22:19	<brtb>	haven't tried cvx yet
22:19	<Universe>	changes where made today
22:19	<brtb>	cvs even
22:19	<Universe>	I will try and let you know brtb..
22:19	<brtb>	yeah i'm scrolling up now
22:21	<mdz_>	Universe: do you use rtjpeg or mpeg4
22:21	<mdz_>	?
22:23	-!-	Namapoos [] has quit [Read error: 110 (Connection timed out)]
22:24	-!-	mmc2 [] has quit [Read error: 104 (Connection reset by peer)]
22:25	-!-	SadMan [] has quit [saberhagen.freenode.net irc.freenode.net]
22:26	<mdz_>	Chutt: everything is looking good
22:27	<mdz_>	Chutt: with the new colour scheme, the progress bar on the delete recordings screen has too little contrast, I can't read the number
22:28	<mdz_>	Chutt: I like the new record selection dialog a lot more
22:28	<Chutt>	if you use the liquid qt theme
22:29	<Chutt>	it's more contrasty
22:32	<Chutt>	and, thanks for the patch =)
22:32	<Chutt>	going to do the program guide?
22:33	<Universe>	I am using rtjpeg but I can use mpeg4
22:34	-!-	nyquiljer [jer@12.211.16.232] has joined #mythtv
22:34	<Chutt>	nyquiljer, yo
22:34	<Universe>	I know the major improvement was on mpeg4
22:35	<nyquiljer>	howdy
22:41	-!-	SadMan [sadman@god.sk] has joined #mythtv
22:42	<Chutt>	good, i'm removing the mythdialog program now
22:46	<Markie>	ARGHHHHHH
22:50	<mdz_>	Chutt: I'm not up for changing the program guide over tonight; I wouldn't be able to test it yet
22:50	<Chutt>	heh
22:50	<Chutt>	that's cool.
22:50	<mdz_>	I was thinking it might be nice to split out playback from TV
22:50	<-- Nothingman	(~chatzilla@ny-utica7a-405.aburny.adelphia.net) has left #mythtv
22:51	<mdz_>	then I could make a mythplay that doesn't suck, and has all the same key bindings and functionality as TV playback
22:51	<Markie>	Chutt: how are you creating the moc_ files?
22:51	<Chutt>	that's kinda the plan for when i start doing the split encoding stuff
22:51	<Markie>	like moc_deletebox.
22:51	<Chutt>	markie, qmake does all that.
22:51	<Universe>	mdz... with my 700, 480x480 mpeg4, audio compression off, and deinterlace off... its only a little jerky...
22:52	<mdz_>	Universe: so close
22:52	<Markie>	rghh..i think thats what my errors were
22:52	<mdz_>	Universe: is that with live TV?
22:52	<Universe>	yep
22:52	<Universe>	live tv
22:52	<Markie>	i gotta figure out how to have qmake generate that file
22:52	<mdz_>	you can probably do scheduled recording and playback fine then
22:52	<Universe>	recording would probably be fine
22:52	<Universe>	yeah
22:52	<mdz_>	in my experience, live TV is more demanding
22:52	<mdz_>	though I haven't looked into why that is...Chutt?
22:52	<Chutt>	markie, you put a Q_OBJECT in the class definition
22:52	<mdz_>	I would expect live TV to be easier because there should be less I/O
22:53	<Chutt>	seems to be more io
22:53	<Chutt>	dunno why
22:53	<mdz_>	weird
22:53	<Universe>	actually
22:53	<Chutt>	at least on my box
22:53	<Chutt>	it might not be now, though, i dunno
22:53	<mdz_>	Universe: did you let live TV run for a while?
22:53	<Universe>	I think it isn't jerky... its the low default mpeg4 setting that doesn't look good
22:53	<mdz_>	Universe: it usually settles down to use less CPU after a little while
22:53	<brtb>	live tv is more io than recording and playing at the same time?
22:54	<Markie>	i got the QOBJECT
22:54	<Universe>	mdz, you are right... it looks better now..
22:54	<Markie>	but no moc_ file
22:54	<Chutt>	no signals or slots?
22:54	<Markie>	heres what i did: copied deleteboc.cpp and .h to themesbox.cpp and .h
22:54	<Markie>	search-replace DeleteBox with ThemesBox
22:54	<Chutt>	oh, first of all, if you're planning on sending in patches
22:54	<Chutt>	you need to be using cvs
22:55	<Markie>	Chutt: thats fine
22:55	<Markie>	Chutt: once i get it working ,i'll incorporate it into CVS
22:55	<mdz_>	ah, CPU comparison advice from the uninformed
22:55	<Markie>	i added the dependencies into the MAkefile and keep getting the vtable error
22:55	<mdz_>	the joys of mythtv-dev
22:56	<Universe>	changing the channel isn't so fun..
22:56	<Universe>	have to pause it a few seconds to get not jerky
22:56	<Chutt>	you don't edit the makefile yourself
22:56	<Candyman>	anyone here have a widescreen monitor? or ever used linux on a widescreen'd display
22:57	<Markie>	yes..i know, but it seemd to be a quick way to add it :^)
22:57	<Markie>	what file should i add the new source to?
22:58	<Chutt>	the .pro file