Back to Home / #mythtv / 2003 / 02 / Prev Day | Next Day
#mythtv IRC Logs for 2003-02-23

00:27<PeteCool>CVS cable? the kind that changes every hour or so? :p
00:27<PeteCool>why would they offset it, anyway?
00:35<rcaskey>pete: not sure
00:35<rcaskey>but they do
00:35<rcaskey>I had to fix this before
00:35<rcaskey>and forgot the name
00:42-!-orangey [] has joined #mythtv
00:42<orangey>hey guys!
00:42<orangey>is something up with the CVS server?
00:45-!-Captain_Murdoch [] has joined #mythtv
00:45<Captain_Murdoch>anyone here?
00:46<Captain_Murdoch>or more to the point, anyone here running the latest CVS?
00:50<orangey>Captain_Murdoch: I kinda am.
00:50<orangey>what's up?
00:52<Captain_Murdoch>I'm the guy who's been posting the commercial skip patches to the dev list and I'm seeing segfaults sometimes and was wondering if anyone else was with the latest CVS. I see them occasionally even if I don't use the commercial skip feature.
00:52<orangey>I think we all suffer from the occasional seg faults..
00:53<orangey>congrats on the great work, btw.
00:53<orangey>in other news, can you update your CVS at the mo ment?
00:53<Captain_Murdoch>these are reproduceable though, I think a buffer is being freed twice somewhere but don't know much about libavcoded to make sure.
00:53<orangey>Mine keeps "hanging" and I'm trying to figure out why..
00:53<Captain_Murdoch>I just updated a few minutes ago.
00:53<orangey>Captain_Murdoch: if it's reproducable, just report it along with the trace.
00:54<Captain_Murdoch>just reupdated and it worked fine.
00:54<orangey>I can't update either from my main linux system or this one..
00:54<orangey>though they both use the same net connection, so that *may* be related..
00:54<orangey>just gonna reboot.. brb.
02:00* bigguyis [away -={ SLEEP }=- ]
02:01<bigguy>night all
02:09-!-orangey [] has quit [Read error: 60 (Operation timed out)]
02:09-!-orangey [] has joined #mythtv
02:09<orangey>hey guys!
02:09<orangey>anyone alive? : )
02:10<orangey>I'm just wondering a bit about backend/frontend separated machines.. does mythbackend have to run on each and every one?
02:16<Captain_Murdoch>mythbackend only needs to run on the server. v0.8 will support running multiple mythbackend servers though with one being the master. all mythbackend servers will be able to record.
02:17<orangey>Captain_Murdoch: OK, well, how do I get my frontend to connect, then?
02:17<orangey>[root@localhost setup]# mythfrontend
02:17<orangey>connecting to backend server: localhost:6543
02:17<orangey>Could not connect to backend server
02:17<orangey>which is fine, since my server is actually on
02:17<orangey>but hwo do I get it to try to connect to
02:29<orangey>Dear god. Do I *really* have to hard-code the change in IP?
02:42<Captain_Murdoch>sorry, was off coding... :) you have to change the source right now I believe. the whole frontend/backend split isn't complete yet.
02:44<orangey>OK, got it..
02:44<orangey>thank you very much : )
02:44<orangey>brb.. gotta rebootski
02:44-!-orangey [] has quit [Remote closed the connection]
02:44<bigguy>wtf do people think they have to reboot everytime they change a userland app's config?
02:49<Captain_Murdoch>are you running current copy of MythTV from CVS?
02:51<Captain_Murdoch>ok, thanks. trying to track down a segfault in it.
02:51-!-orangey [] has joined #mythtv
02:51<orangey>now the problem seems to be the lack of sound..
02:52<orangey>is it possible that this is due to sampling rate differences?
02:52<orangey>between the server and client, that is/
02:52<bigguy>orangey: did you reboot because you recompiled mythtv?
02:53<orangey>bigguy: I rebooted because I just turned off artsd
02:53<orangey>and was having issues with sound.
02:54<orangey>and figured a reboot might help : )
02:54<bigguy>you don't have to reboot for that
02:54<orangey>but my /dev/dsp is clearly usable.
02:54<orangey>bigguy: I come from a long line of rebooters.
02:54<bigguy>there are very few reasons to reboot
02:54<orangey>my pappy rebooted before me, and his pappy before him.
02:54<orangey>bigguy: In any case, any clues?
02:55<bigguy>I'm not running myth atm
02:55<orangey>I rebooted my main linux server today because it wasn't updating the CVS properly..
02:55<orangey>and that fixed it.
02:55<bigguy>what sound card do you have?
02:55<orangey>though it was goodbye to my ~ 67 day uptime.
02:55<orangey>this one is some built-in one.
02:55<orangey>ooh! maybe I don't have alsa going on.. brb.
02:55<bigguy>this on the client box right?
02:56<orangey>Yep, it ain't alsa..
02:56<orangey>yeah, client.
02:56<orangey>maybe alsa will help..
02:56* bigguyis lagging because of apt-get dist-upgrade'in his box
02:57<-- Captain_Murdochhas quit ()
02:57<bigguy>I doubt it will, but you can always try
02:57<orangey>well, any ideas you want to toss out are plenty welcome
02:57<bigguy>it might be one of the issues another guy was having because of cheap onboard cards
02:58<orangey>yeah, but why would said cheap onboard card have no trouble with anything else?
02:58<orangey>plus, it's not like this is trying any full duplex action.
02:58<orangey>the only thing I can imagine is some sampling problem..
02:58<bigguy>because of how myth accesses it?
02:58<orangey>which is how?
02:59<bigguy>the other people that were having problems had something to do with the soundcard reporting back the wrong info to myth. like it had no free "buffers" or something
02:59<orangey>well, no such errors are being reported here..
02:59<orangey>where would it be reported?
03:00<bigguy>Audio buffer overflow
03:00<bigguy>there was something on the mythtv users list
03:00<orangey>yeah.. it's a long-standing issue..
03:00<orangey>I'm *relatively* sure that's not it..
03:02<bigguy>but you get no errors?
03:02<orangey>I dig it.
03:02<orangey>but this really don't look like it.
03:02<orangey>no errors at all.
03:03<bigguy>try alsa and see if that works
03:03<bigguy>dunno what to tell you
03:03<bigguy>I'm gonna head off to bed
03:04<bigguy>let me know in a message later if that worked
03:23-!-debian [] has joined #mythtv
03:35-!-debian [] has quit ["Client Exiting"]
03:43-!-orangey [] has quit [Remote closed the connection]
04:03-!-TheAsp [] has quit [Remote closed the connection]
04:16-!-choenig [] has joined #mythtv
04:53-!-KingSoopa [] has quit [Read error: 60 (Operation timed out)]
09:02-!-choenig [] has quit [Read error: 104 (Connection reset by peer)]
09:05-!-choenig [] has joined #mythtv
09:11-!-choenig [] has quit [Remote closed the connection]
09:14-!-choenig [] has joined #mythtv
10:24-!-choenig [] has quit [Remote closed the connection]
10:26-!-choenig [] has joined #mythtv
10:27-!-TheAsp [] has joined #mythtv
10:27-!-choenig [] has quit [Remote closed the connection]
10:28<TheAsp>hey chutt, is there a reason to mess with the PCM volume instead of the master volume?
10:30-!-choenig [] has joined #mythtv
10:56-!-choenig [] has quit [Remote closed the connection]
10:59-!-choenig [] has joined #mythtv
11:33-!-Edgan [] has joined #mythtv
12:03<PeteCool>TheAsp: maybe because it won't touch recording volume
12:04<TheAsp>main volume wont...
12:06<PeteCool>well, Chutt says changing the line-in volume when it's set to mute and capture has no effect, but it sure does here on my cmi8738
12:06<PeteCool>it might depend on the soundcard
12:06<TheAsp>the main volume controls outgoing sound...
12:19-!-debaserto [] has quit [Remote closed the connection]
12:24-!-bigguy [] has quit [Read error: 113 (No route to host)]
12:28-!-Edgan [] has quit ["Client Exiting"]
13:26<Chutt>mdz, the il8n guy's probably using qt's built-in stuff, which i believe needs to load external files for the translations
13:26<Chutt>i'm not sure how all it works, though
13:27<rcaskey>Chutt: do you remember what the kind of signal is called where the signals are offset? I wanna say its called CVS Cable.
13:28<Chutt>it's called you're using the wrong tuner type when you load the bttv module =)
13:28<rcaskey>Chutt: not its not, because I fixed it once before :)
13:28<rcaskey>I just forgot the acronym so I cant lookup the offset
13:28<Chutt>yes, it is
13:29<TheAsp>there is hrc, which is offset, but probbaly not what you are talking about
13:29<rcaskey>My cable comes off a satelite feed from my apartment and then it gets fed in
13:29<rcaskey>TheAsp: whats it offset by?
13:29<TheAsp>who cares?
13:29<TheAsp>theres a table
13:29<TheAsp>look it up
13:30<Chutt>if all your channels are offset by one value
13:30<Chutt>you're using the wrong tuner type when you load the bttv/tuner modules.
13:32<rcaskey>Chutt: its offset by 103 hz
13:32<Chutt>you're using the wrong tuner type when you load the bttv/tuner modules.
13:33<TheAsp>chutt, want a patch to change the main volume instead of pcm?
13:33<Chutt>i'd prefer it to keep touching the pcm volume
13:33<rcaskey>ok, im in debian with a TV Wonder
13:34<TheAsp>how about an option?
13:34<TheAsp>if my pcm goes > 75% my sound is distorted
13:34<TheAsp>hw flaw
13:35<Chutt>just turn off the volume control and use a receiver
13:35<rcaskey>post-install bttv insmod tuner post-remove bttv rmmod tuner
13:35<rcaskey>those are the two in /etc/modutils/actions
13:35* TheAsppokes chutt in the ear :P
13:35<TheAsp>rcaskey: yay.
13:35<Chutt>rcaskey, which tuner is it loading?
13:35<TheAsp>that has nothing to do with fixing your tuner
13:35<rcaskey>wait hold on
13:35<rcaskey>im chrooted ;)
13:36<TheAsp>chutt: most desktop stuff only changes the main volume :)
13:36<Chutt>theasp, that's bad practice
13:36<TheAsp>i'd say messing with pcm is bad practice...
13:36<Chutt>that's what you're outputting
13:36<Chutt>you shouldn't be modifiying _everything_
13:36<Chutt>just what you're using
13:36<TheAsp>because it's not what most people will expect....
13:38<rcaskey>tuner bttv i2c-core i2c-algo-bit
13:38<TheAsp>pcm is preamp anyway, is it not?
13:38<TheAsp>so messing with it would affect sound quality more then messing with master
13:38<TheAsp>rcaskey: that has nothing to do with what tuner you are using.... dmesg | grep tuner
13:39<Chutt>i don't use the volume control
13:39<Chutt>that's what a receiver is for
13:39<rcaskey>tuner: probing bt848 #0 i2c adapter [id=0x10005] tuner: chip found @ 0xc0
13:39<TheAsp>actually, | grep i2c-core.o:
13:40<TheAsp>so you are arguing about something that wont even affect you? :)
13:40<Chutt>i believe the current behavior is correct
13:40<rcaskey>i2c-core.o: i2c core module i2c-core.o: adapter bt848 #0 registered as adapter 0. i2c-core.o: driver i2c TV tuner driver registered. i2c-core.o: client [Temic PAL* auto (4006 FN5)] registered to adapter [bt848 #0](pos. 0).
13:40<TheAsp>and you dont want to give people the option?
13:40<TheAsp>rcaskey: are you using PAL or NTSC?
13:40<TheAsp>do you not see a problem?
13:40<Chutt>wow, look at that
13:40<Chutt>you're using the wrong tuner type
13:41<rcaskey>Chutt: ok, so how do I fix it?
13:41<Chutt>read the bttv docs
13:41<Chutt>or the mailing list
13:42-!-PeteCool [] has quit ["Client Exiting"]
13:45<Chutt>if you don't like how the volume control stuff, you don't have to use it =)
13:45<Chutt>it's disableable
13:45<TheAsp>it's patchable too :P
13:45<Chutt>too many semi-useless options are bad
13:45<TheAsp>it's a standard option dude...
13:47<TheAsp>hey, mine is already switched, so it's just going to be other people whining about it...
13:49-!-poptix [] has quit [Read error: 104 (Connection reset by peer)]
13:52-!-poptix [] has joined #mythtv
14:10<choenig>Chutt: what would be the best way for the scheduler to find out, if (or how many) clients are connected to the mainserver?
14:13--> ^rcaskey( has joined #mythtv
14:13-!-rcaskey [] has quit [Read error: 110 (Connection timed out)]
14:22<^rcaskey>Chutt: I changed my action to indicate tuner=17 and did update-modules, and rebooted, but still no dice
14:22<^rcaskey>its still showing tuner=19
14:22<^rcaskey>post-install bttv insmod tuner type=17
14:22* ^rcaskeytries autoload=0
14:23<moegreen>^rcaskey: are you using debian?
14:23<Chutt>you need to load the tuner module with the type arg
14:24<^rcaskey>moegreen: yeah
14:26<TheAsp>rca: option tuner type=17...
14:26<^rcaskey>TheAsp: got it
14:27<^rcaskey>autoload must=0
14:32<choenig>Chutt: did you get my question above?
14:33<Chutt>sorry, i was looking at something =)
14:34<Chutt>why's it need to know what clients are connected?
14:34<choenig>ah, I'm again working on some quit/shutdown stuff, but the scheduler really needs to know somehow if clients are connected
14:34<Chutt>not sure how best to handle it, then
14:34<choenig>since the scheduler is responsible for the backend(s) shutdown
14:36<choenig>i thought about smth like making playbackList global, but I do not like global vars and I don't know, how thing get when the backand is not the mainserver
14:37<choenig>I mean using a global reference in scheduler and mythbackend_main.cpp like tvList
14:37<Chutt>could just pass in the mainserver object to the scheduler
14:37<Chutt>then the scheduler could just ask the mainserver object what all's connected
14:38<choenig>:-) Ill have a look ...
14:39<Chutt>you'd probably have to write a couple functions to do that, but that's probably the best way to handle it
14:39<choenig>yeah, the functions are no problem
14:43<^rcaskey>got the video working and no sound still
14:43<^rcaskey>err I had sound but now I dont
14:44* ^rcaskeychanges his setting back and reboots his server again
14:50-!-bigguy [] has joined #mythtv
14:51<-- bigguy( has left #mythtv
14:51-!-bigguy [] has joined #mythtv
14:52<yebyen>star trek owns me
15:16-!-KingSoopa [] has joined #mythtv
15:44-!-SoopaMech [] has joined #mythtv
15:44-!-KingSoopa [] has quit [Read error: 54 (Connection reset by peer)]
15:44-!-SoopaMech is now known as KingSoopa
15:58-!-KingSoopa is now known as Soopaman
16:15-!-TheAsp [] has quit [Remote closed the connection]
16:27<mdz>Chutt: gettext loads external files for the translations, too
16:27<mdz>Chutt: it just loads them from a standard path
16:27<mdz>Chutt: /usr/share/locale, /usr/local/share/locale, etc.
16:33-!-Edgan [] has joined #mythtv
17:27* bigguyis [away -={ SHOWAH }=- ]
17:27-!-Soopaman [] has quit [Read error: 104 (Connection reset by peer)]
17:28-!-Soopaman [] has joined #mythtv
17:34<shad_>anyone around who's using the frontend and backend on seperate machines?
17:53<Edgan>I have
17:54<Edgan>I love it
18:00* bigguyis [back -={ o/~ A sprinkle a day helps keep odor away Have you had your sprinkle today? o/~ }=- ]
18:01<-- ^rcaskeyhas quit (Read error: 60 (Operation timed out))
18:13-!-Soopaman [] has quit [Read error: 110 (Connection timed out)]
18:17<Chutt>mdz, got a settings question for you
18:17<Chutt>want to have a checkbox for the 'master server' setting
18:18<Chutt>i figure it should read/write a hostname from the database
18:18<Chutt>so, i'd want it checked if the hostname matched the current hostname, and unchecked otherwise
18:18<Chutt>and you shouldn't be able to _un_check it manually
18:18<Chutt>without setting it from another machine
18:19<Chutt>although, blah
18:19<Chutt>i might as well just make it an edit box with an ip address
19:33-!-choenig [] has quit [Remote closed the connection]
19:49-!-Soopaman [] has joined #mythtv
19:53<mdz>why is it that nobody is able to spell nuppelvideo? ever?
19:54<Chutt>it's hard to spell
19:54<Chutt>or something
19:55<mdz>I'm running a recent CVS checkout now
19:55<mdz>the rebuffering on seeks seems to be about the same
19:55<Chutt>recent as in more than a few hours?
19:55<mdz>maybe a little smoother, but there is still a >1sec delay before it gets back to normal
19:56<mdz>about 18:24 EST
19:56<Chutt>do you have the aggressive soundcard buffering option?
19:57<mdz>default I assume
19:57<mdz>is it on or off by default?
19:57<Chutt>it's off by default
19:57<Chutt>but, i was asking if you had the option at all =)
19:57<Chutt>since i think i checked stuff in to make it an option right around there
19:58<mdz>seems the same after I turn it on
19:58<mdz>shouldn't that be on the Audio page?
19:59<Chutt>but i just put it where it is temporarily
19:59<Chutt>since i was asking that guy to make sure both were unchecked
19:59<mdz>I've been meaning to add some verbosity to see what is going on
19:59<mdz>whether it is hitting the end of the buffer or what
20:00<Chutt>when you turn it on, does it complain about your soundcard at all?
20:01<mdz>Your soundcard is not reporting free space correctly.
20:01<mdz>Falling back to old method...
20:01<mdz>to stderr
20:01-!-Soopaman [] has quit [Read error: 104 (Connection reset by peer)]
20:01<Chutt>so, it doesn't work for you
20:01<Chutt>which is why i have it off by default =)
20:02<mdz>it would be nice to get an errno value for that ioctl
20:03<Chutt>it's not the ioctl that's failing
20:03<mdz>no way to tell really :-)
20:03<Chutt>it's the fact that the soundcard is reporting an approximate value for it that doesn't even remotely come close to the real value =)
20:04<mdz>it doesn't check
20:05<mdz>I dunno whether the ALSA OSS emulation gets that stuff entirely right
20:05<mdz>hmm, andy davidoff just posted a patch with a bunch of #ifdefs in it
20:06<Chutt>i'm going to reject those parts
20:06<mdz>is that zeroing out of libavcodec stuff related to that crash that I saw before, that apparently someone else sees as well?
20:07<mdz>the free_picture bit
20:07<Chutt>yeah, but i really don't think it's it -- the entire structure those are part of is zeroed out
20:07<Chutt>figured it's nice to be sure, though
20:08<mdz>oh, hey, JitterReduction makes a big difference fro me
20:08<Chutt>for the better?
20:08<mdz>oh yes
20:09<mdz>it does what I hoped the audio buffering change would do
20:09<Chutt>it'll use more cpu to do so, of course
20:09<Chutt>since it's busywaiting a little
20:10<mdz>it works perfectly now
20:13<mdz>it does this whenever the delay is <40ms, right?
20:14<Chutt>it's reducing the max sleep time to 40ms from 200ms
20:14<Chutt>and it's not sleeping as often
20:14<Chutt>instead it'll busywait a little if it needs to sleep for just a short period of time
20:14<mdz>how little?
20:15<Chutt>i think it's 5ms
20:15<Chutt>not sure off the top o my head
20:17<Chutt>he's got it commented fairly well in the source
20:18<mdz>looks to me like for 40ms or more, it usleeps, while for <40ms it calls ReduceJitter
20:18<mdz>reducejitter is not entirely clear to me
20:18<mdz>is nexttrigger the time that we next need to do something?
20:18<Chutt>nexttrigger is when we're supposed to be displaying the next frame
20:19<Chutt>ya know, i bet it's that 40ms value that's causing trouble
20:19<mdz>ah, reducejitter usleeps if it's >5ms
20:19<mdz>might as well change that 40000 to 5000
20:20<Chutt>no, don't want that
20:23<mdz>might help some if it doesn't call gettimeofday() every time through the busywait loop
20:23<mdz>in terms of CPU utilization
20:27-!-TrekCycling [] has joined #mythtv
20:29<mdz>Chutt: what are your thoughts about using a realtime scheduler, now that things are split up a bit more?
20:29<Chutt>i dunno
20:31<mdz>it sounds pretty nice
20:31<mdz>would be able to usleep down to 2ms
20:31<Chutt>if you change HZ in your kernel, you can usleep further down as well
20:32<mdz>under 2ms it automagically busy waits for you
20:32<mdz>so it could do a plain nanosleep no matter what the value
20:33<mdz>actually, I think between 2 and 10 it still sleeps for at least a timeslice
20:33<Chutt>since a timeslice is 10..
20:33<Chutt>the best thing would be for xfree to have some nice standard way to wake up a process when it's time to blit
20:35<mdz>it'd still be limited by the resolution of the scheduler, though, wouldn't it?
20:35<Chutt>interrupts, etc =)
20:36<mdz>I dunno how that stuff works really, when and if things get preempted
20:36<Chutt>yeah, i dunno
20:36<Chutt>the sf mailing list archives are down _again_
20:37<mdz>they seem to have put a lot of work into building their own mail archive system, which seems to only make it more difficult to access the content
20:37<mdz>does a nice job of keeping it from getting indexed by search engines, too
20:37<Chutt>and it's down 80% of the time
20:37<Chutt>all the trouble after they had that big press release saying they were migrating to db2
20:38<Chutt>guess they need a real db admin =)
20:40<Chutt>1600+ messages this month to the two mailing lists
20:41<Chutt>that's down a bunch from last month, i think
20:41<Chutt>well, 300
20:41<Chutt>should beat last months total, then
20:47<TrekCycling>hey, does anyone here know of a tv card that handles encoding or performs better? I'm thinking about getting a WinTV GO, but I'm unsure as to whether there's a "better" card out there.
20:49<Chutt>the tv card doesn't have anything to do with encoding
20:49<TrekCycling>I thought there were tv cards that had encoders also, though. Like the WinTV PVR.
20:49<Chutt>not supported in linux yet
20:50<TrekCycling>Either way, are there cards better at buffering or whatever? Or all are they all basically the same, quality-wise.
20:52<Chutt>go use google to do some research
20:52<TrekCycling>I know how to use google, I just thought I'd ask if anyone had any experience with a good quality tv card.
20:55-!-Edgan [] has quit [Remote closed the connection]
20:55-!-Justin_ [~justin@H233-225.STATE.RESNET.ALBANY.EDU] has joined #mythtv
21:25-!-rcaskey [] has joined #mythtv
21:25* rcaskeywhews and finally got videolan working
21:26<rcaskey>I cant believe it streams over 802.11b this well
21:35<-- TrekCycling( has left #mythtv ("Client Exiting")
21:42<poptix>what are you using videolan for?
21:43<rcaskey>it was working, but then I killed the client, and restarted it, and it ceased to work during tha time period
21:43<poptix>you should check out
21:43<rcaskey>i use myth
21:43<rcaskey>but my cable is downstairs
21:43<rcaskey>and im up here
21:43<poptix>oh, this is #mythtv
21:44* poptixthought this was his #wireless window
21:44<rcaskey>poptix: hehe, if your a wireless guru, maby you can tell me why wlan drivers keep dying on me
21:45<poptix>what kind of wireless card?
21:46<poptix>using the linux-wlan drivers?
21:47<Chutt>i have 2 dead prism2 cards sitting here
21:47<Chutt>they're crap =)
21:47<rcaskey>Chutt: yeah.
21:47<poptix>they aren't crap =p
21:47<rcaskey>Chutt: Is it possible that Myth could eventually function as a videolan frontend?
21:48<rcaskey>Fundamental architectural differences/
21:48<Chutt>pretty much
21:48<Chutt>why would you want it to, though?
21:48<rcaskey>Chutt: Videolan seems to be low enough bandwith to allow streaming over 802.11 and thats not going to be the case with Myth is it?
21:49<Chutt>mythtv'll be whatever bandwidth you tell it to be
21:49<Chutt>just like it always is
21:50<rcaskey>Chutt: I tried to fund the applicable emails on the listserv but kinda failed. Will the backend store the data or will that be the job of the frontend
21:50<rcaskey>err doh
21:51<rcaskey>Chutt: I guess, how are duties divided up?
21:52<Chutt>there are searchable archives, you know
21:52<rcaskey>Chutt: clue me in on some keywords
21:53<Chutt>find it yourself
21:53<rcaskey>gee, thanks
21:54<Chutt>i'm really not inclined to help people that i have to repeat myself 3 times for before they listen to me
21:55<rcaskey>Chutt: I was listening, its just that there was another plausible explination given for my problem earlier and the solution fixed it...
21:56<rcaskey>I promise you I do not delight in recapitulation
21:59<rcaskey>thank you
22:01<rcaskey>btw, the users of redhat trying to use multiple machines might be better suited by commenting out skip-networking instead of adding skip-innodb
22:01<rcaskey>at least if its anything like debian and suse's defaults
22:01<Chutt>submit a patch to robert
22:03<poptix>what the hell
22:04<poptix>FX, TNT, and TNN are all three playing the exact same thing they played 2 hours ago
22:04<poptix>TNN/TBS, that is
22:06-!-Soopaman [] has joined #mythtv
22:53<moegreen>Chutt: If I'm watching a recording then hit exit, my frontend gives a 'Changing from None to None' and then the frontend stops responding to the remote...however if I let the recording go until the end, I can continue to use the frontend normally. I started noticing this about 3 days ago
22:53-!-Edgan [[] has joined #mythtv
23:06<Soopaman>would 2 analogue tv tuners amount to the same amount of bandwidth as a single hdtv tuner/
23:23<mdz>looks like Chris Pinkham has a strong lead on that libavcodec crash
23:25<Chutt>just needs to figure out how the hell that's managing to get set the same
23:25<mdz>Joseph A. Caputo seems to be volunteering to maintain mythvideo
23:25<Soopaman>mdz, chutt, would 2 analogue tv tuners amount to the same amount of bandwidth as a single hdtv tuner/
23:31<Chutt>mdz, it certainly seems that way to me
23:31<Chutt>soopaman, i dunno, do the math
23:42-!-Soopaman [] has quit []
23:42-!-bigguy [] has quit []
23:42-!-Justin_ [] has quit []
23:42-!-vidar [] has quit []
23:42-!-mdz [] has quit []
23:42-!-Edgan [] has quit []
23:42-!-paperclip [] has quit []
23:42-!-yebyen [] has quit []
23:42-!-lichen_ [] has quit []
23:42-!-moegreen [] has quit []
23:42-!-lichen [] has quit []
23:42-!-shad_ [] has quit []
23:42-!-Chutt [] has quit []
23:42-!-poptix [] has quit []
23:42-!-aw [] has quit []
23:42-!-Z11 [] has quit []
23:42-!-hurdel [] has quit []
23:42-!-jfm [] has quit []
23:42-!-rcaskey [] has quit [Connection reset by peer]
23:42-!-rkulagow_ [] has quit [Nick collision]
23:42-!-rkulagow_ [~rkulagow@] has joined #mythtv
23:42-!-Edgan [[] has joined #mythtv
23:42-!-Soopaman [] has joined #mythtv
23:42-!-Justin_ [~justin@H233-225.STATE.RESNET.ALBANY.EDU] has joined #mythtv
23:42-!-bigguy [] has joined #mythtv
23:42-!-poptix [] has joined #mythtv
23:42-!-aw [] has joined #mythtv
23:42-!-Z11 [] has joined #mythtv
23:42-!-paperclip [] has joined #mythtv
23:42-!-hurdel [] has joined #mythtv
23:42-!-yebyen [] has joined #mythtv
23:42-!-vidar [] has joined #mythtv
23:42-!-mdz [] has joined #mythtv
23:42-!-Chutt [] has joined #mythtv
23:42-!-lichen [] has joined #mythtv
23:42-!-moegreen [] has joined #mythtv
23:42-!-lichen_ [] has joined #mythtv
23:42-!-shad_ [] has joined #mythtv
23:42-!-jfm [] has joined #mythtv
23:59<Chutt>watchpoints in gdb really eats cpu, doesn't it?