| 00:02 | -!- | Timon [] has quit ["My damn controlling terminal disappeared!"] |
| 00:07 | -!- | Timon [~nunya@157-11-237-24.gci.net] has joined #mythtv |
| 00:10 | -!- | PeteCool [] has quit ["Client Exiting"] |
| 00:36 | -!- | Timon [] has quit [Read error: 104 (Connection reset by peer)] |
| 00:41 | <schwin97> | time to sleep |
| 01:00 | -!- | rkulagow [~Robert@12.207.131.29] has joined #mythtv |
| 02:35 | -!- | FredFunk [~bog@ip68-100-194-106.nv.nv.cox.net] has joined #mythtv |
| 02:37 | -!- | Soopaman_Hussien [~soopaman@h24-66-55-163.wp.shawcable.net] has joined #mythtv |
| 02:55 | -!- | rkulagow [] has quit [Read error: 110 (Connection timed out)] |
| 04:44 | -!- | FredFunk [] has quit [Read error: 60 (Operation timed out)] |
| 04:55 | -!- | FredFunk [~bog@ip68-100-194-106.nv.nv.cox.net] has joined #mythtv |
| 05:18 | -!- | choenig [~choenig@pD952CB2D.dip.t-dialin.net] has joined #mythtv |
| 05:40 | -!- | Soopaman_Hussien [] has quit [Read error: 60 (Operation timed out)] |
| 06:36 | <thor> | Chutt: you up |
| 08:55 | -!- | Bog [~bog@ip68-100-194-106.nv.nv.cox.net] has joined #mythtv |
| 08:57 | <Chutt> | thor, i'm awake now |
| 09:03 | -!- | FredFunk [] has quit [Read error: 60 (Operation timed out)] |
| 09:42 | <choenig> | and, Chutt, how is it about the scheduler stuff? |
| 09:43 | <choenig> | I will make the thing ip aware early next week, i think |
| 11:14 | -!- | Bog [] has quit [Read error: 110 (Connection timed out)] |
| 11:43 | -!- | FredFunk [~bog@ip68-100-194-106.nv.nv.cox.net] has joined #mythtv |
| 11:44 | <schwin97> | had a segfault when I tried to skip a commercial at the end of a recording |
| 11:44 | <schwin97> | is this being looked at or fixed already? |
| 11:44 | <Chutt> | get a backtrace |
| 11:44 | <schwin97> | will do... |
| 11:44 | <Chutt> | send it to the list, or if you know what you're doing, fix it and send a patch to the list |
| 11:49 | <schwin97> | sent the backtrace... Now will see if I can figure out what is going on |
| 11:52 | <schwin97> | is there a way to find out where the end of a recording is? |
| 11:52 | <Chutt> | yup |
| 11:57 | <schwin97> | and I'm guessing that is through totalFrames in NuppelVideoPlayer |
| 11:59 | <Chutt> | yup |
| 11:59 | <Chutt> | but that only works for files, there's another method for live tv stuff |
| 12:00 | <schwin97> | this happened with a recording so that is where I am looking first |
| 12:02 | <schwin97> | what is a method to print something on the osd... I see that you can do it with startpause, but that looks like you then need to unpause |
| 12:03 | <Chutt> | no, you don't |
| 12:21 | -!- | Edgan [] has quit ["Client Exiting"] |
| 12:40 | -!- | rkulagow [~Robert@12.207.131.29] has joined #mythtv |
| 12:43 | <rkulagow> | chutt, are you here? |
| 12:46 | <Chutt> | yup |
| 12:59 | <rkulagow> | sorry - on the other line with moegreen. have you considered setting the default resolution to 640x480 in setup? i set X for 640x480, but since the default is 800x600, i can't even see the "setup" option in mythfrontend to try to change the appearance, and even if i knew the settings, i'm making a lot of the blindly since practically everything is offscreen at the time. |
| 12:59 | <Chutt> | heh |
| 12:59 | <Chutt> | good call |
| 12:59 | <Chutt> | i'll change that |
| 13:01 | <rkulagow> | thanks. i was going to start on a fancy routine that determined the X parameters for height and width and automatically adjust, but that's hard, and setting the default to 640x480 is easy. |
| 13:01 | <Chutt> | i could just set the default to fullscreen |
| 13:02 | <rkulagow> | and that would be irrespective of the X width and height? |
| 13:02 | <Chutt> | it'd set it to whatever x was set to |
| 13:02 | <rkulagow> | ok. |
| 13:20 | <mdz> | Chutt: do you buy this LIRC/system clock stuff? |
| 13:20 | <Chutt> | i have no idea what it is |
| 13:21 | <rkulagow_> | i have no idea if it's system clock related, but i do know that i still have focus problems when irxevent sends an ESC (CurrentWindow seems to have the wrong focus) |
| 13:22 | <rkulagow_> | (this is on KDE 3.1, Click To Focus is set) |
| 13:22 | -!- | Timon [~nunya@157-11-237-24.gci.net] has joined #mythtv |
| 13:29 | -!- | chuckf [~chuckf@12-235-155-167.client.attbi.com] has joined #mythtv |
| 13:44 | <FredFunk> | rkulagow_ I've got the same problem |
| 13:45 | <FredFunk> | rkulagow_ strnage thing is the keyboard has the right focus (i can use the arrow keys still) but I need to use Alt-Tab to get irxevent's focus back |
| 13:46 | <mdz> | it's probably just a bug in irxevent that makes it not work sometimes |
| 13:48 | <Chutt> | heh |
| 13:48 | <Chutt> | lotsa people having problems with the neuros |
| 13:51 | <Chutt> | mdz, i added support for a recording profile that's the same name as the machine name for a quick hack in my last commit |
| 13:51 | <Chutt> | it'll just use that profile in preference to default/live-tv if it exists |
| 13:52 | <Chutt> | i need to decide if the slave backends should initiate connections with the master, or the other way 'round |
| 13:55 | <mdz> | Chutt: I had been thinking about creating a per-host setting containing the name of the profile to use for recordings, and one for live tv |
| 13:55 | <Chutt> | i just did this as an extremely quick hack |
| 13:55 | <mdz> | but I really have no use for it, so I haven't done anything about it |
| 13:56 | <mdz> | yeah, I know |
| 14:08 | <Timon> | Chutt, thanks for you help last night. I'm gaining a better grasp on pointers. |
| 14:27 | -!- | rkulagow [] has quit [Read error: 110 (Connection timed out)] |
| 14:49 | <Chutt> | can someone either help the "Systems Analyst" that's posting to mythtv-dev, or smack him around a bit for posting the same help request over and over and over |
| 14:49 | <Chutt> | i really don't care which =) |
| 14:49 | <Timon> | haha |
| 14:50 | <Chutt> | he's quite obviously linking against a qt that was compiled against a different version of gcc than what he's using to compile mythtv with |
| 14:51 | <Timon> | I just game him a simple answer. . . Switch to mandrake :-) |
| 14:51 | <Timon> | Actually, I should have said slackware =) |
| 15:12 | <mdz> | he's probably using slackware already; that's why he 's compiling everything |
| 15:13 | <Timon> | he said he was using deb. "Is it because I'm using a libqt3-dev package from debian?" |
| 15:14 | <mdz> | if he were running stable, it would work. If he were running unstable, it would work. he's obviously mixing things up and doesn't know how to handle it |
| 15:16 | -!- | Timon_ [~nunya@157-11-237-24.gci.net] has joined #mythtv |
| 15:16 | -!- | Timon [] has quit [Read error: 104 (Connection reset by peer)] |
| 15:16 | -!- | Timon_ is now known as Timon |
| 15:46 | -!- | paperclip [] has quit ["grits.. they aren't just for breakfast anymore"] |
| 15:47 | -!- | danc_ [~danc``@c66-235-37-121.sea2.cablespeed.com] has joined #mythtv |
| 16:13 | -!- | danc_ [] has quit [Read error: 104 (Connection reset by peer)] |
| 17:11 | -!- | rkulagow [~Robert@12.207.131.29] has joined #mythtv |
| 17:11 | -!- | chuckf [] has quit [Read error: 104 (Connection reset by peer)] |
| 17:13 | <rkulagow> | moegreen: i'm back, if you want to do anything. |
| 17:14 | <rkulagow> | ah, wait, nevermind. duty (baby) calls. |
| 17:57 | <mdz> | Chutt: is there any reason why bookmarking is disabled while watching a recording in progress other than that it doesn't have a seek table yet? |
| 17:58 | <Chutt> | that's the only reason |
| 17:58 | <mdz> | hmm |
| 17:58 | <mdz> | it would be useful if that worked |
| 17:58 | <mdz> | maybe it could ignore the bookmark on resume if there is no seektable? |
| 17:58 | <Chutt> | sure |
| 17:59 | <mdz> | does it work that way in order to handle old recordings, or potentially interrupted recordings? |
| 17:59 | <Chutt> | both, really |
| 17:59 | <mdz> | I guess it would have to print a warning or something if it allowed the user to do it |
| 18:00 | <mdz> | which isn't too nice |
| 18:00 | -!- | Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv |
| 18:00 | <mdz> | I've started seeing some choppiness when simultaneously recording and playing back, even though I have plenty of CPU available |
| 18:00 | <Chutt> | any reason why ScheduledRecording::signalChange is protected? |
| 18:00 | <mdz> | wondering if it's related to enabling the jitter stuff |
| 18:01 | <mdz> | but I can't save my place and change it to test, because I'm watching a recording in progress. which is why I asked :-) |
| 18:01 | <Chutt> | heh |
| 18:01 | <mdz> | I think I only meant for it to be called by member functions...is there some reason to do differently? |
| 18:01 | <Chutt> | i want to call it from the server code |
| 18:01 | <Chutt> | so i just removed the protected |
| 18:02 | <mdz> | won't break anything of course |
| 18:02 | <mdz> | I was just trying to keep all of the code that worked with the scheduling data in one place |
| 18:02 | <Chutt> | yeah |
| 18:02 | <mdz> | when I went to change it in the first place, it was hard to follow because it was spread out |
| 18:15 | <Chutt> | hrmph |
| 18:15 | <Chutt> | trying to make sure that the backend<->backend communication doesn't have that same bug in it |
| 18:16 | -!- | rkulagow [] has quit [Read error: 110 (Connection timed out)] |
| 18:46 | <mdz> | CPU is 42% idle, network is ~80% idle...something must be blocking somewhere |
| 18:46 | <Chutt> | yup |
| 18:46 | <Chutt> | try turning off the aggessive audio buffering if that's on |
| 18:47 | <mdz> | I should map the jump key to something |
| 18:47 | <mdz> | takes a long time to skip an hour into a recording using 30 second skips |
| 18:47 | <mdz> | I turned the aggressive audio buffering back on; it didn't work for me anyway |
| 18:47 | <mdz> | er, back off |
| 18:48 | <Chutt> | ok |
| 18:48 | <mdz> | heh, I have 3 of every setting in the settitgs table now |
| 18:48 | <mdz> | since I ran the frontend on my desktop |
| 18:49 | <mdz> | when it's playing an in-progress recording, does it go over the network or from the file? |
| 18:49 | <mdz> | (assuming the file is local) |
| 18:49 | <Chutt> | from the file |
| 18:49 | <Chutt> | er |
| 18:49 | <Chutt> | maybe not |
| 18:49 | <Chutt> | i think it's from the file, though |
| 18:49 | <mdz> | with the jitter stuff on, if anything, I'd think that the backend would be losing the cycles since it busywaits sometimes |
| 18:50 | <mdz> | but with almost half the CPU idle, I wouldn't think it would even matter |
| 18:50 | <Chutt> | it goes by the file, but gets some data from the network |
| 18:51 | <mdz> | same thing happened when I was watching an earlier recording while it was recording something else anyway |
| 18:53 | <mdz> | http://dijkstra.csh.rit.edu:8088/~mdz/mythtv/mythtv-net.png |
| 18:53 | <mdz> | shows network utilization for mythtv |
| 18:53 | <mdz> | using NFS |
| 18:53 | <Chutt> | heh |
| 18:53 | <mdz> | with a 3000kbs bitrate |
| 18:55 | <mdz> | all of the reads are done in the decoder thread, right? |
| 18:56 | <mdz> | maybe a buffer would help |
| 18:56 | <mdz> | and a reader thread |
| 18:56 | <Chutt> | yeah, it doesn't buffer raw disk reads |
| 18:56 | <Chutt> | qt buffers socket reads internally, though |
| 19:02 | <mdz> | maybe ringbuffer should just use a stdio stream or an fstream |
| 19:02 | <mdz> | rather than raw read()s |
| 19:02 | <mdz> | that might smooth things out |
| 19:05 | <mdz> | I think that buffers on input, not sure though |
| 19:08 | <mdz> | only up to 1k it seems |
| 19:08 | <mdz> | it should be reading bigger chunks than that anyway |
| 19:08 | <Chutt> | most of the time, yeah |
| 19:09 | <Chutt> | heh |
| 19:10 | <Chutt> | one little change to programinfo.h |
| 19:10 | <Chutt> | and the entire beast has to get recompiled |
| 19:14 | <mdz> | gcc 3.3 is coming to unstable soon |
| 19:14 | <mdz> | maybe it will have support for precompiled headers^H |
| 19:14 | <Chutt> | heh |
| 19:14 | <Chutt> | that's pretty funny |
| 19:15 | <mdz> | if I wanted to experiment with adding some buffering on that side, do you think it would make more sense to make the ringbuffer buffer reads, or to have the player buffer frames? |
| 19:16 | <Chutt> | ringbuffer buffer reads |
| 19:16 | <mdz> | it would be easier to move it into a separate thread in the player |
| 19:17 | <Chutt> | the player's frames are shared mem |
| 19:17 | <Chutt> | going to run out of them |
| 19:17 | <mdz> | I mean compressed frames |
| 19:17 | <Chutt> | hmm |
| 19:17 | <mdz> | separate from the existing buffer |
| 19:17 | <Chutt> | i think it'd be easier to have the ringbuffer buffer data |
| 19:17 | <mdz> | have one thread filling a buffer with compressed frames, then the main thread just taking each in turn and passing it to the decoder |
| 19:18 | <mdz> | hmm |
| 19:18 | <mdz> | the ringbuffer wouldn't know how far to buffer ahead |
| 19:18 | <mdz> | I guess a couple of megs would be ok in any case though |
| 19:18 | <Chutt> | right |
| 19:19 | <mdz> | there's no seeking unless the user requests it, right? |
| 19:19 | <mdz> | it won't seek to skip over data it doesn't want or such? |
| 19:19 | <Chutt> | no |
| 19:19 | <mdz> | hmm |
| 19:19 | <mdz> | it'd be easiest to ditch the buffer on a seek |
| 19:19 | <Chutt> | it'll seek to skip data, it'll seek to skip commercials |
| 19:19 | <Chutt> | it'll seek for a couple other reasons, too |
| 19:19 | <Chutt> | bad data in the stream, etc |
| 19:19 | <mdz> | if that only happens when it'll be seeking far, that's ok |
| 19:24 | -!- | Edgan [] has quit ["Client Exiting"] |
| 19:25 | -!- | Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv |
| 19:27 | <Chutt> | heh |
| 19:27 | <Chutt> | i hope people don't mind i've been committing broken code all day |
| 19:28 | <Chutt> | not that any of it should be getting called, but... |
| 19:30 | -!- | Edgan [] has quit ["Client Exiting"] |
| 19:34 | <mdz> | if they mind, they should be reading -commits |
| 19:34 | <mdz> | where I believe you said something like "this is probably all broken" |
| 19:35 | <Chutt> | true |
| 19:35 | <Chutt> | i did =) |
| 19:37 | <moegreen> | that's like expecting someone to read a file called README :) |
| 19:38 | <Chutt> | i'm going to go through and cull out unnecessary includes |
| 19:38 | <mdz> | which reminds me, I shouldn't cvs up before testing this stuff |
| 19:38 | <Chutt> | live-tv and playback of recordings works for me |
| 19:39 | <Chutt> | can i supress those warnings in settings.cpp? |
| 19:40 | <mdz> | yeah, looks like it'll be a while before I get around to actually using those classes |
| 19:40 | <mdz> | those methods anyway |
| 19:40 | <mdz> | they're for the recording editor |
| 19:41 | <Chutt> | right |
| 19:42 | <moegreen> | Chutt: I'll take out the unneeded includes from progfind |
| 19:44 | <mdz> | hmm |
| 19:44 | <mdz> | I'm eyeing this usleep(2000) in nuppelvideoplayer suspiciously |
| 19:44 | <Chutt> | moegreen, i'm going through all of them |
| 19:44 | <Chutt> | no worries |
| 19:44 | <Chutt> | progfind.h is 2 files away |
| 19:44 | <moegreen> | ok |
| 19:45 | <mdz> | when stracing the playback thread, once it gets spooled up, when it goes to sleep to let the buffer drain, it sometimes has to sleep twice |
| 19:45 | <mdz> | two 2ms sleeps in a row |
| 19:46 | <Chutt> | hmm |
| 19:46 | <mdz> | I wonder if a semaphore would be better |
| 19:46 | <mdz> | should be only one context switch I'd think |
| 19:47 | <mdz> | there are too many places it could be getting hung up; I need to figure out how to programmatically detect that this is happening so I can see what's going on |
| 19:47 | <mdz> | or catch it in the act somehow |
| 20:00 | <mdz> | if nothing else, buffered reads in ringbuffer would get rid of those 12-byte reads to get the headers |
| 20:03 | <mdz> | out of 44441 reads during my sample period, 22927 were only 12 bytes |
| 20:03 | <mdz> | that seems like significant system call overhead |
| 20:04 | <Chutt> | could just make all of the larger reads be size + 12 |
| 20:04 | <Chutt> | and store that in a buffer |
| 20:05 | <Chutt> | return the 12 bytes if the next read is a frame header |
| 20:05 | <Chutt> | or tack it on to the beginning if it's not |
| 20:05 | <Chutt> | that's kinda how the streaming stuff works |
| 20:08 | <mdz> | what streaming stuff? |
| 20:09 | <Chutt> | the remote frontend stuff |
| 20:09 | <mdz> | joshua bernstein has hosed his system |
| 20:09 | <Chutt> | the minimum blocksize it requests is 128k |
| 20:09 | <mdz> | oh, the remotefile stuff? |
| 20:09 | <Chutt> | so like 3 or 4 frames |
| 20:10 | <Chutt> | qt internally buffers it all |
| 20:11 | <mdz> | does the backend keep sending until the frontend tells it to stop? |
| 20:11 | <mdz> | or does the frontend do explicit reads? |
| 20:11 | <mdz> | I haven't looked at that code at all |
| 20:17 | <Chutt> | it does explicit reads, but in 128k chunks |
| 20:17 | <mdz> | ah |
| 20:17 | -!- | paperclip [~joe@ip68-11-30-173.no.no.cox.net] has joined #mythtv |
| 20:17 | <Chutt> | i should be more aggressive about triggering the next read |
| 20:18 | <Chutt> | but it's only right now when it doesn't have enough data in the buffer |
| 20:18 | <Chutt> | should be when it's less then 128/4 or whatnot |
| 20:19 | <mdz> | hmm, I just discovered setvbuf |
| 20:19 | <mdz> | (3) |
| 20:19 | <mdz> | how handy |
| 20:21 | <mdz> | it does exactly what I want with no extra work |
| 20:21 | <Chutt> | heh |
| 20:21 | <Chutt> | except changing to use file streams |
| 20:21 | <mdz> | I'm glad I found this before I implemented my own buffered i/o setup |
| 20:21 | <mdz> | yeah, already did that |
| 20:21 | <mdz> | only catch is I'm not sure if I have the LFS stuff right |
| 20:21 | <Chutt> | make sure you don't mess up the 64-bit stuff |
| 20:21 | <Chutt> | hah =) |
| 20:21 | <Chutt> | anyway, i'll bbl |
| 20:21 | <mdz> | we are using -D_FILE_OFFSET_BITS=64 now, right? |
| 20:22 | <mdz> | I think that makes fseek() act like fseek64() |
| 20:22 | <mdz> | easy enough to test |
| 20:22 | -!- | Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv |
| 20:44 | -!- | choenig [] has quit [Remote closed the connection] |
| 21:26 | <Chutt> | heh |
| 21:26 | <Chutt> | i fixed that bug with the frontend going away in the middle of watching livetv |
| 21:28 | <mdz> | I doubt that will make him go away |
| 21:29 | <mdz> | next he'll say that the frontend crashes if he kill -9s the backend |
| 21:30 | <Chutt> | which it probably does |
| 21:30 | <Chutt> | but the backend recovers gracefully if you kill -9 the frontend =) |
| 21:30 | <Chutt> | of cousre |
| 21:30 | <Chutt> | course |
| 21:30 | <Chutt> | you lose _all_ those shm segments if you kill the frontend |
| 21:31 | <Chutt> | so it's not too smart to do that |
| 21:33 | <mdz> | I did not realize until now that fseek took a long, and not an off_t |
| 21:33 | <mdz> | so they had to make fseeko and ftello |
| 21:33 | <mdz> | gross |
| 21:34 | <mdz> | I broke seeking somehow |
| 21:34 | <mdz> | even after fixing that |
| 21:34 | <Chutt> | do you ever need to flush those buffers? |
| 21:35 | <mdz> | something tries to read 539609505 |
| 21:35 | <mdz> | bytes |
| 21:35 | <Chutt> | yeah, you're getting off the boundaries |
| 21:35 | <mdz> | yep, sounds like it's reading a garbage header |
| 21:35 | <mdz> | I'm calling fseeko64 explicitly though |
| 21:35 | <Chutt> | well, what if it's not flushing those buffers of yours |
| 21:35 | <Chutt> | when you seek |
| 21:36 | <Chutt> | that'd make the first data read after a seek garbage, basically |
| 21:36 | <mdz> | all I'm doing is pointing stdio to a big buffer and telling it to use it instead of its internal buffer |
| 21:36 | <mdz> | so it should handle all that stuff the same way |
| 21:36 | <Chutt> | hmm |
| 21:36 | <Chutt> | i dunno |
| 21:36 | <mdz> | it also does it if I remove the setvbuf stuff |
| 21:36 | <mdz> | looking at strace, it seems to be calling llseek |
| 21:36 | <mdz> | is that the 64-bit one? |
| 21:37 | <Chutt> | believe so |
| 21:37 | <Chutt> | err |
| 21:37 | <Chutt> | no |
| 21:37 | <Chutt> | lseek64 is |
| 21:37 | <Chutt> | but, looks like the llseek syscall is the proper one |
| 21:37 | <mdz> | 5444 _llseek(11, 13250548, [13250548], SEEK_SET) = 0 |
| 21:37 | <Chutt> | takes two unsigned longs as an offset |
| 21:38 | <mdz> | the fact that both of those values are the same is suspicious |
| 21:38 | <mdz> | 13250548 doesn't sound like the offset of the seektable |
| 21:38 | <mdz> | maybe the top 32 bits |
| 21:39 | <mdz> | can you strace something real quick and see if it's the same syscall for you? |
| 21:43 | <mdz> | good news is, playback seems to be smooth while I'm recording |
| 21:43 | <mdz> | I hope it's as easy as this |
| 21:43 | <mdz> | nope |
| 21:43 | <mdz> | still doing it |
| 21:43 | <Chutt> | heh |
| 21:44 | <mdz> | can't hurt to do fewer reads though, assuming I can fix the seeking |
| 21:46 | <Chutt> | ah well |
| 21:46 | <Chutt> | gotta spend time with ye olde wife =) |
| 21:47 | <mdz> | I'm about to go out myself |
| 21:50 | <mdz> | I think a 1M buffer was too big, it would block too long reading |
| 21:50 | <mdz> | but a 100k buffer seems to work nicely |
| 21:53 | <mdz> | better anyway |
| 21:53 | <mdz> | seems to only get hung up every minute or two |
| 21:53 | <mdz> | instead of several times per minute |
| 21:54 | <mdz> | I assume that the reads from the buffer are returning quickly, and then once in a while it has to read new data in and that one is slow |
| 21:54 | <mdz> | there's probably a sweet spot |
| 21:54 | <mdz> | but it's going to relate to the bandwidth of the stream |
| 21:54 | <mdz> | so I think it really needs a reader thread |
| 22:07 | <rkulagow_> | moegreen, are you here? |
| 22:33 | -!- | justin [~justin@ool-18b81c6a.dyn.optonline.net] has joined #mythtv |
| 23:08 | -!- | Edgan [] has quit ["Client Exiting"] |
| 23:10 | -!- | rkulagow [~Robert@12.207.131.29] has joined #mythtv |
| 23:32 | <-- rkulagow | (~Robert@12.207.131.29) has left #mythtv |
| 23:45 | -!- | rkulagow [~Robert@12.207.131.29] has joined #mythtv |
| 23:47 | -!- | Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv |
| 23:56 | <Timon> | woohoo. . . I now understand pointers! |
| 23:59 | <bigguy> | you go, boy |
