Back to Home / #mythtv / 2002 / 11 / Prev Day | Next Day
#mythtv IRC Logs for 2002-11-20

00:00<Markie>yep got it. thanks
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 [] has joined #mythtv
00:02<Markie>so it must have tried to redraw, went throug the list, and the pixmaps were null
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>ok..good night!
00:45-!-_shad [] has quit [Read error: 104 (Connection reset by peer)]
01:16<-- aw( has left #mythtv ("Client Exiting")
01:40-!-Tuscany [] has joined #mythtv
02:22-!-bigguy [] has quit ["Sleep Owned Me"]
04:09-!-nevertheless [] has joined #mythtv
09:56-!-Tinaral [] has joined #mythtv
09:56-!-Tinaral [] has quit [Remote closed the connection]
10:17-!-Universe [] has joined #mythtv
10:20-!-Tuscany [] has quit ["Trillian ("]
11:13-!-tuscany [~ctalbot@] 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:39lichenlichen_ Nov 20 11:39:33 <mdz> lichen: apt-get install libxmltv-perl
11:39lichenlichen_ 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: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>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: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<-- Universehas 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> 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:09<Chutt>what _could_ be done, on the other hand
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>didnt know the parent closed it..sorry just jumped in here :^)
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>echo "changing to $1"
12:45<tuscany>/usr/local/bin/ $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:48-!-Universe [] has joined #mythtv
13:13-!-chris__ [] 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: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:
13:41<mdz>tuscany: google for "csh programming considered harmful"
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 [] 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>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<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>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: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>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<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>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<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<Markie>it's called "mythsettings"
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<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<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<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<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>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>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<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>it depends on how big the soundcard buffers are
15:55-!-elsefuderr [] has quit [Ping timeout: 14400 seconds]
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>Chutt: disk space usage, or disk I/O 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>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: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<mdz>huffyuv is signifacntly slower on the decode side
16:06<mdz>like, 50%
16:07<Chutt>at least with that implementation
16:07<mdz>oh lord
16:07<mdz>is sourceforge still broken?
16:07<mdz> is broken even in google's cache
16:08<Chutt>the website works for me
16:08<mdz>what IP does it resolve to?
16:08<Chutt>just stuff like the mailing list archives are broken
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>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>a address on both lists =)
16:33<Chutt>not that i see
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<-- Universehas quit ()
16:44<Chutt>libavcodec's mjpeg stuff looks ok at 640x480 @ 3 gig an hour
16:46<Chutt>guy on the list is using pc133 with an xp 1700+
16:47<mdz>and I feel bad about using pc133 with my 1.4 tbirt
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>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<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>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 [] 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<mdz>no capture here
17:14<mdz>Chutt: thinking about per-recording capture/encoding 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>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:
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>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<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: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 [] 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>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:52<mdz>have you looked at that guy's patch to suck a file into mythfilldatabase?
17:52<mdz>I had thought about doing that, it'd be handy
17:52<Chutt>i'm going to apply it tonight
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<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>that guy that wants to get rid of the database is silly.
18:39-!-hadees [] has joined #mythtv
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<-- hadeeshas 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<mdz_>plus my tiny dialog patch
19:10<mdz_>grr, conflicts in setup/main.cpp
19:53-!-nevertheless [] has quit []
20:03<mdz_>Chutt: 215 deb downloads from 110 unique IPs
20:53-!-Universe [] has joined #mythtv
21:09-!-Nothingman [] has joined #mythtv
21:09<Nothingman>oh, wow
21:09<Nothingman>anyone getting just "couldn't open db" when they run setup?
21:10* Nothingmanlistens to crickets chirping
21:11<mdz_>Nothingman: that will happen when it can't connect to the database
21:11<Nothingman>and that would be because...
21:11<mdz_>Nothingman: well there's your problem
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<-- Nothingmanhas quit ()
21:28-!-Tuscany [] has joined #mythtv
21:29-!-KeyserSoze is now known as Keyser[zzz]
21:29<-- Keyser[zzz]has quit ("Client Exiting")
21:36-!-hadees [] 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 [] 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-!-Nothingman [] 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:11-!-Candyman [] 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<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>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>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: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 []
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@] has joined #mythtv
22:34<Chutt>nyquiljer, yo
22:34<Universe>I know the major improvement was on mpeg4
22:41-!-SadMan [] has joined #mythtv
22:42<Chutt>good, i'm removing the mythdialog program now
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>that's cool.
22:50<mdz_>I was thinking it might be nice to split out playback from TV
22:50<-- Nothingman( 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>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<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<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
22:58<Chutt>you just add the .c and the .h to the lists
22:58<Universe>all and all, right work mdz... probaby a 1gig and you would be set with nice quality
22:58<Universe>err nice work, I meant
22:58<Markie>thats why i was asking you the other day what you use, cause it seemed even the .pro files are auto-generated
22:59<Chutt>and i said 'you edit those manually'
22:59<Markie>yea...i wasnt sure which "those" you meant :^)
22:59<Markie>ok, i got it added to the .pro file
23:00<Markie>now what to generate the moc_ files? qmake
23:00<Chutt>if it needs to have a moc file, then qmake will automatically make it
23:01<Markie>yea!! thats it! thanks!
23:02<mdz_>Universe: great
23:02<mdz_>Universe: a 1gig what?
23:02<Chutt>anything non-crippled
23:02<Chutt>ie, celery, duron =)
23:02<mdz_>Chutt: might be a good idea to remove the comments at the top of the .pro files which say they're autogenerated
23:02-!-nyquiljer [] has quit [Read error: 54 (Connection reset by peer)]
23:02<mdz_>Chutt: it's confusing when they're expected to be edited
23:02<Chutt>bah, that's a pain
23:02<mdz_>I'll send you a patch if you like :-)
23:03<Universe>1gig processor mdz..
23:03<Chutt>fine, send a patch
23:03<Chutt>or better yet, i'll give you write access
23:03<Chutt>and you can do it yourself
23:04<Chutt>i should go and slap copyright notices on all the files, too
23:04<Chutt>but again, i'm lazy lazy
23:04<mdz_>Chutt: ssh or pserver?
23:04<Chutt>though i think pserver works, too
23:04<mdz_>Chutt: I'll mail you a public key
23:05<Chutt>i'd rather just let you ssh in and change your password and all that
23:05<mdz_>ok, ok
23:05<Chutt>then you can setup whatever you want
23:05<mdz_>I hate passwords
23:05-!-nyquiljer [jer@] has joined #mythtv
23:07<Candyman>Chutt, too late
23:07<Candyman>i already copywrote it :S
23:07<Candyman>err :D
23:07* Candymandances on his Microsoft'd copywrights
23:08-!-Candyman is now known as Namapoos
23:11<Markie>Chutt: what hardware card is i nthe owrks in CVS?
23:11<Chutt>any of the hardware mjpeg cards
23:15<brtb>how about the completely nonstandard miroVideo DC20? >=]
23:16<Universe>Chutt.. you are working on support for hardware encoding cards?
23:16<brtb>that thing barely works in windows, much less linux... last drivers they released were for nt4 and win95
23:17<Chutt>well, anything that works with the mjpeg tools
23:17<Markie>it works! it works! it works! :^)
23:19<mdz_>Chutt: what kind of bitrate comes out of that mjpeg card you have?
23:19<Chutt>really high
23:19<mdz_>depends on the quality, I assume
23:19<mdz_>but how high is really high?
23:19<brtb>ok... p3-667 will *almost* do 480x480 in rtjpeg (deinterlace/compress audio both on). but judging from the way the drive's thrashing I can't tell if it's drive IO or the cpu
23:19<Chutt>or so
23:19<Chutt>pretty much =)
23:20<Chutt>brtb, so with them off, it handles it?
23:20<Chutt>well, close to handling it?
23:20<brtb>it's close with them on
23:21<brtb>if i had a faster hard drive it might actually do it
23:21<yebyen>i need a low-power/low-heat processor
23:21<yebyen>so I can put together a quiet mini-itx system for mythtv
23:22<Universe>Chutt... when you get hardware cards working... we will not need fast processors, right?
23:22<Namapoos>yebyen, talk to paper, i believe he is doing that
23:22<Chutt>no, you will
23:23<Chutt>universe, since the hardware mjpeg stuff pretty much sucks
23:23<Chutt>it's _huge_
23:23<Chutt>and decompressing takes a lot of cpu
23:23<Chutt>since you need two cards to do compression and decompression simultaneously
23:23<yebyen>Namapoos: hmmm
23:23<yebyen>Namapoos: I'd like to spend less than a crapton, :D
23:23<Universe>so whats the advantage to using a hardware card?
23:23<brtb>ok, it's jumping the same with them off... is there a better way then `top` of reading cpu usage?
23:25<Chutt>yebyen, did you see someone sent a patch to mythfilldatabase to add arbitrary files?
23:25<mdz_>Universe: takes almost no CPU
23:25<mdz_>brtb: vmstat 10
23:25<Universe>ok.. I am confused then...
23:26<Namapoos>Chutt, don't most modern ati video cards do hardware mpeg2 decompression?
23:26<Namapoos>at around 70bucks american
23:27<Chutt>most cards do some mpeg2 decompression helping, yeah
23:27<brtb>does mpeg4 start dropping playback frames? mpeg4 480x480 almost looks like it's running at half framerate
23:27<yebyen>Chutt: they did? :D
23:27<mdz_>my video card has motion compensation and idct acceleration
23:27<mdz_>but I don't think the gatos drivers support it
23:27<mdz_>I don't even know if X has an API for it
23:27<yebyen>Chutt: would I need to do anything special to change my channel list in mythtv (additionally)?
23:28<Chutt>x has this lame api for it
23:28<Chutt>that absolutely nobody uses
23:28<mdz_>as opposed to the other X APIs? :-P
23:28<yebyen>Chutt: where can I get it :)
23:28<yebyen>Chutt: or is it in cvs
23:29<mdz_>yebyen: it was posted to mythtv-dev, you can find it in the archives
23:29<Chutt>it's going in cvs soon
23:29<Chutt>like, 5 minutes
23:29<yebyen>Chutt: then I will wait :)
23:30<Chutt>i'm not sure how easy it'll be to use
23:30<yebyen>Chutt: hmm
23:30<yebyen>Chutt: well I already have the xml file, heh
23:31<yebyen>actually I really can't dick with it tonight
23:31<yebyen>I have to pack for CMU
23:31<brtb>ok... tweaked it a bit
23:31<yebyen>(visiting tomorrow)
23:31<yebyen>and uhh, it's 11:30 alreacy
23:31<brtb>deinterlace and audio compress off, it'll do rtjpeg 480x480 no skips
23:32<yebyen>you know, when I turned deinterlace off, it looked like crap again :)
23:32<lichen_>man the hardest part of building a myth box is putting all the hardware in the box without it freaking out about irqs
23:32<brtb>my stupid hard drive can't write fast enough for rtjpeg at higher quality
23:32<yebyen>probably because I was still 320x240
23:32<Chutt>brtb, heh
23:32<mdz_>brtb: at least you have a hard drive :-)
23:32<lichen_>ive got my g400, rainbow runner, nic, live, live addon card
23:32<mdz_>lichen_: why do you need the addon card?
23:33<Markie>what's the difference betwen the Background image defined in the theme.xml file, versus the BackGroundPixmap defined in the qt.txt file?
23:33<brtb>lol... just barely, i had to steal it out of my main machine (the ibm 60gb is on its way back AGAIN)
23:33<lichen_>i suppose i dont.. but it was already in the machine my roommate let me borrow.. s oi figured i would keep it in there, its not liek it uses an irq or anything does it?
23:33<Chutt>markie, one's used for the qt dialogs, one's used for menus
23:34<Markie>menu's being the xml files, and dialogs being generated from code?
23:34<mdz_>it looks like gatos does support the DVD acceleration features
23:34<Chutt>yeah, but what _uses_ those =)
23:34<mdz_>who needs em?
23:35<mdz_>DVD playback takes almost no CPU here
23:35<brtb>grr, audio compress puts it over the edge
23:35<Markie>thanks for making my work harder :^)
23:35<-- Universehas quit ()
23:35<mdz_>now if only I could get TV output to fill the entire TV screen...
23:37<mdz_>macrovision bastards
23:38<Chutt>that has nothing to do with the amount of overscan, i don't think
23:38<yebyen>I couldn't get it to fill the TV, then I switched from 800x600->640x480
23:38<yebyen>now it fills it completely
23:39<yebyen>don't ask me why
23:40<brtb>macrovision is the reason ati won't release the specs
23:41<\dmz>ive heard the same reason supposedly given by matrox
23:42<brtb>since there's probably a MacrovisionOn=1/0 bit somewhere
23:43<brtb>i need to find my wireless keyboard and try out the scan-converter box
23:43<mdz_>Chutt: macrovision is the reason why there is no proper TV output support in the gatos drivers
23:44<yebyen>damned man, keeping us down
23:44* yebyenslaps the man
23:45<yebyen>DAMN YOU MAN
23:46<brtb>352x480 works. 480x480 skips.
23:46* yebyenis stuck at 320x240
23:46<yebyen>and it doesn't really bother me
23:47<brtb>somewhere around 170,000 pixels is the limit, if that makes any sense
23:48<brtb>i'm guessing switching to the duron 700 would make things worse?
23:49<mdz_>I just want mythtv to be able to occupy the entire television screen
23:49<mdz_>brtb: switching to a duron 700 from what?
23:49<brtb>pe 667
23:49<brtb>p3 even
23:51<mdz_>probably whichever has more cache
23:51<brtb>p3 has 256k, dunno how much the duron has, less i'm sure
23:51<brtb>`cat /proc/cpuinfo` 64k? ew. nevermind.
23:52<nyquiljer>do all durons have 64k?
23:52<nyquiljer>my 1200 does
23:52<brtb>newer ones might have 128, not sure... that's why they're durons
23:53<nyquiljer>yeh, thats what i figured
23:54<mdz_>my t-bird and XP both have 256k
23:58<\dmz>ah, is back up