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

---Logopened Fri Feb 15 00:00:29 2008
---Daychanged Fri Feb 15 2008
00:00-!-grokky [n=grokky@] has joined #mythtv
01:08<hads>How odd. A 'this timeslot every day' recording didn't record and shows as 'will be recorded at a later time instead'.
01:21<nordenm>I'm just curious, who decides what the scope of 0.21 and 0.22 is?
01:23<kormoc>That depends. Mr. Isaac decides when to release, the devs as a whole tend to decide what they want to put in before the release
01:40-!-feiner [] has quit [Read error: 110 (Connection timed out)]
01:42-!-feiner [] has joined #mythtv
01:49-!-eskil [] has joined #mythtv
02:05-!-xris [] has quit []
02:23-!-phix [] has quit [Remote closed the connection]
02:23-!-phix [] has joined #mythtv
02:25-!-davilla [] has quit ["Leaving"]
02:26-!-felix_da_catz [] has quit [Read error: 113 (No route to host)]
02:36-!-eskil [] has quit ["Ex-Chat"]
02:37-!-phix [] has quit [Remote closed the connection]
02:53-!-grokky [n=grokky@] has quit [Read error: 110 (Connection timed out)]
02:54-!-gnome42 [] has quit [Remote closed the connection]
02:56-!-phix [] has joined #mythtv
02:59-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
03:00-!-kormoc [] has joined #mythtv
03:01<kormoc>So we're not to submit fixes into -trunk at all, right?
03:53-!-ahbritto [] has joined #mythtv
04:01-!-felix_da_catz [] has joined #mythtv
04:10-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
04:32-!-ahbritto [] has quit [Client Quit]
04:32-!-felix_da_catz [] has quit [No route to host]
05:00-!-Netsplit <-> quits: kvandivo, justinh, Daviey, Vaelys, prg3, canatella, mace, CDev, Snow-Man
05:01-!-hemul_ [] has joined #mythtv
05:01-!-Netsplit over, joins: kvandivo
05:02-!-bio__ [] has joined #mythtv
05:07-!-Vaelys [i=awong@slammer.cs.Dal.Ca] has joined #mythtv
05:07-!-Snow-Man [] has joined #mythtv
05:07-!-CDev [] has joined #mythtv
05:07-!-justinh [] has joined #mythtv
05:07-!-prg3 [] has joined #mythtv
05:07-!-canatella [] has joined #mythtv
05:07-!-Daviey [n=dave@ubuntu/member/daviey] has joined #mythtv
05:08-!-hemul [] has quit [Read error: 104 (Connection reset by peer)]
05:08-!-bio_ [] has quit [Read error: 104 (Connection reset by peer)]
05:10-!-Dibblah [] has quit [Excess Flood]
05:12-!-_crichardson [n=crichard@] has joined #mythtv
05:13-!-crichardson [n=crichard@] has quit [Read error: 110 (Connection timed out)]
05:16-!-prg3 [] has quit [Connection timed out]
05:22<justinh>hmmm seems there's much more duplication in ui.xml than I first thought. gonna be able to save loads of effort by the time I'm done :)
05:29-!-mykeul [n=mykeul@] has joined #mythtv
06:03-!-gardz [] has joined #mythtv
06:16-!-Dibblah [] has joined #mythtv
06:29<gbee>error: invalid Python installation: unable to open /usr/lib64/python2.5/config/Makefile (No such file or directory)
06:31-!-jhulst_ [n=jhulst@unaffiliated/jhulst] has joined #mythtv
06:54<gbee>janneg: I don't want to mess around with the mpeg/ffmpeg code so would you mind looking at this possible leak?
06:56<gbee>doesn't look like it should leak so long as pes_free is called, but I've not followed the code path through
07:08-!-MrGandalf [] has quit ["work (again)"]
07:18-!-jhulst_ is now known as jhulst
07:38<gbee>Chutt: what's the purpose of the "bool global = (GetGlobalObjectStore() == parent);" global checks in XMLParseBase::doLoad() ? We're leaking the font there if global is true and I don't want to break anything in fixing it
07:44<janneg>gbee: that's not ffmpeg code but I don't know why it's leaking.
07:49-!-prg3 [] has joined #mythtv
08:10-!-skamithi [] has joined #mythtv
08:12-!-purserj [] has quit ["leaving"]
08:34-!-TelnetManta [n=benwilli@] has joined #mythtv
08:36-!-_gunni_ [] has joined #mythtv
08:36<Chutt>gbee, what's leaking?
08:37<Chutt>wrong leak
08:38-!-tstm [] has left #mythtv []
08:38<Chutt>i don't see how it's leaking in that function
08:39<Chutt>ooh, further down
08:40<Chutt>gbee, just another 'delete font' at like line 371 should work fine
08:44<skamithi>i'm confused about where to put bug fixes. if i commit to release-0-21-fixes will this be automatically merged into trunk at some point or do i have to do that myself ?
08:45<GreyFoxx>they will get merged automatically once a day
08:46<Chutt>well, no
08:46<Chutt>not yet
08:46<Chutt>but, if you commit _just_ to fixes, that should be ok
08:46<Chutt>we can do a big merge later on
08:46<GreyFoxx>I thought you had it automated :)
08:47<Chutt>too much possibility for bad things
08:47<GreyFoxx>makes sense
08:49<justinh>so then, before I spend a lot of time this weekend messing about bringing about some commonality to ui.xml - any fundamental objections?
08:50*rooaus thinks svn's new merge tracking is long overdue :)
08:50<justinh>there'll be theme breakage but I'll take care of that & make sure 3rd pary folks have opportunity to keep up
08:50<Chutt>justinh, wait until after the release.
08:51<justinh>Chutt: I wasn't planning on comitting anything from it until then. just checking nobody minds so I don't waste time dabbling with it
08:51<Chutt>i think it's kind of pointless
08:51<Chutt>if stuff needs rewritten anyway
08:52<justinh>I know where you're coming from wrt mythui but I think it might ease the transition a little
08:55<justinh>whether it's used or not it's a nice little exercise for me to practise with. godknows I need more experience
08:55<gbee>Chutt: I got the location of the leak wrong, both global and non-global fonts are added to an instance of FontMap - global ones to the globalfontmap, can't see where FontMap cleans up those but it doesn't seem as simple as it first looks
08:57-!-|gunni| [] has quit [Read error: 110 (Connection timed out)]
08:58<Chutt>whereever it calls GetGlobalFontMap()->Clear()
08:58<gbee>from the size of it, it's probably not worth spending any more time looking at it
08:59<Chutt>could probably stick it in the destructor of MythThemeBase() or whatnot
08:59<gbee>ahh, we're assiging a copy
09:00<Chutt>there _is_ a leak in that file
09:00<gbee>right, so we do need to delete font in xmlparsebase around line 371
09:06<justinh>woo them domes don't like it up 'em. no good for the Saudis cos the internal plastic deforms a bit at 60 deg C ambient. oops
09:08-!-mattwire [] has joined #mythtv
09:18-!-jdhall [] has joined #mythtv
09:22-!-Andui1 [] has joined #mythtv
09:25-!-f4lt3r_ [] has joined #mythtv
09:27-!-felix_da_catz [n=felix_da@] has joined #mythtv
09:28-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:35-!-Anduin [] has quit [Read error: 110 (Connection timed out)]
09:53-!-jdhall [] has left #mythtv []
10:04-!-danielk22 [] has left #mythtv []
10:29-!-felix_da_catz [n=felix_da@] has quit [" HydraIRC -> <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)"]
10:31-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"]
10:47-!-MrGandalf [] has joined #mythtv
10:49*gbee has finally tired of valgrinding
10:54-!-danielk22 [] has joined #mythtv
10:59-!-nordenm [] has quit []
11:01-!-jmk_ [n=jmk@] has joined #mythtv
11:04-!-nemik [] has joined #mythtv
---Logclosed Fri Feb 15 11:14:25 2008
---Logopened Fri Feb 15 11:14:41 2008
11:14-!-mikegrb [] has joined #mythtv
11:14-!-Irssi: #mythtv: Total of 96 nicks [0 ops, 0 halfops, 0 voices, 96 normal]
---Logclosed Fri Feb 15 11:23:16 2008
---Logopened Fri Feb 15 11:23:19 2008
11:23-!-mikegrb [] has joined #mythtv
11:23-!-Irssi: #mythtv: Total of 97 nicks [0 ops, 0 halfops, 0 voices, 97 normal]
11:23-!-Irssi: Join to #mythtv was synced in 15 secs
11:24-!-Jordan [] has left #mythtv []
11:25-!-Bathory [] has joined #mythtv
---Logclosed Fri Feb 15 11:29:45 2008
---Logopened Fri Feb 15 11:35:38 2008
11:35-!-mikegrb_ [] has joined #mythtv
11:35-!-Irssi: #mythtv: Total of 96 nicks [0 ops, 0 halfops, 0 voices, 96 normal]
11:35-!-Irssi: Join to #mythtv was synced in 20 secs
11:36-!-mikegrb [] has quit [Read error: 104 (Connection reset by peer)]
11:42-!-mykeul [n=mykeul@] has left #mythtv []
11:43-!-gnome42 [] has joined #mythtv
12:12<gbee>server is down
12:13-!-xris [] has joined #mythtv
12:14<gbee>xris: you have access to reboot the server?
12:15*jams wonders if snow-man is about
12:16<janneg>Snow-Man, Chutt: ^^^
12:16<Snow-Man>is it down?
12:17-!-jgarvey [] has joined #mythtv
12:18<gbee>trac loads very slowly, but etc isn't responding at all
12:18<janneg>trac was slow, and now the webserver timeouts
12:20<gbee>server seems to have been having a lot of problems this week
12:20<Chutt>www seems fine
12:20<Chutt>unless Snow-Man killed stuff off already
12:20<Snow-Man>havn't touched anything
12:21<Chutt>it's probably trac acting up
12:21<janneg> doesn't loads for me
12:22<Chutt>server load's very high
12:22<danielk22>I had some problems with trac yesterday, but they cleared up after a little while.
12:22<Chutt>outta ram, looks like
12:27<Chutt>should be better momentarily
12:28<Chutt>(it was trac, as usual)
12:28<Chutt>apache had a ton of very large instances sitting around
12:29<Chutt>xris, did we really only get 2GB of ram on this thing?
12:29<Chutt>(if you can remember that far back) =)
12:29<xris>can't remember back that far
12:29<xris>but if that's what free says, I'd believe it
12:30<xris>should be more than enough RAM for web serving, though
12:30<Chutt>yeah, but it's not just that
12:30<Chutt>mailing list (python + mailman use a bunch of ram)
12:31<Chutt>trac (python + apache == bad)
12:32<xris>could sell some mythtv tshirts to pay for ram. :)
12:33-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
12:33<Chutt>ram's pocket change these days
12:37<xris>depends on how much you want
12:37<xris>once he pops online, we can ask kormoc to look up what the machine takes and how many slots it has available
12:47-!-ahbritto [] has joined #mythtv
12:57-!-nordenm [] has joined #mythtv
12:58-!-danielk22 [] has left #mythtv []
13:01-!-danielk22 [] has joined #mythtv
13:06-!-JoeBorn [] has joined #mythtv
13:11-!-BathoryQuorthon [] has joined #mythtv
13:15-!-beavis [] has joined #mythtv
13:17<xris>j-rod: looks like your old employer went belly up
13:18<xris>good choice to move to red hat. :)
13:19<gbee>janneg: is #2498 still relevant? Last update to the ticket was a year ago
13:19<janneg>gbee: I'm searching for the sample atm
13:22-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
13:47-!-PointyPumper [i=Pintlezz@] has quit [Read error: 104 (Connection reset by peer)]
13:47-!-briand [] has joined #mythtv
13:48<gbee>CDev: there?
13:52<CDev>gbee: for a few minutes.
13:53<gbee>just wondering if you've any thoughts on or objections to
13:53*CDev goes and looks at the patch
13:59<CDev>I don't think it's the best solution. If I am reading the patch correctly, you will have registered 2 instances of MythXML.
13:59<gbee>not that there are any good reasons to disable upnp anymore (that I know of)
14:01-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
14:01<CDev>In the original code, I would move the if (Initialize(... line below where we register the MythXML extension is done.
14:01<CDev>Also move the IP & bDisableUpnp conditions down as well.
14:02<CDev>It shouldn't hurt anyone if we load the devicedesc into memory all the time. It's just data.
14:02<CDev>That way MythXML is initialized correctly either way, with upnp & without.
14:02<CDev>Make sense?
14:03-!-lcase [] has joined #mythtv
14:05<gbee>I don't see the need to disable upnp personally, but assuming it still has problems and that some people will want to disable it then it would be best if the mythxml stuff still works which is why I'm considering getting that functionality into 0.21
14:06<CDev>I agree completely.
14:09<gbee> << something like that work for you?
14:10<CDev>looks about right.
14:23<gbee>svn is slow again :(
14:24-!-ahbritto [] has quit [Client Quit]
14:31-!-jwhite [] has quit ["Leaving"]
14:46-!-czth__ [n=dbrobins@nat/microsoft/x-e34203b464ccd929] has joined #mythtv
14:50-!-JoeBorn [] has joined #mythtv
15:00-!-lcase [] has quit []
15:03-!-czth_ [n=dbrobins@nat/microsoft/x-c73f14de04a2086a] has quit [Read error: 110 (Connection timed out)]
15:06<justinh>bah I forgot contexts don't set visibility by themselves
15:06<Chutt>gbee, load's low on the box
15:08<justinh>and to use contexts on individual elements of containers will be nasty. might have to sack this as a bad idea after all since defining loads of different areas differentiated by context won't give any real advantage
15:09-!-davilla [n=davilla@] has joined #mythtv
15:10<xris>GreyFoxx: updated patch?
15:15<xris>Chutt: looks like 8 slots of pc3200/DDR400 Registered ECC interleaved.. 2 slots currently ued.
15:22*justinh wonders how mythui would get around this context issue & having to set each & every area visible or not in the code itself
15:29<justinh>yeah I fully realise now why contexts weren't used to use more common windows in ui.xml . oh boy do I ever
15:35<j-rod>xris: yeah, I knew about LNXI going kaput before it was public, still have some friends that, well, worked there...
15:35<j-rod>working on hooking some of them up with groups in RH that are hiring
15:38-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
15:38-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
15:42<xris>apparently many people had suspicions after they didn't show up for sc07
15:43<gbee>anyone explain why using VERBOSE in a dtor might trigger a segfault?
15:43<kormoc>who went under?
15:44<xris>kormoc: you see the link I sent you earlier today?
15:46<j-rod>basically, company-wide meeting yesterday, during which everyone was told "we're locking the doors at the end of business today, never to be unlocked again"
15:47<j-rod>one of my buddies there had a bad feeling, and packed his desk up Wednesday
15:47<j-rod>(well, he wasn't the only one that had a bad feeling)
15:47<gbee>justinh: not really following what you've been saying, guess if I'm honest I'm concentrating on other things right now, but what's visibility got to do with context? Using contexts in myththemeddialog with a redraw after changing it should handle visibilty just fine
15:47<xris>sucky for them
15:47<j-rod>supposedly, they're going to get half-decent severance packages
15:47<j-rod>but damn.
15:47<xris>at least they're getting severance
15:48<j-rod>yeah, better than simply not having any income all of a sudden with zero warning
15:48<kormoc>xris, ahh, I thought they were just another vendor (tm)
15:49<kormoc>wait, SGI? as in *the* sgi?
15:49-!-PointyPumper [i=Pintlezz@] has joined #mythtv
15:49<justinh>gbee: doh. I've been daft then... I looked in the wrong program for an example of context to job my memory
15:49<xris>kormoc: no.. simech competitor, j-rod used to work for them
15:49<xris>kormoc: sgi bought them
15:49<j-rod>yeah, not a good sign when you're bought by SGI... :)
15:49<kormoc>Yeah, really :)
15:49<MrGandalf>that's sad
15:49<xris>j-rod: well, bought by the former ceo
15:49<MrGandalf>I actually liked SGI
15:49<j-rod>guy left SGI, came to LNXI as CEO, then went back to SGI
15:50<justinh>gbee: I should be looking at a non-mythui example methinks. thanks for pointing out what i've clearly already forgotten
15:50<gbee>justinh: not that I've written a complete example of a libmyth window, but the ones I've seen all worked that way
15:50<j-rod>feels mildly like possibly something less than ethical in there, but..
15:50<j-rod>pic of the sgi ceo by my buddy at lnxi, in lnxi font and colors
15:51<justinh>I thought ooo I used contexts in mythappearance so I'll look there. then saw the visibility setting stuff in setContext(). all mixed up, am I
15:52<gbee>funny, could have sworn I was reading something about LNXI in the last week
15:52<justinh>the fact it'd been ported over to mythui which doesn't do contexts yet had er.. well.. ahem. guess I should turn my work box on again then :)
15:59<gbee>so the story is that SGI guy joins LNXI as CEO, a while later LNXI shuts it's doors and SGI buy up their assets at a cutprice rate? Definately dodgy
16:01<j-rod>SGI guy joins LNXI as its CEO, then bails to take over as CEO at SGI again, and shortly thereafter, buys out LNXI
16:02<xris>j-rod: yeah, it's definitely a bit odd-looking
16:02<xris>smells of the 80s. :)
16:05<xris>anyone know of anyone going to OSCON this year?
16:05-!-eskil [] has joined #mythtv
16:06<kormoc>xris, I do
16:06<xris>ah, lame
16:06<kormoc>Well, I'm trying...
16:06<kormoc>Of course
16:06<xris>she's at all of those shows, though...
16:06<kormoc>You didn't specify...
16:07<kormoc>You going?
16:07<xris>I'm trying to come up with a good reason to get work to sponsor the trip... but since people started talking about a mythtv dev get-together, it also sounded like a good place for it.
16:07-!-ahbritto [] has joined #mythtv
16:07<kormoc>I'm trying to go, but the mysql con is before it on my list, so I'm pushing for that one first
16:08<kormoc>I should email Ken again bout it all...
16:09<xris>mysql would be useless for me in my new job. and we missed the west coast postgres one.
16:09<kormoc>MySQL 6 is looking really snazzy in the subquery relm
16:10-!-dorao [] has joined #mythtv
16:10<xris>I'm digging all of these other data types in pg. except that 8.3 introduced mandatory hard-typing... so you can't compare string to int without type casting.
16:12-!-dorao [] has left #mythtv []
16:13<kormoc>hard typing is one of those good habits anyway
16:13<xris>yeah, but annoying to implement in 250k lines of code.
16:13<xris>thankfully I'm not the one doing it.
16:15<danielk22>xris: have you looked at the patch on #3995?
16:16<xris>danielk22: was just compiling it in
16:16<xris>had a compile error so I need to test the compile without the patch
16:17<danielk22>it should compile, that's really the only test I could do..
16:17<xris>fighting a nasty cold, so work + mythtv + cold is overtaxing my brain
16:17<xris>really want to know why these zero-byte recordings even happen.
16:17<xris>would love it if the backend could detect them and re-initiate the recording on its own.
16:18<danielk22>me too, and I just got over another bad cold a couple weeks ago.
16:18<xris>anyway, compile error could have been the particular checkout I made, or a conflict with some other patches I was running.
16:18<gbee>we should be able to detect when we aren't getting data from the card/firewire and reinitialise in those cases
16:18<xris>figured it should be easy
16:19<xris>it's weird when it happens, though... firewire box goes wonky sometimes.. changes ports, etc.
16:19<danielk22>We need a firewire signal monitor to actually detect if there is data, I think we already did this on one of the other signalmonitors, let me check..
16:19<xris>ok, it built that time, but I can't test it until this recording finishes... anthony bourdain is more important. :)
16:20<gbee>it would be a nice change for dvb, dodgy drivers cause zero byte files quite often
16:21*xris has pondered just getting an hd homerun to avoid some of these hassles.. but no spare cash if I want to have extra fun in italy this summer
16:21<danielk22>Hmm, it looks like I was thinking of the encryption status monitoring for DVB. It does look at the data, but it doesn't actually have "I see data" signal
16:21<gbee>a failure to obtain data after X tries should then cause the recording to fail and the history forgotten so that it might record a repeat at a later date/time
16:21-!-anykey_ [] has quit ["leaving"]
16:21<danielk22>yeah, there is a ticket for this I think.. it's just not the highest priority.
16:22<danielk22>I really want to fix the channel scanner more...
16:23<xris>danielk22: yeah, I created that ticket. :)
16:23<xris>or one like it, anyway
16:23-!-purserj [] has joined #mythtv
16:24<xris>helped with the current code that re-schedules any recordings that have a zero-byte version in the recordings list, which helps with some stuff, but can also re-record unnecessary stuff if both a full version and a zero-byte version exist in "deleted"
16:25<danielk22>Ticket #2931, is one, someone else reported it.
16:25<mattwire>danielk22: have you tried scanning for dvb-s recently? It doesn't seem to be enabling voltage as far as I can see though it says it is
16:25<danielk22>No, I haven't tried in several months, but I also haven't changed the code..
16:25<danielk22>are you using a dish legacy switch?
16:26<mattwire>no it's just a single lnb
16:26<mattwire>thing is it gets a carrier fine with dvbscan
16:26<danielk22>circular or linear?
16:26<mattwire>universal (european)
16:26<danielk22>hmm, that should work.
16:26<mattwire>ie. 13 and 17v
16:27<mattwire>dvbtune sorry
16:27<mattwire>it used to work
16:27<danielk22>ah #3872, isn't mine so I didn't see it.
16:27<mattwire>but i moved the dish recently to a different satellite so had to clear out transponders and now it doesn't get a lock
16:28<xris>would be nice if trac actually let you link tickets.
16:28<danielk22>matt: all I can thing of is something to do with the multirec merge, you might try reverting to before it.
16:29-!-MrGandalf [] has quit ["home"]
16:29<xris>wondering how much work it'd be to write my OWN ticket system... but someone would probably want me to do it in ruby/rails instead of something sledge-hammery like perl.
16:29<danielk22>xris: just write a comment with #ticketnum in it in each ticket.
16:29-!-TelnetManta [n=benwilli@] has quit ["Ex-Chat"]
16:29<xris>danielk22: I did, long ago. just not quite as nice as how jira does it... a "links" section at the top, etc.
16:30<mattwire>i might have to, but would rather not if I could help it cos the satellite cards not on the dev box :(
16:31<mattwire>the logs seem to say it is enabling voltage but when i had my meter in series with the cable it was indicating that there was no voltage on the line
16:32<mattwire>whereas with dvbtune there is voltage there
16:33<danielk22>matt: pls try reverting. If that fixes it, that will go a long way to helping us come up with a solution...
16:43<Cardoe>xris: trac 0.11 will allow ticket depends afaik
16:43<xris>Cardoe: different than linking
16:44<xris>and it takes a plugin and some wonky config magic, if I recall correectly.
16:44<xris>for some reason the main authors don't think dependency is necessary
16:44<xris>same with how I think they way they handle svn commit messages needs to be addressed to separate them from ticket comments.
16:46<xris>but actually, I think that plugin is for links, not just dependency, so it would help.
16:46<xris>my problem is that I've come to see the ticket manager as a project tracker, and trac doesn't quite cut it for that.
16:56<gbee>justinh: I've only just realised what you were saying, mythui doesn't have an equivalent to the concept of contexts yet (maybe you could argue that's what statetypes offer) and rather than implement something I just added a temporary solution when converting mythappearance.
16:58<gbee>so in that respect, mythappearance can't be considered an example of how contexts will be handled after we've moved to mythui or how contexts work in libmyth
17:01<cesman>I see there is a 0.21-fixes branch already
17:01<cesman>has 0.21 been frozen?!
17:02-!-adante_ [] has joined #mythtv
17:02<jams>cesman- bug fixes only.
17:02<jams>no new features
17:03<cesman>so 0.21 is frozen?
17:03<gbee>cesman: aiming for release on 1st March (or close to it)
17:03*cesman needs to get busy w/ KnoppMyth
17:04<gbee>cesman: feature frozen (mostly) yeah, but lots of outstanding bug fixes to be applied
17:04<gbee>we're trying something a little different this time, branching early etc
17:04<cesman>so, where should I pull from to get ready?
17:05<cesman>0.21-fixes obviously
17:06<gbee>mythweather is one area where more than just bug fixes need to be applied
17:09<jams>gbee- what do you think command line option to NOT show the database configuration screens if mfe can't contact the database?
17:11<gbee>jams: what sort of use case are you thinking about?
17:12<jams>well if the mysql database happens to be down or rebooting. I don't want to see those configuration screens and possibly screw up the configuration.
17:12<gbee>ok, that sounds reasonable :)
17:13<jams>obviously default behaviour will not be changed.
17:13-!-main [] has joined #mythtv
17:14<main>Hello I have mythtv working fine with one controller but when i put in a secind the first one stoped working any ideas?
17:14<xris>main: please read the topic
17:14<main>ah shit my bad
17:14<gbee>of course, just being obtuse by asking why you want the feature ;)
17:15<main>eh to play snes though it
17:15<jams>it was broken for a while and I loved it that way.
17:15-!-main [] has left #mythtv ["Leaving"]
17:15<gbee>I started to say that it was a good idea, but then realised that I'd rather see the auto-discovery screen while I waited for the database come back online than have mythfrontend just exist
17:15<jams>then someone had to come along and fix it.
17:16<jams>gbee- the difference is I don't use the auto-discovery stuff
17:16<jams>it doesn't work for me
17:16<gbee>well doesn't work for me either right now, it's broken .... :p
17:17<jams>i was thinking of not even touching that screen. The option i proposed would only be valid with -d
17:17<gbee>but when it does work, I really like it and it's very handy for switching between backends
17:17-!-adante [] has quit [Read error: 110 (Connection timed out)]
17:17-!-adante_ is now known as adante
17:20<gbee>come up with a patch and we'll take a look :) Can't promise that everyone will like the idea, but it seems harmless enough
17:20<jams>gbee- will do.
17:20<jams>it can wait in line beside the main menu popup patch.
17:22<jams>was thinking of expanding that to include some jumppoints, but then decided against it.
17:29-!-lsobral [n=sobral@] has quit [Remote closed the connection]
17:36-!-dekarl [] has joined #mythtv
17:40-!-f4lt3r_ [] has quit ["Ex-Chat"]
17:41-!-renatofilho^_ [n=renato@] has quit ["Ex-Chat"]
17:47-!-Andui1 [] has quit [Read error: 113 (No route to host)]
17:49-!-MrGandalf [] has joined #mythtv
17:50<MrGandalf>danielk22: regarding ticket 4566 (tuning stuck), do you mean active or passive EIT?
17:50<MrGandalf>k, I'll disable it..
17:51-!-dekar1 [] has quit [Read error: 110 (Connection timed out)]
17:51-!-Anduin [] has joined #mythtv
17:51<MrGandalf>it always happens while tuning from tuner 5 to tuner 5 or from tuner 5 to anything else.. tuner 5 is the only one set for multirec, but only 1 of 3 tuners
17:54-!-jamesd [] has quit [Read error: 110 (Connection timed out)]
17:56<MrGandalf>ok, so I thought setting xmltvgrabber to 'none' would disable eit.. guess not
17:58-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit [Remote closed the connection]
17:58-!-beavis [] has quit ["Verlassend"]
17:59<gbee>MrGandalf: trunk includes a "disable active EIT" option under each cards advanced settings
17:59-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
17:59<gbee>and then there is a global setting which disables EIT altogether ... somewhere ... I think
17:59<MrGandalf>gbee: thanks, but I think daniel wanted me to test with passive disabled as well
18:00-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit [Client Quit]
18:01<gbee>"Perform EIT Scan" on the video source page
18:01<gbee>Changing the listings grabber doesn't have any effect on EIT, it's possible to configure both an XMLTV grabber and EIT on the same source
18:02<MrGandalf>ya know, the bug in question, which I happen to get every 1-2 days, I JUST got again
18:02<gbee>always works that way :)
18:02<MrGandalf>danielk22: if you have anything you'd like me to try while the time is good..
18:02<gbee>either that, or you report it and then never see it again ;)
18:03<MrGandalf>right :(
18:03<MrGandalf>well, that's ok as well
18:04<danielk22>MrGandalf: Was EIT disabled?
18:05<MrGandalf>no, hadn't gotten that far yet
18:05<MrGandalf>active was running on two cards and passive on card 5
18:05<danielk22>ok, then I don't need another backtrace. it'll probably just tell me the same thing..
18:06<MrGandalf>I thought maybe you'd be a gdb wizard. :)
18:14-!-jmk_ [n=jmk@] has quit ["Leaving"]
18:16<MrGandalf>danielk22: managed to get it to fail.. eit disabled
18:17<danielk22>if you could grab a backtrace + send me the logs... could be very valuable..
18:17-!-jgarvey [] has quit ["Leaving"]
18:17<MrGandalf>you want me to do any stepping on the stuck thread?
18:19<danielk22>you're sure which thread is the stuck one?
18:19<danielk22>the setchannel one?
18:19<MrGandalf>I'm pretty sure.. it loops
18:19<xris>danielk22: not sure if it's your patch or not, but I'm getting a lot of weird slowdowns in scheduler and query_recorded calls now
18:19<danielk22>k, yeah an more info is useful..
18:20<Chutt>i wonder if i should update trac
18:20<danielk22>xris: sounds unrelated, unless CPU usage has spiked do to the busy loop.
18:20<Chutt>maybe a newer version will have fewer bugs
18:21<xris>no spike
18:21<MrGandalf>looks like it loops in while (!HasFlags(kFlagRingBufferReady))
18:21<xris>no death, but something's definitely spinning... might the loop get in the way of queries about the recording?
18:22<xris>tried to delete a zero-byte in progress recording and mythweb is just spinning on that page.
18:22<danielk22>MrG: That's definately interesting...
18:23<danielk22>xris: attach gdb and then do a "thread apply all bt" and it to me...
18:24<xris>will take me a sec to remember how to do gdb...
18:24-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
18:25<xris>I'm missing a bunch of symbols
18:26<MrGandalf>danielk22: I've step'ed all threads directly relating to runing and they all step into that loop
18:28<danielk22>MrG: so we need to figure out where the flag is supposed to be set, and why it isn't being set..
18:28<danielk22>was this bfr or after signal monitoring?
18:28<danielk22>thx xris
18:29<xris>hope it helps
18:29<xris>recompiled without the patch to see if I get similar behavior
18:29<danielk22>yep, it looks like there is something wrong with the patch. it looks like it is stuck in FirewireSignalMonitor::Stop ()
18:31<gbee>xris: do the perl bindings need/use utf8 conversions on things like title, storagegroup names etc?
18:31<xris>no clue
18:32<xris>perl's pretty smart about that sort of stuff, but might need it if the db runs in a different lang than the filesystem
18:53<MrGandalf>danielk22: I'm guessing near the end of HandleTuning() within if (HasFlags(kFlagWaitingForRecPause)) recorder->IsPaused() is false thus TuningFrequency() isn't called and kFlagRingBufferReady isn't set.
19:01<gbee>stuarta, justinh: just a heads up, looks like some things have moved around, might need to do a rescan or risk missing recordings
19:02<justinh>the bastards. why are they always doing this for NO GOOD REASON?
19:03<justinh>good thing I have a spare box I can do a sly scan on :)
19:07<justinh>gbee: just done a diff of last week's .conf with a one just taken. only changes are the channels which go off air at certain times
19:08<gbee>justinh: Mux A had some changes here, enough that I could tune Five*
19:09<gbee>no great loss you might think ;)
19:09<justinh>wtf are they doing anyway?
19:10<gbee>hmm, maybe it's not them ... rescanned and it's still giving me PMT errors
19:11<MrGandalf>danielk22: I think the actual stuck thread is 3 in DeviceReadBuffer::WaitForUsed()
19:11<gbee>any recent changes to the dvb stuff? Something that might break tuning?
19:11<MrGandalf>danielk22: RunTS() never ends so the recorder is never paused
19:13<danielk22>ahh, it's the pause and wait code which is incorrect..
19:14<MrGandalf>request_pause probably isn't getting set
19:14<danielk22>right. But I'
19:14<MrGandalf>but I don't see where it ever does
19:14<danielk22>m not sure it should be.
19:14-!-jamesd [] has joined #mythtv
19:15<danielk22>Pause shouldn't really pause if there is another virtual recorder using the stream..
19:15<MrGandalf>I see.. but in this case there wasn't
19:15<justinh>gbee: maybe your local tx is borked
19:16<MrGandalf>SetRequestPause() looks like it only gets called out of DeviceReadBuffer() and only setting it to false.. seems less than usefull
19:16<danielk22>MrG: When all the listeners are removed it should stop
19:16<MrGandalf>but RunTS() never exits
19:17<gbee>justinh: probably, seems to have recorded off that mux just fine earlier today so probably a temporary glitch
19:17<danielk22>The Pause code for the DRB is not supposed to be used by the DVBRecorder.
19:18<justinh>gbee: btw sorry about the brain fart earlier. I was genuinely going to give up on it - wasn't asking for help in a roundabout way. totally forgot how I'd done the contexts in mythappearance before you converted it ;)
19:18<danielk22>MrG: Yeah, it's definately borken, but I think I'm going to have to look at this in the morning when I'm more fresh...
19:18<justinh>embarrassing since it was only like the other week though!
19:19<gbee>pretty exhausted at the end of a long week, so if I don't seem to be as interested as I normally am that's the reason :)
19:19<MrGandalf>danielk22: np, glad I could challenge ya :)
19:20<MrGandalf>time for beer
19:20-!-davilla_ [] has joined #mythtv
19:21<gbee>in fact I need to get to bed, if I don't go now it will be another couple of hours before I look at the clock ;)
19:23<justinh>heh nn
19:25<j-rod>piss. I got an hvr-1500, but the stupid thing won't go all the way into the expresscard slot on my thinkpad. wtf.
19:28-!-davilla [n=davilla@] has quit [Read error: 110 (Connection timed out)]
19:29<j-rod>maybe I'm on crack, and that's as far as it goes in...
19:45<MrGandalf>if you were on crack you wouldn't care
19:46-!-Hannibal- [] has joined #mythtv
19:47-!-mattwire [] has quit ["Leaving"]
19:49-!-davilla_ [] has quit [Read error: 113 (No route to host)]
19:55-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
19:58-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
20:13-!-leprechau [] has quit [Read error: 113 (No route to host)]
20:15<kormoc>MrGandalf, you never heard that all developers are on crack? It's why code is how it is rather then how it should be :P
20:16-!-leprechau [] has joined #mythtv
20:18<MrGandalf>kormoc: At work I see MANY examples of exactly what you're talking about.. enterprise apps that were no doubt written by people on crack.
20:18-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"]
20:20<MrGandalf>example, Manugistics. It takes 14gigs of memory to run for a hand full of users, takes a box with at least 4 Itanium2 processors and it's a web app but users use it through a web browser on Citrix because it's faster than using a web browser on their desktops.
20:22<MrGandalf>as far as commercial software goes, it seems that hardware is getting faster and faster, better and better while software gets worse by leaps and bounds.
20:22*MrGandalf steps off his soap box
20:23<danielk22>MrG: ya wanna try something for #4566? add "if (_device_read_buffer) _device_read_buffer->Stop();" bfr SetRunning(false); in DVBStreamHandler::Run(void)
20:25<danielk22>if my flu hazed brain isn't betraying me it should fix it.
20:25-!-davilla [] has joined #mythtv
20:31<MrGandalf>sorry, work called.. and I think I have to reboot the backend.. ivtv died.. odd, haven't had one of those in a long time..ivtv_sched_VBI
20:32<MrGandalf>danielk22: you want that added to the beginning or end?
20:33<MrGandalf>ah, bfr.. sorry
20:33<MrGandalf>you mean bfr SetRunning(true)
20:36<danielk22>It shouldn't actually matter
20:48-!-eskil [] has quit ["Ex-Chat"]
20:48-!-eskil [] has joined #mythtv
20:50-!-|gunni| [] has joined #mythtv
20:53-!-grokky [] has joined #mythtv
20:58*MrGandalf changes channels like mad testing..
21:02<MrGandalf>ok, that's about 15 channels or so..
21:05<danielk22>and how many did it take bfr?
21:05<MrGandalf>about 5 or 6
21:05<MrGandalf>I haven't made it fail yet
21:05<MrGandalf>my thumb is getting tired changing channels :)
21:06<danielk22>paper weight around?
21:06<MrGandalf>I'd say if it lasts through the weekend it's a success
21:06<MrGandalf>heh :)
21:07<MrGandalf>very stable though.. not one issue
21:09<MrGandalf>33 channel changes, all flawless
21:09-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
21:10<MrGandalf>nice work, thanks!
21:10*MrGandalf has to come up with a bigger challenge next time
21:11<danielk22>hehe, it may still break...
21:11<MrGandalf>well, after now 34.. it's a whole lot better, but you could be right.
21:12<MrGandalf>it did look very much timing related
21:13-!-|gunni| [] has quit ["KVIrc 3.2.4 Anomalies"]
21:15<danielk22>yeah, I think if it was in WaitForUnused() AND there was no data in the driver buffers when the last listener was removed it would stall forever.. but if there was data, or it wasn't waiting on data it wouldn't stall.
21:16<MrGandalf>that makes sense
21:16<danielk22>So probably a little driver dependant too. Cleaner drivers would cause this more than sloppy ones, and also it would be more likely if the mux couldn't be tuned.
21:17<danielk22>I'll look over it tmrw and if it still looks right to me in the morning I'll commit it.
21:17<MrGandalf>that's the last big bug I have
21:18<MrGandalf>and for dvb, I use Genpix and the drivers are very stable and seemingly well written
21:18<MrGandalf>but I think that's because they were partially written by the hardware developer of the Genpix
21:19<MrGandalf>the engineer I mean
21:20<danielk22>Heh, that doesn't always guarantee good drivers.. look at the VIA OpenChrome drivers..
21:20<danielk22>I mean the ClosedChrome drivers :]
21:20<MrGandalf>no, you're right, but the bulk of it was written by someone who knew what he was doing
21:20<danielk22>The OpenChrome ones are reverse engineered.
21:21<MrGandalf>never tried them
21:21<danielk22>You're blessed :)
21:21<MrGandalf>I can go months without dvb card or driver issues
21:22-!-MaverickTech [] has joined #mythtv
21:30-!-_spike [i=spike@] has quit [Read error: 104 (Connection reset by peer)]
21:30-!-_spike [] has joined #mythtv
21:36-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
21:37<MrGandalf>with new mythtv versions, -dishpro isn't needed (nor wanted)
21:40-!-MavT [] has quit [Read error: 113 (No route to host)]
21:47<kormoc>gbee, see if [16053] fixes your popup issues?
21:51-!-eskil [] has quit ["Ex-Chat"]
21:56-!-jamesd [] has quit [Read error: 110 (Connection timed out)]
22:03-!-ahbritto [] has quit [Client Quit]
22:12-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
22:13-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
22:16-!-danielk22 [] has left #mythtv []
22:24-!-BathoryQuorthon [] has left #mythtv ["Great Hall Awaits a Fallen Brother"]
22:51-!-djc_ [n=djc@] has quit [Read error: 110 (Connection timed out)]
22:52-!-djc_ [n=djc@] has joined #mythtv
23:07-!-JoeBorn [] has joined #mythtv
23:11-!-JoeyBorn [] has joined #mythtv
23:13-!-TelnetManta [] has joined #mythtv
23:15-!-JoeXBorn [] has joined #mythtv
23:23-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
23:28-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
23:30-!-JoeXBorn is now known as JoeBorn
23:31-!-grokky [] has quit []
23:33-!-JoeyBorn [] has quit [Read error: 110 (Connection timed out)]
23:43-!-skamithi [] has quit ["WeeChat 0.2.3"]
23:54-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Remote closed the connection]
23:55-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
23:58-!-tlichti [n=chatzill@] has joined #mythtv
---Logclosed Sat Feb 16 00:00:52 2008