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

---Logopened Sun Feb 24 00:00:34 2008
00:04-!-grokky [] has joined #mythtv
00:09-!-gnome42 [] has joined #mythtv
00:13-!-BathoryQuorthon [] has left #mythtv ["Great Hall Awaits a Fallen Brother"]
00:27-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
00:47-!-grokky [] has quit []
01:17-!-mzb [] has quit ["Time to quit"]
01:17-!-acc_ [] has joined #MythTV
01:19<acc_>Hello, #MythTV. I'm in the process of setting up 0.20.2 on a Mac Mini. Since I don't have a TV capture/tuner card, do I need to set up a backend at all? All I want to do with MythTV is watch AVI/MPG/etc. videos that I'v'e got on a fileserver.
01:20<acc_>... and listen to MP3/OGG/etc., though I'm not 100% sure it can do that.
01:20-!-mzb [] has joined #mythtv
01:27<okolsi>acc_: see topic and check out #mythtv-users
01:27-!-map7 [] has joined #mythtv
01:27-!-map7 [] has left #mythtv ["Leaving"]
01:34<acc_>okolsi: Thanks, sorry for the noise.
01:34-!-acc_ [] has left #MythTV []
01:38-!-cattelan [] has quit ["Leaving"]
02:19-!-gnome42 [] has quit [Remote closed the connection]
02:35-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Remote closed the connection]
02:35-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
02:42-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Remote closed the connection]
02:42-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
02:55-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Remote closed the connection]
02:56-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
03:20-!-laga_ is now known as laga
03:46-!-xris [] has quit []
04:00-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Remote closed the connection]
04:00-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
04:10-!-rooaus [] has left #mythtv []
04:21-!-superm1 [n=superm1@ubuntu/member/superm1] has quit [Remote closed the connection]
04:41-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Read error: 110 (Connection timed out)]
05:15-!-czth__ is now known as czth
05:23-!-richards [] has quit [Remote closed the connection]
05:27-!-gammelmark [] has joined #mythtv
05:30<gbee>stuarta, janneg: looking at #4632 .... so passive scanning is really just active scanning but confined to the currently tuned mplex?
05:33<gbee> just modifies tv_rec.cpp, but I wouldn't have thought that tv_rec was involved in active scanning and if it is, what TVState would be used? Doesn't seem that we have a state which just means "not recording, not watching, but grabbing EIT data"
05:49-!-rxd [n=rxd@] has joined #mythtv
05:50-!-rxd [n=rxd@] has left #mythtv []
06:10-!-_gunni_ [] has joined #mythtv
06:24<janneg>gbee: it has kFLagEITScannerRunning and I would say active scanning is passive scanning plus changing multiplexes. it's the same but I think the possitive definition makes more sense
06:27-!-briand [] has quit [Read error: 110 (Connection timed out)]
06:27-!-briand [] has joined #mythtv
06:41-!-|gunni| [] has joined #mythtv
06:47-!-gammelmark [] has quit ["Leaving"]
06:48-!-briand [] has quit [Read error: 110 (Connection timed out)]
06:52-!-briand [] has joined #mythtv
06:53-!-MaverickTech [] has quit [Read error: 113 (No route to host)]
06:56-!-_gunni_ [] has quit [Read error: 113 (No route to host)]
07:01-!-rooaus [] has joined #mythtv
07:12-!-briand [] has quit [Read error: 110 (Connection timed out)]
07:15-!-beavis [] has joined #mythtv
07:19-!-briand [] has joined #mythtv
07:37-!-briand [] has quit [Read error: 110 (Connection timed out)]
07:39-!-robthebob [] has joined #mythtv
07:43-!-briand [] has joined #mythtv
08:37-!-dekar1 [] has joined #mythtv
08:41-!-turbo [] has joined #mythtv
08:43-!-briand [] has quit [Read error: 110 (Connection timed out)]
08:44-!-dekarl [] has quit [Read error: 145 (Connection timed out)]
09:23-!-turbo is now known as briand
09:41-!-turbo [] has joined #mythtv
09:43-!-briand [] has quit [Read error: 110 (Connection timed out)]
09:44-!-CDev [] has quit ["."]
10:13<Hannibal->i'll add a frontend trace for that crashing on tuner change; paulh could be on to something i suppose - i get a crash when i start a recording playback from the media library -> watch recordings also.
10:14<Hannibal->but if it was a jacked font; i'd expect it to always happen... eventually, you do get to change inputs / watch your movie.
10:14<Hannibal->movies = 2 tries, changing inputs is usually 3-4 tries.
10:16-!-CDev [] has joined #mythtv
10:21-!-briand [] has joined #mythtv
10:23-!-turbo [] has quit [Read error: 110 (Connection timed out)]
10:28<CDev>GreyFoxx: There still seems to be a problem with ParentId and childCount in upnp video.
10:30<CDev>The parentIds that I have circled should be "Videos/0"
11:09-!-turbo [] has joined #mythtv
11:11-!-briand [] has quit [Read error: 110 (Connection timed out)]
11:16<GreyFoxx>CDev: Ok, that's a simple one, I'll do that right now
11:16<GreyFoxx>I hadn'tthought to take that into account
11:20<GreyFoxx>CDev: Can you try this patch ?
11:22-!-djc_ [n=djc@] has quit [Read error: 110 (Connection timed out)]
11:22-!-djc_ [n=djc@] has joined #mythtv
11:25<stuarta>gbee: janneg has it right. both eit scanning types use the same method to collect data
11:26<stuarta>the difference being, passive uses the recordings to tune to a channel, while active does it in the background when tuners aren't otherwise busy
11:28<gbee>stuarta: thanks, I've spent a little more than 5 minutes looking at the scanning code now so my understanding has improved, should have done that before bothering you and janneg :)
11:28<stuarta>hey np
11:28-!-turbo [] has quit [Read error: 110 (Connection timed out)]
11:28<gbee>but that reminds me, I need to install/test the debugging patch I put together earlier
11:30<gbee>not that suprising, but the number of 0.21 tickets is steadily increasing :(
11:30<stuarta>oh dear, haven't looked for a few days :(
11:31<gbee>don't think we've much chance of hitting the first at this rate
11:33<Hannibal->1st of march?
11:35-!-turbo [] has joined #mythtv
11:36-!-turbo is now known as briand
11:40<CDev>GreyFoxx: you know you have a potential use of an uninitialized pItem at line 165 in upnpcdsvideo.cpp
11:43<CDev>GreyFoxx: Nope... made it worse. now the parentId = "Videos/0/itemVideos/0/item100000"
11:43<GreyFoxx>pItem fixed, looking at that again no
11:44<CDev>Are you going to fix the childCount as well? I know some clients won't request child objects if the count is 0
11:44<GreyFoxx>yeah, I've got a fix for that I beleive
11:44<GreyFoxx>any chance I could get that test tool off ya ?:)
11:45<GreyFoxx>I've got vista in a VM I could run it on :)
11:45<CDev>It's really crude and will require vista.
11:45<CDev>I'll see what I can do.
11:45<CDev>Do you have visual studio's 2008?
11:46<GreyFoxx>my vista vm has pretty much nothing installed. would a downlaod of studio express be enough ?
11:46<CDev>np. I'll just give you the exe then.
11:54-!-briand [] has quit [Read error: 110 (Connection timed out)]
12:01-!-briand [] has joined #mythtv
12:13-!-TelnetManta [] has quit [Read error: 110 (Connection timed out)]
12:14-!-gnome42 [] has joined #mythtv
12:20-!-briand [] has quit [Read error: 110 (Connection timed out)]
12:26-!-briand [] has joined #mythtv
12:26<gbee>janneg: do you know what the problem is with the passive scan yet? I've just had a look and it looks like we're stopping the scan when the signal monitor is stopped
12:28<gbee>because the start/stop of the passive scan is linked to the tuning code, the moment we are no longer tuning we stop scanning - maybe we need to move the start/stop stuff elsewhere?
12:30<gbee>err, might have that all wrong - I saw what I expected to see in the log, but what was really there is different
12:36<stuarta>EIT scanning disabled for this card.
12:36<stuarta>that might be why it doesn't work
12:36<gbee>yeah, that's pretty odd
12:37<stuarta>wonder if danielk22 stuck something in the code to disable it when it sees that driver
12:37<gbee>but why card 30? why even mention that card when we're recording on 27?
12:37<stuarta>are they the same card?
12:37<gbee>stuarta: active scanning works, passive scanning seems to have been broken around the time of the multirec merge
12:38<gbee>and I'd wager that it's broken for everyone, but no-one has noticed because the active scan masks the problem
12:38<gbee>27/30 are same card but different tuner (so effectively different cards), 27-29 are #1, 30-32 are #2
12:39<stuarta>its a dual card isn't it?
12:39-!-robthebob [] has quit [Connection reset by peer]
12:40*stuarta curses this dead hdd
12:40-!-rn114 [] has joined #mythtv
12:40<jamesd>stuarta, buy 2 or 3 at a time... raid is your friend... did you loose more than $100 of data and your time... harddrives don't last as long as they used too... and they sucked back then.
12:41<stuarta>it's an old pc i was hoping to reuse
12:41<stuarta>plan aborted, hardware broken
12:41*stuarta sighs
12:42<jamesd>then buy a used harddrive on ebay... $20 gets you 20-40GB these days...
12:42<stuarta>that's pointless
12:42<stuarta>i was hoping to only have to buy a sata card to move the recording drives over
12:42<gbee>can't really remember the last time a hdd failed on me - which doesn't mean that it won't happen
12:42<stuarta>since that's can't happen without a new root disk, i may as well buy 500gb
12:43*jamesd replaces a harddrive every 2weeks... but that is for work.. 150 machines can be that way...
12:43*stuarta runs systems for a living
12:43<jamesd>me too
12:44<stuarta>so thanks for the raid tip, but been there, done that, bought the t-shirt
12:44<jamesd>when is mythtv going to be ported to solaris, even if just for transcoding and video playback...
12:44<gbee>I think the google report on HDD failure rates/causes is probably accurate - that usage/conditions don't affect failure rates, a drive either contains minor manufacturing faults or it doesn't
12:45<stuarta>jamesd: feel free to start coding
12:45<gbee>a good drive will last forever (well you'll throw it away long before it fails) or it will fail in the first few years
12:45<stuarta>infant mortality, or old age, there's no middle ground
12:46<jamesd>perhaps next month.. when my current contract ends... i wil have some time i think
12:46-!-briand [] has quit [Read error: 110 (Connection timed out)]
12:51-!-briand [] has joined #mythtv
13:05<CDev>GreyFoxx: I tried to clean it up a little... hope this helps.
13:05<CDev>let me know if you have any issues with it.
13:26-!-turbo [] has joined #mythtv
13:28-!-briand [] has quit [Read error: 110 (Connection timed out)]
13:32<stuarta>this Erik bloke has been sitting on a *lot* of patches
13:34<Hannibal->Erik Hovland?
13:34<Hannibal->like every possible memory leak ever
13:35<stuarta>i don't get why he waited until we branched for 0.21
13:35<Hannibal->i'm compiling with debug options so i can do a stackdump on that mythfrontend crashing out -- it does it to me all the time. it's quite lovely.
13:36<Hannibal->dunno, maybe he was on 0.20-fixes the whole time, just started testing 0.21-fixes
13:36*stuarta shrugs
13:38<Hannibal->maybe he was testing you guys to see if you'd find them!
13:38<stuarta>more likely he's the sort of person who just fixes stuff but doesn't bother to report it at the time
13:39<Hannibal->could be.
13:39<laga>poor guy if he finds that many segfaults
13:39<Hannibal->he has to be running in valgrind all the time ;-)
13:39<stuarta>its just plain bizzare
13:40<stuarta>Hannibal-: i'd say he's just a good reader of code
13:40<Hannibal->perhaps that what he does for a living
13:40<Hannibal->that is*
13:40<Hannibal->'code cleaner'
13:44*laga just stops wondering and hopes he continues doing whatever he's doing
13:44*stuarta agrees
13:47<Hannibal->poof. i hope gdb left a backtrace.
13:48<gbee>most of his stuff seems to come from reading through the code specifically looking for common problems, none of his patches seemed to fix actual leaks that I've seen through valgrinding or segfaults, they just had the potential to cause problems under certain conditions
13:49<Hannibal->mythfrontend[23374]: segfault at 00000014 eip b63425e0 esp bfff0840 error 4
13:49<Hannibal->gdm[23279]: segfault at 00000000 eip b7559658 esp bfa94070 error 4
13:52<Anduin>laga: They changed their pages, I started working on a fix last night, should get it in there today.
13:52<laga>Anduin: great, thanks!
13:52-!-turbo [] has quit [Read error: 110 (Connection timed out)]
13:53-!-briand [] has joined #mythtv
13:53<gbee>btw, backend still has a small leak - over two/three days it went from a fairly steady 4.3% to 6.5% - if I had a dedicated development backend I'd valgrind it, but I can't spare my production machine for long term 'grinding
13:54<Hannibal->i could lend a box, as long as the only tuner present is the hdhomerun
13:56-!-rn114 [] has quit [Read error: 113 (No route to host)]
13:56-!-rn114__ [] has joined #mythtv
13:57<gbee>Hannibal-: thanks for the offer, but I'll manage for now :)
13:57<Hannibal->is 'paulh' in here? cuz i can repro that tuner input change crash all day, but the mythfrontend -v all logs are over a meg... not sure if he wants it trimmed down.
13:58<Hannibal->gbee - the offer stands if you want / need; i can open ssh / vnc for you to access it.
13:59<gbee>well I'd start by using -v most for a start, and for a tuner related segfault -v record,channel,siparser would cut down the size of the logs but still help
13:59<gbee>Hannibal-: I'll bear it in mind
14:02<Hannibal->will try that; just checking to see if the logs look similar when it happens during a recording playback
14:02<Hannibal->mythfrontend: Fatal IO error: client killed
14:02<Hannibal->2008-02-24 13:56:13.846 MythSocket: readyread thread exit
14:04<gbee>I'm probably more likely to reproduce the problem with my own backend because factors such as the number of inputs, sources, DVB streams and configuration could all play a part - might be a wild goose chase looking for the issue with a completely different backend
14:05<Hannibal->besides not being able to process backend jobs -- what else does valgrinding it prevent?
14:07<gbee>very little really, I'm just not brave enough to risk losing a recording because of some race condition that valgrinding might cause (slows things down a fair bit)
14:08<gbee>but if I pick the right moment I can probably set it running under valgrind for ~20 hours which should be enough time to find the problem, even if it shows up in the results as being pretty small
14:09-!-gerhard [] has joined #mythtv
14:13-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
14:14*laga has been seeing weird behavior for some time
14:16<laga>my remote frontend won't play some recordings. the master backend where these recordings are located just spits out "failed to open remote file:"
14:16<laga>the recording is in the database and the file name is correct
14:20-!-aevil [] has joined #mythtv
14:31-!-turbo [] has joined #mythtv
14:32-!-MaverickTech [] has joined #mythtv
14:32-!-loops [] has quit ["Leaving"]
14:32-!-briand [] has quit [Read error: 110 (Connection timed out)]
14:32-!-loops [] has joined #mythtv
14:36-!-gerhard [] has quit [Remote closed the connection]
14:42-!-abarbaccia [] has joined #mythtv
14:44-!-abarbaccia [] has left #mythtv []
14:48-!-turbo [] has quit [Read error: 110 (Connection timed out)]
14:50-!-loops [] has quit [Remote closed the connection]
14:52-!-loops [] has joined #mythtv
14:53<laga>hum, mythfrontend on the master backend works fine. this might be a bug in the storage group code, found a similar report which is supposed to be fixed
14:55-!-turbo [] has joined #mythtv
14:58-!-MaverickTech [] has quit [Read error: 113 (No route to host)]
15:06-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
15:06-!-xris [] has joined #mythtv
15:08<stuarta>i like #4760
15:08-!-foxhunt [] has joined #mythtv
15:08-!-foxhunt [] has quit [Client Quit]
15:11*gbee couldn't be bothered to read it ;)
15:11<stuarta>you got blamed, er credited for the ideas withing
15:20<stuarta>okay who broke the build
15:20*stuarta blames GreyFoxx
15:24<MrGandalf>danielk22: there?
15:29-!-briand [] has joined #mythtv
15:29<MrGandalf>16233 segfaults while changing card inputs.. can anyone confirm?
15:30-!-turbo [] has quit [Read error: 110 (Connection timed out)]
15:40<stuarta>hmmm, maybe it was daniel who broke it
15:40<MrGandalf>are you seeing the segfault as well?
15:40<stuarta>doesn't even build
15:40<stuarta>changeset 16229 is my problem
15:41<stuarta>looks like those event changes have broken mythcontrols build
15:42<MrGandalf>He patched mythcontrols to include qdeepcopy
15:43<stuarta>ah, so he did (i'm building on 2 different boxes atm)
15:46-!-ebil [] has joined #mythtv
15:50-!-richards [] has joined #mythtv
15:53<Jared5552>are there any stand alone dvr systems that work with the computer/mythtv?
15:54<Jared5552>(ex: since the accesscard junk isn't supported)
15:54<Jared5552>sorry, wrong channel
15:55-!-ebil [] has left #mythtv ["Leaving"]
15:55-!-BathoryQuorthon [] has joined #mythtv
15:58-!-gbee [] has quit ["Gone"]
15:59-!-gbee [] has joined #mythtv
16:01-!-turbo [] has joined #mythtv
16:02-!-briand [] has quit [Read error: 110 (Connection timed out)]
16:03-!-dfghj is now known as dfgh
16:05-!-rn114 [] has joined #mythtv
16:05-!-rn114__ [] has quit [Read error: 104 (Connection reset by peer)]
16:07-!-dfgh [] has left #mythtv ["Leaving"]
16:07-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Success]
16:20-!-turbo [] has quit [Read error: 110 (Connection timed out)]
16:26-!-turbo [] has joined #mythtv
16:33-!-dekar1 [] has quit [Read error: 104 (Connection reset by peer)]
16:38*MrGandalf wonders if his issue is cccache.
16:39<stuarta>only one way to find out
16:56<richards>MrGandalf: I was following your seg fault bug hunting yesterday, my mythtv server seg faults on a daily basis. I am guessing that you use gdb to attempt to pin down the location of the seg fault.
16:56<stuarta>richards: section 22.2 of the howto
16:56<MrGandalf>richards: in part, yes.
16:57<gbee>richards: what version are you running? (since there is little point debugging an issue which affects versions earlier than 0.21)
16:58<richards>stuarta: I have a gdb command file based on, I think, that howto already and dumpd from gdb runs
16:58<richards>gbee: svn head
16:59<stuarta>then please pastebin some gdb logs
16:59<gbee>ok, debug away :)
17:00<richards>looking at howto to check I am doing roughly the right thing
17:02<richards>OK, build is done as per howto,
17:04<richards>I have had to remove the -v record,channel,siparser as the computer can not keep up with the log writes. I realise this may make the dumps unusable
17:06-!-grokky [] has joined #mythtv
17:08<richards>How much of the logfile do you want, from the seg fault on? before that is only new thread starts and thread exits
17:09<stuarta>from where gdb goes "program died with SIGSEGV" or similar and include the complete output of thread apply all bt full
17:11<MrGandalf>nope, not cccache related..
17:13-!-aevil [] has quit [Read error: 110 (Connection timed out)]
17:14<Hannibal->MrGandalf - are you using --enable-opengl-video?
17:15<richards>how long should I give the post before it expires?
17:15<stuarta>doesn't matter really, couple of days min
17:15*stuarta goes to the couch for a bit
17:16<MrGandalf>hannibal- this is the backend that's crashing - on a backend only machine, so nope
17:18<richards>uploaded -
17:19-!-mattwire [] has joined #mythtv
17:19<Hannibal->ah, ok
17:26<richards>I have anopthe
17:27-!-reynaldo [] has joined #mythtv
17:28<richards>Try again, I have another 6 gdb logs I could post if the first has sufficient detail to work on
17:29<richards>I will be around until about 23:45 GMT
17:48<gbee>richards: backtrace doesn't fit with trunk,line numbers are wrong and it refers to a function (DVBRecorder::AdjustFilters) which doesn't even exist in trunk
17:50<richards>one mo, I will get the ./configure line as I am using a DVB-T card and had to config it in
17:51<gbee>can you pastebin the output of mythbackend --version too?
17:51<richards>complete with the lib version :-)
17:53<gbee>#1 0xb6ebfb64 in ?? () from /opt/mythtv/0.20.2/lib/ << heh, that's 0.20.2 not svn head
17:55<sphery>gbee: re: #4760, it was meant to be credit for the ideas, not blame. And, I completely understand your not reading my novel.
17:56<gbee>sphery: :D
17:56<sphery>Since I'm assuming stuarta liked the idea, but didn't read all the code, he was saying he like your ideas (and Daniel's and Rob's)
17:57-!-beavis [] has quit ["Verlassend"]
17:58<gbee>seems rude not to read it when you've gone to so much trouble writing it, so I'll make the effort tomorrow
17:59<sphery>Actually it's just a bunch of details that's really only useful to the person who reviews the patch. I really don't expect anyone other than the reviewer to read it.
18:00<richards>gbee: if the gdb dump does not make sense I will start again and make a clean pull from svn
18:00<hads>richards: That's not SVN head.
18:00<gbee>richards: ok, a little confusion then - that's the 0.20-fixes branch, the old version which we are no longer supporting - the new version is 0.21-fixes which should be released as 0.21 in a week (or two, or three)
18:01<danielk22>MrGandalf: Are you here? Ref #4768
18:01<richards>np, I will start again
18:01<gbee>and neither of those is svn head, which is the development version but pretty closely resembles the 0.21 branch
18:01<danielk22>Can you run this through valgrind?
18:01<gbee>well it does right now
18:02<sphery>richards: Any chance you still have parts of 0.20 on the system (i.e. libs, etc.)? I'm suspecting mixed versions...
18:02<MrGandalf>I don't know..
18:02<danielk22>the only thing that explains those segfaults is memory corruption not local to the segfault itself...
18:02<danielk22>so the backtraces are useless :(
18:02<MrGandalf>that's what I thought
18:02<MrGandalf>lemme see
18:03<richards>sphery: I will be careful cleaning up
18:03<danielk22>It's probably triggered by the signal monitor code.. but that doesn't localize it very much..
18:04<danielk22>BTW, you are seeing sanskrit audio, bizarre
18:04<danielk22> ISO-639 Language: code(san) canonical(san) eng(Sanskrit)
18:05<danielk22>Is there audio on that extra stream, or is it just a placeholder?
18:05<richards>gbee: should I go for 0.21-fixes or head
18:06<MrGandalf>I'll check it out as soon as I get done valgrinding..
18:06<MrGandalf>I shouldn't need to enable valgrind in the compile for the backend, correct?
18:07<MrGandalf>I think that's only for the frontend
18:07<sphery>richards: If you plan to do active development, head is where you'll need to be. For now, though, a backtrace on 0.21-fixes would get sufficient attention from devs.
18:08<gbee>richards: really depends whether you want to be trying cutting edge features in a couple of months time, or if you just want stability - get 0.21-fixes if you aren't bothered about testing new features as they are added to MythTV
18:09<gbee>0.21-fixes will only receive bug fixes, head is where all the new work is done
18:10<richards>sphery: I'll go for the 0.21-fixes, stablity but something that the front lines devs can use debug info from when it breaks.
18:11<sphery>richards: good plan (glad gbee answered with a clearer explanation, too--I shouldn't be IRC'ing after only 2-hours sleep last night)
18:13<richards>thanks all, I will go away and rebuild from 0.21-fixes and come back if it breaks, hopefully with better info.
18:13<Hannibal->thanks for the sugestion on disable-opengl-video danielk22 ;-) much more stable now.
18:13*MrGandalf needs a much faster system for valgrind
18:13<gbee>sphery: from my perspective your explanation was clearer, but then I got just 3 hours sleep and I'm so tired right now that I'm having trouble focusing my eyes on the screen ;)
18:16<MrGandalf>ya know, I'm thinking there was a reason why extradata wasn't being copied..
18:17-!-mrpockets [n=mrpocket@] has joined #mythtv
18:17-!-mrpockets [n=mrpocket@] has left #mythtv ["Leaving"]
18:17<sphery>gbee: Yours was more of a "What's in it for me?" explanation. Sounds like you you should go get some sleep--it's pretty much bed time where you are, anyway...
18:17<danielk22>Hannibal: There is a known problem with switching to & from OpenGL rendering.. And there is also a problem with OpenGL V-Sync in that the glx vsync call is not protected by the X11 lock (but making it safe by simply adding the lock also makes XvMC impossible and XVideo performance too sluggish..)
18:18<danielk22>MrG: I think it was just hiding some other problems...
18:20<MrGandalf>daniel: I don't know that my system is fast enough for valgrind.. mythbackend hasn't even finished initializing all the DVB cards yet.
18:24<MrGandalf>danielk22: nope, can't.. takes too much.. grinds to a halt. I can start disabling things but, knowing my luck, I'll disable the very thing which causes the bug
18:25<danielk22>hmm, ok give the latest svn a try. I fixed a SignalMonitorValue bug, but without the valgrind info I don't know if this will really fix the problem you are experiencing.
18:26<MrGandalf>which committ?
18:28<danielk22>This fix is based on the partial backtrace in the backend2.txt output...
18:29-!-BathoryQuorthon [] has left #mythtv ["Great Hall Awaits a Fallen Brother"]
18:29<Hannibal->is that known issue with opengl-vsync new to 0.21? I used to always use that option in 0.20-fixes.
18:29<MrGandalf>k, thanks :) If that doesn't do it, tomorrow I'll try disabling EIT and see if I get any further.
18:30<MrGandalf>or maybe I'll give that a try tonight..
18:30<Hannibal->The only thing I've noticed, is that in 0.21-fixes -- I can no longer use the 'experimental' option to 'Use Video as timebase' - I get horrible prebuffering pauses.
18:30<danielk22>Hannibal: No it is a very old problem. It will start to be more of a problem as more people start using multicore CPUs.
18:31<Hannibal->heh, my new backend is a Core2Quad.
18:33<MrGandalf>two successfull tunings..
18:33<danielk22>MrG: Is that good?
18:33<MrGandalf>so far, still testing
18:34<danielk22>SignalMonitorValue is one of my classes, but from before I realized how unsafe QString was..
18:34<MrGandalf>hmm, nope
18:34<stuarta>sphery: yes i liked the idea :)
18:35<danielk22>MrG new debug though?
18:35<MrGandalf>can't tell.. bad bt again
18:36<danielk22>post to the ticket anyway, maybe it or the log tells me something...
18:36-!-MaverickTech [] has joined #mythtv
18:40<MrGandalf>trying valgrind one last time.. this time with no eit scanner
18:48-!-|gunni| [] has quit ["KVIrc 3.2.4 Anomalies"]
18:52<MrGandalf>nope, too slow
18:54-!-richards [] has quit ["ChatZilla 0.9.81 [Firefox]"]
18:58-!-grokky_ [] has joined #mythtv
18:59<MrGandalf>danielk22: added a new set, this time with -v network on again. Looks like the exact same place in the signal monitor..
18:59<MrGandalf>and that's with EIT turned off
19:00-!-_null_ [] has joined #mythtv
19:00-!-_null_ [] has left #mythtv []
19:01-!-BobSlob [] has joined #mythtv
19:05<danielk22>k, bt3 doesn't tell me anything.. looking at others..
19:05-!-BobSlob [] has left #mythtv []
19:07<danielk22>so backend4.txt is with the latest code?
19:12<danielk22>MrG: I'll run under valgrind here. Maybe it will report something even though I don't see the segfaults here...
19:14<MrGandalf>I can pick it up again tomorrow.. disable some timeouts and whatnot. My head is aching right now.
19:14<MrGandalf>thanks for your help on this, BTW
19:15-!-grokky [] has quit [Read error: 110 (Connection timed out)]
19:16-!-TelnetManta [] has joined #mythtv
19:17<danielk22>np.. when I first started using MythTV it crashed all the time, I know if you work at those problems they do eventually go away..
19:17<danielk22>k, gotta go help with dinner now..
19:28-!-xris [] has quit []
19:35-!-rn114 [] has quit [Read error: 104 (Connection reset by peer)]
19:38-!-grokky_ [] has quit []
19:46-!-ahbritto [] has joined #mythtv
19:48-!-turbo is now known as briand
20:37-!-eharris [] has quit ["leaving"]
20:39-!-MavT [] has joined #mythtv
20:41-!-XChatMav [] has joined #mythtv
20:58-!-MaverickTech [] has quit [Read error: 110 (Connection timed out)]
20:59-!-MavT [] has quit [Read error: 110 (Connection timed out)]
21:06-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
21:23-!-bowlarium [] has joined #mythtv
21:30-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Connection timed out]
21:37-!-mattwire [] has quit [Read error: 113 (No route to host)]
21:38-!-mattwire [] has joined #mythtv
21:42-!-bowlarium [] has left #mythtv []
21:47-!-Dave123 [] has joined #mythtv
21:50-!-MaverickTech [] has joined #mythtv
22:06-!-XChatMav [] has quit [Read error: 110 (Connection timed out)]
22:07<kormoc>stuarta, You handle mythweather right now, right?
22:08-!-mattwire [] has quit ["Leaving"]
22:28-!-davilla [] has joined #mythtv
22:56-!-MavT [] has joined #mythtv
23:02-!-XChatMav [] has joined #mythtv
23:09-!-czth_ [n=dbrobins@nat/microsoft/x-742ef7d507fbbe9c] has joined #mythtv
23:13-!-MaverickTech [] has quit [Read error: 110 (Connection timed out)]
23:19-!-MaverickTech [] has joined #mythtv
23:19-!-MavT [] has quit [Connection timed out]
23:25-!-czth [n=dbrobins@nat/microsoft/x-d4539efd95ad3913] has quit [Read error: 110 (Connection timed out)]
23:38-!-XChatMav [] has quit [Read error: 110 (Connection timed out)]
---Logclosed Mon Feb 25 00:00:29 2008