--- | Log | opened Sat Jan 12 00:00:21 2008 |
00:14 | -!- | davilla [n=davilla@nc-65-41-43-142.sta.embarqhsd.net] has joined #mythtv |
00:37 | -!- | davilla [n=davilla@nc-65-41-43-142.sta.embarqhsd.net] has quit ["Leaving"] |
00:42 | -!- | okolsi [n=mythtv@62.142.251.131] has joined #mythtv |
00:48 | -!- | MavT [n=Maverick@111.86.233.220.exetel.com.au] has joined #mythtv |
00:51 | -!- | guest_ [n=guest@adsl-64-161-117-110.dsl.snfc21.pacbell.net] has quit [Client Quit] |
01:01 | -!- | ahbritto [n=guest@adsl-64-161-117-110.dsl.snfc21.pacbell.net] has joined #mythtv |
01:02 | -!- | cattelan_away is now known as cattelan |
01:03 | -!- | okolsi [n=mythtv@62.142.251.131] has quit [Read error: 110 (Connection timed out)] |
01:04 | -!- | ahbritto [n=guest@adsl-64-161-117-110.dsl.snfc21.pacbell.net] has quit [Client Quit] |
01:04 | -!- | ahbritto [n=guest@adsl-64-161-117-110.dsl.snfc21.pacbell.net] has joined #mythtv |
01:06 | -!- | MaverickTech [n=Maverick@111.86.233.220.exetel.com.au] has quit [Read error: 110 (Connection timed out)] |
01:13 | -!- | erik__ [n=fargod@c-216b72d5.020-77-6b73642.cust.bredbandsbolaget.se] has joined #mythtv |
01:17 | -!- | cattelan is now known as cattelan_away |
01:31 | -!- | XChatMav [n=Maverick@111.86.233.220.exetel.com.au] has joined #mythtv |
01:50 | -!- | MavT [n=Maverick@111.86.233.220.exetel.com.au] has quit [Read error: 110 (Connection timed out)] |
01:56 | -!- | tmk [n=tmk@c-69-181-135-225.hsd1.ca.comcast.net] has joined #mythtv |
01:56 | <tmk> | anyone around this evening? |
01:57 | * | tmk pokes Chutt |
02:05 | -!- | tmk [n=tmk@c-69-181-135-225.hsd1.ca.comcast.net] has quit ["Leaving"] |
02:33 | <clever> | xris: you there? |
02:35 | -!- | hachi [i=hachi@shego.kuiki.net] has joined #mythtv |
02:35 | <hachi> | the howto really... badly... in section 8 needs to mention that lirc_i2c is dead and... dead |
02:36 | <hachi> | I just wasted a week of my evenings trying to get lirc_i2c working... never finding any sign that it's not even what I'm supposed to use |
02:36 | <hachi> | following the mythtv instructions, checking the lirc docs and screaming when my kernel would panic or the module wouldn't even compile |
02:39 | <GreyFoxx> | nothing in that section seems to give specific details on your remote |
02:40 | <xris> | clever: ? |
02:40 | <GreyFoxx> | You still would want lirc installed |
02:40 | <GreyFoxx> | just using input events |
02:40 | <hachi> | yes, after a week someone finally told me this |
02:40 | <hachi> | and said it's on the v4l wiki |
02:41 | <hachi> | but why would I ever look on the v4l wiki to find out that lirc kernel modules are not what I need |
02:41 | <clever> | xris: hold on while i try and remember |
02:41 | <clever> | ahh yeah |
02:41 | <hachi> | I'm asking the person for where this sort of information comes from, but I haven't gotten any answers |
02:41 | <clever> | xris: when SD does start hosting the guide data would it be posible to dl the ENTIRE range your fetching in 1 big go? |
02:42 | <GreyFoxx> | I would think, though I've never looked at it, that the most logical place to look would be LIRC + the ivtv docs themselves. And IVTV was recently merged into the V4L/KErnel stuff |
02:42 | <hachi> | it HURTS to know that I've wasted a week on a problem that was perfectly solved, but I couldn |
02:42 | <clever> | 1 massive dl would probly go faster then 500 small downloads |
02:42 | <hachi> | 't get anyone in #mythtv-users (till now) or #debian, or couldn't find any matches with google or on the wiki |
02:43 | <xris> | clever: you can do that now |
02:43 | <xris> | that's a mythtv limitation. |
02:43 | <clever> | xris: currently mythfilldatabase appears to make a large number of wget calls |
02:43 | <clever> | and each needs multiple round trips before it even starts to fetch data |
02:43 | <xris> | yeah. that's mfdb |
02:43 | <xris> | because it wants to grab today+tomorrow+last-day-out |
02:43 | <xris> | instead of "everything" |
02:44 | <clever> | cant it get today+tomorow in 1 grab |
02:44 | <clever> | then 2days->14days in a 2nd grab |
02:44 | <clever> | in larger chunks |
02:44 | <clever> | but the zap2it servers are able to serve multiple days in a single query? |
02:45 | <GreyFoxx> | hachi: Dunno what to tell ya, if I had been paying attention one of the times you were asking I would have mentioned it, but just think of everything you got to learn along the way :) |
02:45 | <GreyFoxx> | clever: Yes |
02:45 | <clever> | ah |
02:45 | <GreyFoxx> | You tell it the start and endtime you want data for |
02:45 | <GreyFoxx> | mfdb just breaks it into daily chunks |
02:45 | <clever> | so its a defect within mfdb mostly |
02:46 | <clever> | any button on mfdb to make the chunks larger? |
02:46 | <hachi> | I'm trying to impart how important it is to have this information in the docs |
02:46 | <GreyFoxx> | clever: No |
02:46 | <clever> | :( |
02:46 | <GreyFoxx> | hachi: Then document it. Be part of the solution |
02:46 | <clever> | hachi: ir receiving with a pvr card? |
02:46 | <hachi> | yes |
02:46 | <GreyFoxx> | document it in the wiki |
02:46 | <clever> | hachi: which method? |
02:47 | <GreyFoxx> | submit a trac ticket (with a patch) if you feel something needs to be changed on that part of the sites docs |
02:47 | <hachi> | I don't even know anymore |
02:47 | <clever> | im using lirc_i2c |
02:47 | <hachi> | I've read so many different things that I have to forget now |
02:47 | <clever> | lol |
02:47 | <clever> | ive got a few minor bugs with lirc receiving |
02:47 | <clever> | certain buttons on the ui dont work right |
02:48 | <GreyFoxx> | back on topic : |
02:48 | <clever> | ok is properly connected to 'select' but some buttons seem to push in and get stuck in |
02:48 | <clever> | and then the remote is totaly ignored till i get up and hit enter on a keyboard |
02:48 | <GreyFoxx> | For any of you out there using a DSM based upnp player can you try it with recent trunk? Specifically video playback of avi files? |
02:49 | <GreyFoxx> | The one I have for testing keeps complaining about being unable to handle the codec in the file, but if I use ushare it plays the same file just fine |
02:49 | <clever> | no upnp players here anywhere |
02:49 | <clever> | only things using upnp are routers,mythtv,utorrent |
02:49 | <GreyFoxx> | and I've now changed libmythupnp to return as far as I can tell identical http headers and content but it still complains |
02:49 | <clever> | still ushare and clone its headers maybe |
02:50 | <clever> | sniff i mean |
02:50 | <GreyFoxx> | unfortuntely tomorrow I have to give my dad back his player :) |
02:50 | <GreyFoxx> | clever: been there done that |
02:50 | <clever> | lol |
02:50 | <clever> | i copyed the IE headers ages ago before i learned any of them |
02:50 | <clever> | caused some problems later on when i tried to dl a page that the server gzip'ed on me |
02:50 | <clever> | text only lib i made was claiming to accept gzip encoding:P |
02:53 | <clever> | damnit |
02:53 | <clever> | a livetv i set to not expire is missing |
02:53 | <clever> | auto expired:P |
02:53 | <clever> | 2008-01-12 03:40:26.328 autoexpire: Expiring Program: Expiring 7 MBytes for 1002 @ Sat Jan 12 03:35:00 2008 => Paid Programming |
02:53 | -!- | okolsi [n=mythtv@62.142.251.131] has joined #mythtv |
02:53 | <clever> | why must myth ignore what i tell it!!! |
02:54 | <GreyFoxx> | clever: move it to another recording group |
02:54 | <clever> | i'll have to do that after i record it |
02:55 | <clever> | if it doesnt expire it while im in the middle of moving it |
02:56 | <GreyFoxx> | hit Record while it's recoring an it should be automoved to the default recording group |
02:56 | <clever> | like that! |
02:56 | <clever> | i was 1 key away from putting it in default and it disapeared! |
02:57 | <clever> | there |
02:57 | <clever> | its in default now and set to not expire |
02:58 | <GreyFoxx> | how long was the recording ? |
02:58 | <clever> | <10 seconds |
02:58 | <GreyFoxx> | if it's under 2 minutes those get expired almost immediately |
02:58 | <GreyFoxx> | yeah |
02:58 | <clever> | just a sample of the horid quality of the tuner in the pvr150 |
02:58 | <clever> | but channels up near 45 are noticable better |
02:59 | <clever> | the cable goes from the poll to the corner of the house where it splits in 2 |
02:59 | -!- | gnome42 [n=gnome42@76-10-153-72.dsl.teksavvy.com] has quit [] |
02:59 | <clever> | no 3 |
02:59 | <clever> | one goes up to the living room and splits(one to the main digital box) |
02:59 | <clever> | the other goes to the computer desk where it splits again(one to the 2nd digital myth uses) |
03:00 | <clever> | and the last leg goes to the pvr150 itself |
03:00 | <clever> | 3 spliters and 4 cables in total from the poll to the pvr150 |
03:01 | <clever> | yet the digital tuner it normaly records thru is the exact same distance away and perfect quality |
03:01 | <clever> | (for SD) |
03:01 | <GreyFoxx> | the digital tuner likely is recording a digital version of the analog channel |
03:02 | <clever> | it isnt |
03:02 | <GreyFoxx> | here all analog channels have digital counterparts that the digital stb's use instead of the analog version |
03:02 | <clever> | if i pull the cord out of the digital box while on a 'analog' channel |
03:02 | <clever> | it goes to plain old static |
03:02 | <clever> | if i rip it out on a 'digital' channel it freezes |
03:02 | <clever> | posibly with some mpeg macroblocks messed up |
03:03 | <GreyFoxx> | fun |
03:03 | <clever> | i can also feed in a channel3/4 from a game console |
03:03 | <clever> | and put it on 3 |
03:03 | <clever> | and it pulls the analog 3 without a problem |
03:04 | <clever> | some cochannel problems are also visible on 5 with the pvr150 |
03:07 | <clever> | GreyFoxx: and how much work would it be to allow overlaping recordings on the same channel+input? |
03:11 | -!- | purserj [n=purserj@k-sit.com] has quit [Remote closed the connection] |
03:11 | -!- | purserj [n=purserj@k-sit.com] has joined #mythtv |
03:49 | -!- | kvandivo [n=kvandivo@adsl-76-199-7-235.dsl.chmpil.sbcglobal.net] has quit [Remote closed the connection] |
03:49 | -!- | kvandivo [n=kvandivo@adsl-76-199-7-235.dsl.chmpil.sbcglobal.net] has joined #mythtv |
03:55 | -!- | loops [n=sean@bas7-london14-1242516584.dsl.bell.ca] has quit ["Leaving"] |
04:07 | -!- | ahbritto [n=guest@adsl-64-161-117-110.dsl.snfc21.pacbell.net] has quit [Client Quit] |
04:09 | -!- | ivor_ [n=ivor@kde/developer/ivor] has joined #mythtv |
04:15 | -!- | ivor [n=ivor@kde/developer/ivor] has quit [Read error: 110 (Connection timed out)] |
04:15 | -!- | jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"] |
04:16 | -!- | ivor [n=ivor@kde/developer/ivor] has joined #mythtv |
04:28 | -!- | ivor_ [n=ivor@kde/developer/ivor] has quit [Read error: 110 (Connection timed out)] |
04:51 | -!- | grokky [n=grokky@ppp59-167-169-11.lns1.mel4.internode.on.net] has joined #mythtv |
05:23 | -!- | xris [n=xris@xris.forevermore.net] has quit [] |
05:36 | -!- | beavis [n=beavis@drms-590c894f.pool.einsundeins.de] has joined #mythtv |
06:15 | -!- | MavT [n=Maverick@111.86.233.220.exetel.com.au] has joined #mythtv |
06:34 | -!- | XChatMav [n=Maverick@111.86.233.220.exetel.com.au] has quit [Read error: 110 (Connection timed out)] |
06:46 | -!- | grokky [n=grokky@ppp59-167-169-11.lns1.mel4.internode.on.net] has quit [] |
06:53 | -!- | beavis_ [n=beavis@drms-590d5f25.pool.einsundeins.de] has joined #mythtv |
07:05 | -!- | robthebob [n=rn114@robthebob.plus.com] has joined #mythtv |
07:09 | -!- | beavis [n=beavis@drms-590c894f.pool.einsundeins.de] has quit [Read error: 110 (Connection timed out)] |
07:19 | -!- | turbo [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has quit [Read error: 110 (Connection timed out)] |
07:51 | -!- | turbo [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has joined #mythtv |
07:56 | -!- | mru [n=mru@78-86-181-100.zone2.bethere.co.uk] has joined #mythtv |
08:12 | -!- | turbo [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has quit [Read error: 110 (Connection timed out)] |
08:17 | -!- | turbo [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has joined #mythtv |
08:27 | -!- | purserj [n=purserj@k-sit.com] has quit [Read error: 104 (Connection reset by peer)] |
08:27 | -!- | purserj [n=purserj@k-sit.com] has joined #mythtv |
08:45 | -!- | briand [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has joined #mythtv |
08:45 | -!- | robthebob [n=rn114@robthebob.plus.com] has quit [Read error: 113 (No route to host)] |
08:45 | -!- | rn114 [n=rn114@robthebob.plus.com] has joined #mythtv |
08:46 | -!- | turbo [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has quit [Read error: 110 (Connection timed out)] |
08:51 | -!- | \S2 [n=s2@host246-23-dynamic.0-87-r.retail.telecomitalia.it] has joined #mythtv |
08:51 | -!- | \S2 [n=s2@host246-23-dynamic.0-87-r.retail.telecomitalia.it] has quit [Remote closed the connection] |
08:52 | -!- | \S2 [n=s2@host246-23-dynamic.0-87-r.retail.telecomitalia.it] has joined #mythtv |
08:52 | -!- | RogerM [n=chatzill@212.247.248.179] has joined #mythtv |
08:53 | -!- | \S2 is now known as S2 |
09:10 | -!- | briand [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has quit [Read error: 110 (Connection timed out)] |
09:11 | -!- | briand [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has joined #mythtv |
09:36 | -!- | turbo [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has joined #mythtv |
09:37 | -!- | briand [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has quit [Connection timed out] |
09:37 | -!- | beavis [n=beavis@drms-590d5f25.pool.einsundeins.de] has joined #mythtv |
09:41 | -!- | beavis [n=beavis@drms-590d5f25.pool.einsundeins.de] has quit [Client Quit] |
09:49 | -!- | beavis_ [n=beavis@drms-590d5f25.pool.einsundeins.de] has quit [Remote closed the connection] |
10:04 | -!- | Toxicity999 [n=bryan@unaffiliated/Toxicity999] has quit [Read error: 113 (No route to host)] |
10:05 | -!- | Toxicity999 [n=bryan@unaffiliated/Toxicity999] has joined #mythtv |
10:09 | -!- | Dibblah [n=Dibblah@80-192-14-169.cable.ubr02.dund.blueyonder.co.uk] has quit [Read error: 113 (No route to host)] |
10:11 | -!- | viz1 [n=Administ@c-71-58-216-245.hsd1.nj.comcast.net] has joined #mythtv |
10:29 | -!- | Toxicity999 [n=bryan@unaffiliated/Toxicity999] has quit [Read error: 104 (Connection reset by peer)] |
10:33 | -!- | Toxicity999 [n=bryan@unaffiliated/Toxicity999] has joined #mythtv |
10:38 | -!- | Dibblah [n=Dibblah@80-192-14-169.cable.ubr02.dund.blueyonder.co.uk] has joined #mythtv |
10:53 | -!- | superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv |
10:55 | -!- | PointyPumper [i=Pintlezz@OL162-112.fibertel.com.ar] has quit [Read error: 104 (Connection reset by peer)] |
11:00 | -!- | dekarl [n=deKarl@dslb-084-058-073-105.pools.arcor-ip.net] has joined #mythtv |
11:02 | <gbee> | sphery: the backend crashing from http requests, I've completely forgotten what you found when looking at that the other week? |
11:04 | -!- | turbo is now known as briand |
11:05 | -!- | dekar1 [n=deKarl@dslb-084-058-077-249.pools.arcor-ip.net] has quit [Read error: 60 (Operation timed out)] |
11:10 | <janneg> | GreyFoxx: upnp playback of recordings seems to be broken on the ps3 |
11:11 | <mru> | to elaborate on that, it starts receiving the TS, but almost instantly, without displaying any video, declares that "The data is corrupted" |
11:12 | <laga> | didn't get that broken by a firmware update? |
11:13 | <mru> | I suspected it could be a firmware thing too |
11:13 | <mru> | but the ps3 isn't too happy about downgrading... |
11:19 | <janneg> | mru: it seems to be a bug in the 2.10 firmware: http://mythtv.org/pipermail/mythtv-dev/2007-December/059011.html |
11:20 | <janneg> | mpeg4 streaming over upnp works according to one post in that thread |
11:20 | <mru> | avi files play fine here |
11:21 | <janneg> | but I doubt mythtv's nuv files will play |
11:21 | <mru> | mpeg4 is a bit ambiguous... |
11:21 | <gbee> | mpeg4 part 14 |
11:22 | <janneg> | mpeg4 part 2 |
11:22 | <janneg> | part 14 is h264 aka AVC |
11:23 | <mru> | the curious thing is, if I dump the data stream with tcpdump, and save it on a flash stick, the resulting 2-second TS fragment plays perfectly fine on the ps3 |
11:23 | <janneg> | s/14/10/ |
11:23 | <gbee> | err, yeah, getting the two confused ;) |
11:23 | <mru> | part 14 is the mp4 file format |
11:23 | <gbee> | or three, part 14 is the container ... |
11:24 | <mru> | like I said, mpeg4 is an ambiguous term |
11:24 | <gbee> | aye |
11:24 | -!- | gnome42 [n=gnome42@76-10-153-72.dsl.teksavvy.com] has joined #mythtv |
11:25 | -!- | Dave123 [i=nobody@cpe-72-230-182-200.rochester.res.rr.com] has quit ["Leaving"] |
11:29 | <mru> | the copy trick works here too |
11:29 | -!- | cattelan_away is now known as cattelan |
11:30 | <mru> | I guess it's just a matter of waiting for a fix from sony |
11:32 | <janneg> | mru: btw libavcodec's bitrate management does not happen to be one of your development subjects? |
11:33 | <mru> | I'm afraid not |
11:33 | <janneg> | the mpeg4 encoder does not adhere to the requested bitrate |
11:33 | <janneg> | and outputs streams witrh almost double bitrate |
11:33 | <mru> | did you set qmax or lmax? |
11:33 | -!- | rn114 [n=rn114@robthebob.plus.com] has quit [Read error: 104 (Connection reset by peer)] |
11:34 | -!- | rn114__ [n=rn114@robthebob.plus.com] has joined #mythtv |
11:34 | <mru> | you can't do that if you want rate control to work |
11:34 | <mru> | you also need to set a vbv buffer size |
11:34 | <janneg> | I think so, but I'll check |
11:34 | <mru> | rc_buffer_size or something |
11:35 | <mru> | I recommend experimenting with the ffmpeg command line until you have something that works, then apply the same settings in your code |
11:40 | <janneg> | ffmpeg command line works. I'll compare the options. thanks so far |
11:41 | <gnome42> | Hi janneg, I've seen reference to that double bitrate problem but don't think I've ever seen it here. Is there something that triggers that? |
11:42 | <janneg> | gnome42: I can reproduce it with a mpeg4 transcode |
11:42 | <gnome42> | oh, transcoding. I was thinking just soft encode |
11:44 | <janneg> | I have no framegrabber installed but there shouldn't be a difference |
11:48 | <gnome42> | checking my current files I have roughly 20 mpeg4 files going back to Dec. 2006 and the sizes don't look abnormal too me. |
11:48 | -!- | PointyPumper [i=Pintlezz@OL162-112.fibertel.com.ar] has joined #mythtv |
11:48 | -!- | PointyPumper [i=Pintlezz@OL162-112.fibertel.com.ar] has quit [Remote closed the connection] |
11:51 | <gnome42> | I use v4l2 api instead of v4l, but I don't think I changed anything in the encoder. |
11:52 | -!- | Dave123 [i=nobody@cpe-72-230-182-200.rochester.res.rr.com] has joined #mythtv |
11:54 | <gnome42> | janneg: Let me know if I can check anything for you. |
11:59 | -!- | Syphn [n=canadabo@fctnnbsc15w-156034084120.nb.aliant.net] has joined #mythtv |
12:00 | * | gnome42 tries a mpeg2 -> mpeg4 transcode |
12:03 | <gbee> | if anyone is interested in fixing the mjpeg playback issue in #4275 I'd appreciate it, I'd like to commit a patch to allow mythgallery use of the internal player but since mjpeg is a common format for camera to use there is little point until the internal player can handle them |
12:10 | <gnome42> | gbee: I would if I could :) |
12:11 | <gbee> | thanks gnome42 ;) |
12:11 | <gnome42> | yeah, I'm very helpful |
12:12 | <gnome42> | gbee: I assume you got the player working from the gallery? (for other formats) |
12:12 | <gbee> | I would too if I had time between now and 0.21 to learn the ins and outs of ffmpeg and the possible areas of NVP which might be causing the problem |
12:13 | <gbee> | gnome42: actually no, I ran into a weird bug but I'm pretty sure that I'll fix that when I get a couple of hours to look at it |
12:14 | <gbee> | but the player can't handle these mpjeg files when used directly |
12:14 | <janneg> | gbee: I'll look at it |
12:15 | <gbee> | janneg: thanks, I appreciate that |
12:17 | <janneg> | I think I promised that already |
12:17 | <gnome42> | janneg: the transcoded file is abnormally large 1.2G -> 1.7G at 2200 bitrate |
12:17 | <gbee> | janneg: I think you did, sorry, I'd forgotten that |
12:18 | <janneg> | it's even my ticket |
12:18 | <gbee> | so it is ... now I feel stupid |
12:20 | <janneg> | I'll look at it tommorrow after hopefully solving the bitrate problem |
12:21 | <sphery> | superm1: Though I don't know which changeset fixed #4174, I'm certain that it's fixed in current trunk (but not in -fixes). If the user is using a miscellaneous status information script, though, the patch on #4381 is required (or the backend will crash). |
12:22 | <sphery> | gbee: I'm pretty certain that #4174 is fixed--HTTP requests from port 6544 will not cause the backend to crash. |
12:22 | <gbee> | sphery: ok, sorry for needing a reminder, guess my memory hasn't been too good lately |
12:22 | <sphery> | However, I don't know if the TCP check on port 6543 will cause a crash (that wouldn't surprise me). Perhaps someone using monit can test current trunk (with patch from #4381). |
12:23 | <sphery> | No problem. There's way too much going on to remember it all. |
12:24 | -!- | rn114 [n=rn114@robthebob.plus.com] has joined #mythtv |
12:24 | -!- | rn114__ [n=rn114@robthebob.plus.com] has quit [Read error: 104 (Connection reset by peer)] |
12:24 | * | sphery just lost mythtv-commits and tickets folders (and the reminders inside) on his IMAP server when he dropped the mouse connected to his laptop |
12:25 | <gbee> | ouch |
12:25 | <sphery> | the part that really annoys me (as the reminders will eventually become unimportant) is that I can't figure out where it went (if a delete, it somehow confirmed the delete, too)... |
12:26 | <gbee> | maybe that cautionary tale will finally make me setup a backup cron job for my imap mail folders |
12:26 | <sphery> | Yeah. I should probably do the same. |
12:27 | -!- | foxhunt [n=Richard@cazadelzorro.demon.nl] has joined #mythtv |
12:27 | -!- | tafsen [n=tafsen@61.89-20-231.enivest.net] has joined #mythtv |
12:28 | <gbee> | I'm using cached IMAP, so there are copies on the other machines I use to read my email, but I can't rely on that as a backup since any folders or mail deleted on the server will be deleted from the client the next time it connects |
12:28 | <sphery> | Do you by any chance know how monit does a TCP check on a port? I don't feel like installing monit, but I have a feeling that the port 6543 check will actually crash the backend, so with a command-line equivalent, I can check. |
12:29 | <sphery> | heh. my laptop was the only one with the local cache (so the worst one for it to happen on) |
12:30 | <sphery> | It really seemed more like a move (didn't see a confirm dialog), but I can't find the folders anywhere. I've been trying to reproduce the issue, but can't. |
12:32 | <superm1> | sphery, this being the case, backporting it seems like a moot point (as long as its fixed in trunk) |
12:33 | <sphery> | Yeah. It seems 0.21 might be out quickly enough it's not an issue. |
12:33 | <superm1> | i was planning on switching the hardy builds to trunk later this month |
12:33 | <superm1> | under the assumption that things should be ready by late march |
12:34 | <jams> | .21 will be released when duke nukem forever is. |
12:34 | <laga> | there was a new duke nukem forever trailer |
12:34 | <sphery> | we should make a teaser trailer for 0.21... |
12:34 | <laga> | *drools* |
12:34 | <superm1> | haha |
12:35 | <tafsen> | Are you guys working on making it possible to search in Video Manager? |
12:37 | <tafsen> | Because it really sux when you got a big libary |
12:42 | <janneg> | jams: I would even say 0.21 will be released before Duke Nukem Forever |
12:43 | <janneg> | I'm missing that for the "watch recordings" but haven't got around implementing something like search as you type |
12:44 | <sphery> | gbee: for #4460, rather than marking as a dup of #4174 (since #4460 is using TCP checks rather than HTTP requests), I'd ask for more info and have someone test TCP checks on each of the ports individually (at least 6543 and 6549) to see which cause crashes and/or deadlocks. Oh, and a good debug bt would be nice... ;) |
12:45 | * | janneg curses kmail which can't handle suspend to ram while being connected |
12:45 | <sphery> | It seems monit just does a select on the TCP port checks so I can write a little program to do that without monit, but it will probably be at least a month before I get a chance. |
12:45 | -!- | dash [n=washort@tesla.divmod.com] has joined #mythtv |
12:45 | -!- | dash [n=washort@tesla.divmod.com] has left #mythtv [] |
12:46 | <sphery> | (I have other myth things at higher priority.) |
12:47 | <jams> | sphery- what do you want checked? |
12:47 | <gbee> | sphery: feel free to make that request yourself, I'm happy to do it, but I'm sure no-one would mind if you did |
12:48 | <gbee> | I'd like to know whether the issue can be replicated with trunk, so many thinks have changed since 0.20 |
12:50 | <gbee> | things |
12:50 | <sphery> | jams: on #4360, someone reported what sounds like a deadlock when doing monit TCP checks on ports 2422 (mtd), 6543 (mbe), 6544 (mbe HTTP status), and 6549 (UPnP). I'd like someone to test each port individually to see which causes crashes/deadlocks. Ideally, the tester would be running current trunk with the patch on #4381 applied (and would be able to get a backtrace when it fails). |
12:50 | <gbee> | #4460 |
12:50 | <sphery> | oops, yeah. what he said |
12:51 | <jams> | so the patch is already in trunk or it must be applied? |
12:52 | <gbee> | not in trunk yet |
12:52 | <sphery> | The patch on #4381 needs applied. If you disable the miscellaneous status information script, testing without that patch is not a problem. |
12:53 | <sphery> | Oh, and really we only need a test on trunk, not on 0.20-fixes. |
12:54 | <jams> | i will see if the port checks can be added to my hobbit instance. |
12:56 | <sphery> | thx |
12:58 | <jams> | any mention of how long it takes to lock? |
12:58 | <sphery> | From my read of the ticket, it sounds like it happens really fast. |
12:58 | * | jams reads the ticket |
12:59 | <sphery> | which port are you trying first? I'd do the mtd port last (2422) |
13:00 | <jams> | i'm going to try them all at once to check that I can reproduce it. then go from there |
13:00 | <sphery> | that's a /very/ good idea. :) |
13:00 | <jams> | how does one didable the miscellaneous status script? |
13:02 | * | gbee updates his checkout of multirec |
13:02 | <jams> | disable |
13:02 | <sphery> | make sure there's no script name in "Miscellaneous Status Application" in mythtv-setup (by default there is none). If you want to check via MySQL, ensure SELECT data FROM settings WHERE value = 'MiscStatusScript'; returns a blank string |
13:02 | <jams> | thx |
13:03 | <jams> | yep it's empty |
13:03 | <sphery> | Cool. Then you won't get hit with the bug in the misc. status stuff. |
13:04 | <jams> | just did a fresh test install, so you had decent timing. |
13:04 | -!- | tafsen [n=tafsen@61.89-20-231.enivest.net] has quit ["Konversation terminated!"] |
13:05 | -!- | Bullzeye [n=od@pD9E67DA0.dip.t-dialin.net] has joined #mythtv |
13:11 | <sphery> | jams: any deadlocks? |
13:11 | <jams> | not yet |
13:12 | <jams> | still working on adding mtd though |
13:12 | <sphery> | According to http://svn.mythtv.org/trac/ticket/4174#comment:5 , the TCP check issue may actually be fixed in trunk, too. |
13:13 | <sphery> | I'm starting to think--based on that and your testing--that #4460 can be closed (fixed in trunk/won't fix 0.20.2) |
13:14 | <jams> | had the wrong port for mtd..but it's going now |
13:15 | <sphery> | Sorry. Didn't look it up--just went on what the ticket said. |
13:16 | <jams> | just going to let this run for a bit. it does a check every 5 minutes. |
13:18 | <sphery> | Ooops. Ticket was right. I can't type. |
13:18 | <jams> | yeah i noticed that but wasn't going to say anything |
13:18 | <jams> | ;) |
13:18 | <mru> | would you like a copy of my lighttpd configuration for mythweb? I see the sample is still blank in svn |
13:19 | <sphery> | Wow, you're doing the test for me and not correcting me when I'm wrong. You're way too kind. |
13:19 | -!- | S2 [n=s2@host246-23-dynamic.0-87-r.retail.telecomitalia.it] has quit [Remote closed the connection] |
13:19 | <sphery> | mru: attach it to a ticket with component MythWeb ( http://svn.mythtv.org/ ) |
13:20 | <gbee> | just seen an new error, watching a recording and halfway through it exits with "Failed to reinit video" |
13:20 | <gbee> | s/an/a/ |
13:21 | <gbee> | looks like the video was corrupted at that point, can seek past it and everything is fine ... |
13:22 | <jams> | oops this test is invalid. |
13:22 | <sphery> | ? |
13:22 | <jams> | i'm only scanning the output of netstat..not really actively hitting the ports |
13:22 | <jams> | i will fix that and get back to you |
13:23 | <sphery> | oh. monit does a select. Is that an option with hobbit? |
13:23 | <jams> | i would have to write the test |
13:24 | <sphery> | "monit will open a connection to this port (TCP or UDP) and check that it is possible to send and recieve data from the port (via the select system call or test for an ICMP error in case of udp) |
13:24 | -!- | reynaldo [n=rverdejo@190-82-41-140.adsl.cust.tie.cl] has quit ["leaving"] |
13:24 | <sphery> | It seems the nagios check_tcp does a similar thing |
13:24 | -!- | reynaldo [n=rverdejo@190-82-41-140.adsl.cust.tie.cl] has joined #mythtv |
13:28 | <jams> | found the spot. |
13:28 | <jams> | one moment while i add everything in. |
13:32 | -!- | jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv |
13:33 | <jams> | actively checking the ports, now to wait |
13:34 | -!- | reynaldo [n=rverdejo@190-82-41-140.adsl.cust.tie.cl] has quit ["leaving"] |
13:39 | <gbee> | and wait ... |
13:39 | <sphery> | I compiled (didn't install) nagios, and have it running check_tcp against 6543 in a loop, and it's not locking (though it seems the response time is continually increasing) |
13:39 | <sphery> | It's probably hit it 10k times or so... |
13:40 | <sphery> | up to 0.009s. Started at more like 0.00002s |
13:41 | <sphery> | 0.01s |
13:41 | <gbee> | not sure I see the need for monitoring post 0.21, I can't remember the last time my backend crashed, must be at least 8/9 months |
13:44 | <sphery> | Yeah, but some seem to monitor everything. I don't monitor and my system is rock-solid stable (after I finally gave up on trying to make do and replaced a motherboard with a bad chipset--before and after that bad M/B, it's never had problems). |
13:45 | <sphery> | I was wondering if it was the check_tcp program causing the increased response time, but I stopped and restarted check_tcp and it resumed at the same response time. Restarted mbe, and the response time went back down. |
13:45 | <sphery> | I'm back to 0.01s |
13:46 | <jams> | sphery- it looks fine here. |
13:46 | <jams> | no increase in repsonse time no locks |
13:47 | <sphery> | cool |
13:49 | <sphery> | gbee: It sounds like #4460 should be closed as a dup of #4174 based on http://svn.mythtv.org/trac/ticket/4174#comment:5 and jams's tests with a comment that it won't be fixed in 0.20-fixes and that using a full HTTP request check against 6544 should be more stable in -fixes (though it may crash eventually) |
13:49 | <sphery> | heh... each time check_tcp hits the backend, it outputs: 2008-01-12 13:49:29.020 Unknown socket closing |
13:50 | <jams> | gbee- i only monitor cause it falls in line with other stuff i'm doing. Plus everybody loves graphs! |
13:50 | <jams> | sphery- yeah i see those to |
13:51 | <sphery> | log file is 2.5MB already and only 3834 bytes in other lines... :) |
13:52 | -!- | foxhunt [n=Richard@cazadelzorro.demon.nl] has quit [Read error: 110 (Connection timed out)] |
13:52 | <jams> | backend memory usage went up slightly with those checks running. |
13:52 | <jams> | i'm just going to let it run for a while. |
13:53 | <sphery> | Yeah. I'm seeing a slight increase, too. |
13:54 | <jams> | oh time to renew my linux pro subscription |
13:55 | <sphery> | I'll check to see the response time/whether it's deadlocked after mowing the lawn... |
13:57 | <jams> | mowing the lawn? sheesh mines covered with snow/ice |
13:58 | <mru> | mine would be covered in rain if I had one |
14:00 | <jams> | mru did you also open 4462? |
14:05 | <mru> | yes |
14:05 | <mru> | forgot to add my email address |
14:06 | <mru> | do as you wish with the patch; I figured recording the information somewhere might save someone else's hair being pulled out in the future |
14:07 | <sphery> | jams: Florida. Only have to mow 12mos/yr. :) |
14:10 | <mru> | now if only mythtv-setup would work over ssh... |
14:21 | <gbee> | sphery: is there an increase in memory usage as well, or cpu? |
14:22 | <gbee> | doh, didn't finish reading scroll back |
14:22 | <jams> | for me it was just memory, but that seems to have leveled off. |
14:27 | <gbee> | ok, good enough for me, I'll close the ticket as fixed |
14:28 | -!- | reynaldo [n=rverdejo@190-82-41-140.adsl.cust.tie.cl] has joined #mythtv |
14:28 | <gbee> | it may be spawning new threads to deal with concurrent requests and then reaching a limit on the number, but that's just speculation until I actually look at it |
14:29 | <gbee> | the increasing reponse time doesn't fit that theory, so maybe not |
14:35 | -!- | dekarl [n=deKarl@dslb-084-058-073-105.pools.arcor-ip.net] has quit [Read error: 54 (Connection reset by peer)] |
15:03 | -!- | feiner [n=feiner@12-214-64-245.client.mchsi.com] has quit [Read error: 110 (Connection timed out)] |
15:18 | -!- | xris [n=xris@xris.forevermore.net] has joined #mythtv |
15:22 | <gnome42> | janneg: A little something I noticed while cruising transcode.cpp http://zeke.yi.org/mythtv/fixes/mythtv_transcode_IDCT_IME_opts.diff |
15:46 | <sphery> | gbee: It was definitely increasing memory usage. I started at < 6% (of 512MB) RAM and when I killed the polling loop, it had gotten to 14.9%. |
15:46 | <sphery> | CPU was maxed at 100% (had been at about 60% when started), and was getting very small response time (0.0002s) about 4 times, then very large (1s) one time, repeating. |
15:47 | <sphery> | Memory increase seems to fit the thread leak theory. The response time was rising linearly when I first started, but seemed to have changed when the CPU maxed out. |
15:48 | <sphery> | But, now that I killed the tcp_check loop, it's running just fine--listening on 6543, clients can hit the backend and it serves things as fast as always and CPU has gone back to normal (almost nothing). |
15:49 | <sphery> | Granted, mine was a torture test (with millions of tcp_check pings), so it's not likely to be much of an affect on any real-world usage. |
15:53 | -!- | mattwire [n=mattwire@host81-158-236-197.range81-158.btcentralplus.com] has joined #mythtv |
15:56 | -!- | xris [n=xris@xris.forevermore.net] has quit [] |
15:56 | -!- | xris [n=xris@xris.forevermore.net] has joined #mythtv |
15:56 | <sphery> | If gdb would see all the leaked threads, it's not a thread leak--only 17 threads (which should be about right). So, perhaps just a mem leak in the code that handles the network. May have to valgrind it. |
16:07 | <gnome42> | janneg: No need to look at the "[mythtv-users] Live TV problem in multirec" thread. Problem was elsewhere. |
16:11 | -!- | feiner [n=feiner@12-214-64-245.client.mchsi.com] has joined #mythtv |
16:18 | -!- | _gnome42 [n=gnome42@206-248-176-190.dsl.teksavvy.com] has joined #mythtv |
16:19 | -!- | gnome42 [n=gnome42@76-10-153-72.dsl.teksavvy.com] has quit [Read error: 104 (Connection reset by peer)] |
16:21 | <sphery> | Hmmm. There are many places in mythtv-setup that no longer work at 800x600. |
16:22 | -!- | _gnome42 is now known as gnome42 |
16:23 | <jams> | just like the recent deinterlace screen doesn't fit 800x600 |
16:24 | <sphery> | Yeah. I'm sure mythfrontend settings has many, also. |
16:26 | <mru> | who would use 800x600 anyway? |
16:27 | <mru> | it's too high for an SD TV and lower than anything else |
16:29 | <sphery> | anything lower than 800x600 won't work, either (though IME the NVIDIA TV out did better with the GUI rendered at 800x600 or 1024x768) |
16:30 | <jams> | sphery- think the port test has run long enough? memory usage has levelled out and no deadlocks have occured |
16:32 | <mru> | sphery: it is possible to craft an X modeline that outputs a tv-compatible signal on the vga port |
16:32 | <sphery> | Yeah. I think closing #4460 is good--I'm much more comfortable saying so thanks to having your test as well as mine. So, thanks for helping. |
16:32 | <sphery> | I may look into whether I have found a mem leak, but it's low priority |
16:33 | <sphery> | mru: with drivers that work right... :) |
16:36 | -!- | inkynoo1 [n=stuporgl@72.8.105.46] has joined #mythtv |
16:36 | -!- | inkynoo1 [n=stuporgl@72.8.105.46] has left #mythtv [] |
16:37 | -!- | Bentley__ [n=Bentley@S010600179a41b083.cg.shawcable.net] has joined #mythtv |
16:38 | -!- | Bentley__ [n=Bentley@S010600179a41b083.cg.shawcable.net] has left #mythtv ["Leaving"] |
16:42 | <sphery> | Ooops. Guess mythtv-setup's fine at 800x600. Just the frontend settings that have issues. |
16:45 | -!- | erik__ [n=fargod@c-216b72d5.020-77-6b73642.cust.bredbandsbolaget.se] has quit ["Lämnar"] |
17:03 | <tuppa> | hi all, who's the best person to talk to with modifying OSD menu entries? |
17:09 | <sphery> | tuppa: what kind of mod? |
17:10 | <tuppa> | sphery: adding more entries in |
17:10 | <sphery> | that do what? |
17:10 | -!- | guest_ [n=guest@adsl-64-161-117-110.dsl.snfc21.pacbell.net] has joined #mythtv |
17:12 | <gbee> | tuppa: adding new entries is easy, it's what they do which might be harder and are you asking here because you want to write the code, or because you want someone else to do it? |
17:12 | <tuppa> | I'm looking at writing/changing the code myself |
17:13 | <tuppa> | just for experimenting around atm |
17:13 | <sphery> | If it's just adding things that are easily accessible through the keys, you may find resistance since the OSD menu is already huge enough. |
17:13 | <tuppa> | hmmm |
17:14 | <gbee> | from memory you want to look at osd.cpp/h and/or osdtypes.cpp/h in libmythtv |
17:14 | <tuppa> | gbee: thanks, will have a look there |
17:16 | -!- | jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"] |
17:20 | -!- | mattwire [n=mattwire@host81-158-236-197.range81-158.btcentralplus.com] has quit [Read error: 113 (No route to host)] |
17:22 | -!- | mattwire [n=mattwire@host81-158-236-197.range81-158.btcentralplus.com] has joined #mythtv |
17:28 | -!- | Syphn [n=canadabo@fctnnbsc15w-156034084120.nb.aliant.net] has quit [] |
17:38 | -!- | mattwire [n=mattwire@host81-158-236-197.range81-158.btcentralplus.com] has quit [Read error: 113 (No route to host)] |
17:40 | -!- | jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv |
17:43 | -!- | mattwire [n=mattwire@host81-158-236-197.range81-158.btcentralplus.com] has joined #mythtv |
17:47 | -!- | foxhunt [n=Richard@cazadelzorro.demon.nl] has joined #mythtv |
18:01 | -!- | mzb [n=ubernut@ppp108-88.static.internode.on.net] has quit ["Time to quit"] |
18:02 | -!- | mzb [n=ubernut@ppp108-88.static.internode.on.net] has joined #mythtv |
18:04 | -!- | mattwire [n=mattwire@host81-158-236-197.range81-158.btcentralplus.com] has quit [Read error: 110 (Connection timed out)] |
18:06 | -!- | mattwire [n=mattwire@host81-158-236-197.range81-158.btcentralplus.com] has joined #mythtv |
18:07 | -!- | davilla [n=davilla@nc-65-41-43-142.sta.embarqhsd.net] has joined #mythtv |
18:09 | -!- | foxhunt [n=Richard@cazadelzorro.demon.nl] has quit [Remote closed the connection] |
18:09 | -!- | RogerM [n=chatzill@212.247.248.179] has quit [Read error: 104 (Connection reset by peer)] |
18:17 | <gbee> | multirec crashed my backend :/ |
18:19 | -!- | Dibblah [n=Dibblah@80-192-14-169.cable.ubr02.dund.blueyonder.co.uk] has quit [Read error: 104 (Connection reset by peer)] |
18:22 | -!- | Dibblah [n=Dibblah@80-192-14-169.cable.ubr02.dund.blueyonder.co.uk] has joined #mythtv |
18:26 | -!- | mattwire [n=mattwire@host81-158-236-197.range81-158.btcentralplus.com] has quit ["Leaving"] |
18:39 | <gnome42> | gbee: misbehaving for you again? It was a bit of a train wreck last time too as I recall. :/ |
18:39 | -!- | grokky [n=grokky@ppp59-167-169-11.lns1.mel4.internode.on.net] has joined #mythtv |
18:39 | <gnome42> | got any info? logs etc. |
18:39 | <GreyFoxx> | gbee: crashed the process or the entire box died ? |
18:40 | <gbee> | the process |
18:40 | <GreyFoxx> | So far I've had no problems at all with it in months |
18:40 | <GreyFoxx> | hopefully it's something you can reproduce |
18:40 | <gbee> | gnome42: logs, I'll check that now and if I can reproduce it tomorrow I'll get a backtrace |
18:41 | <gbee> | dual tuner system, at the time two scheduled recordings were in progress and I was changing channels in livetv |
18:41 | <gnome42> | gbee: cool. No time ATM but I'll look later/tomorrow. |
18:43 | <gbee> | are the " seconds until" messages normal? log is full of them |
18:43 | <gnome42> | yeah, it's not perfect in that whole livetv while recording channel surfing area. But shouldn't crash obviously :) |
18:44 | <gnome42> | yeah daniel recently reenabled that debugging stuff |
18:44 | <gnome42> | not sure if he meant to or not though :) |
18:45 | <gnome42> | gotta run. |
18:46 | -!- | FyreFoX [n=fox@fyres.net] has joined #mythtv |
18:48 | <gbee> | log is worthless, I'll try to reproduce, a backtrace would be more valuable |
18:49 | <FyreFoX> | hi is there a way to make mythtv auto refresh the video list instead of having to goto setup/video manager each time .. ? |
18:49 | <sphery> | FyreFoX: try #mythtv-users |
18:50 | <FyreFoX> | oh. oh sorry! I didnt even read the topic. |
18:50 | -!- | FyreFoX [n=fox@fyres.net] has left #mythtv [] |
18:51 | <gbee> | one of the reasons I'd like to see multirec in trunk soon is so that there is more time to spot any problems with a wider test group |
18:53 | <gbee> | when trying to change to an unavailable channel you just get bounced to a previous channel with no explanation, shouldn't be hard to use the existing status container to flash up a "channel unavailable" message |
19:07 | -!- | jason [n=jason@70.116.85.193] has joined #mythtv |
19:07 | -!- | jason [n=jason@70.116.85.193] has left #mythtv ["Leaving"] |
19:08 | -!- | Bullzeye [n=od@pD9E67DA0.dip.t-dialin.net] has quit ["get satisfied! • :: ««« (Gamers.IRC) »»» ::"] |
19:09 | -!- | rn114 [n=rn114@robthebob.plus.com] has quit [Read error: 104 (Connection reset by peer)] |
19:09 | -!- | rn114 [n=rn114@robthebob.plus.com] has joined #mythtv |
19:46 | -!- | mzb [n=ubernut@ppp108-88.static.internode.on.net] has quit [Read error: 110 (Connection timed out)] |
19:48 | -!- | candrews [i=candrews@gateway/tor/x-070c51485bfbb5ef] has joined #mythtv |
19:51 | -!- | mzb_d800 [n=mzb@ppp108-88.static.internode.on.net] has quit ["Time to quit"] |
19:52 | -!- | mzb_d800 [n=mzb@ppp108-88.static.internode.on.net] has joined #mythtv |
19:53 | -!- | davilla [n=davilla@nc-65-41-43-142.sta.embarqhsd.net] has quit ["Leaving"] |
19:55 | <candrews> | I'm hoping one of you fine fellows will be able to help me complete the mythcontext restructure patch |
19:55 | <candrews> | unfortunately, my ninja skills are not terribly applicable to this build process. |
19:55 | <candrews> | The ticket is at: http://svn.mythtv.org/trac/ticket/4264 |
19:58 | <candrews> | don't all raise your hands at once :-) |
19:58 | <candrews> | Well, I'm dying to get this straightened away, as it prevents me from using Mythtv, and I'm sure it bugs lots of distro managers too. |
19:58 | <candrews> | I'm reachable on the mailing list, and there is some discussion there too. |
20:01 | -!- | Ice_Wewe [n=icewewe@ppp-216-106-96-38.storm.ca] has joined #mythtv |
20:01 | <Ice_Wewe> | can someone help me? I'm trying to run mythtranscode from the command line and it isn't properly detecting the aspect ratio. The aspect ratio on the original video is 4:3 and on the encoded it's 6:3 |
20:02 | -!- | reynaldo_ [n=rverdejo@190-82-56-55.adsl.cust.tie.cl] has joined #mythtv |
20:04 | -!- | MavT [n=Maverick@111.86.233.220.exetel.com.au] has quit ["Leaving"] |
20:10 | -!- | Ice_Wewe [n=icewewe@ppp-216-106-96-38.storm.ca] has left #mythtv ["Ex-Chat"] |
20:14 | -!- | reynaldo [n=rverdejo@190-82-41-140.adsl.cust.tie.cl] has quit [Read error: 110 (Connection timed out)] |
20:23 | -!- | briand [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has quit [Read error: 110 (Connection timed out)] |
20:24 | -!- | briand [n=brian@c-68-35-254-149.hsd1.fl.comcast.net] has joined #mythtv |
20:34 | -!- | reynaldo_ [n=rverdejo@190-82-56-55.adsl.cust.tie.cl] has quit ["leaving"] |
20:34 | -!- | reynaldo [n=rverdejo@190-82-56-55.adsl.cust.tie.cl] has joined #mythtv |
21:02 | -!- | jadams_ [n=jadams@97.82.24.182] has joined #mythtv |
21:02 | -!- | jadams_ [n=jadams@97.82.24.182] has left #mythtv ["Leaving"] |
21:24 | -!- | reynaldo [n=rverdejo@190-82-56-55.adsl.cust.tie.cl] has quit ["leaving"] |
21:25 | -!- | reynaldo [n=rverdejo@190-82-56-55.adsl.cust.tie.cl] has joined #mythtv |
21:41 | -!- | candrews [i=candrews@gateway/tor/x-070c51485bfbb5ef] has quit [Remote closed the connection] |
21:41 | -!- | rn114 [n=rn114@robthebob.plus.com] has quit [Read error: 113 (No route to host)] |
22:18 | -!- | grokky [n=grokky@ppp59-167-169-11.lns1.mel4.internode.on.net] has quit [] |
22:22 | -!- | beandog [n=sdibb@gentoo/developer/beandog] has joined #mythtv |
22:23 | -!- | guest_ [n=guest@adsl-64-161-117-110.dsl.snfc21.pacbell.net] has quit [Client Quit] |
22:31 | -!- | jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"] |
22:34 | -!- | mzb [n=ubernut@ppp108-88.static.internode.on.net] has joined #mythtv |
23:04 | -!- | jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv |
23:05 | -!- | jhatch [n=jhatch@azza.com] has joined #mythtv |
23:17 | -!- | rtsai [n=rtsai@76.191.146.183] has joined #mythtv |
23:30 | -!- | Chutt [n=ijr@dsl093-011-148.cle1.dsl.speakeasy.net] has quit [Remote closed the connection] |
--- | Log | closed Sun Jan 13 00:00:15 2008 |