Back to Home / #mythtv / 2008 / 03 / Prev Day | Next Day
#mythtv IRC Logs for 2008-03-17

---Logopened Mon Mar 17 00:00:30 2008
00:20-!-carvajal_ [n=carvajal@] has joined #mythtv
00:21-!-mkrufky [n=mk@unaffiliated/mkrufky] has quit [Read error: 104 (Connection reset by peer)]
00:26-!-carvajal [n=carvajal@] has quit [Read error: 110 (Connection timed out)]
00:58-!-fus10nx [n=fus10nx@] has joined #mythtv
01:18-!-rooau1 [] has joined #mythtv
01:18-!-rooaus [] has quit [Read error: 110 (Connection timed out)]
01:31-!-Captain_Murdoch2 [] has joined #mythtv
01:51-!-CDev_ [] has joined #mythtv
01:51-!-ireverentReveren [] has joined #mythtv
01:52-!-Netsplit <-> quits: eharris, CDev, jarle, jeffc91, sphery, packetscan, Ozymandias, visit0r, anykey_, _charly_
01:52-!-gnome42 [] has quit [Remote closed the connection]
01:52-!-Netsplit over, joins: packetscan
01:55-!-anykey_ [] has joined #mythtv
01:55-!-sphery [] has joined #mythtv
01:55-!-visit0r [] has joined #mythtv
02:06-!-jarle [] has joined #mythtv
02:07-!-_charly_ [] has joined #mythtv
02:10-!-ToadP [] has quit []
02:16-!-czth__ [n=dbrobins@nat/microsoft/x-79338ab276a2456b] has joined #mythtv
02:31-!-Captain_Murdoch2 [] has left #mythtv ["Leaving"]
02:31-!-Captain_Murdoch [] has joined #mythtv
02:33-!-czth_ [n=dbrobins@nat/microsoft/x-69bfa235a750a047] has quit [Read error: 110 (Connection timed out)]
02:34-!-grokky [] has quit [Read error: 110 (Connection timed out)]
02:45-!-runlevel [] has joined #mythtv
02:46<runlevel>i have sound but its very crackly and crappy sounding. can some one help me out? ive checked every setting possible that i could find.
02:48<cesman>runlevel: #mythtv-users
02:54-!-davilla [] has quit ["Leaving"]
03:17-!-fus10nx [n=fus10nx@] has quit []
03:18-!-aravind [] has joined #mythtv
03:29-!-Captain_Murdoch [] has quit ["Leaving"]
03:39-!-clever_ [] has joined #mythtv
03:41-!-clever [] has quit [Read error: 110 (Connection timed out)]
03:41-!-Captain_Murdoch [] has joined #mythtv
03:52-!-Cougar [] has quit [Remote closed the connection]
03:56-!-Cougar [] has joined #mythtv
04:15-!-mykeul [n=mykeul@] has joined #mythtv
04:23-!-xris [] has quit []
04:42-!-Captain_Murdoch [] has quit [Remote closed the connection]
04:46-!-media [n=media@] has joined #mythtv
04:48-!-Captain_Murdoch [] has joined #mythtv
04:58-!-grokky [] has joined #mythtv
05:03-!-reynaldo [] has quit [Read error: 110 (Connection timed out)]
05:06-!-media [n=media@] has quit [Remote closed the connection]
05:23-!-grokky [] has quit []
05:28-!-MaverickTech [] has joined #mythtv
05:30-!-kurre2___ [] has joined #mythtv
05:30-!-kurre2 [] has quit [Read error: 104 (Connection reset by peer)]
05:32-!-rosco [] has joined #mythtv
05:36-!-kurre2 [] has joined #mythtv
05:36-!-kurre2___ [] has quit [Read error: 104 (Connection reset by peer)]
05:40-!-grokky [] has joined #mythtv
05:42<janneg>gbee: the quotes are wrong. are you sure that you used the qt4 qmake?
05:43<gbee>janneg: no, I discovered afterwards that it keeps using the q3 qmake (/usr/lib/qt3/bin/qmake) despite QTDIR being /usr/lib/qt4/
05:43<janneg>the qmake checks in configure are bogus, I'll fix them
05:44<gbee>I'm trying to find out why
05:44<janneg>gbee: qt4 does not need QTDIR to be set, just make sure that it is found in PATH before the qt3 qmake
05:45<gbee>janneg: ok
05:45<gbee>wish I'd known that last night
05:46<gbee>actually I removed the qt3 bin from PATH when trying to fix it last night, didn't make a difference
05:47-!-MavT [] has quit [Read error: 113 (No route to host)]
05:48<gbee>heh, but I didn't add qt4 to PATH - that fixed it
06:00-!-grokky [] has quit []
06:00-!-MaverickTech [] has quit ["Leaving"]
06:02<janneg>gbee: try again, configure has now --qmake and tests if it is using qmake for qt4
06:02-!-kurre2__3 [] has joined #mythtv
06:04-!-kurre2 [] has quit [Read error: 113 (No route to host)]
06:18<gbee>janneg: thanks for making those changes, adding the qt4 qmake to path fixed it for me and now that it's compiling I'm going to leave it alone but I'll try test those changes tonight
06:21<janneg>sure, I was already annoyed by the need of sourcing the right file depending which branch I was going to build
06:34-!-gardz [] has joined #mythtv
07:10-!-grokky [] has joined #mythtv
07:12-!-kurre2__3 [] has quit [Read error: 104 (Connection reset by peer)]
07:12-!-kurre2 [] has joined #mythtv
07:34<gbee>QSqlDatabase: QMYSQL driver not loaded << Could be that Mandriva don't include it in their packages, or is there another explaination?
07:34<gbee>I've got something called libQtSql
07:37<gbee>nevermind, needed the qt4-database-plugin-mysql-lib64 package .... nice consistent package naming :(
07:42-!-grokky [] has quit []
07:45<gbee>ok, so opengl rendered text is broken
07:45<gbee>so is xinerama support
07:47<gbee>and opengl rendering of some images
07:48<gbee>no ... just a redraw problem
07:49-!-ToadP [] has joined #mythtv
07:50<gbee>seems to have problems determining the dirty areas, it's missing whole layers but still managing to draw the base layers
07:55-!-ToadP_ [] has joined #mythtv
07:55-!-ToadP_ [] has quit [Remote closed the connection]
08:10-!-MaverickTech [] has joined #mythtv
08:13<gbee>damn this is slow, it's taking 3/4 seconds to move betewen menus, X is taking 95% CPU and redraws are all screwed up (QT Painter)
08:15-!-ToadP [] has quit [Read error: 110 (Connection timed out)]
08:20<janneg>gbee: you're right, I haven't noticed it since it is fast enough here
08:21<gbee>I'm looking into it now
08:21<janneg>gbee: there are some dubious changes to mythmainwindow.cpp
08:23<janneg>drawTimeout() should probably not be called in MythMainWindow::paintEvent
08:24<janneg>and than a connect(d->drawTimer, SIGNAL(timeout()), this, SLOT(drawTimeout())); is missing
08:28<gbee>still trying to work out what that means for us
08:39<gbee>I don't know if it has any effect on us, I'm not sure if it means that all painting must be triggered through PaintEvent, or a more literal interpretation, that all painting has to happen in PaintEvent
08:42<janneg>all painting has to be triggered by paintEvent
08:42-!-grokky [] has joined #mythtv
08:43-!-grokky [] has quit [Client Quit]
08:47<gbee>just replacing the Q3Support libs from mythui, had to do the following: int logicalDpiY = this->logicalDpiY();
08:48<gbee>not sure why and if no-one else minds then neither do I
09:24-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:49-!-jgarvey [] has joined #mythtv
10:03-!-adante [] has quit [Remote closed the connection]
10:03-!-adante [] has joined #mythtv
10:19<gbee>janneg: do you mind me porting libmythui from QT3Support to QT4? I don't want to make it harder for you
10:21-!-gardz [] has quit [Read error: 101 (Network is unreachable)]
10:28-!-phatmonkey [n=ben@] has joined #mythtv
10:30-!-phatmonkey [n=ben@] has quit [Remote closed the connection]
10:30-!-phatmonkey [n=ben@] has joined #mythtv
10:30-!-phatmonkey [n=ben@] has quit [Remote closed the connection]
10:37<janneg>gbee: I don't mind. I think it is a great Idea. mythgallery is almost done
10:38<janneg>gbee: why does mythgallery has its own tiff reader? is tiff support in Qt optional and usually disabled?
10:38-!-jmk_ [n=jmk@] has joined #mythtv
10:40<Chutt>janneg, yes
10:40<Chutt>at least in qt3
10:41<gbee>janneg: don't know much about mythgallery, I only looked at it when I started converting it to mythui
10:49-!-gardz [] has joined #mythtv
10:49<gbee>Chutt: any preference between STL style iterators and Java style? QLinkedList, a replacement for QPtrList offers both and I was going to use it in MythListButton (for one)
10:52<gbee>The Java style iterator is probably closest to QPtrListIterator, but QPtrListIterator would could probably have been described as a mix of the two styles
10:52<gbee> vs
10:52<gbee>compared to
10:54<gbee>if you don't have a preference I'll go with the java style
10:56-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
10:56<Chutt>i have no preference
10:57<Chutt>gbee, janneg, should we try to explicitly use 'qmake-qt4' if it exists?
10:58<gbee>anything we can try to save others the hassle I had
10:59<janneg>I prefer stl type iterators and converted to them already. it's no strong preference but I'm used to stl iterators
11:03<janneg>Chutt: good idea if qmake-qt4 exists. I don't have one. I'll commit in a minute
11:07<gbee>maybe I'll go with STL on second thoughts, it's more likely to be familiar to those with a C++ background and I doubt we have many Java people wanting to get involved in the project
11:08<gbee>I think the way Java steps past items is probably a little confusing too
11:10<danielk22>Ieah, I'm 100% for using STL iterators. It's what I've been using for years as have most C++ programmers..
11:12<gbee>I'm comfortable with both, but STL is more familiar
11:19-!-gnome42 [] has joined #mythtv
11:48<gbee>ahh fooey, QPtrLists auto delete feature has been ditched so I've got to go through making sure we delete everything :(
11:50<gnome42>gbee: ugh, really!!!?
11:51*gnome42 was looking at how to cleanup after QPtrLists and vectors the other day
11:53<gbee>it was a useful convienance function and though I can live without it, I regret ever using it now that I've got to go through and fix everything
11:54-!-reynaldo [] has joined #mythtv
11:54<gnome42>yeah, really! :/
11:58<danielk22>gbee: if there is not autodelete anymore, maybe we should use vectors? PtrList is O(n) when someone does an .at(i) so a simple for loop which doesn't use iterators suddenly becomes O(n^2)
11:59<danielk22>it's rare that anyone takes advantage of the cheap inserts and deletes anyway..
12:00<gbee>well ptrlist itself doesn't exist any more, it's replaced with QList
12:01<gbee>QList claims to be faster than vector
12:02<gbee>but I'll use whatever you think best
12:03<Chutt>QList is just a vector
12:04<Chutt>i think it'd be preferable to use std containers
12:05<Chutt>since there's fewer hidden side-effects =)
12:05<danielk22>ah, I thought it was the same as QLinkedList
12:07<danielk22>i'm still thinking of Qt 3, obviously.. :)
12:08<Chutt>0.22 will be qt4 + mythui, btw
12:09<gbee>I'm losing track of what is what and what's "under the hood"
12:09<danielk22>it looks like Qt4 might be faster, just looking at the data structure changes...
12:09<Chutt>oh, and + safe strings
12:09<danielk22>some good stuff in there
12:09<gbee>std containers are fine by me, but I thought there was a reason for using QT containers throughout Myth
12:10<Chutt>gbee, either way
12:10<danielk22>yeah, safe strings are essential... esp with all these multi-core machines being mainstream now..
12:11<gbee>btw, startup with QT4 Myth is faster, or maybe it just feels that way
12:22<Cardoe>gbee: it should be faster
12:23<Cardoe>Trolltech claims qt4 startup is significantly faster
12:23<Cardoe>Chutt: promising me mythui now ;)
12:25-!-^_oo_^ [] has joined #mythtv
12:25-!-^_oo_^ [] has left #mythtv []
12:26<gbee>janneg: I really don't envy you the job you've started
12:27<gbee>I started replacing all the easy stuff, e.g. QValueVector to QVector etc, but I might regret starting to convert QPtrList to QList, it's taking ages
12:27<Chutt>Cardoe, bah, gbee's made good progress on it
12:28<gbee>I'd like to get mythui off QT3Support so that I can work on it without worrying about conflicts later
12:50<MrGandalf>has anyone tried the new software scalar in ffmpeg yet?
12:50<MrGandalf>wondering about the quality
13:02-!-foxhunt [] has joined #mythtv
13:02-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit [Remote closed the connection]
13:04-!-foxhunt [] has quit [Client Quit]
13:06<jarle>How can I get svn to tell me at which revision "mythtv/i18n/mythfrontend_nb.ts" was updated the last time?
13:08<kormoc>svn info might, or svn log would for sure
13:09-!-mykeul [n=mykeul@] has left #mythtv []
13:09-!-jk1joel [] has quit [Read error: 104 (Connection reset by peer)]
13:10-!-jk1joel [] has joined #mythtv
13:11<gbee>svn info mythtv/i18n/mythfrontend_nb.ts
13:11<jarle>If I start working on a translation, and in the meantime the ts. file is updated with more phrases in the trunk. How would that affact my translation in progress (based on an older revision)?
13:12<kormoc>if things go well, the changes will merge together, if things don't, you'll need to fix the conflicts by hand
13:12<gbee>jarle: depends, if the changes in trunk and your copy are not near each other in the file then you won't be affected
13:13<gbee>otherwise it will merge as best it can and then as kormoc says, you would need to manually fix the conflicts
13:14<jarle>gbee: I was not aware of the format used for .ts files, but I now see that it is pure xml so I guess it should be easy to solve the diff...
13:15<gbee>jarle: yeah
13:15<gbee>how are you editing? with linguist?
13:16<jarle>gbee: yea..
13:16<gbee>ok, just checking, so people try editing the xml directly and I really wouldn't recommend that :)
13:17<gbee>linguist is a hundred times faster
13:17<jarle>gbee: I figure that I should fix the typos from the previous translator and than submit a patch, and then start the work on translation the newly added phrases..
13:18-!-johnp__ [] has joined #mythtv
13:19<gbee>jarle: whatever is easiest for you
13:22-!-aravind_ [] has joined #mythtv
13:25<jarle>gbee: I have been browsing around Qt Linguist (and looking a bit in the docs), but I can't find any information about how to spell-check your translation, to narrow down typical typos?
13:25-!-dekar1 [] has joined #mythtv
13:26-!-xris [] has joined #mythtv
13:27<gbee>jarle: it's been a while since I used it, but I can't remember if that's a feature
13:28<jarle>gbee: if I could just get a file with only translations in it I could use an external program to do it, but that would take some awk/sed wizardry I guess...
13:30<gbee>yeah :(
13:30-!-dekarl [] has quit [Read error: 60 (Operation timed out)]
13:30<gbee>some good editors will perform spell checking whilst ignoring the xml markup
13:31<jarle>gbee: problem is that the .ts contains both the original text and the translation, than the original text will give you problem when spell checking in another language..
13:32<gbee>jarle: didn't think of that :(
13:33<jarle>gbee: so one needs to spellcheck only <translation></translation>
13:33<gbee>I can't think of a good solution right now
13:34<gbee>just fired up linguist and noticed this string "Add some for channels first!"
13:34<gbee>add some what??
13:35<jarle>gbee: LOL :)
13:35<Chutt>losing context is fun
13:35<gbee>tr() allows for context to be kept with the string, but it's rarely used
13:36<Chutt>because it's annoying to do so
13:36<jarle>I'll send a feature request to Trolltech for adding a better way of spellchecking the translation...
13:37<gbee>turns out to be a typo, should be "Add some channels first!"
13:37*CDev_ wonders what the performance penalty is with translations using full string lookups instead of unique keywords or constants.
13:40-!-aravind [] has quit [Read error: 110 (Connection timed out)]
13:40<gbee>does it use full string? I assumed that the qm files reduced it to something faster
13:41<CDev_>Don't know, but we supply the fill english text in code, I assume it has to do some sort of processing on it at runtime (hash maybe).
13:42<danielk22>The performance penalty of the translations is negligible compared to drawing a button on screen...
13:42<CDev_>Just curious... not really important.
13:43<gbee>CDev_: I assumed that they were dealt with at compile time
13:44<CDev_>It's a function call to a QObject method... not sure how it could be done at compile time.
13:47<CDev_>My windows background is showing... I tend to use resource ID's (numeric) that are constants and it would load the proper string from the language specific dll resource. I assume QT does something simular, but uses the entire original string as the key.
14:05<janneg>mythmusic is pleasantly clean
14:05<Anduin>The Qt4 qmake and cpsvndir don't seem to play nice (qmake puts the full path in, making the destination not correct)
14:06<sphery>Anduin: On the bright side, Nigel is still cleaning up cpsvndir(s) :)
14:18-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
14:20<janneg>Anduin: add $(basename destination)
14:21<janneg>CDev fixed that already and I reverted it since it looked like failed merge
14:21<sphery>Hmmm. libs/libmythtv/dbcheck.cpp seems to have some accidentally-left-in debug in it (lines 3587 and 3608, "In 1213 upg"). Looks to the untrained user like something failed during the upgrading (failing to finish the log output, even).
14:21-!-Koffa [] has joined #mythtv
14:21<sphery>I can make a patch/ticket if desired.
14:22-!-Koffa [] has left #mythtv ["*kaboom*"]
14:22<sphery>It's in both 0.21-fixes and trunk.
14:23<sphery>Might as well make a ticket...
14:25<Anduin>janneg: Thanks, that fixes it and is less work that what I was going to do.
14:31-!-NightMonkey [n=NightMon@pdpc/supporter/sustaining/NightMonkey] has joined #mythtv
14:37<janneg>bummer, RHEL and CentOS 5.1 have only Qt4.2.1
14:38<Chutt>what's different?
14:38<Chutt>4.3's almost a year old
14:40<CDev_>I can't find where I read it, but I thought 4.2 had issues. (Then again, I may be remembering it wrong.)
14:40<jams>sphery- does the database backup use it's own storage group?
14:41<Chutt>janneg, i'm tempted to just require 4.3
14:43-!-CDev_ [] has left #mythtv []
14:43-!-CDev_ [] has joined #MYTHTV
14:43-!-CDev_ [] has quit ["."]
14:44-!-CDev [] has joined #mythtv
14:45<CDev>nm, I might be getting confused with the fact that native window support (in free version) was released in 4.3
14:47<Chutt>janneg, i want to look into using qtscript for theming bits, so, i'd like to require 4.3
14:47<gbee>stick to 4.3, RHEL is always, by nature going to be using older versions of most things - we shouldn't retard the development of MythTV for the slowest distro
14:47<Chutt>gbee, ie, something like the guidegrid
14:47<Chutt>right now it's a 'special' widget
14:48<sphery>jams: kind of. I'll explain more in -users.
14:48<Chutt>but that could be built up from more primitive things and some scripting, i think
14:48<gbee>Chutt: I'll have to look at qtscript, I don't know anything about it
14:48<jams>sphery- k
14:48<Chutt>eh, i'm just assuming it can do standard things
14:49<Chutt>would be neat to move some of the logic out
14:49<Chutt>presentation logic, that is
14:50<janneg>last plugin ported
14:50<janneg>well except mythbrowser
14:50<Chutt>drop mythbrowser
14:51<Chutt>hasn't been maintained in ages.
14:51<janneg>it's disabled
14:51<gbee>ok, I'm almost on the same page - QTScript is an ecma based scripting language
14:51<Chutt>good enough
14:51<Chutt>gbee, it's mostly just idle speculation
14:52<Chutt>but i think it'd be neat
14:52<Chutt>just have to provide some functions to retrieve data
14:52<Chutt>wrap all the mythui objects
14:52<Chutt>then look's defined by the xml
14:53<Chutt>and feel's defined by a script
14:53<gbee>it's a good idea
14:53<Chutt>like, if someone wanted a different style epg
14:53<Chutt>tivo-esque, or whatnot
14:55<gbee>post 0.22 though? :P
14:55<Chutt>oh, sure
14:58<gbee>my initial enthusiasm for removing Q3Support from mythui has waned
14:59<Chutt>it won't help the merge
15:02-!-grokky [] has joined #mythtv
15:02<gbee>figured that it would make changes to mythui less likely to conflict with any work by others on the qt4 port
15:03<Chutt>but you'd still be changing the same code, though
15:04<gbee>I'm working in the branch and not making any changes to libmythui until the merge
15:05<gbee>there isn't much else I can do until the merge anyway, it's going to conflict and the pain of fixing it isn't worthwhile
15:06-!-grokky [] has quit [Client Quit]
15:07-!-kormoc_ [n=kormoc@unaffiliated/kormoc] has joined #mythtv
15:12<janneg>gbee: I had hoped that the qt4 port of mythui would solve the constant repainting
15:13<gbee>janneg: I got sidetracked, I was going to try and fix that
15:14<gbee>I'm not sure that removing the QT3 support libs would help that problem
15:14<janneg>gbee: you could work in the branch let's hope that the OSD is fixed soon
15:14<Chutt>what's left?
15:14<gbee>janneg: I'll do that for now then
15:14<Chutt>bad painting with qt painter
15:14<Chutt>osd issues
15:14<Chutt>opengl text
15:15<gbee>xinerama busted
15:15<gbee>only sees one screen instead of both - Xinerama screen 1 was specified, but only 1 available, so using screen 0.
15:16<janneg>that are the known major issues
15:17<gbee>that's all I can think of and it's hard to spot other uses when nothing is being painted properly and you can't really navigate ;)
15:20<gbee>ok, mythlistbutton is free of qt3 but for all the effort it's probably not worth much, I changed from using java to stl iterators and from QListLinked to QList halfway through, as a result there are probably a few mistakes
15:20<iamlindoro_>janneg, If you are around-- two part question. Any idea when you intend to sync ffmpeg to trunk next? If so, any chance you would accept a couple of patches for MLP/E-AC3 and the demuxer so that I can dump mplayer for Blu-Ray material?
15:20<iamlindoro_>(or at least consider them)
15:20<Chutt>iamlindoro, get them in ffmpeg upstream
15:21<gbee>ASSERT: "!isEmpty()" in file /usr/lib/qt4/include/QtCore/qlist.h, line 246
15:21<iamlindoro_>Chutt, Well, that's where they're languishing, it's the reason I ask :)
15:21<gbee>yeah, screw it, I'm just reverting those changes
15:21<Chutt>i _really_ prefer not to have local patches
15:21<iamlindoro_>fair enough, I'll wait I suppose
15:21<iamlindoro_>Or just patch locally
15:21<janneg>iamlindoro_: not this month, qt4 is more important now
15:22<janneg>mythfrontend is segfaulting if the osd menu is activated :(
15:25-!-onyxsoft [] has quit [Remote closed the connection]
15:27-!-mattwire [] has joined #mythtv
15:36-!-JoeBorn [] has joined #mythtv
15:47-!-Chutt [] has quit [Remote closed the connection]
15:50-!-onyxsoft [] has joined #mythtv
15:54-!-fus10nx [n=fus10nx@] has joined #mythtv
15:55-!-erik_ [] has joined #mythtv
16:00<janneg>found the cause of the osd issue. QString changes breaks xml parsing
16:01<fus10nx>Anyone know if Happaguage 1800's would work well with MythTV?
16:02-!-Chutt [] has joined #mythtv
16:02<danielk22>fus10nx: see #mythtv-users
16:03<gbee>janneg: great, one less problem
16:03<gbee>I'm looking at the QT painter
16:04<GreyFoxx>cool, looks like QT4
16:04<GreyFoxx>s default configure options cover everything but the mysql support
16:05-!-skamithi [] has joined #mythtv
16:05<Chutt>osd fixed?
16:08<janneg>Chutt: yes
16:09<janneg>looking now at xinerama
16:10<gbee>I put in a debugging string on a hunch -- Tried to draw outside the screen.
16:11<gbee>now I added something a couple of months back that should stop that being an issue, but I'm still curious why it's happening
16:11-!-mattwire [] has quit [Read error: 104 (Connection reset by peer)]
16:11-!-mattwire [] has joined #mythtv
16:20<janneg>gbee: is your qt xinerama enabled? we are using qt to get the xinarama config and your setup looks too qt as it is one big screen
16:20<gbee>janneg: I've no idea
16:22<gbee>have a clue about the QT painting issues btw, paint events smaller than the screen rect don't work, but when it requests a full screen repaint it does
16:22<gbee>and then for some reason it immediately calls another paint event and the screen is painted black
16:26<gbee>janneg: how would you suggest I find out?
16:27<janneg>gbee: grep -i xinerama /usr/lib64/qt4/libQtGui.prl
16:27<gbee>QMAKE_PRL_LIBS = -L/usr/lib64 -L/usr/lib/qt4/lib64 -L/usr/X11R6/lib -lpng -lSM -lICE -lQtCore -L/usr/lib64 -L/usr/lib/qt4/lib64 -lz -pthread -lgthread-2.0 -lrt -lglib-2.0 -lpthread -lXi -lXrender -lXrandr -lXfixes -lXcursor -lXinerama -lfreetype -lfontconfig -lXext -lX11 -lm -ldl
16:27<gbee>so yes
16:28<fus10nx>What are u trying to do with Xinerama and mythTV?
16:28<gbee>get it working under QT4
16:28-!-nordenm [] has quit []
16:28-!-skamithi [] has quit ["WeeChat 0.2.3"]
16:28<fus10nx>QT4? Quicktime?
16:28<fus10nx>are you trying to run multiple displays (projectors maybe?)
16:29<gbee>Chutt: you've made my night
16:29-!-nordenm [] has joined #mythtv
16:30<Chutt>gbee, do i need anything other than qt4-dev packages?
16:31-!-BleedAway [] has quit [Remote closed the connection]
16:31<janneg>Chutt: you might need another package for the database driver/libs
16:31<Chutt>already have that
16:32<Chutt>core, gui, qt3support, sql packages
16:32<janneg>xml, network, opengl?
16:32<janneg>if all the qt modules are in separate packages
16:32<Chutt>don't appear to be that separated
16:33<Chutt>core = core+network+xml
16:33<Chutt>gui = gui+opengl
16:34-!-BleedAway [] has joined #mythtv
16:34<janneg>that should be enough, we aren't using the other modules (yet)
16:34-!-mo0dbo0m [] has joined #mythtv
16:35<Chutt>compiling now..
16:36<gbee>Chutt: sql packages caught me out, they were under qt4-plugin-database-mysql on Mandriva (lib64qt3-mysql previously) but looks like you've got that covered
16:37<gbee>I already had the qsql package and it took me a while to work out that it didn't include the mysql driver
16:37<Chutt>already had em
16:37<Chutt>we'll see once it's done compiling =)
16:39<Chutt>-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore
16:39<Chutt>wonder why it's doubling those up
16:39<Chutt>/home/ijr/mythbranch/mythtv-qt4/ 11: [[: not found
16:40<Chutt>it failed linking libmythupnp
16:40<Chutt>undefined references to libmyth stuff
16:41<janneg>Chutt: bug in qmake, reported saturday. I have a patch
16:41<Chutt>which issue? =)
16:41<janneg>Chutt: [Issue N203254] qmake appends Qt lib include directories twice to INCPATH
16:43<whodat>hey lol did you get my message?
16:44<whodat>oh just wondered if you still lived in willougby
16:48-!-Nikas [] has joined #mythtv
16:48<janneg>Chutt: fixed
16:48<Chutt>janneg, link error, though?
16:49<Chutt>janneg, and same error, btw, in
16:50<whodat>chutt: i moved here recently... by lost nation
16:50<janneg>Chutt: please paste the error
16:50<Chutt>/home/ijr/mythbranch/mythtv-qt4/ 11: [[: not found
16:53<Cardoe>janneg: question about your latest 0.21 commit..
16:53<Cardoe>janneg: does this mean that if we link to libXvMCW... users will be able to use Via stuff just fine?
16:54<Cardoe>Because previously I had asked about packaging in there and I was told that we needed to explicitly link to the chrome or via implementation to take advantage of all the features..
16:55<janneg>Chutt: the link error
16:55<Chutt>janneg, everything mythupnp links to from libmyth
16:56<janneg>Cardoe: I'm not sure and I can't test
16:56<janneg>Chutt: so the circular dependencies are biting you?
16:57<Chutt>qmake is apparently adding -Wl,--no-undefined
16:57<Chutt>to QMAKE_LFLAGS
16:57<janneg> should be finally fixed
16:57-!-henkie [] has joined #mythtv
16:58<Chutt>yeah, updated and it worked.
16:58-!-henkie [] has left #mythtv ["Leaving"]
16:59<janneg>Chutt: does "QMAKE_LFLAGS -= -Wl,--no-undefined" in settings pro fix the linking?
17:01<Chutt>oh wait, it didn't regen the Makefile
17:01<Chutt>still nope, though
17:02<janneg>is that still used or does it even fail with those flags removed?
17:02<Chutt>it links without it
17:04-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit [Read error: 104 (Connection reset by peer)]
17:04<janneg>Chutt: try without the -Wl,
17:05<janneg>grep -rn "no-undefined" /usr/share/qt4/mkspecs/
17:05<Chutt>it's -Wl,--no-undefined :p
17:09<Chutt>i'm removing the right thing
17:09<Chutt>unless something else is adding it..
17:10<janneg>but maybe not from the right variable
17:10<Chutt>try wrong =)
17:11<Chutt>mythmainwindow.cpp:59: error: ‘QFile’ has not been declared
17:11<Chutt>mythmainwindow.cpp:60: error: ‘QDir’ has not been declared
17:12-!-mattwire [] has quit ["Leaving"]
17:12<janneg>just add them, probably fallout from my #include replacing
17:13<janneg>with Qt4 we can and should just #include <class name>
17:17-!-erik_ [] has quit ["Lämnar"]
17:20-!-grokky [] has joined #mythtv
17:22<Chutt>yeah, already did
17:22<Chutt>just pasting errors in here :p
17:23<Chutt>lotta new signed/unsigned warnings, it eseems
17:32<janneg>yes, .size() of most/all? classes returns now ints
17:32<janneg>and we have many for (unsigned int ... < x.size() ...
17:33-!-Rigolo [] has joined #mythtv
17:33<Rigolo>good evening
17:33-!-johnp__ [] has quit [Read error: 110 (Connection timed out)]
17:33-!-Agrajag- [] has quit [Read error: 110 (Connection timed out)]
17:34<danielk22>so can .size() now return negative numbers? For error conditions?
17:36<Rigolo>mythtv 0.21 makes it impossible to scan any dvb-c channel on the @home network
17:37-!-Dillweed [] has joined #mythtv
17:37-!-Dillweed [] has left #mythtv []
17:39<danielk22>heh, they define size_type as an signed int too. "For STL compatibility", but size_type is an unsigned int in STL so this seems to be more for STL incompatibility :)
17:40<danielk22>I guess it's an intentional 'vendor lock-in' regression in Qt 4.x
17:40<janneg>the opengl issue is GetImageFromString() drawing white images
17:41<janneg>there was a function returning -1 on error/invalid conditions, can't remember if it was size() or count()
17:42<danielk22>so at least they are using it..
17:43<Rigolo>janneg: can you give me an update on bug #3640. Is anybody working on resolving that bug? what can I do? can I do some testing?
17:44<Rigolo>at the moment mythtv is not usable for anyone on the @home dvb-c network
17:44<Rigolo>it is not possible to get the channels correcly scanned via myth-setup
17:46<Rigolo>in 0.20.something (before 0.20.2) it was possible to just import a proper channels.conf and get a working setup, now that also does not work
17:46<danielk22>rigolo: janne is working on the Qt 4.x port but it looks like there are some patches on the ticket, have you tried any of these?
17:47<Rigolo>danielk22: I looked at them, but I have not tried to apply them. I'm running mythbuntu .. so I do not compile my own binaries
17:48<Rigolo>but I'm suprised that the dvb-c support went down hill so much ...
17:48<danielk22>Rigolo: if you do not apply patches you are on the wrong IRC channel.
17:50<gbee>janneg: the redraw issue with the QT painter is QPainter setting the screen black, only the clipped areas are then drawn over the top - I haven't a clue why though
17:51<Rigolo>danielk22: well, I think that is a bit "short sighted". Running a precompiled binary excludes me from this channel? I have no problem setting up a development system and checking those issues, but how can it be that dvb-c support is going downhill instead of getting better?
17:51<gbee>Rigolo: because people won't test patches ....
17:52<gbee>Devs had to have access to the hardware or broadcasts to fix issues or they rely on users to test fixes and help debug
17:52-!-jgarvey [] has quit ["Leaving"]
17:53<Rigolo>gbee: okee, so again .... if I just say now ... it works .. it will be released then?
17:54<janneg>the opengl painter tries to draw empty strings
17:55<gbee>so it's a string issue? or is that just a side problem?
17:56<janneg>Rigolo: I can assure you that DVB-C just works fine. only the garbage @Home transmits in the SI doesn't work
17:56<janneg>still wondering why it results in white boxes
17:56<janneg>probably another issue
17:57<Chutt>i'll look into the painter issues tonight as well
17:57<janneg>no, just the first string was empty
17:57<gbee>Chutt: thanks, I'm out of ideas and just trawling through the Qt4 docs for a possible explanation
17:57<Rigolo>janneg: why is it garbage? They transmit all the transponder information of all their networks in the other network information. cscan can pick it up correctly, my dreambox picks it up ... so why can't mythtv? what breaks it?
17:58<janneg>Rigolo: it's in the ticket
17:58<Chutt>what version of qt does debian stable have in it?
17:59<Chutt>hum, only 4.2
17:59<janneg>debian etch has also 4.2.1
18:00-!-_gunni_ [] has joined #mythtv
18:01<Rigolo>janneg: so they only problem is that the NIT-actual is a "dummy" value? that to me does not mean garbage. I think they use the NIT others exactly the way it was meant to be used. And by calling it garbage you know break mythtv dvb-c for all users of the @home network?
18:02-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:03<Rigolo>janneg: what happens now is that if I make all my transponders correct (and even update the network id directly via the database) and then do a scan existing transponder, mythtv still thinks it is smart and starts to add NEW transports and use those ... instead of the one I asked it too use
18:05<janneg>Rigolo: please stop argueing. 1st I'm occupied with something else, 2nd we will fix it
18:05<danielk22>*sigh* Rigolo, they do not follow the DVB spec, but do something proprietary instead, that is why it is garbage data. No one has said MythTV will never support this garbage, but if you are unwilling to test patches I really don't understand why you keep bugging people on the dev channel.
18:07<Rigolo>danielk22: first: I never said that I was unwilling to test patches .... it is not something proprietary, they use NIT-others exactly for what it was supposed to do. Inform about other networks.
18:08<Chutt>janneg, immediate crash =)
18:08-!-skamithi [] has joined #mythtv
18:09<Chutt>ah, plugins
18:09<Chutt>there, works now
18:11<Dibblah>Rigolo: I'd be more than happy to continue this across at #mythtv-users. But not here.
18:12<gbee>Rigolo: NITo isn't supposed to be used without a valid NITa, but like Dibblah said, discuss it in -users
18:12<gbee>the problem is still that no-one will test the patches, until that happens there is no purpose in discussing the topic
18:13<janneg>opengl painter draws text,
18:14<janneg>colorTable doesn't seem to return a pointer
18:15<Rigolo>I'm also on -users now
18:34-!-phatmonkey [n=ben@] has joined #mythtv
18:35-!-_gunni_ [] has quit ["KVIrc 3.2.4 Anomalies"]
18:37-!-JoeBorn [] has quit [Read error: 104 (Connection reset by peer)]
18:40<Chutt>did you guys fix the painters?
18:41<gbee>Chutt: QT painter seems to be behaving a little better, though I can't really explain why, but it's still slow, uses a lot of CPU and if you force a paint event by changing focus, dragging over a new window etc it doesn't work too well
18:41-!-reynaldo [] has quit [Read error: 113 (No route to host)]
18:42<gbee>seems to start working better, for me at least, after [16634] but there is nothing in there which would account for it
18:42-!-fus10nx [n=fus10nx@] has quit []
18:43-!-fus10nx [n=fus10nx@] has joined #mythtv
18:43<Chutt>wow, that does use a lot of cpu
18:44<janneg>the opengl painter is fixed. long texts are partially clipped with metallurgy though
18:45<gbee>only full screen paint events work for me with the QT painter, clipped ares draw fine but the rest of the screen is black
18:46<gbee>with either painter, going to watched recordings no text is displayed until I move up/down
18:46<Chutt>high cpu is because it's redrawing the entire screen every time
18:46<CDev>janneg: what was the problem? I could figure it out when I looked at it a few months ago.
18:46<Chutt>update() does a full screen redraw, iirc
18:47<janneg>CDev: ^^^
18:47<janneg>the setColorTable() call alone fixed it
18:52<Chutt>we might be able to get rid of that silly text stuff now
18:52<Chutt>if qt can now draw AA text directly to the widget
18:52<Chutt>at a given alpha level, at least
18:53<gbee>ok, think I've figured out the black screen thing, someone removed the WRepaintNoErase flag from mythmainwindow
18:54<Chutt>gbee, i'm recompiling to test the full-screen redraw thing
18:55<Chutt>well, the horribly high cpu thing
18:56<gbee>Chutt: iirc I disabled that timer earlier but I didn't look at what effect it had on CPU, it didn't fix my paint problems but probably did sort out the cpu
18:57<janneg>not connecting the drawtimer with update fixes the high cpu but does not redraw then needed
18:58-!-ToadP [] has joined #mythtv
18:59-!-fus10nx [n=fus10nx@] has quit []
18:59<gbee>but it can be dependant on the current painter, it's only needed for opengl?
18:59<Chutt>we need it for qt
18:59<Chutt>just not for the whole screen..
19:01<Chutt>there's some parenting issues with window backgrounds as well
19:03-!-adante [] has quit [Remote closed the connection]
19:03-!-adante [] has joined #mythtv
19:05<Chutt>now it's going back to black..
19:10<Chutt>gbee, did you figure out the black screen issue?
19:10-!-PointyPumper [i=Pintlezz@] has quit [Read error: 104 (Connection reset by peer)]
19:11<gbee>Chutt: playing with window attributes and flags
19:13<Chutt>RepaintNoErase is deprecated
19:15-!-MavT [] has joined #mythtv
19:17<janneg>and it just killed my X and left the gpu in a bad state. I had to reboot
19:17<gbee>yeah, just looking at Qt::WA_OpaquePaintEvent
19:17<janneg>that's or outputting the bounding rect of the repaint region was to much
19:18<gbee>"Qt normally erases the widget's area before the paintEvent() call. If the Qt::WA_OpaquePaintEvent widget attribute is set, the widget is responsible for painting all its pixels with an opaque color."
19:18<janneg>it was mainly the full screen
19:18<gbee>it's similar to RepaintNoErase
19:22<Chutt>i set that, still not repainting everything
19:22<Chutt>still clearing the screen :/
19:24<gbee>yeah, didn't work here either, looking at other attributes just in case
19:25-!-Rigolo [] has quit [".... leaving ... time to give my eyes some rest"]
19:30<Chutt>got it
19:31<gbee>nice, where's that go?
19:31<Chutt>where the flag was before
19:32<gbee>just found it in QWidget
19:32-!-MaverickTech [] has quit [Read error: 113 (No route to host)]
19:33<gbee>ok, I've cleaned up/fixed the rest of the flags/attributes, care to comment on the choice?
19:33<Chutt>lemme check my stuff in first
19:35<gbee>Qt::WindowFullScreen is good, it uses the proper 'fullscreen' flag so we are no longer a borderless window at screen size
19:35<Chutt>make sure to not set that if it's not full-screen :p
19:36<gbee>what check the actual dimensions of the window in addition to RunFrontendInWindow ?
19:36<Chutt>i don't run my frontend in a window
19:36<Chutt>but it's not full-screen
19:37<gbee>yeah, I know there are use cases - I often debug themes with -geometry
19:39<Chutt>ok, one more compile (touched mythmainwindow.h cleaning up)
19:39<gbee>even with the fullscreen attribute running a window smaller than the screen size behaves just like it does now
19:39<Chutt>that's fine then
19:39<gbee>which isn't what I expected but saves work
19:41<Chutt>got rid of the double-buffering in the qt painter, too
19:41<Chutt>no longer required =)
19:42<gbee>still uses too much cpu rendering and it's _slow_, plus areas of the screen look fuzzy
19:42<gbee>could be side-effects of the buffering, I'll wait to see :)
19:46<Chutt>what was wrong with the old cpsvndir?
19:47<Chutt>the watch recordings screen sucks
19:47<Chutt>it blinks and everything
19:47<Chutt>janneg, the settings screens are fairly broken
19:48<gbee>#4989 < heh, I should have taken bets, I'd be rich :p
19:48<janneg>Chutt: which one?
19:48<Chutt>just stuff like it's not keeping the highlights to show what's active
19:48<Chutt>'down' on a combobox wasn't exiting
19:48<gbee>spinboxes, at least the themecache one doesn't work
19:49<gbee>only pressing up works and it jumps 10 at a time, I'm stuck with 11 atm ;)
19:49<janneg>I sorted that under minor issues
19:50<gbee>Chutt: you waiting to build/test those changes before you commit them?
19:50<janneg>the painter and the osd was more important
19:51<Chutt>gbee, just committed
19:52<Chutt>janneg, gotta be able to navigate the settings screens =)
19:52<janneg>use tab
19:52<janneg>;) I'll look at it now
19:54<Chutt>i'm looking at the watch recordings screen
20:00<gbee>reparent no longer exist, can anyone remember why it was even needed? We were reparenting the widget to it's current parent which seems odd
20:09<gbee>damn, still not drawing properly here
20:09<Chutt>the menus?
20:10<Chutt>native qt stuff (old ui) still won't draw properly, of course
20:10<xris>grumble.. firewire stuff still unstable. maybe I should think about upgrading my box tonight.
20:11<janneg>Chutt: the highlights working here, combobox too. spinboxes don't overwrite keyPressEvent and have therefor native qt behaviour
20:12<Chutt>gbee, i'm using gant
20:13<Chutt>gbee, something's funky about alpha in the opengl painter, too
20:13<janneg>gbee: it's working here with metallurgy at r16643
20:15<gbee>wtf? I should be at [16647], that's what I've just built and installed, but --version is saying [16612]
20:16<janneg>MythTV Version : 16643
20:16<gbee>now I know I'm running 16647, the changes I've just made are there and removing the double buffering did work to speed up QT back to normal
20:16-!-monkeyBox [n=ben@] has joined #mythtv
20:16<gbee>so I guess the version script still isn't working right
20:16<Chutt>it wasn't the double buffering
20:16<Chutt>it was the timer redrawing the entire screen every 1/60th of a second
20:17<gbee>Chutt: I was still having problems after disabling the timer and signal
20:17<Chutt>well, yes
20:17<Chutt>do you have any local changes?
20:17<monkeyBox>Help! I just upgraded a bunch of mythtv packages on my ubuntu (mythbuntu) box, and when I rebooted I started having a lot of trouble watching HD (using QAM). I can watch normal SD tv just fine, but w/ HD it's just really, really slow, and I can hear my hard drive working hard. What could be the cause of this?
20:18<sphery>monkeyBox: #mythtv-users
20:18<gbee>wasn't constant like with the timer, but every time it redraw it shot up to 100% and I had to wait seconds for it to draw anything
20:18<monkeyBox>oops, sorry
20:19<gbee>no local changes, nothing that I haven't now committed
20:19<gbee>just did a make clean and I'm rebuilding to be sure
20:27<gbee>probably wasn't necessary to make clean every lib ... I'll be here all night waiting for it to finish compiling
20:28<Chutt>is the qt painter working for anyone else now?
20:28<Chutt>(at least in the menus)
20:29<gbee>or mythappearance ;)
20:29<janneg>it's working here
20:29<janneg>except startup
20:29<gbee>well "Screen Settings Wizard" or whatever it's called now
20:31<Chutt>janneg, do you know why MythDialog got a Q3Frame instead of a QFrame?
20:32<Chutt>yeah, i know it's different
20:32<Chutt>but we're not using any of the more 'advanced' features, iirc
20:32<gbee>dunno that the porting script bothers to check that, it just plays safe
20:32<Chutt>yeah, that'd make sense
20:33<janneg>probably because the porting tool did it
20:33<Chutt>i can't wait until all this code goes away
20:34<janneg>no it is pretty stupid, it changed even local variables red, green, blue to Qt:red, ...
20:34<janneg>Chutt: comitted a keyPressEvent for MythSpinBox
20:35<Chutt>i'm using the 'Plastik' qt theme, if that helps
20:35<janneg>the other widgets are ok as far as I can see
20:36<Chutt>highlights still aren't workin here
20:36<gbee>ok, finished compiling and no difference
20:36<Chutt>gbee, does it draw the proper things for a second, then go black?
20:37<Chutt>i'm on qt 4.3.4, btw
20:38<gbee>starts up fine, first move I make in the menus only two/three buttons are drawn, rest is black, second move the full page is drawn fine and it repeats like that
20:38<janneg>the ui theme selector is broken
20:39<janneg>I'm on qt 4.3.3
20:39<gbee>odd thing is that button highlights appear on buttons I've not selected
20:39<janneg>the preview doesn't change and it is not saved
20:39<gbee>every other move something is drawn wrong
20:39<gbee>or to put it better, every second paint event it screws up
20:40<Chutt>sounds like something's not getting cleared properly
20:40<Chutt>in our code
20:40-!-clever_ is now known as clever
20:41-!-monkeyBox [n=ben@] has quit [Read error: 110 (Connection timed out)]
20:41<gbee>I'm off to bed, I'll look at it tomorrow assuming it doesn't get fixed overnight
20:42<Chutt>gbee, where's your theme at?
20:43<Chutt>i'll try it..
20:46<Chutt>theme selector doesn't work
20:46<janneg>I know
20:47<Chutt>gbee, works perfectly here
20:47<gbee>odd, maybe it's related to my version of qt4, I'll see if there are updated packages in cooker
20:54<Chutt>it might be difficult to fix the old ui stuff
20:55-!-jeffc91 [] has joined #mythtv
20:56-!-reynaldo [] has joined #mythtv
20:56-!-eharris [] has joined #mythtv
21:00-!-skamithi [] has quit ["WeeChat 0.2.3"]
21:11<Chutt>yeah, it's the double buffering
21:12<Chutt>(breaking the watch recordings screen, etc)
21:12-!-PointyPumper [i=Pintlezz@] has joined #mythtv
21:13-!-JoeBorn [] has joined #mythtv
21:15<janneg>qt4's double buffering or our old?
21:15<Chutt>our old
21:16<Chutt>well, they're fighting
21:16<Chutt>that's what's causing the flickering
21:17-!-joobie [n=joobie@] has joined #mythtv
21:20-!-grokky [] has quit [Read error: 110 (Connection timed out)]
21:28-!-phatmonkey [n=ben@] has quit []
21:34<janneg>something broke multi screen settings, the previous pages do are still there
21:36-!-eharris_ [] has joined #mythtv
21:38<Chutt>i don't see an easy way to fix this.
21:43-!-grokky [] has joined #mythtv
21:47-!-grokky_ [] has joined #mythtv
21:51-!-eharris [] has quit [Read error: 110 (Connection timed out)]
21:52<janneg>Chutt: Theme selector fixed
21:52<Chutt>'set priorities' doesn't work, btw
21:52<Chutt>left/right says you can only paint from a paintEvent
21:53-!-Ozymandias [] has joined #mythtv
21:54-!-davilla [] has joined #mythtv
21:54-!-adante [] has quit [Remote closed the connection]
21:55-!-adante [] has joined #mythtv
21:55-!-Nikas [] has quit ["( :: NoNameScript 4.2 :: )"]
21:55<Chutt>i have a 'fix' for the old screens
21:55<Chutt>but it bleeds through some of the previous screen..
22:00-!-grokky__ [] has joined #mythtv
22:00-!-ireverentReveren [] has quit [Read error: 104 (Connection reset by peer)]
22:02<Chutt>janneg, what i just checked in helps a bit
22:02-!-grokky [] has quit [Connection timed out]
22:04<janneg>fixed set priorities
22:06<Chutt>gbee, when you see this, give the fix i did in mythdialogs.cpp a try in mythmainwindow.cpp (to see if it helps your problems)
22:08-!-grokky [] has joined #mythtv
22:13-!-jams [] has quit [Read error: 104 (Connection reset by peer)]
22:13-!-grokky_ [] has quit [Connection timed out]
22:15<janneg>Chutt: much better
22:17<janneg>I'm going to bed now but I think we are ready to merge it to trunk tommorow
22:21-!-grokky__ [] has quit [Connection timed out]
22:25<Chutt>not quite yet
22:30-!-jams [] has joined #mythtv
22:57-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
22:57-!-XChatMav [] has joined #mythtv
22:57-!-purserj [] has joined #mythtv
22:57-!-JoeBorn [] has quit ["bedtime"]
22:58-!-JoeBorn [] has joined #mythtv
22:58-!-JoeBorn [] has quit [Read error: 104 (Connection reset by peer)]
23:13-!-ToadP [] has quit []
23:13-!-MavT [] has quit [Read error: 110 (Connection timed out)]
23:22-!-sc00p [] has joined #mythtv
23:25-!-joobie [n=joobie@] has quit ["Leaving"]
---Logclosed Tue Mar 18 00:00:09 2008