Back to Home / #mythtv / 2008 / 02 / Prev Day | Next Day
#mythtv IRC Logs for 2008-02-14

---Logopened Thu Feb 14 08:52:39 2008
08:52-!-mikegrb [] has joined #mythtv
08:52-!-Irssi: #mythtv: Total of 89 nicks [0 ops, 0 halfops, 0 voices, 89 normal]
08:52-!-Irssi: Join to #mythtv was synced in 1 secs
08:55<gbee>a local delicacy?
08:57-!-Dibblah [] has quit [No route to host]
09:01-!-sigger [] has joined #mythtv
09:01-!-felix_da_catz [] has quit [Connection timed out]
09:02-!-mykeul [n=mykeul@] has quit [Read error: 104 (Connection reset by peer)]
09:04-!-jams [] has joined #mythtv
09:13-!-loops [] has quit [Read error: 113 (No route to host)]
09:14-!-loops [] has joined #mythtv
09:14<gbee>NFS should be available on Solaris?
09:15<Chutt>why am i still awake
09:16<Chutt>automated merging from branch->trunk almost works
09:16<Chutt>but then, it's going to fail horribly when there's a conflict..
09:19<gbee>anyone know of a fix that lets sendfile64 work with CIFS?
09:20-!-felix_da_catz [n=felix_da@] has joined #mythtv
09:21-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:26-!-sigger [] has left #mythtv []
09:32-!-PointyPumper [i=Pintlezz@] has quit []
09:32-!-PointyPumper [i=Pintlezz@] has joined #mythtv
09:33<gbee>CDev: mind looking at this patch, I'd appreciate your thoughts on it -
09:39-!-skamithi [] has joined #mythtv
09:39-!-mo0dbo0m [] has joined #mythtv
09:58<justinh>gbee: CCTV cameras - they can zoom, pan & tilt through 360 degrees (180 vertical) within a domed enclosure
09:59<gbee>yeah, knew what you meant by dome camera, but cooking them isn't something you usually hear :)
09:59<justinh>environmental tests, part of the development process
10:00<gbee>wasn't sure if that was just a colourful turn of phrase, or you were literally going to stick them in an oven
10:00<gbee> :)
10:00<gbee>heh, ok
10:02<justinh>already done the prototypes. now it's the turn of the first production samples. I dunno how much point there is since the prototypes didn't dissipate heat very well but hey I'm just the monkey
10:04<justinh>somebody thought putting a fan in would help. in an airtight enclosure. glad it's not my funeral.. oh wait it is if they don't sell
10:06<stuarta>Chutt: i think everyone is being quite disciplined about it to not really need it
10:15-!-Dibblah [] has joined #mythtv
10:36<stuarta>tell you what, the bug fixes have been coming thick and fast lately
10:36<janneg>gbee: The question for NFS availability on solaris made my day.
10:36<janneg>NFS was developed by sun
10:39<janneg>gbee: #4669 is a duplicate of #4350
10:53-!-clever [] has quit [Read error: 110 (Connection timed out)]
10:57-!-skamithi [] has quit ["WeeChat 0.2.3"]
11:01-!-jgarvey [] has joined #mythtv
11:03<gbee>janneg: heh, well glad to have entertained you
11:03<gbee>if I'd really thought about it, I guess I knew that
11:04<gbee>but I hadn't a clue why anyone would be using samba instead of NFS in that situation
11:05<janneg>me neither
11:06<jams>well i thought you were trying to make a point without directly saying it.
11:07<janneg>has anyone already looked at a backtrace when the backend is in 100% cpu usage?
11:08<janneg>I'll do that when I get home
11:09<gbee>jams: I was, I knew NFS was available on Solaris, but I had forgotten at that moment that Sun developed it - so that bit was unintentional
11:09<gbee>janneg: no, but I was just about to do that
11:10<gbee>I first wanted to check if I could reproduce the problem by requesting something other than preview images
11:10<gbee>in theory I should be able to, but I need to confirm that
11:11<janneg>it's maybe stuck in an endless loop or busy waiting on a lock
11:12-!-clever [] has joined #mythtv
11:12<janneg>the preview image requests probably triggers it since it takes longer to respond
11:13<gbee>yeah, I was going to try the channel icon stuff first since that should reproduce similar delays, especially if we ask for larger images and force it to scale
11:14<gbee>definately getting stuck in a loop and probably because of a deadlock
11:14<stuarta>gbee: where you able to reproduce that long list problem?
11:15<gbee>stuarta: I can reproduce it, but I can't explain it as anything except a bug in QListBox at the moment
11:18<gbee>I have a patch which I've yet to test, but I don't expect it to make a difference
11:19<gbee>just upgrading all my kernels because of the priviledge escalation flaw found the other day
11:26<j-rod>meh: MythMusic requires taglib 1.4
11:26<j-rod>is that "requires 1.4, and installing something newer will break"?
11:26<j-rod>oh, hrm, something else may have busted
11:26<j-rod>./configure: line 488: test: =: unary operator expected just before that
11:26*j-rod investibigates
11:27<j-rod>good news is that all plugins outside of mythmusic built w/gcc4.3 for me last night
11:27<janneg>j-rod: since taglib 1.5 was released just a couple of days ago, it might just works
11:28<Anduin>or you do not have taglib-config
11:28<j-rod>janneg: yeah, looks like that's actually what I've been building against
11:29<j-rod>and its worked just fine
11:29<j-rod>but something failed in my rpm build last night
11:30<j-rod>ok, good, taglib-config is there in the buildroot
11:31<j-rod>if has_library libtag && has_header taglib/fileref.h && test `taglib-config --version` = "1.4"; then
11:32<j-rod>oh special.
11:32<j-rod>on my laptop, a pre-1.5 svn build still spits out 1.4
11:32<Anduin>It is checking for 1.4 but the error is from sh, and should mean taglib-config --version didn't return anything.
11:32<j-rod>with a later 1.5, it spits out nothing
11:32<j-rod>yeah, bingo
11:32<j-rod>so someone screwed up rawhide taglib...
11:33<j-rod>(or upstream did it)
11:33*j-rod gets out club, figures out who to beat
11:33-!-xris [] has joined #mythtv
11:34<Anduin>May want to look at taglib-config, 1.4 was just a sh script (with --version doing a simple echo)
11:35<j-rod>I've got one of the fedora taglib maintainers looking at it now
11:36<j-rod>Anduin: oh special. still a shell script, and for case $1 --version, it now does nothing but 'echo'.
11:37<Anduin>j-rod: Hmm, weird, that isn't the way the srpm looks.
11:42<Anduin>The srpm here make a good taglib-config for me (though on f8)
11:42-!-JoeyBorn [] has joined #mythtv
11:43<j-rod>Anduin: yeah, rex just said that one looks to be correct, it was the prior build that was busted
11:44<xris>oops.. j-rod: looks like the GL thing is a common issue for some macports/fink apps... but no real help on how to fix it.
11:44<j-rod>xris: did you update your X11 to XQuartz yet? I thought that might have been one of the fixes, actually
11:44<j-rod>er, "fixes" :)
11:46-!-rod_ [] has quit [Remote closed the connection]
11:46<xris>upgraded, no help
11:46-!-rod_ [] has joined #mythtv
11:46<xris>though xquartz is WAY faster than apple's x11, so that was a nice bonus
11:48<j-rod>Anduin: so that version does spit out something appropriate, but what it spits out is '1.5' now. :)
11:48*j-rod fixes configure
11:49<j-rod>suck. text comparison, not numerical...
11:51-!-davilla [n=davilla@] has joined #mythtv
11:57-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
11:58<gbee>j-rod: my fault, wasn't really expecting a new release - 1.4 was released in June 2005 :)
11:59<gbee>1.5 is still a RC, wonder whether it breaks anything in mythmusic, I can't see a changelog
11:59<j-rod>I've been building against pre-1.5 svn for ages, but I dunno if I've actually ran mythmusic anytime lately
12:00<jams>gbee are fonts defined in base.xml global..just like theme.xml used to be?
12:01<jams>ok guess i will move all my fonts to there
12:01<gbee>should be anyway, never actually tested the theory on non-libmyth stuff
12:02<jams>or at least the fonts needed for mythdialogbox
12:02<gbee>that should be "non-libmythui"
12:02<gbee>yeah, all fonts required for mythdialogbox should be in base.xml
12:02<jams>just attempting to not redefine fonts
12:03<jams>one of the reasons i moved all fonts to theme.xml a few years ago.
12:05<j-rod>gbee: you want I should test that it actually works, or just check in a change for configure that will work with 1.5 also?
12:07<gbee>just check in the change for now, I'll see if it actually works later today
12:07<gbee>looking at the mailing list there were no API changes mentioned, just bug fixes and optimisations
12:11-!-jgarvey [] has quit [Read error: 110 (Connection timed out)]
12:11-!-jgarvey [] has joined #mythtv
12:24-!-beavis [] has joined #mythtv
12:26<j-rod>I'm assuming chances are slim anyone will be running taglib 0.9 or later, and 2.0 will be a ways out...
12:26<j-rod>(i.e., the check just looks for minor >= 4)
12:27<gbee>sounds fine to me
12:29<j-rod>er, 0.9 or earlier, that should have been
12:29<j-rod>but yeah, committed for trunk and 21-fixes
12:29<gbee>yeah, I figured you meant that
12:29-!-MrGandalf [] has joined #mythtv
12:42<j-rod>argh. of course. mythmusic still fails to build w/gcc 4.3 :)
12:47<j-rod>fixing slowly
12:47-!-_al_ [] has joined #mythtv
12:48-!-felix_da_catz [n=felix_da@] has quit [Success]
12:48-!-_al_ [] has left #mythtv []
12:50<j-rod>what header provides 'atoi' ?
12:51<danielk22>#include <cstdlib>
12:52<j-rod>build rolling again
12:52<j-rod>so far, 3 more header includes to add to mythmusic code to make gcc 4.3 happy
12:52<j-rod>and done. so just 3.
12:52*j-rod commits...
12:54<gbee>cool backend memory leak when I run - while true;do GET -eUsd\&StartTime=2007-04-22T21:58:00;done
12:56<gbee>pretty big leak too when I've got three lots of that loop running
12:56<gbee>interestingly though, I wasn't able to trigger the 100% bug with that
13:01-!-felix_da_catz [n=felix_da@] has joined #mythtv
13:02-!-f4lt3r [] has joined #mythtv
13:20<gbee>has anyone run valgrind on the backend while hitting it with a bunch of different requests? Stuff that might expose small leaks which are hard to detect during a normal valgrind run but might expose problems when the backend has been running for a while?
13:28-!-\S2 [] has joined #mythtv
13:28-!-\S2 is now known as S2
13:36-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
13:40<f4lt3r>is someone here?
13:40<f4lt3r>i have a problem with mythtv
13:40<kormoc>f4lt3r, might want to read the topic
13:41<f4lt3r>as root it starts, but as a normal user i have no connection to the database
13:41<f4lt3r>ohh i see sorry
13:42<f4lt3r>is there anywhere a supportchannel? google can help me
13:42<GreyFoxx>the topic points you to #mythtv-users for user support :)
13:45<okolsi>kormoc: reg #4387, I'll update the patch at some point, a bit busy atm
13:53<kormoc>okolsi, no worries, I just can't really test things myself too well, so I rather let someone who can test verify
13:57-!-_gunni_ [] has joined #mythtv
13:59-!-_gunni_ [] has quit [Client Quit]
14:01-!-gnome42 [] has joined #mythtv
14:03<justinh>anybody up for going to linuxtag this year then?
14:03<jams>GreyFoxx- did you post a patch for the full screen screenshot? if not not big deal
14:05<gbee>justinh: dunno, probably too expensive for me at this end of the year
14:06<kormoc>justinh, anyone want to pay for my airfare? :P
14:06<justinh>prolly a bit dear for me too but worth a bit of debt IMHO
14:07<justinh>looks like there's no linuxworld expo this year yet - and LRL for me is a complete non-event
14:07<gbee>I'll look at the likely cost of travel + accommodation
14:07<gbee>a European get together would be good
14:08<justinh>priced flights to Dusseldorf a while ago - they come in about £70 return from liverpool
14:08<justinh>der.. not there.. where linuxtag is
14:10<nordenm>woohoo more than 800 tickets on 0.21
14:10<nordenm>excellent work everyone :)
14:11-!-mattwire [] has joined #mythtv
14:12<GreyFoxx>jams: just testing more of it now
14:12<GreyFoxx>I can force it to only grab the part of the screen where myth is located
14:12<GreyFoxx>but if you have half of it off screen, or covered up by another app that will be seen
14:12<GreyFoxx>as long as nothing is over it, then you are gold :)
14:13<GreyFoxx> for example of what I mean
14:14<GreyFoxx>I'm fine with that though
14:14<kormoc>damn, delta flights to Germany from here are only $1300, that's not bad at all
14:16-!-sparrw [n=kvirc@pdpc/supporter/active/sparr] has joined #mythtv
14:20<gbee>nordenm: closer to 1200 at least
14:21<gbee>Roadmap only shows tickets where people remembered to set the milestone
14:22<nordenm>I guess
14:22<nordenm>even better
14:24<gbee>and that doesn't include all of the features that were added, devs don't always bother to create tickets for the stuff that they add - so yeah, a nice number of changes but then it's been 18 months since the last release
14:24<GreyFoxx>ok, just to be clear, we are committing fixes to the fixes branch and "new stuff" to trunk now right?
14:24<gbee>GreyFoxx: yes
14:24<GreyFoxx>just want to make sure I don't go commiting a fix to one and it be the wrong one :)
14:24<gbee>at least least as I understand it
14:25<jams>GreyFoxx- works for me, import does the same thing
14:25<justinh>is it not fixes to both (where applicable) and new stuff to trunk?
14:25<GreyFoxx>gbee: what about 16021 and 16020? Or did I miss that ?
14:25<gbee>fixes will get merged back to trunk (possibly automatically, Chutt is working on that idea)
14:25<GreyFoxx>justinh: it was getting to confusion and too much work
14:25<GreyFoxx>so now it's fixes to fixes and nightly merge back to trunk
14:25<justinh>ah okees
14:26<gbee>GreyFoxx: wanted to double check that I didn't break anything first
14:26<justinh>now that I have any commits planned in the very near future anyway
14:26<GreyFoxx>jams: cool. Just testing a few more things and I'll update the patch
14:26<gbee>just finished recompiling the backend to test it - could have waited to do that first I suppose, but I wasn't thinking
14:27<GreyFoxx>gbee: ahh
14:27<GreyFoxx>just being paranoid :)
14:27<GreyFoxx>I didn't want to see one get lost :) heh
14:28<GreyFoxx>That Erik Hovland seems to have quite the stockpile of fixes stored up :)
14:30-!-sparrw [n=kvirc@pdpc/supporter/active/sparr] has left #mythtv ["Time makes no sense"]
14:31<gbee> << looks like those took care of the leaks, backend is pretty clean otherwise, though I'd really like to run it for 24 hours under proper conditions with recordings and a frontend connected
14:32<GreyFoxx>The same leak you fixed in 16020 is in GetChannelIcon as well
14:33<GreyFoxx>we Allocate pImage and possibly exit without deleting
14:35<Chutt>gbee, and the mythweb hang?
14:36<xris>GreyFoxx: you see my note about your screenshot thing hanging?
14:36<GreyFoxx>xris: Nope, missed them
14:36<xris>ah. it causes my frontend to lock up
14:36-!-f4lt3r [] has left #mythtv ["Ex-Chat"]
14:36<GreyFoxx>I've fixed a couple of the bugs mentioned yesterday
14:36<gbee>Chutt: just finding out
14:36<GreyFoxx>what? Really?
14:36<xris>GreyFoxx: I sent you some info in pm
14:37<GreyFoxx>ok, I'll check my history
14:37<GreyFoxx>Was that using the webget or jumppoint ?
14:37<xris>last night, around midnight my time
14:37<xris>at least, I think I sent it in pm
14:38-!-czth [n=dbrobins@nat/microsoft/x-05cca39bbb3d7917] has joined #mythtv
14:39<xris>screencap worked if the frontend was just starting up, resizing pixmaps, etc.. but if I tried to get one at any other point, it would lock up (web process would just spin and spin), and I'd need to use control-c to kill the frontend
14:40<xris>felt like an infinite loop
14:40<GreyFoxx>xris: QT or OpenGL painter?
14:40<xris>didn't seem to be using much cpu
14:40<GreyFoxx>Ok, I've only tested the QT painter, but I'll add that to my test list
14:41<xris>ah. thought you had it working with gl painter to test the osd screenshot
14:41<GreyFoxx>gl video renderer
14:42<GreyFoxx>but QT menu painter
14:44<gbee>danielk22, janneg: we don't seem to delete the ChannelInputInfo objects created in InitializeInputs, at least not within channelbase.cpp, can't see if we are passing that responsibilty on to another class
14:44-!-czth_ [n=dbrobins@nat/microsoft/x-c73f14de04a2086a] has joined #mythtv
14:46<GreyFoxx>doh I just commited a fix to trunk and not -fixes
14:48<xris>GreyFoxx: ahh
14:48<xris>so then yeah, that makes sense.. I think the errors looked gl-related, but I was confused since I thought you had tested it with gl.
14:48-!-_gunni_ [] has joined #mythtv
14:49<GreyFoxx>xris: I'll do my best to test that out tonight
14:49<gbee> << Might see if we're still holding any locks etc after that error
14:49-!-S2 [] has quit [Remote closed the connection]
14:49<GreyFoxx>got most of the rest worked out now
14:49<danielk22>gbee, they are never deleted.. Not that this will buy any memory savings, TVRec::channel isn't really ever deleted while mythbackend is running, the HW change code isn't run anymore after the multirec merge, and should be removed..
14:50<xris>gbee: so you think you got the backend cpu usage thing worked out?
14:50<gbee>danielk22: ok
14:50<gbee>xris: no, just fixed some potential leaks
14:51<GreyFoxx>danielk22: I know you worked on the iptv stuff and was wondering if you had ever looked at ticket #3489.
14:51<gbee>at least one of them was my fault - whoops
14:51<GreyFoxx>some thread is getting hung up there
14:51<xris>well, that recompile shouldn't hurt much. heh
14:52-!-briand [] has quit [Read error: 110 (Connection timed out)]
14:52<GreyFoxx>if threads didn't make my head hurt so much I might be able to track it down on my own :)
14:53<gbee>xris: one of the leaks was pretty big, under a particular circumstance it was leaking the image and that adds up pretty fast
14:53<xris>ah, yeah
14:54<GreyFoxx>if I commit 16022 to -fixes... will that cause issues later with the merge ?
14:54<danielk22>greyfoxx: no not really, I was pretty burnt out after dealing with that stuff the last time around. The guys who wrote it didn't really believe in mutexes.
14:54<GreyFoxx>or should it happily continue ?
14:54<gbee>a good argument for the single return point and I may rewrite that function
14:54<GreyFoxx>danielk22: Ahhh
14:55<GreyFoxx>danielk22: For the moment then I'd like to commit that patch that avoids the hangup if you don't mind
14:55<gbee>GreyFoxx: commit it should cause problems
14:55<danielk22>greyfoxx: if it works, go ahead.
14:55<GreyFoxx>It does for me and many others who I've had try iut
14:57<GreyFoxx>gbee: Should or shouldN'T cause problems ? :)
14:57<GreyFoxx>heh k
14:57<xris>gbee: actually, I think that definitely fixed one of the issues.. all of my pixmaps are showing up again.. before, some of them were black/blank
14:58<gbee>unless the lines you've patched change again in trunk before the merge
14:58<gbee>xris: dunno how, but I won't argue ;)
14:59<GreyFoxx>gbee: just a tiny one, I doubt anyone will mod it
14:59<janneg>I can't reproduce the problem since mythweb doesn't display pixmaps
14:59<janneg>might be lighttp related
14:59<gbee>cpu bug still hits me (or it did when I deleted all the existing preview images)
15:00-!-jarle [] has quit [Remote closed the connection]
15:00-!-czth [n=dbrobins@nat/microsoft/x-05cca39bbb3d7917] has quit [Read error: 110 (Connection timed out)]
15:00<gbee>janneg: shouldn't be, do you have upnp enabled?
15:01<gbee>GreyFoxx: thanks for that
15:01<gbee>I was planning to go through looking for more leaks in mythxml since any in there will cause serious problems, but I'm happy to have help
15:02<janneg>gbee: I don't disable it explicitly
15:03<gbee>does that work from a browser? (filling in valid values)?
15:04-!-jarle [] has joined #mythtv
15:04<janneg>svn: Checksum mismatch for 'programs/mythfrontend/.svn/text-base/mediarenderer.cpp.svn-base'; expected: '9c4d75379ddd239211b0b990a9e06765', actual: 'b54d95fabd6415bc35fce0fe5bc00ebf'
15:05<janneg>what is that. I was updating an older checkout, smart and dmesg don't indicate drive errors
15:05<gbee>committed a mem leak fix to mediarenderer the other day
15:05<kormoc>janneg, svn checkouts do get corrupted from time to time without any reason I can figure out
15:07<janneg>never happened before
15:08<janneg>gbee: thanks, but too complicated. I did simply rm -rf programs/mythfrontend && svn up
15:09<gbee>that will work too :)
15:10<gbee>probably what I would do
15:13<justinh>gbee: just been having a read of the project guidelines for linuxtag. they really have their heads screwed on compared to umm.. other expos
15:15<gbee>janneg, Chutt: backend backtrace created after causing the backend to get stuck at 100% CPU -
15:17<Chutt>more stuff not using mythsocket
15:18<Chutt>gbee, which threads are spinning?
15:18<janneg>justinh: I'll go to linuxtag and probably register the project
15:18<Chutt>(if you can get that detail)
15:18<Chutt>ie, top?
15:18<janneg>Chutt: I would guess 28 & 29
15:19<Chutt>well, yeah
15:19<Chutt>confirmation would be good. =)
15:19-!-grokky [n=grokky@] has joined #mythtv
15:20<janneg>s/ would guess/'m sure/
15:20<justinh>janneg: nifty. wouldn't mind going to lend a hand if you could use any help. be nice to meet more people in r/l too
15:21<justinh>have to get my pass stamped from SWMBO first though
15:21<Chutt>nothing's actually sleeping in that loop
15:22<Chutt> while ( (BytesAvailable() < (int)nMaxLen) && !bTimeout )
15:22<Chutt> m_pSocket->WaitForMore( msecs, &bTimeout );
15:22<gbee>forgotten how to get the thread view in top ...
15:23<janneg>capital H
15:24<Chutt>gbee, pick one of those threads and step through it =)
15:26<gbee>little slow tonight, lack of sleep has caught up, so bear with me
15:30<gbee>CDev: can't drag you into this can I? You know your code better than I do :)
15:32<Cardoe>release-0-21-fixes ?
15:33<Cardoe>official 0.21 branch?
15:33<kormoc>will be, yes
15:34<gbee>yes, but won't be released for another 2 weeks, call it a beta (or early RC)
15:34<Chutt>release isn't tagged yet
15:34<gbee>techincally beta since it's not feature complete, although we're in a feature freeze with a couple of exceptions - mythweather being one
15:36-!-luisc [] has joined #mythtv
15:38-!-luisc [] has quit [Client Quit]
15:41-!-luisc [] has joined #mythtv
15:43-!-feiner [] has quit ["Leaving"]
15:43<luisc>I'm trying to compile the qt4 branch of MythTV
15:43<luisc>but, I don't know it's status
15:43<luisc>can someone tell me if it's working?
15:43<Chutt>it is not.
15:43<luisc>mmm ok
15:44<luisc>if the configure script ok?
15:44<luisc>because it seems to not detect my Qt4
15:44<Chutt>not likely to be
15:44<luisc>that explains a lot
15:44<luisc>so, who's working on that?
15:44<Chutt>nobody right now
15:45<janneg>it works sort off, but it hasn't been merged lately
15:46<janneg>the configure checks for qt are wrong. make sure that the path with qt4 qmake is first in PATH and QTDIR is set correctly
15:47<luisc>I haven't got QTDIR set
15:47<luisc>I'll try it
15:48<janneg>qmake is more important and if QTDIR is unset would be ok too
15:48<luisc>I got it working now
15:49<janneg>but trying to work with it is atm a waste of time
15:50<luisc>aren't you thinking of supporting Qt4?
15:50<Chutt>not until after 0.21
15:51<luisc>so, I better leave the branch as it is atm
15:51<luisc>I wanted to do some coding in MythTV
15:51<janneg>it's work in progress, has some severe bugs atm and nobody will care until 0.21 is released
15:53<luisc>thanks for your time :-)
15:53<janneg>and another reason not to touch it: I have an uncommitted merge on my disc
15:53<luisc>thats a good one
15:53<luisc>well, I'll try to stay tuned
15:54<luisc>in the mailing list
15:54<luisc>for the progress in Qt4
15:56<GreyFoxx>well this is odd with the opengl renderer I don't see as well defined shadows on text as I do with QT, and the clock is shaded under opengl but pure white in qt
15:57<GreyFoxx> for the curious
15:57<GreyFoxx>I use to think it was just my TV before but I guess it's not
15:59<Chutt>kind of hard to tell with that level of compression
15:59<Chutt>but the clock probably has an alpha level set
15:59<Chutt>the Qt renderer doesn't support arbitrary alpha levels for text, IIRC
16:00<Chutt>the fonts shadows are probably the same thing
16:00-!-TelnetManta [n=benwilli@] has quit ["Ex-Chat"]
16:00<Chutt>but i can't see _any_ shadows in the .jpgs :p
16:00<gbee>jpeg compression is nasty
16:00<GreyFoxx>It's a very minor black outline in QT that isn't t here at all under openGL
16:01<GreyFoxx>I can see it on my monitor with 2 different mythfrontends running (different users and hostnames)
16:01<GreyFoxx>gbee: Yeah I left it at it's default quality
16:01<GreyFoxx>I'll play around with upping that to 100% :)
16:01<gbee>ok, didn't get far stepping through the threads - didn't even find the right thread, but I've got recordings starting so I had to give up for now
16:05<Cardoe>oh any chance some more apps can be made to print out their --help before connecting to the X server?
16:05<Cardoe>like mythwelcome for example.
16:08<danielk22>cardoe, I began looking at this problem a couple months back, but it got pretty harry, I wanted to create a command line parsing class though, it might be relatively simple to just process the --help before connecting.
16:08<Cardoe>danielk22: mmk
16:10<Cardoe>maybe I'll poke around at that
16:20<gbee>should be, I just moved up the --version output for that reason
16:21<gbee>little messy maybe
16:21<danielk22>Definately messy, but until someone wants to tackle the whole problem...
16:22<gbee>kormoc: getting some errors in the upcoming recordings page with firebug, looks related to unescaped strings in the AddTip JS stuff
16:22<kormoc>gbee, can you copy and paste the full line? I might not be escaping something correctly
16:24*MrGandalf escapes
16:24-!-MrGandalf [] has quit ["home"]
16:30<kormoc>something's strange there...
16:39<gbee>full script element -
16:39<gbee>noticed I missed a couple of lines
16:39<kormoc>Yeah, but those newlines should have been wiped...
16:42<gbee>shouldn the apostrophes be replaced with entities?
16:43<kormoc>nah, no need, it's using "" as the string delimiter
16:43<kormoc>it's the newline that's breaking it
16:45<gbee>I just have the habit of escaping everything, that avoids issues down the road
16:48<kormoc>true enough
16:48<kormoc>I'll poke at it in a few, I need to get some food
16:52-!-JoeyBorn [] has quit [Read error: 110 (Connection timed out)]
16:52<danielk22>I Mark Kendall here? Q: about #4513
16:54-!-danielk22 [] has left #mythtv []
16:59<gbee>anyone using upnp? Does music work?
17:00-!-danielk22 [] has joined #mythtv
17:04<gbee>GreyFoxx: you use upnp right?
17:06-!-MavT [] has joined #mythtv
17:13<janneg>danielk22: I don't think so.
17:14<gbee>okolsi: I'm looking at #4372, I've got a patch, would you mind testing it?
17:19<danielk22>it's ok, I'm looking at the XRandR patch now.
17:19-!-danielk22 [] has left #mythtv []
17:21-!-danielk22 [] has joined #mythtv
17:24-!-MaverickTech [] has quit [Read error: 113 (No route to host)]
17:35-!-dekar1 [] has joined #mythtv
17:47<gbee>whitespace/ident fixes count as a fix?
17:51-!-dekarl [] has quit [Read error: 110 (Connection timed out)]
17:53<janneg>gbee: less than a fix if it's whitespace change only. should be applied to both branches to avoid merge conflicts
17:55<justinh>oh bleh. my planned ui.xml work is in playbackbox.cpp. buggeration
18:00-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:04<justinh>mmm interesting
18:06-!-luisc [] has quit ["[BX] Just do it like Nike... BEEATCH!"]
18:12<justinh>gbee: any idea if contexts can be used on things like columns in listareas ?
18:12<justinh>buh. yeah they can! nevermind
18:13<justinh>all this time mangling themes & I never really paid that much attention to things other than filename, font & position
18:17-!-beavis [] has quit ["Verlassend"]
18:17<justinh>no points for guessing I've started taking a look at reducing the number of ui.xml windows
18:21-!-MrGandalf [] has joined #mythtv
18:22<justinh>I could regret not looking at this sooner actually. all those edits, all those hours & hours & hours
18:25<justinh>good opportunity to clean up some things like the brackets in the priority screen too
18:25<MrGandalf>Does anyone know how to make av_find_stream_info() only read a subset of data instead of reading constantly?
18:27<MrGandalf>trying to make myth behave better with bad streams but av_find_stream_info() locks up the decode thread
18:29<MrGandalf>and the bad stream seems to get past av_probe_input_format() due to its file extension only.
18:30-!-felix_da_catz [n=felix_da@] has quit [Read error: 110 (Connection timed out)]
18:31-!-jgarvey [] has quit ["Leaving"]
18:38<danielk22>MrGandalf: the TS stuff was largely rewritten by us because the ffmpeg code couldn't cope with broadcast streams where pids change, audio streams come and go and resolutions change, etc.. But the initial code was my first foray into ffmpeg and could have been done a lot better.. I've just never found the time to implement it correctly, and by correctly I also mean in such a way that it will be accepted upstream.
18:40<danielk22>When things change this should really be reported in another a/v/info stream and not done with callbacks. I'm not sure if that would actually help with the issue you're having with a broken file though...
18:41<janneg>ffmpeg has some improvements in the mpegts demuxer which are not yet merged due to my lazyness
18:42<gbee>storage group name is provided by the user, correct?
18:48<gbee>Captain_Murdoch: doesn't look as though the storage group code has any utf8 fixups? I started to add them in ProgramInfo but there is no point unless I add them everywhere else, where should I be looking?
18:49<MrGandalf>danielk22: It's no so much a problem as just wanting Myth to be a bit friendlier.. what happens is with bad or encrypted DVB streams the frontend gets stuck and when you manage to get it to exit you get that generic "error while displaying video" error. I was hoping to make it so that the dummydecoder produced frames all the up to there being good frames produced by ffmpeg/libmpeg2.
18:49<MrGandalf>danielk22: And I think I can do that really easily if av_probe_input_format() did't attempt to continue reading the entire stream trying to identify it.
18:51-!-waini [] has joined #mythtv
18:51<waini>hello and good evening
18:52<MrGandalf>I'll look around a bit.. there's probably a way in ffmpeg to do a quick check on the validity of the stream before proceeding to av_find_stream_info().
18:53<waini>i want to use a svn-version of mythtv-backend on my ubuntu-serer
18:53<justinh>waini: #mythtv-users
18:53<MrGandalf>er, rather av_probe_input_format() doesn't attempt to read the entire stream but av_find_stream_info() does.
18:53<waini>is there a "easy" way - or a less awful
18:53<waini>excuse me
18:53<waini>goog night
18:58<MrGandalf>danielk22: btw, I'm not trying to point out any problems with anyone's code. I wouldn't know good code from bad in most cases since I'm not a developer by trade.
18:59<justinh>pfft. that makes me something akin to a guy who cuts & pastes code & hopes it'll work. oh wait, that _is_ me
19:00-!-mattwire [] has quit ["Leaving"]
19:01<MrGandalf>though, in my defense, I have written a few Qt apps including my own TWS GUI (if anyone here knows what TWS/Unison Maestro is)
19:08-!-davilla [n=davilla@] has quit ["Leaving"]
19:19<danielk22>xris, you there? I just attached a patch to #3995... I don't have firewire so I can't test.. but it should fix the problem in that last stack trace.
19:24-!-grokky [n=grokky@] has quit []
19:31<Captain_Murdoch>gbee: "find ./ -name '*.cpp' | xargs grep -i StorageGroup" it's in a few more files than I thought. name isn't displayed in too many places though. I'm out of commission for the weekend starting tonight, family stuff, so I can't help too much before Monday. I shouldn't even be on the computer now, but had to run upstairs for something. :|
19:33<gbee>Captain_Murdoch: no problem, I've fixed the places I could find with a quick grep but I'll do a more thorough search at the weekend, I wasn't entirely correct plenty of places already did the utf8 conversions correctly
19:35<gbee>I really need someone who is affected by these bugs to let me know what other areas have problems, but ideally we need to wrapper the QT query stuff so that the utf8 conversions are done transparently
19:37<gbee>MSqlQuery would become MythQuery or something
19:37<MrGandalf>wouldn't be too hard
19:39<gbee>heh, MSqlQuery _is_ a wrapper for the QT query stuff ..
19:43<gbee>ok, wouldn't be hard but it would touch a lot of places and might require some cooperation
19:45-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
19:46<janneg>gbee: there is already a wrapper in the in qt4 branch
19:48-!-felix_da_catz [n=felix_da@] has joined #mythtv
19:48<gbee>janneg: include utf8 conversions on data yet? I realised that the existing class is a wrapper and the changes could be made there, just that they are invasive - if we can make the change as part of the QT4 port then it would be easier to slip in
19:54-!-|gunni| [] has joined #mythtv
20:02-!-grokky [n=grokky@] has joined #mythtv
20:08<MrGandalf>damn it, I hate it when Myth gets stuck tuning
20:12<janneg>gbee: yes, it was neccessary due qsqlquery changing null strings into NULL and empty strings being null string after converting them to utf8
20:16-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
20:21-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
20:28-!-davilla [] has joined #mythtv
20:34-!-skamithi [] has joined #mythtv
21:29-!-cecil [n=cecil@] has joined #mythtv
21:39-!-cesman [n=cecil@pdpc/supporter/sustaining/cesman] has quit [Read error: 110 (Connection timed out)]
21:39-!-cecil is now known as cesman
21:40<waini>how long does a build takes? (on 1 Gh - Machine)
21:40<waini>ohh sorry
21:40-!-waini [] has left #mythtv ["Apple forever!"]
21:41-!-jamesd_ [] has quit [Remote closed the connection]
21:50-!-jamesd [] has joined #mythtv
21:55-!-doobeh [] has joined #mythtv
22:06-!-skamithi [] has quit ["WeeChat 0.2.3"]
22:07-!-doobeh [] has left #mythtv ["Konversation terminated!"]
22:09-!-ahbritto [] has quit [Client Quit]
22:13-!-hmcgregor [] has joined #mythtv
22:14-!-hmcgregor [] has left #mythtv ["mythtv"]
22:37-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
22:54-!-JoeBorn [] has joined #mythtv
22:59-!-grokky [n=grokky@] has quit []
23:09-!-felix_da_catz [n=felix_da@] has quit [Connection timed out]
23:24-!-superm1 [n=superm1@ubuntu/member/superm1] has quit [Read error: 113 (No route to host)]
23:25-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
23:30-!-Kernel [n=free@] has joined #mythtv
23:31-!-Kernel [n=free@] has left #mythtv ["Leaving"]
23:47-!-felix_da_catz [] has joined #mythtv
23:56-!-feiner [] has joined #mythtv
---Logclosed Fri Feb 15 00:00:29 2008