MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (86):

aloril, amessina, anykey_, brfransen, CaCtus491, caelor_, Captain_Murdoch, Chutt, Cougar, damaltor, dblain, dekarl, foxbuntu, gary_buhrmaster, gpd, gregL, J-e-f-f-A, jams, jarle, joki, jpabq, jstenback, kc, kenni, knightr, kwmonroe, laga, mag0o, malelan2, monkeypet69, mrand, MythBuild, MythLogBot, NightMonkey, Peps, pheld, poptix, rhpot1991, seld, Sharky112065, sraue, suffice, sunkan, sutula, taylorr, tgm4883, toeb, tris, Vernon_at_work, Yanch0, _charly_, Anssi, Beirdo, clever, coling, dinamic|screen, eharris, ElmerFudd, ghoti, gigem, GreyFoxx, highzeth, joe___, jwhite, kurre2, markcerv, peitolm, purserj, Seeker`, Slasher`, SmallR2002_, sphery, stuarta, superm1, vallor, wagnerrp, wahrhaft, wolfgang, XDS2010_, xris, neufeld, pipopopo, Anoia, danielk22, sheppard, cecil_
Wednesday, September 12th, 2012, 00:01 UTC
[00:01:02] Mousey (Mousey!~r0dent_@ross154.net) has quit (Quit: Read Error: Connection reset by beer)
[00:11:45] pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has joined #mythtv
[00:51:06] sphery: stichnot: mfdb can't be storing originalairdate as 2012-09–14T00:00:00 , because it's a date field in the DB--meaning there is no time component (because it's reported by the provider, TMS, with no time component)... That's also why UTC doesn't make sense (as a particular date in a non-UTC time zone will always span 2 dates of UTC time)
[00:52:08] sphery: stichnot: and if you had to restart the backend twice a year, your underlying system is broken--I haven't restarted mine on any of the DST changes and have never missed a recording (and have even scheduled recordings of garbage that spanned DST change to verify everything worked)
[00:55:15] sphery: But, hey, now that we're a "sane application" (as any sany application stores times in UTC), instead of making users have to think twice a year about override rules to include start early/end late for any shows they might record that span the DST change (for all that quality 2am programming), we now get to worry about time zone issues affecting rules/shows/... every day of the year, so that's progress I guess. :)
[00:55:57] sphery: FWIW, I think the reason you thought mfdb is storing originalairdate as 2012-09–14T00:00:00 is because you're using some kind of function on the value in oad that's converting the date to a datetime
[01:10:48] dekarl (dekarl!~dekarl@p4FCEE77A.dip.t-dialin.net) has joined #mythtv
[01:12:16] dekarl1 (dekarl1!~dekarl@p4FCEEA32.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[01:20:42] brfransen (brfransen!~brfransen@64.179.141.163) has quit (Ping timeout: 252 seconds)
[01:22:43] brfransen (brfransen!~brfransen@64.179.141.163) has joined #mythtv
[01:24:00] pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has quit (Quit: pvr4me)
[01:35:49] bill6502: stichnnot: Just finished: http://www.mythtv.org/wiki/UTC with a category of glossary, and included the 16 tables and the columns changed in the UTC update, based on the '1300 series' in dbcheck.cpp. I'll add a link to it in the release notes.
[02:04:40] Ruler_Of_Heaven_ (Ruler_Of_Heaven_!~pipopopo@ip-83-101-33-248.customer.schedom-europe.net) has joined #mythtv
[02:06:10] pipopopo (pipopopo!~pipopopo@ip-83-101-33-91.customer.schedom-europe.net) has quit (Ping timeout: 252 seconds)
[02:35:05] neufeld` is now known as neufeld
[02:37:35] joki (joki!~joki@p54861C4D.dip.t-dialin.net) has quit (Ping timeout: 252 seconds)
[02:38:06] joki (joki!~joki@p54861BD3.dip.t-dialin.net) has joined #mythtv
[02:42:06] stichnot (stichnot!~stichnot@192.55.55.41) has joined #mythtv
[02:42:06] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:42:06] stichnot (stichnot!~stichnot@192.55.55.41) has quit (Changing host)
[03:15:13] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[03:21:17] andreax (andreax!~andreaz@p4FE64C95.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[03:23:57] brfransen (brfransen!~brfransen@64.179.141.163) has quit (Ping timeout: 260 seconds)
[03:27:14] brfransen (brfransen!~brfransen@64.179.141.163) has joined #mythtv
[04:29:58] dekarl (dekarl!~dekarl@p4FCEE77A.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[05:04:52] bill6502 (bill6502!~bill@2002:cdb2:1a2b:7cd3:9ef4:32ea:c6ea:200) has left #mythtv ()
[05:20:51] cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has quit (Ping timeout: 244 seconds)
[05:25:33] cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #mythtv
[05:35:30] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 264 seconds)
[05:49:15] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[05:54:18] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has joined #mythtv
[06:08:00] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[06:09:04] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has quit (Remote host closed the connection)
[07:27:12] dekarl (dekarl!~dekarl@p4FCEEB0F.dip.t-dialin.net) has joined #mythtv
[08:14:29] Ruler_Of_Heaven_ is now known as pipopopo
[10:01:55] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[10:18:15] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Quit: Gone)
[10:21:13] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[10:21:13] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[10:21:13] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[10:37:35] danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv
[10:42:44] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Quit: Gone)
[10:53:03] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[11:00:31] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[11:35:13] stuartm: I'm noticing something really strange with read speeds on my new SSD, they almost exactly halve if I start playback of a recording (from a distinct HDD)
[11:35:45] stuartm: it remains at that reduced rate even if I pause playback
[11:37:38] stuartm: exit and it rebounds back to the 'normal' speed, so what are we doing in the frontend or backend which might explain a severe performance impact on another drive?
[11:38:04] stuartm: danielk22: any thoughts? ^^
[11:40:13] stuartm: it's almost as though we're actively toggling something at kernel level when we read a file from disk
[11:47:32] Yanch0 (Yanch0!~mpulis@unaffiliated/yancho) has quit (Ping timeout: 248 seconds)
[11:56:07] Yanch0 (Yanch0!~mpulis@unaffiliated/yancho) has joined #mythtv
[11:57:01] danielk22: stuartm: Is your SSD backing /var ?
[12:00:25] Yanch0 (Yanch0!~mpulis@unaffiliated/yancho) has quit (Ping timeout: 246 seconds)
[12:03:40] stuartm: yes
[12:04:21] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[12:04:51] stuartm: I considered the DB, but we're not actually reading much while streaming a recording and nothing at all when paused?
[12:21:03] stuarta: reads should be fast off SSD regardless
[12:23:09] stuarta: stuartm: strace the frontend while paused and that'll tell you what syscall we are hitting
[12:24:38] sheppard (sheppard!~sheppard@shellbox.fastdns.ca) has joined #mythtv
[12:33:12] stuartm: http://pastebin.com/gCyhw3QC < while paused
[12:41:08] Sharky112065 (Sharky112065!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has quit (Read error: Connection reset by peer)
[12:41:09] Sharky-Sleep (Sharky-Sleep!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has joined #mythtv
[12:43:07] cecil_ (cecil_!~cesman@pool-108-0-54-134.lsanca.fios.verizon.net) has joined #mythtv
[12:43:30] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Remote host closed the connection)
[12:44:10] ** stuarta hmmms **
[12:45:58] stuartm: heh, UTC change has broken my user job, we're squirting out the starttime in localtime but mythcommflag expects UTC
[12:47:33] stuartm: not sure how to fix that in bash alone, or whether it's worth the hassle of performing conversions, maybe we want a %STARTTIMEUTC% arg
[12:48:48] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[12:59:29] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[13:06:10] danielk22: stuartm: Hmm, the afaik system events have had %XXXtime% & %XXXtimeutc% versions almost since day 1, the user jobs don't use the same code?
[13:07:30] danielk22: stuartm: From the syscalls it looks like all that is running is a Qt event loop.
[13:09:05] danielk22: The writev, recvfrom & poll are all for the event loop and the stat("/etc/localtime",...) is for a QDateTime::currentDateTime() call.
[13:10:26] danielk22: I'm not sure where the nanosleep call is coming from bit it wouldn't hit the disk either.
[13:10:34] Yancho (Yancho!~mpulis@78.133.73.59) has joined #mythtv
[13:10:34] Yancho (Yancho!~mpulis@unaffiliated/yancho) has joined #mythtv
[13:10:34] Yancho (Yancho!~mpulis@78.133.73.59) has quit (Changing host)
[13:11:57] stuartm: yeah, I didn't see any obvious there, could be the backend instead
[13:12:24] stuartm: danielk22: system events have *TIMEISO but not *TIMEUTC that I can see
[13:15:26] danielk22: stuartm: See ProgramInfo::SubstituteMatches(), I guess it's only for events where a ProgramInfo is involved.
[13:16:29] danielk22: XXX, XXXiso, XXXutc & XXXisoutc are substituted, where XXX is starttime, endtime, progstart, progend
[13:18:35] stuartm: ah ok, I was grepping for a complete string
[13:19:13] stuartm: I'll add those to the documentation on the wiki
[13:19:50] danielk22: stuartm: With the SSD perhaps a SATA controller issue? A google might tell or PCIe SATA controller to test that theory should be pretty cheap.
[13:20:23] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Remote host closed the connection)
[13:21:07] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[13:26:52] stuartm: danielk22: yeah, worth trying, it's not the end of the world but it's still a little strange – so far I'm only able to reproduce with MythTV and only when playing video
[13:27:03] stuartm: recording has an effect, but a much smaller one
[13:40:36] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Quit: Gone)
[13:43:10] danielk22: cppcheck wants m_lock to be assigned here "Member variable 'HLSStream::m_lock' is not assigned a value in 'HLSStream::operator='" which doesn't make any sense.
[13:43:45] danielk22: AFAIK this is the only place where it reports this, any ideas what makes this assignment different?
[13:45:23] danielk22: m_lock is mutable, so my only hypothesis is out.
[13:46:48] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[13:46:48] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[13:46:48] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[13:50:23] Sharky-Sleep is now known as Sharky112065
[13:50:25] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Client Quit)
[13:53:49] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[13:53:49] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[13:53:49] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[13:59:20] stuartm: interesting that toggling from AHCI to IDE mode also reduced read speeds to exactly 50% just as I'm seeing with playback
[14:09:37] zombor (zombor!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv
[14:09:37] zombor (zombor!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host)
[14:09:37] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[14:09:44] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Quit: Gone)
[14:14:55] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[14:14:55] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[14:14:55] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[14:15:56] wagnerrp: !seen j-rod
[14:15:57] MythLogBot: j-rod was last seen 46 days 21 hours 1 minute 3 seconds ago
[14:16:38] cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has quit (Ping timeout: 244 seconds)
[14:16:39] wagnerrp: anyone recall why the BCM stuff was disabled for the 70012? http://code.mythtv.org/cgit/mythtv/commit/mythtv?id=6931d46c
[14:19:48] cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #mythtv
[14:23:47] stichnot: danielk22: do you recall which fields CC708Window::lock is supposed to protect? All of them? If so, there appear to be a number of unprotected accesses, more than http://code.mythtv.org/trac/attachment/ticket . . . w-text.patch attempts to fix.
[14:23:52] cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has quit (Ping timeout: 244 seconds)
[14:34:31] dekarl: sphery, its 2 times a year where all "record this" rules have to be fixed for the next three weeks (or whatever your guide carries) as all times past the switch point are off and will only be fixed once the swich point has been reached... At least thats what I had on my setup :(
[14:35:36] stuarta: the EIT guide data in the UK automatically accomodated DST changes
[14:36:53] stuartm: dekarl: SD only?
[14:37:01] dekarl: the XMLTV data over here did not
[14:37:10] gigem: dekarl: That sounds like a grabber or import problem. We never had that problem with Schedules Direct.
[14:37:28] stuartm: yeah, never had that with tv_grab_uk_rt either
[14:37:54] dekarl: likely due to only getting the offset for one point in time and applying it on all points in time (both pre and post the switch)
[14:38:35] dekarl: I have to look up the details if anyone is still interested, but I think its mostly of historic relevance now
[14:38:38] stuartm: dekarl: yeah, sounds like the grabber's at fault there
[14:38:51] dekarl: s/grabber/mfdb/ ;)
[14:39:02] stuartm: s/mfdb/grabber/
[14:39:30] dekarl: ok, I'll look it up later
[14:39:58] stuartm: mfdb doesn't apply a single offset to all dates (unless the user has configured a fixed offset, which is the setting I want rid off anyway)
[14:41:19] stuartm: it treats each date/time according to the offset specified with that date/time e.g. you can have "<date> <time> +01:00" alongside "<date> <time> +03:00" in the xml and it should handle both correctly
[14:42:35] stuartm: but that behaviour does depend on grabbers including the timezone as part of every datetime as the xmltv spec requires for non UTC times
[14:43:04] stuartm: "All dates and times in this DTD follow the same format, loosely based
[14:43:06] stuartm: on ISO 8601. They can be 'YYYYMMDDhhmmss' or some initial
[14:43:07] stuartm: substring, for example if you only know the year and month you can
[14:43:09] stuartm: have 'YYYYMM'. You can also append a timezone to the end; if no
[14:43:10] stuartm: explicit timezone is given, UTC is assumed."
[14:46:57] cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #mythtv
[14:53:53] stuartm: dekarl: actually, I may end up owing you an apology, the fromXMLTVDate() function is fishy
[14:54:21] gigem: Had anyone successfully used the 300 series nvidia drivers? Every time I've tried, I saw a corrupted video every few seconds and went back to version 295.53. I see there's a new long-lived branch version (304.43) out and am wondering if it's worth trying.
[14:54:52] cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has quit (Ping timeout: 244 seconds)
[14:56:47] dekarl: stuartm, no worries. I'm looking at the pre-UTC xmltvparser.cpp right now, too. and again, it just gives me headaches following the variants of XMLTV Timezone Auto vs. None.
[14:58:08] dekarl: I think we can agree on "it will only work with the default setting of None when the guide is from the same time zone as the machine is setup in" which rules out using tv_grab_co_uk in germany ;)
[14:58:15] stuartm: if we make 'Auto' the default we can clean that up
[14:59:01] stuartm: dekarl: any value other than 'Auto' is pointless post-UTC
[15:00:30] stuartm: if xmltv had used the ISO format we could have just dropped that straight into QDateTime without any of that messy parsing we have now
[15:01:18] dekarl: that's on "the list" for xmltvTNG, just use and xml datetime element
[15:01:44] dekarl: but I'll not have time for that this year :(
[15:03:04] dekarl: I'd rather convert the channel icons and xmltv grabber configuration over to SG and work on the configuration format.
[15:05:45] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[15:22:48] malelan2 (malelan2!~malelan@173-9-101-130-NewEngland.hfc.comcastbusiness.net) has joined #mythtv
[15:23:51] malelan (malelan!~malelan@173-9-101-130-NewEngland.hfc.comcastbusiness.net) has quit (Ping timeout: 246 seconds)
[15:25:00] danielk22: gigem: Captain_Murdoch: Chutt: I'm looking at porting MythSocket to the new Qt socket classes and I'm a bit confused.. Is the same socket used for ReadStringList & WriteStringList + the messages the MainServer::ProcessRequestWork() processes? It looks that way, and I don't think messages that arrive between a writeStringList() and readStringList() are handled correctly if this is the case.
[15:25:57] danielk22: i.e. if the two ends of a socket both do a writeStringList at the same time, what happens...
[15:26:15] Chutt: i thought that was a separate one
[15:26:30] Chutt: mainserver had a pool
[15:28:03] danielk22: Chutt: SendReceiveMessage() appears to have some code to handle BACKEND_MESSAGE, I don't see how that is needed if they are segregated nor why MythSocket::IsExpectingReply() would be needed..
[15:29:10] Chutt: i really wouldn't know details anymore =)
[15:30:26] gigem: danielk22: That's an area I have very little knowlege of, but my understanding is that the myth protocol was entirely synchronous. That means any async activity like messages were sent on a separate socket.
[15:30:38] Captain_Murdoch: this is why clients have 2 connections. one for sending commands to the MBE and receiving responses and then another one for receving events from the MBE.
[15:30:50] wagnerrp: not technically, but yes in practice
[15:31:08] wagnerrp: the server does support communications in both directions, but the client isnt supposed to do that
[15:31:25] Captain_Murdoch: so it's up to the client to make sure that the send/recv socket doesn't say it wants events on the send/recv socket
[15:32:15] Captain_Murdoch: it's either a playback socket (send/recv from client perspective) or a monitor socket (recv only for events from MBE to client)
[15:32:31] wagnerrp: thats one of the things i was planning on making mandatory in 0.27, when i start switching over to libmythprotoserver
[15:32:53] Captain_Murdoch: but I think both are in the socket list on the MBE, but when we want to send an event from the MBE, we cycle through looking for connections that want events.
[15:33:36] Captain_Murdoch: I'm not sure if there's anything in the backend to prevent sending commands over the monitor socket
[15:34:21] wagnerrp: no, i used to have the bindings configured to only use one socket for everything
[15:34:31] wagnerrp: and the locking to manage that became a bit of a mess
[15:35:23] danielk22: Ok, so for 0.27 I'll make it mandatory that commands can only be issued by one end of the mythsocket... That simplifies the code a fair bit..
[15:37:17] danielk22: Thanks for the info
[15:37:39] Captain_Murdoch: wagnerrp, if you try that, you'll run into the issue that Daniel is describing. that's why mythfrontend uses 2 sockets.
[15:38:20] Captain_Murdoch: you can't know that the MBE won't send an event when you're sending a command, unless you implemented locking within the protocol itself which would be a pain.
[15:38:52] wagnerrp: it "worked"... the problem was that if some event code errored out, it would terminate the shared connection and event handling thread, breaking things all over the place
[15:39:22] wagnerrp: all the errors should have been handled, and that shouldnt have happened... but it did anyway
[15:40:00] Captain_Murdoch: but how do you know an event is an event and not a result from the command unless you hard code a list of events and/or assume anything not a valid command result is an event.
[15:40:16] wagnerrp: events were always prepended with BACKEND_MESSAGE
[15:40:33] wagnerrp: if that were the case, it would just shuffle the string into a queue to be handled by the event thread
[15:40:44] ** Captain_Murdoch thought we had others, but can't recall off the top of his head. **
[15:41:05] wagnerrp: the event thread itself just woke up periodically on its own to check the socket for data
[15:41:07] Captain_Murdoch: been dealing with server side mainly, not client side.
[16:03:24] andreax (andreax!~andreaz@p4FE6496A.dip.t-dialin.net) has joined #mythtv
[16:22:57] stichnot (stichnot!stichnot@nat/intel/x-jktfftvyghgltzfe) has joined #mythtv
[16:22:57] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:22:57] stichnot (stichnot!stichnot@nat/intel/x-jktfftvyghgltzfe) has quit (Changing host)
[16:34:58] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has joined #mythtv
[16:41:29] 14WAAEJ00 (14WAAEJ00!~Goga777@2.95.240.146) has joined #mythtv
[16:41:29] 45PAA08PF (45PAA08PF!~Goga777@2.95.240.146) has joined #mythtv
[16:41:30] 45PAA08PF (45PAA08PF!~Goga777@2.95.240.146) has quit (Read error: Connection reset by peer)
[16:48:34] Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv
[17:01:54] 14WAAEJ00 (14WAAEJ00!~Goga777@2.95.240.146) has quit (Remote host closed the connection)
[17:03:22] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[17:07:45] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[18:29:00] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has quit (Remote host closed the connection)
[18:51:33] andreax (andreax!~andreaz@p4FE6496A.dip.t-dialin.net) has quit (Ping timeout: 255 seconds)
[19:39:23] Yanch0 (Yanch0!~mpulis@unaffiliated/yancho) has joined #mythtv
[20:50:10] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat)
[21:24:40] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[21:31:29] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[21:37:11] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds)
[22:13:55] stichnot (stichnot!~stichnot@134.134.139.76) has joined #mythtv
[22:13:55] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[22:13:55] stichnot (stichnot!~stichnot@134.134.139.76) has quit (Changing host)
[22:29:48] stuartm_ (stuartm_!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[22:29:48] stuartm_ (stuartm_!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[22:29:48] stuartm_ (stuartm_!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[23:13:28] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:16:54] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[23:34:13] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[23:37:25] Mousey (Mousey!~r0dent_@ross154.net) has quit (Ping timeout: 240 seconds)
[23:48:53] highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 245 seconds)
[23:50:16] highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv
[23:50:24] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.