Back to Home / #mythtv / 2007 / 02 / Prev Day | Next Day
#mythtv IRC Logs for 2007-02-07

---Logopened Wed Feb 07 00:00:46 2007
00:08|-|MonkeyINAbaG [n=WiseMonk@is.da-bom.com] has quit [Excess Flood]
00:09|-|MonkeyINAbaG [n=WiseMonk@is.da-bom.com] has joined #mythtv
00:12|-|[1]ASiDiE [i=HydraIRC@c-67-176-109-163.hsd1.co.comcast.net] has joined #mythtv
00:13|-|ASiDiE [i=HydraIRC@67.176.109.163] has quit [Read error: 104 (Connection reset by peer)]
00:13|-|[1]ASiDiE changed nick to ASiDiE
00:24|-|[1]ASiDiE [i=HydraIRC@c-67-176-109-163.hsd1.co.comcast.net] has joined #mythtv
00:24|-|ASiDiE [i=HydraIRC@c-67-176-109-163.hsd1.co.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
00:24|-|[1]ASiDiE changed nick to ASiDiE
00:35|-|beernutz [n=beernutz@12-207-66-121.client.mchsi.com] has joined #mythtv
00:35|-|beernutz [n=beernutz@12-207-66-121.client.mchsi.com] has left #mythtv ["Leaving"]
00:38|-|cattelan changed nick to cattelan_away
00:42|-|cattelan_away changed nick to cattelan
00:44|-|marc_ [n=marc@adsl-69-109-40-228.dsl.irvnca.pacbell.net] has joined #mythtv
00:45<marc_>I am recording a program, and watching at the same time, I see an option to skip commercials, does this work?
00:45<marc_>or do
00:45<marc_>or do I have to wait until the commflagging is done after recording?
00:45<marc_>ah shit sorry
00:57|-|luna6 [n=luna6@ip68-14-110-43.no.no.cox.net] has joined #mythtv
01:03|-|gnome42 [n=obi@dsl-145-67.aei.ca] has quit ["Leaving"]
01:09|-|marc_ [n=marc@adsl-69-109-40-228.dsl.irvnca.pacbell.net] has quit ["Changing server"]
01:31|-|cattelan changed nick to cattelan_away
01:41|-|degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has joined #mythtv
01:48|-|[1]ASiDiE [i=HydraIRC@c-67-176-109-163.hsd1.co.comcast.net] has joined #mythtv
01:48|-|ASiDiE [i=HydraIRC@c-67-176-109-163.hsd1.co.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
01:48|-|[1]ASiDiE changed nick to ASiDiE
02:06|-|purserj [n=purserj@k-sit.com] has quit [Remote closed the connection]
02:06|-|purserj [n=purserj@k-sit.com] has joined #mythtv
02:11|-|xris [n=xris@xris.forevermore.net] has quit ["Leaving."]
02:33|-|degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has quit [Remote closed the connection]
02:51|-|c0w_ [n=c0w@staff-ns50-3.as25178.net] has quit [Read error: 110 (Connection timed out)]
03:04|-|stuarta [n=stuart@unaffiliated/stuarta] has joined #mythtv
03:05|-|c0w_ [n=c0w@212.9.98.123] has joined #mythtv
03:40<Captain_Murdoch>hmm, so our database design is too lousy to work on, but not lousy enough to use according to usleepless.
03:40[~]Captain_Murdoch debates going back on his "one comment" comment.
03:51<Captain_Murdoch>evidently I'm envious of some guy wanting me to code for him for free. evidently I'd rather be the one trying to get people to code for me for free.
03:52<Captain_Murdoch>It's a bit hard, but I'll just let them live in their fantasy world and refrain from continuing the thread.
03:53<gbee>well I've made my reply
03:53<gbee>don't think it will make much different, but it makes me feel a little better
03:53<hads>Captain_Murdoch: From here your post was perfectly valid.
03:54[~]stuarta is still catching up
03:55<Captain_Murdoch>hads: thanks, I thought so. didn't even say as much as I wanted. I'm normally a bit wordier than that. :)
03:57<stuarta>that's my 2c worth added...
03:59<gbee>I tend to get carried away
04:04<gbee>right, well the music file scanner is now in it's own class and working well
04:04<gbee>time to implement the caching
04:07<Captain_Murdoch>stuarta: I think this guy is the one who wants to switch to postgres because he likes it more, that's why he's slamming Myth's use of MySQL.
04:08<stuarta>i suspect so too.
04:08<stuarta>though i think once we sort out the BFSQ blocking the DB, things should improve
04:08<Captain_Murdoch>he's posted before, possibly even with patches but I'm not sure.
04:09<Captain_Murdoch>Bruce and David are working on that I believe. there's an off-list discussion going on about it right now.
04:09[~]stuarta wonders if that should be on one of the lists....
04:13<Captain_Murdoch>mainly talking about what to change in to preserve existing functionality using the oldrecorded table instead of recorded. possibly a change in the dup* fields to make them more flexible and allow handling of current functionality with only the one table.
04:14|-|Cougar [n=cougar@lost.data.ee] has quit [Remote closed the connection]
04:15|-|Cougar [n=cougar@lost.data.ee] has joined #mythtv
04:19<janneg>the postgres tickets in trac seems to be from different person
04:24<gbee>I did actually check trac _before_ suggesting he post patches instead of complaining
04:27|-|LLyric [n=simon@d58-108-40-187.dsl.vic.optusnet.com.au] has joined #mythtv
04:30<stuarta>as i've mainly seen him recently, i went with seat of my pants...
04:34[~]gbee decides to make more work for himself by changing all the member variables in metadata.cpp/.h to conform to the coding standards
04:38<janneg>what's the issue with dvb radio? is it bad buffering for audio only streams?
04:46<gbee>no idea, DVB-T radio works fine here
04:49<janneg>except an occasional buffer underrun at the beginning of playback here too
04:55|-|Jonty [n=Jontydog@cpc2-macc2-0-0-cust355.bagu.cable.ntl.com] has joined #mythtv
04:56|-|Jonty [n=Jontydog@cpc2-macc2-0-0-cust355.bagu.cable.ntl.com] has left #mythtv ["Leaving"]
05:06|-|DrNickRiviera [n=riviera@so-5494-x0.essex.ac.uk] has joined #mythtv
05:07|-|DrNickRiviera [n=riviera@so-5494-x0.essex.ac.uk] has quit [Client Quit]
05:09|-|DrNickRiviera [n=riviera@so-5494-x0.essex.ac.uk] has joined #mythtv
05:13|-|DrNickRiviera [n=riviera@so-5494-x0.essex.ac.uk] has quit [Read error: 104 (Connection reset by peer)]
05:13|-|DrNickRiviera [n=riviera@so-5494-x0.essex.ac.uk] has joined #mythtv
05:35|-|aevil [n=aevil@i59F55C14.versanet.de] has joined #mythtv
05:44|-|LLyric [n=simon@d58-108-40-187.dsl.vic.optusnet.com.au] has quit ["Leaving"]
05:48<stuarta>*sigh* he just doesn't get the concept that his hasn't followed any of the accepted procedures relating to bugs
05:48<stuarta>1. identify bug
05:48<stuarta>2. submit patch for review
05:48<stuarta>etc etc...
05:53<gbee>aye, he got shot down on postgreSQL and took a childish, petulant attitude
05:56<stuarta>personally i don't mind if postgres support was added.
05:56<stuarta>but i'd want everything else fixed first.
05:56<gbee>"mythtv is crap because I've patched lots of things but never contributed them"
05:57<gbee>exactly, I don't mind if it's added, but it's at the very bottom of a near endless list of jobs
05:58|-|MrGandalf [i=buechlmr@cpe-72-225-32-214.rochester.res.rr.com] has quit ["Leaving"]
05:58<gbee>I'd rather move to an embedded db however because that ultimately simplifies setup
06:00[~]stuarta sends off a bit of rational argument
06:15<briand>i was just reading through his crap on the list
06:16<briand>i do not envy you guys, conversing with him -- i've dealt with that type before, and (in his mind) you'll never win.
06:20<stuarta>this guy is just becoming a PITA
06:21<stuarta>no patches & abuse. deep joy...
06:21<briand>exactly. he's just a sniper, at this point.
06:21<briand>anyway.. i've got to get to work. have a great day. :)
06:22<gbee>I've got to resist the temptation to feed the troll
06:22<stuarta>can he join us on irc so at least we can kickban him....
06:23<gbee>on IRC it might be easier to shoot him down - email is to slow a medium to get on top of him :)
06:23<stuarta>heck, i even offered to review his patches in my last email...
06:24<gbee>e.g. his QSQLQuery stuff - he's not thought it through
06:24<stuarta>how so?
06:24<stuarta>i'm intriged by his ipc assertions.
06:25<gbee>well, his suggestion that we just call "next" for example - doesn't allow us to know if the query failed and provide a user friendly error
06:25|-|DrNickRiviera [n=riviera@so-5494-x0.essex.ac.uk] has quit ["Leaving."]
06:26<gbee>next will return false in at least three different situations - that's why the size and isActive functions exist to start with
06:28<gbee>it might be that many places don't use size and isActive to return errors - but that's not an argument for removing them, but adding those errors instead
06:32<gbee>maybe it's just that I prefer defensive programming, not taking anything for granted and providing clear errors even for situations which should never arise
06:49|-|c0w_ [n=c0w@212.9.98.123] has quit [Remote closed the connection]
06:49|-|c0w_ [n=c0w@staff-ns50-3.as25178.net] has joined #mythtv
07:42|-|MoRpHeUz [n=morphbr@200.184.118.132] has joined #mythtv
07:43|-|Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
07:54|-|MrGandalf [n=mgandalf@cpe-72-225-37-244.rochester.res.rr.com] has joined #mythtv
08:05|-|purserj [n=purserj@k-sit.com] has quit [Read error: 104 (Connection reset by peer)]
08:08|-|ASiDiE [i=HydraIRC@c-67-176-109-163.hsd1.co.comcast.net] has left #mythtv []
08:14|-|MrGandalf [n=mgandalf@cpe-72-225-37-244.rochester.res.rr.com] has quit [Remote closed the connection]
08:19|-|MoRpHeUz [n=morphbr@200.184.118.132] has left #mythtv ["Leaving..."]
08:21|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
08:38|-|_Jaak_ [n=ernst@elanser.demon.nl] has joined #mythtv
08:38<gbee>any ideas how to split and return the path from a filename purely in SQL?
08:39<stuarta>i'd love to be able to do sed in sql :)
08:41<gbee>it's got some usefull string functions but none of them can split a string at the final instance of the delimiter ( / ) and return everything to the left
08:42<gbee>there are some REGEXP functions I've not really considered
08:43<gbee>don't think they can be used for that though
09:04|-|beavis [n=beavis@p54A7A252.dip0.t-ipconnect.de] has joined #mythtv
09:04|-|decay [n=decay@p5091F6EC.dip.t-dialin.net] has joined #mythtv
09:06<gbee>huh - am I imaging it, or have we made a breakthrough with usleep?
09:06<gbee>imagining
09:06<janneg>projection
09:06<stuarta>maybe he went to bed
09:06<janneg>he says we should avoid size() becaues it isn't supported by all DB systems
09:07<gbee>I disagree for exactly the reason he gave - that mysql is our DB and that won't change
09:08<gbee>but otherwise the tone of his last email was different
09:08<stuarta>maybe we are starting to get through...
09:08<gbee>maybe it's wishful thinking, maybe I am just seeing what I wanted to see ;)
09:09<stuarta>it may be because your last email came across as constructive rather than dismissive.
09:11<gbee>at the very least, he doesn't seem to be pushing the argument further
09:12<stuarta>which is indeed an improvement
09:12[~]stuarta is still waiting to see his first patch
09:12<gbee>I'm tempted to correct one thing about his last email - he sees the scheduler problem as a mysql problem, when it's really a MyISAM problem
09:13<gbee>innoDB is still mysql, but doesn't have the lock contention issues that MyISAM does
09:14<gbee>I wonder how much of his anti-MySQL/pro-postgreSQL stance comes down to issues with the default MyISAM engine
09:14<stuarta>quite a bit
09:17|-|jgarvey [n=jgarvey@cpe-075-177-158-190.nc.res.rr.com] has joined #mythtv
09:22|-|splat1 [n=splat1@cpc2-leic7-0-0-cust281.lei3.cable.ntl.com] has quit [Read error: 104 (Connection reset by peer)]
09:22|-|splat1 [n=splat1@cpc2-leic7-0-0-cust281.lei3.cable.ntl.com] has joined #mythtv
09:22<gbee>SELECT SUBSTRING(path FROM 1 FOR INSTR(filename, SUBSTRING_INDEX(path, '/', -1))-1) FROM music_songs;
09:23<gbee>a little ugly, but that seems to work
09:24<gbee>well actually this:
09:24<gbee>SELECT SUBSTRING(filename FROM 1 FOR INSTR(filename, SUBSTRING_INDEX(filename, '/', -1))-1) FROM music_songs;
09:34<Chutt>we switched to using size() because the _last_ person wanting postgres insisted on it.
09:34<Chutt>btw.
09:39<gbee>lmao
09:39|-|_Jaak_ [n=ernst@elanser.demon.nl] has quit ["Weggaan uit"]
09:41<gbee>although there are no killer features in MySQL 4/5, I was just wondering how long we'll continue support for 3.23?
09:41<Chutt>until Captain_Murdoch stops using an old distro
09:41<gbee>right ;)
09:43<Chutt>heh, i just got some new prototype hardware
09:43<Chutt>of course, there's no instructions. =)
09:43<stuarta>isn't that half the fun??
09:43<Chutt>yeah.
09:44<gbee>like you would read them anyway ;)
09:44<Chutt>the best part is if i fry this, there's only 4 others of them in existance
10:07|-|MrGandalf [n=mgandalf@cpe-72-225-37-244.rochester.res.rr.com] has joined #mythtv
10:07<MrGandalf>Can anyone tell me what the db update "UPDATE record SET dupin = 31 WHERE dupin = 4" is for?
10:07<MrGandalf>and will that prevent me from reverting back to a previous svn without changing that back?
10:14|-|decay [n=decay@p5091F6EC.dip.t-dialin.net] has quit [Remote closed the connection]
10:25<gbee>isn't dupin the duplicate check method? in which case it looks like it's just reseting it to a sane value?
10:34|-|WZ__ [n=useru@S0106000c414b8569.cg.shawcable.net] has quit [Read error: 110 (Connection timed out)]
10:48|-|gnome42 [n=obi@dsl-145-67.aei.ca] has joined #mythtv
11:15|-|gnome42 [n=obi@dsl-145-67.aei.ca] has quit ["Leaving"]
11:15|-|PointyPumper [i=Pintlezz@OL221-67.fibertel.com.ar] has quit [Read error: 104 (Connection reset by peer)]
11:15|-|PointyPumper [i=Pintlezz@OL221-67.fibertel.com.ar] has joined #mythtv
11:21|-|MonkeyINAbaG [n=WiseMonk@is.da-bom.com] has quit [Connection timed out]
11:22|-|MonkeyINAbaG [n=WiseMonk@is.da-bom.com] has joined #mythtv
11:33|-|gnome42 [n=obi@dsl-145-67.aei.ca] has joined #mythtv
11:39<GreyFoxx>davi: are you ssh'd in now ?
11:56|-|brtab [n=brtab@c-24-63-181-112.hsd1.ma.comcast.net] has joined #mythtv
12:06<Chutt>heh
12:07<Chutt>this proto hardware is awesome.
12:07<Chutt>it's a cell phone with a bigass circuitboard coming out where the usb port should be
12:08|-|splat1 [n=splat1@cpc2-leic7-0-0-cust281.lei3.cable.ntl.com] has quit ["changing servers"]
12:08|-|splat1 [n=splat1@cpc2-leic7-0-0-cust281.lei3.cable.ntl.com] has joined #mythtv
12:14<MrGandalf>sounds hard to use..
12:26|-|rtsai1111 [n=rtsai@208-201-231-158.dsl.dynamic.sonic.net] has joined #mythtv
12:30|-|xris [n=xris@dsl081-161-160.sea1.dsl.speakeasy.net] has joined #mythtv
12:30<gbee>it's the start of a reversal in the trend for ever smaller gadgets - "The technology of the future! A Phone which doesn't fit in your pocket!"
12:31<gbee>xris: http://pastebin.ca/344230
12:32<gbee>not tested it as a complete update yet, but the individual parts work as intended
12:33<gbee>won't be able to populate the parent_id field though, that will require users to rescan their music - but we aren't using the parent_id initially anyway
12:34|-|jmk_ [n=jmk@pat.foofus.net] has quit ["Leaving"]
12:35<xris>gbee: you can use MODIFY instead of CHANGE if you don't want to change the field name
12:36<gbee>yeah I know, just forgot when I typed that ;)
12:37<gbee>ok changed :)
12:37<gbee>if there are no obvious problems I'll go ahead and commit what I've gt so far
12:37<xris>looks ok at first glance, but for some reason my brain isn't letting me actually READ it.
12:37<xris>heh
12:38<gbee>:D
12:39<gbee>things are going to get worse before they get better, the initial commit is a mix of the directory stuff and a refactor of the scanner and metadata
12:40<gbee>it should all work, but the scanner will actually be slower until I add the caching due to the extra queries to populate the music_directories table
12:42<xris>heh
12:42<xris>I should write up something about how to tweak my.cnf to improve performance, too.
12:42<xris>turning on the query cache makes a HUGE difference for mythweb.
12:44|-|rtsai [n=rtsai@208-201-231-158.dsl.dynamic.sonic.net] has quit [Read error: 110 (Connection timed out)]
12:57|-|WZ__ [n=useru@S0106000c414b8569.cg.shawcable.net] has joined #mythtv
13:04<gbee>sort of thing that moving to an embedded database will solve - no config
13:10<stuarta>what is going on with this recording?
13:10<stuarta>seems to think it's only 3.5mins long when it's about an hr
13:11<stuarta>rebuilding the seektable hasn't helped
13:12<gbee>is it stopping after 2.5 minutes, or is it only the position info saying that?
13:12<stuarta>it's like compressing the whole 1hr down to 3.5 mins
13:12<gbee>huh
13:13<gbee>ultimate timestretch
13:13<stuarta>1 second seek while editing moves >>> 1 sec
13:13<stuarta>more like 7mins
13:14<stuarta>however it plays normally
13:15<stuarta>ahah! it's got a dodgy audio stream
13:18<stuarta>lets transcode it and see what happens
13:18|-|Merlin83b [n=Merlin83@office.34sp.com] has quit [Read error: 110 (Connection timed out)]
13:22<stuarta>hmmm. audio is diverging from video
13:23<stuarta>(transcode is queued)
13:25<janneg>stuarta: try mythtranscode --buildindex
13:25<stuarta>when did we add that?
13:26<janneg>I don't know. probably together with the lossless mpeg2 transcode
13:28<xris>gbee: you sort of want config for mysql, though, since it can depend on how much RAM you have.
13:29<janneg>unfortunately it does its job very well otherwise I might have fixed the keyframe detection in avformatdecoder already
13:29<stuarta>101% complete????
13:29<stuarta>116...
13:30<kvandivo>i've heard of giving 110%, but that's a bit much
13:30<gbee>true, but at least it may be possible to make any necessary config options, such as that, internal to mythtv so users don't have to be told they need to edit X, Y & Z external configs
13:30<stuarta>143%...
13:31<stuarta>169%... ok... 181% something is properly broken
13:32<stuarta>janneg: it's in your home dir if you want to examine it..
13:33|-|o_cee [n=oscar@c83-249-96-144.bredband.comhem.se] has left #mythtv []
13:35<stuarta>looks like it's common to a few of my recent recordings...
13:36<stuarta>but has been fixed by the update i did on monday
13:38<xris>janneg: something in that is broken for me.
13:38<xris>Captain_Murdoch has a couple of tickets open about it... and I know that I consistently have stuff from one channel that comes in "off"... (detects the correct number of commercials, but displays them at the wrong time points)
13:38<stuarta>okay this is weird. i've a bunch of other recordings that are 45mins long, showing up as 3hrs
13:41<janneg>xris: I think I inherited at least one of the tickets
13:41<janneg>mythtranscode --buildindex works for me
13:45|-|aevil^aw [n=aevil@i59F5698B.versanet.de] has joined #mythtv
13:46<xris>janneg: you use dvb?
13:47<xris>the current patch I have applied is against mythtv/libs/libmythtv/avformatdecoder.cpp and bassically just removes the "if an avi" check around line 833
13:48<xris>since it seems to help on some of my mpegts recordings, too.
13:57<janneg>yes, I use dvb for more than 98% of my recordings
14:01|-|aevil [n=aevil@i59F55C14.versanet.de] has quit [Read error: 110 (Connection timed out)]
14:04|-|lcase [n=l-case@p54B32912.dip0.t-ipconnect.de] has joined #mythtv
14:11<xris>well, if you're ever interested in looking at one of my wonky recordings, I'll happily provide one. :)
14:22<stuarta>well now it's not supposed to SEGV on this DecoderBase::GetFramesRead (this=0x0) at decoderbase.h:96
14:24<janneg>IBTD. I would expect it to segfault with a NULL this pointer
14:25<stuarta>that came out wrong, i would, as you do, expect this=NULL to SEGV
14:25<gbee>bah, I really can't win at the moment
14:25|-|sinnlos [n=sinnlos@217-68-167-87.dynamic.primacom.net] has joined #mythtv
14:26<stuarta>got -> TV Error: nvp->IsPlaying() timed out
14:26<stuarta>then ctrl-c, so it's something not being cleaned up right...
14:34<stuarta>somebody's deleting nvp on me. hmmmm.
14:37|-|sinnlos [n=sinnlos@217-68-167-87.dynamic.primacom.net] has quit [Read error: 54 (Connection reset by peer)]
14:39<gbee>the mythtv gremlins
14:39<kvandivo>after all, it's _always_ after midnight somewhere
14:40<stuarta>hmpf... and i thought i had a window to try and fix some of my tickets....
14:40<stuarta>hah!
14:43|-|o_cee [n=oscar@c83-249-96-144.bredband.comhem.se] has joined #mythtv
14:45<gbee>bleh I hate using vi - always accidently use some key combo belonging to another editor which then causes it to go into some mode which I can't get out of
14:46<stuarta>i just always use vi :P
14:47|-|eskil [n=eskil@natint3.juniper.net] has joined #mythtv
14:47<janneg>hah, cleaned the h264 keyframe detection mess. it's also much faster down from 3% to below 0.1%
14:47<GreyFoxx>stuarta: ghehe me too
14:48<GreyFoxx>but I do get annoyed when I try and hit ESC when using notepad on someones machine :)
14:48<stuarta>notepad is evil...
14:49<GreyFoxx>yes, but like VI it's on everyones machine
14:49<GreyFoxx>so if I'm stuff on windows doing minor edits I use notepad. If I regular use the machine I install gvim for windows :)
14:50<kvandivo>i drop into edit.com and try to remember my wordstar keybindings
14:50<stuarta>at least usleep has finally started submitting patches!
14:51<gbee>I'm spoilt by fancy editors - I wouldn't willingly switch kdevelop or ultraedit for vi, emacs or notepad
14:51<gbee>but of course vi or emacs is a lot easier to use across ssh
14:55<GreyFoxx>gbee: I've yet to find a fancy editor I liked. And as you mention I like the abvility to do eveything over ssh
15:06<xris>gbee: jedit for me, all the way. :)
15:08<eskil>sed & awk anyone ?
15:08<kvandivo>for editing?
15:08<kvandivo>that's hard core
15:09<eskil>yeah, hopefully noone does that.
15:09<eskil>unless they're wearing suspenders, a long beard and work as a admin on some old AIX installation.
15:09<janneg>dd should be enough :)
15:09<eskil>janneg, that's just a fancy cat.
15:10<gbee>what I particularly couldn't live without in Kdevelop is that it's designed around multiple project work, I can resume working where I left off with all the same files open for each project, I can quickly open new files and switch between open files, search replace in all project files or only the open files etc
15:12<gbee>things like syntax highlighting are also nice (though not unique), it gives my eyes a rest :)
15:12<eskil>IDEs are like etags, I really feel I should use them, and I occasionally try. But at the end of the day, I just revert back to me old habits for absolutely no good reason.
15:12<kvandivo>^5
15:13<eskil>word
15:14|-|Chai_Sangeen [n=Chai_San@89.148.3.9] has joined #mythtv
15:14<Chai_Sangeen>hello
15:14|-|mythn00b [n=pepin@69.159.216.64] has joined #mythtv
15:14<Chai_Sangeen>anyone can help
15:14<gbee>it's built in grep support is also nice, do a search and it'll hyperlink the results so that clicking on one will open that file and take you to the line in question
15:14<Chai_Sangeen>im having ttouble runing muthtv
15:15[~]stuarta points to the topic
15:15<Chai_Sangeen>on ubuntu edgy can anyone help
15:15[~]stuarta points to the topic again
15:15<Chai_Sangeen>ohh heheh sorry
15:15<Chai_Sangeen>thanx
15:15<gbee>at the end of the day I feel it saves me some time - which I can then spend doing anything but working :p
15:15<mythn00b>I made a patch to mythtv last night, to adjust the PMT processing method.. however, even though my code doesnt modify the inbound PMT, I get myth messages about a wrong pmt
15:15<mythn00b>what am I missing.. whats 'wrong' about it?
15:16|-|Chai_Sangeen [n=Chai_San@89.148.3.9] has left #mythtv ["Leaving"]
15:16<mythn00b>the structure its analysing is generated/sourced by myth, not my code
15:16<stuarta>how are you attempting to do that??
15:17<gbee>mythn00b: might help if you pastebin the patch
15:17<mythn00b>there's a routine which receives a structure.. so I copy in memory the inbound pmt structure, then do my modified processing in parallel.. so I can spit otuut messages from my routine
15:17<mythn00b>to see wtf's up
15:17<mythn00b>but myth keeps saying wrong pmt
15:17<mythn00b>like it knows what the right # should be
15:17<mythn00b>??
15:18<stuarta>it's looking for a specific pmt
15:18<stuarta>so that is knows which streams to pick out of the broadcast to form the "program"
15:18<mythn00b>I guess it records pmt#'s during the channel scan, but like, it should use the same freq 'n shit, when I try to watch 'live tv'
15:18<mythn00b>so, I would assume it would tune the same freq from its records
15:18<mythn00b>and so the pmt should also match up
15:18<mythn00b>right
15:18<mythn00b>?
15:19<stuarta>pmt != frequency
15:19<mythn00b>I would love to paste the patch, but I'm @ work right now, I dont have access to my machine @ home.
15:19<mythn00b>pmt is like a pre-table to mpeg substreams
15:19<mythn00b>but like
15:19<stuarta>how well do you understand multiplexing of multiple program streams into an mpeg broadcast stream?
15:19<mythn00b>a given freq has a given transport, has a given pmt
15:19<mythn00b>right?
15:19<stuarta>no
15:20<mythn00b>I thought it was an A-B-C kinda relationship
15:20<stuarta>a given transport is on a specific freq
15:20<mythn00b>freq (1hz) - has 1 TS.. and there should be one PMT to 1 TS? no?
15:21<stuarta>nope. multiple PMTs (or programs) at any time
15:21<mythn00b>pmt says, "okay, you got an mpeg2 ts, its got these program stream pid's... this is how it 'maps out' for viewing"
15:21<mythn00b>oh
15:21<mythn00b>so there's many PMT's per TS
15:21<mythn00b>1 pmt per "video channel" / program
15:21<stuarta>i *strongly* suggest going off and doing some more reading on multiplexing DVB
15:22|-|degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has joined #mythtv
15:22<mythn00b>I can accept that, but I dont understand why I'd be getting those messages from myth
15:22<stuarta>mythn00b: pop quiz! what does PMT stand for?
15:22<mythn00b>if I'm not modifing its struct
15:22<mythn00b>program multiplex table?
15:22<stuarta>bzzzt
15:22<stuarta>Program Map Table.
15:23<janneg>program map table
15:23<mythn00b>is the map not describing a multiplex?
15:23<stuarta>okay, you don't understand yet the underlying technologies.
15:23<stuarta>you *NEED* to do some more reading
15:23<mythn00b>okay
15:23<mythn00b>maybe you could answer this
15:24<mythn00b>what could cause myth to print that message? assuming myth worked fine before, and was not patched
15:24<janneg>no, it describes a program (mpeg) / service (dvb)
15:24<mythn00b>and started spitting out "wrong PMT" messages
15:24<mythn00b>?
15:25<mythn00b>... and the room goes silent..?
15:25|-|lcase [n=l-case@p54B32912.dip0.t-ipconnect.de] has quit []
15:25<mythn00b>bbbzzzzztt... sorry.. you didnt answer in time.. correct answer is: "they dont know!"
15:25<mythn00b>:)
15:25<stuarta>it can't find it.
15:26<mythn00b>is it possible for the dvb card to be reading the stream "off" offset
15:26<stuarta>(actually I was busy trying to find *you* a link to a basic multiplexing tut i've seen)
15:26<mythn00b>like, its trying to find a block header start or something
15:26<mythn00b>and it cant, so its interpreting the data wrong
15:28<mythn00b>I would appreciate that link
15:28[~]stuarta is still digging
15:29<mythn00b>its funny how quick ppl are to tell you you're wrong, but when they cant answer back.. who's right? :)
15:29<mythn00b>thats not a poke or anything.. just a quip :)
15:29<stuarta>put it this way, the info you are talking about is covered by at least 1000 pages of specification documents.
15:29<mythn00b>well I've been googlin' on why myth
15:29<mythn00b>would even print that message
15:29<mythn00b>and documents to that end are slim to none
15:30<janneg>are you sure that you get a "wrong pmt" message? I don't know that would cause this. I have a ticket about wrong PATs
15:30<mythn00b>ppl complaining about the message
15:30<mythn00b>but nobody actually saying how they fixed it
15:30<Chutt>google answers questions about why something prints much better than looking at the code does.
15:30|-|test34 [n=test34@unaffiliated/test34] has joined #mythtv
15:30|-|test34 [n=test34@unaffiliated/test34] has left #mythtv []
15:30<mythn00b>sometimes
15:30<mythn00b>when other ppl've had the same problem.. it does
15:30<stuarta>you can get it if channels have been removed since you last scanned for channels
15:30<mythn00b>and sometimes doing an endless grip helps
15:30<janneg>that are either caused by changes in the multiplex or for other mysterious reasons.
15:30<Chutt>grip?
15:30<mythn00b>grip = grep
15:31<Chutt>mythn00b, switch to a real nick.
15:31|-|mythn00b changed nick to mythnoob2
15:31<mythnoob2>happy :P
15:31<janneg>lol
15:31<Chutt>uh, no.
15:31<stuarta>one that doesn't include myth
15:31|-|mythnoob2 changed nick to noob2my7h
15:31<kvandivo>try pmtn00b
15:31<noob2my7h>haha
15:31<gbee>hang on, didn't you say to begin with that your patch was causing the errors?
15:32<noob2my7h>no no.. I patched it. so I thought it could be the source.. BUT, it hsouldnt be.. because I'm not 'interrupting' the existing flow
15:32<noob2my7h>its a copy & operate.. and it doesnt pass on modified data to myth
15:32<gbee>well does it work without the patch?
15:32<noob2my7h>it was strictly an analytical operation
15:32<noob2my7h>myth allways says wrong PMT now..
15:32<noob2my7h>patched and unpatched
15:33<noob2my7h>didn't before
15:33[~]janneg ignores the l33t hax0r noob2my7h and hopes that he doesn't change the nick again
15:33<noob2my7h>heh
15:33<noob2my7h>exciting times.
15:34[~]stuarta goes back to fixing bugs
15:34<noob2my7h>thanks for your time guys
15:34<noob2my7h>its been fun.
15:34<noob2my7h>I'll be back.. stay leet here.
15:34|-|noob2my7h [n=pepin@69.159.216.64] has quit ["leaving"]
15:36<janneg>it might actually be a regression. It's probably caused by a multiplex with several PMT on the same PID
15:36<stuarta>they exist in the wild?
15:38<janneg>iirc dishnet has such multiplexes. as they are short on PIDs
15:38<stuarta>he was in canada
15:42|-|jmk_ [n=jmk@pat.foofus.net] has joined #mythtv
15:45<xris>wow. how cool is he for being so 31337... ;)
15:56<stuarta>prime example of a PEBKAC
15:58|-|_splat1 [n=splat1@cpc2-leic7-0-0-cust281.lei3.cable.ntl.com] has joined #mythtv
15:59|-|MrGandalf [n=mgandalf@cpe-72-225-37-244.rochester.res.rr.com] has quit [Remote closed the connection]
16:00|-|sc00p_ [n=oldendic@cpe-071-076-001-155.sc.res.rr.com] has left #mythtv ["Leaving"]
16:02|-|Netsplit leguin.freenode.net <-> irc.freenode.net quits: WZ__, splat1
16:02|-|Netsplit over, joins: WZ__
16:06|-|Anduin [n=awithers@adsl-69-110-13-87.dsl.pltn13.pacbell.net] has joined #mythtv
16:11<janneg>bah, the free bsd support patch is ugly and I doubt that ifdefing the locks out is correct
16:17<GreyFoxx>hahahah
16:18<GreyFoxx>and he's submitting patches against SVN but he is running 0.18 with his custom patches
16:18<Chutt>it's not.
16:18<GreyFoxx>so it's not like he has tested any of it other than compiling (if that) :)
16:26|-|_splat1 changed nick to splat1
16:30<xris>I just liked the attitude of "I'm happy to submit patches for a 2+ year old program for you to apply to the current version"
16:30<briand>ah, so Shakespeare wrote about him: "it is a tale, told by an idiot; full of sound and fury... signifying nothing."
16:30<briand>;)
16:32<briand>oh, and xris: i was serious about doing that patch for mythmusic searching -- whenever you and paul are done with the database optimization, etc, I'll see what I can put together for it. (it'd be a good "starter" project for me to get my feet wet, anyway)
16:42<gbee>what patch it this?
16:46|-|degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has quit [Remote closed the connection]
16:53<Chutt>the freebsd one
17:00|-|czth_ [i=dbrobins@nat/microsoft/x-23cce967b64f0e1d] has quit ["Leaving"]
17:01|-|aevil^aw [n=aevil@i59F5698B.versanet.de] has quit [Read error: 60 (Operation timed out)]
17:03<gbee>I meant the one briand mentioned
17:03<Chutt>ah
17:03<Chutt>right.
17:04<briand>gbee: I was considering writing a patch to add a sort field to the music_artists table, so that the 'sort name' doesn't have to be the display name
17:05<gbee>ahh
17:05<briand>basically, so I don't have to change my mp3 headers to say "McCartney, Paul" or "Ten Thousand Maniacs" to get them to show up where I'd expect.
17:06<gbee>Chutt: I messed up on that scanning commit - sorry for dragging you into it
17:06<briand>by default, the new column would contain a copy of the artist_name varchar(255) column, so everything would work like it always did, unless someone edited their sort string for that artist
17:06<Chutt>heh, np
17:07|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
17:08<gbee>briand: personally I'd try to think of ways I could keep the storage cost down and get the maximum performance from it
17:09<gbee>but I don't have any ideas at the moment ;)
17:10<briand>i agree re: storage... but varchar(255) would take no more than 255 extra bytes (usually far less) to properly classify/sort a ~4.5MByte file. trivial compared to the size of the media represented
17:10<gbee>256 :)
17:10<briand>well, true.
17:11<gbee>255+1
17:11<briand>I don't think I have too many 255-character artist names, tho...
17:11<briand>and I do have a LOT of mp3 files (and more to come!)
17:11<gbee>but yes, it's not a huge cost if it's the only way to go about it
17:12<briand>well, I'm thinking in terms of program performance as well... trying to codify the rules such that everybody would be happy with the result would cost a lot more than this proposal would, in my opinion
17:13<briand>in fact, there'd be practically 0-time to fill the list, since the program wouldn't have to sort it (the column could be indexed)
17:13<briand>so this change should actually improve performance (noticeably so for folks that have lots of mp3 files)
17:14<gbee>I'm not sure I'd personally want to go through all my mp3s to make that change, but I guess those that want the feature would see it differently
17:14<briand>well, in my case, I'd probably change it programmatically for the majority, to repopulate that column with {lastname,firstname}... then make the tweaks past that
17:15<briand>but then, this wouldn't be the first time I've been accused of being anal-retentive about things like this, either.. ;)
17:15<gbee>well the problem with ORDER BY is that it resorts to "file sorting" in queries with lots of joins etc - something which the mythmusic schema requires a lot of
17:15<Chutt>old scheme didn't need any joins =)
17:16<gbee>aye
17:16<briand>well, there's a join between music_songs and music_artists, already...
17:17<briand>then it sorts based on music_artists.artist_name to fill the alphabetical list
17:17<gbee>If the way mythmusic behaves is changed that should be much of a problem though - right now the tree builder etc loads all the songs pulling in the artist, album, genre information
17:18<gbee>if instead we fetched the information as needed it would avoid that overhead
17:18<briand>right.. and my thinking was that it should improve that tree-filling routine, because the data would already be pre-sorted as it was returned from the fetch()
17:19<gbee>i.e. on the playlists screen you have the options "Artist, Album, Genre, Year" etc selecting Artist would just call up the information from the artists table
17:19<briand>exactly: we don't need to pull up artists starting with "F", if the user is looking at artists starting with "A"
17:19<gbee>glad your following me :)
17:20<gbee>loading up the lot isn't needed - in fact it's one reason why the mythmusic menus are so slow
17:21<briand>i've done some relational database work in the past (a 2.9 TB Oracle database of homes for sale) for print/web/etc..
17:21<briand>agreed. ...and, as the music collection grows, it only becomes slower.
17:21<gbee>if you go to the music tools menu, it loads up the lot in the backend, for no good reason - same with the settings pages
17:21<briand>i hope to change it so that the interface is at the same performance level, regardless of the number of music files in one's collection
17:22<gbee>well we're working towards the same goal then :)
17:22|-|beavis [n=beavis@p54A7A252.dip0.t-ipconnect.de] has quit [Remote closed the connection]
17:22<briand>if you throw 15,000 mp3 files in your directory, it becomes evident in fairly short order. ;)
17:22<eskil>progressive loading would also reduce the memory consumption.
17:22<briand>yep.
17:22<gbee>eskil: yep, another benefit
17:22<eskil>my box is unhappy when mythmusic loads more than 40K entries.
17:23<briand>well, as I said, this is something I can "tackle" to get my feet wet with mythtv programming, so i'm happy to take it on
17:24<briand>i feel i should do -something-, considering all the entertainment/convenience i've received from the project for nothing. :)
17:24<eskil>I've been looking at writing a upnp browser as a kinda mythmusic replacement, and upnp has a nice way of encouring loading small portions
17:24<gbee>I only started to take a look at this when I found myself waiting 10 minutes for it to peform an _update_ scan i.e. when only a dozen files had changed on the system, it was still taking that long to complete
17:24<eskil>(and generating huge xml strings for little content...)
17:25|-|jgarvey [n=jgarvey@cpe-075-177-158-190.nc.res.rr.com] has quit ["Leaving"]
17:25<gbee>now I reduced that to a few seconds pretty quickly by fixing some timestamp bugs, but in doing that I noticed how inefficient the existing code it
17:25<gbee>s/it/is/
17:25<briand>eskil: you have 40K music files on your system now?
17:26<eskil>briand, somewhere around that number.
17:26<briand>i am humbled by your encoding prowess.
17:26<briand>;)
17:26<eskil>briand, it's more a question of various roommates over the years and the occasional "Mind if I just copy all your crap?"
17:26<briand>I've got most of my #1 singles encoded, and most of my 'one hit wonder' singles encoded
17:27<briand>but, i'd estimate that's less than 1/10th of my music collection
17:27<briand>ideally, i would like to have every song that ever charted on the billboard hot 100 chart available on my system
17:28<eskil>I just have a lot of dupes....
17:28<briand>i've got most of the music... just not digitally encoded
17:28<gbee>eskil: it is quite likely that mythmusic may become more of a uPnP client - turning mythmusic into a backend/frontend setup is a long term item on the wishlist and with the uPNP changes being made now it's coming closer to reality than it has since Thor's work
17:29<eskil>gbee, I was looking at the mfd to see if it be a good starting place.
17:30<eskil>gbee, I've been working on ipod support, but adding multiple storages mythmusic is hard.
17:30<eskil>gbee, so that's when I figured that mfd already has it. But code that's been untouched for that long also seems like a bad starting point.
17:30<gbee>I think CDev's upnp work might be better starting point, combined with some protocol additions
17:31<eskil>gbee, my main problem is just that the existing mythmusic codebase is unwieldy, and that any stab at it first requires big cleanups.
17:31<eskil>gbee, CDev's, is that the severside upnp support ?
17:32<gbee>multiple storage directories for mythmusic might be made easier with the music_directories table - it has a parent_id field, so it could in theory reference different base directories
17:33|-|Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
17:33<eskil>gbee, yes and no, some stores, ie. the list of shoutcast streams or an iPod don't have directories.
17:33<gbee>eskil: yeah mythmusic needs a lot of work - but something as simple as breaking the scanning code into it's own class makes it easier to eventually migrate to the backend
17:34<CDev_>eskil: My main focus has been with the server side uPnp Code. (Media server: Content Directory Service).
17:34<eskil>gbee, yes.
17:34<CDev_>However, my most recent changes have been with adding the basic support for mythfrontend to be a MediaRenderer/Control point.
17:34<eskil>CDev_, yeah I was looking at using that to write a 'mythmusic' that would traverse the content directory instead of talking to the db.
17:35<gbee>a directory doesn't _have_ to mean a system path - it's just a question of how we handle switching between a stream and a physical path
17:36<eskil>gbee, ideally the music browsing would not at all talk to the db, but only to stores. One such store would then be the upnp content directory that would use the db.
17:37<gbee>probably not at the top of my list, getting the current code into better shape comes first
17:37<stuarta>what about removable devices?
17:37<eskil>stuarta, they would be another store that the frontend would talk to.
17:37<gbee>stuarta: that's easier, if we can tie in to the mediamonitor to know when it is or isn't available
17:38<stuarta>yup, just wondering where you'd get the upnp from
17:38<eskil>gbee, which brings me to my patch to use inotify to make mediamonitor discover newly added devices...
17:38<stuarta>or planning to generate it from the device?
17:38<gbee>eskil: not sure that's the direction I would take - not immediately at least
17:39<eskil>stuarta, a locally connected things like an ipod or usb drive wouldn't be using upnp, but all stores would be subclasses of something that supports upnp style browsing.
17:39<eskil>gbee, reg. inotify ?
17:39<stuarta>fair enough
17:39[~]stuarta goes back to lurking
17:41<gbee>meant using the content directory interface for everything
17:42<gbee>it's probably a good idea in the longer term, but I'd rather focus on the near term - i.e. fixing the current structure to at least an acceptable level for 0.21
17:44<gbee>btw, I might make some changes to the APIC patch if that is ok - not entirely happy with a couple of things
17:44<eskil>gbee, sure, at long as it loads images I'm happy. (what's wrong ?)
17:45<eskil>gbee, the content directory interface it just already that kinda nice generic progressive loading lets-support-any-kinda-media-known-to-mankind-bullshit api that would make a good starting point to steal rather than reinvent.
17:47<gbee>well purely from memory - in the function which looks for the album art in the id3 tag, if it fails to find any then it calls the art in folder check
17:48<gbee>I'd rather it just returned false, then the calling function in metadata would make that call
17:48<eskil>gbee, 10 to 1 says that anyone ever calling the method will end up doing just that check.
17:48<gbee>if that's poorly explained, well like I said I'm going from memory without looking at the code or patch
17:49<eskil>gbee, no I know what you mean, and I can understand why (but I don't agree :-))
17:49<eskil>gbee, it just seemed like the natural way to subclass it. The generic MetaIO would look for a file, but the id3v2 subclass would first look for a APIC tag, then fallback to files.
17:50<gbee>It just seperates out id3 handlign functions/class from the metadata functions better to not have them both referencing each other
17:50<eskil>gbee, that way it works the same way for any file format, other formats can also override the method if they support albumart in the tags.
17:50<eskil>gbee, it's all good, you're the one with svn acces, you make the call.
17:51<gbee>it could still work that way - if the subclass for a particular format doesn't support the metadata in tags then it just returns false
17:51<eskil>gbee, yeah, but 10 to 1 says that anyone who ever does that call and gets a false will then go ahead and look for the file.
17:52<eskil>gbee, but otoh, with your change, people know that the image wasn't in the tags, and can decide to add it. My way doesn't really allow for that.
17:52<gbee>think we must be misunderstanding each other here
17:52<eskil>gbee, so your change is probably good.
17:53<gbee>functionally I wouldn't change anything, it's just how the actual code is organised
17:54<eskil>gbee, I think I understand what you mean, and it makes sense since it makes it obvious if an image came from the tags or random file picking.
17:54<gbee>so it would still automatically fall back to grabbing the art from the folder - but the call to that function wouldn't be from the same place
17:55<eskil>gbee, yeah, that's a good change.
17:55<gbee>anyway, you'll see what I mean when I commit it
17:55<gbee>I'll just try to remember to add that decoder/encoder deletion before I do :)
17:57<gbee>heh, wasn't either it's the tagger
17:58<eskil>oh the one I forgot ?
17:59<gbee>yeah
18:01<gbee>what is this fascination with removing QSqlQuery methods when there is no performance to be gained?
18:03<gbee>sure for the sake of clarity and just keeping the code tidy I would probably make the changes myself - but why make such a big deal of it?
18:10|-|brtab [n=brtab@c-24-63-181-112.hsd1.ma.comcast.net] has left #mythtv []
18:10|-|MrGandalf [i=buechlmr@cpe-72-225-32-214.rochester.res.rr.com] has joined #mythtv
18:11<MrGandalf>Has anyone ever seen a case where a PVR 250/500 can't switch inputs from Tuner 0?
18:15<eskil>oh, snow in the mountains! must pack gear!
18:15|-|eskil [n=eskil@natint3.juniper.net] has quit ["Leaving"]
18:16<MrGandalf>computers and I are not getting along this week
18:21|-|clever [n=clever@fctnnbsc16w-156034210168.nb.aliant.net] has quit ["leaving"]
18:22<stuarta>the preview thread giving anyone else grief on their frontend lately?
18:24<GreyFoxx>happily I haven't had any issues with preview generation in along time
18:25<stuarta>just started with the latest update i've done
18:25<stuarta>try scrolling through a long list of recordings
18:25<GreyFoxx>after janne's mpeg2 startcode commit ?
18:25<stuarta>just before that
18:25<GreyFoxx>ahhh
18:25<GreyFoxx>I haven't updated in acouple days
18:26<GreyFoxx>at least, not here at home
18:26<stuarta>frontend goes nuts, it's busy off doing something
18:26<stuarta>comes back after maybe 20-30secs....
18:26<stuarta>nasty.
18:27<GreyFoxx>I need to send my wife and daughter away for aweekend so I can sit down and finish some of the patches I've been working on
18:27<stuarta>i can relate to that. need a weekend with nothing planned to do the same...
18:27<GreyFoxx>yeah, nothing planned and noone to distract me
18:28<stuarta>and no recordings :)
18:28<GreyFoxx>and of course , no oncall for work heh
18:28<GreyFoxx>that to :)
18:36<janneg>ffmpeg isn't handling my recordings h264 that well. mpeg2 is fine even with the "current_picture not initialized" part
18:36<janneg>and I see that error ocasionally
18:40<janneg>but it's probably ok to revert that change and report errors upstream if they are reproduceable with ffmpeg/ffplay
18:44<gbee>since commenting out that change I've seen no reoccurance of the problem
19:17<MrGandalf>I don't know why but I seem to attract the most obscure bugs in everything..
19:29|-|AcidUK [n=acid@horace.resolve.me.uk] has joined #mythtv
19:52|-|frank___ [n=frank@CPE001839c1904e-CM00080d26a042.cpe.net.cable.rogers.com] has joined #mythtv
19:53|-|frank___ [n=frank@CPE001839c1904e-CM00080d26a042.cpe.net.cable.rogers.com] has left #mythtv ["Konversation terminated!"]
20:42|-|degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has joined #mythtv
20:48|-|cattelan_away changed nick to cattelan
21:30|-|CDev_ [n=CDev@c-71-233-206-26.hsd1.ma.comcast.net] has left #mythtv []
21:31|-|CDev [n=CDev@c-71-233-206-26.hsd1.ma.comcast.net] has joined #mythtv
21:33|-|Netsplit leguin.freenode.net <-> irc.freenode.net quits: Nem^
21:34|-|Netsplit over, joins: Nem^
21:40|-|o_cee [n=oscar@c83-249-96-144.bredband.comhem.se] has quit [Read error: 110 (Connection timed out)]
21:47<Captain_Murdoch>Chutt, I figure it was partially a joke, but I'm fine with upgrading to MySQL 4.x/5.x anytime. I have a couple 5.x servers already, just need to update the VM that houses my Myth DB. :)
21:50<xris>I'd *love* to add a requirement for 5.x. heh.
21:50<xris>should at least ponder setting it as a target for some point in the future (.22, etc)
21:50<xris>subqueries would make some of the slower queries a lot faster.
21:51<Captain_Murdoch>I don't think I"m the only dev using 3.x though. I thought there were a couple more. my Myth DB is in its own dedicated VM and I can upgrade it anytime in probably less than an hour.
21:52<Captain_Murdoch>yeah, would make a lot of things quicker probably.
21:59<xris>well, could just do it when we move to embedded mysql
22:01|-|russellb [n=russell@12-214-191-64.client.mchsi.com] has joined #mythtv
22:03[~]xris twiddles his thumbs while waiting for new website to roll out.
22:10[~]Captain_Murdoch tries to shoehorn a new kernel into the CentOS image in Opsware so he can image some new Dell PE1950 servers
22:23<Chutt>kevin still is, iirc
22:23<Chutt>and it was partially a joke =)
22:24<Captain_Murdoch>figured so. :)
22:24<Captain_Murdoch>we could say that 0.21 is the last version to support 3.x
22:26<Chutt>sure
22:26<Chutt>and older qt's as well.
22:26<Chutt>want to bring it up on the list?
22:26<Captain_Murdoch>min of 3.3 after 0.21?
22:26<Chutt>sure
22:26<Captain_Murdoch>bring it up for discussion or warning? :)
22:27<Chutt>discussion on developers
22:27<Captain_Murdoch>ok.
22:27<Captain_Murdoch>will do
22:29<xris>I've already set .21 as the last version of mythweb to support < php 5
22:30<mikegrb_>BLACK JACK!
22:30<Captain_Murdoch>ok, I'll mention that as well.
22:33<xris>I need to keep kormoc in line with his mythweb-video rewrites to be php4-safe, too. heh
22:33|-|xris [n=xris@dsl081-161-160.sea1.dsl.speakeasy.net] has quit ["http://forevermore.net/"]
22:36|-|cmorgan [n=cmorgan@68-116-193-70.dhcp.oxfr.ma.charter.com] has joined #mythtv
22:38|-|Nem^1 [n=Nem@dslb-084-056-244-200.pools.arcor-ip.net] has joined #mythtv
22:48|-|russellb [n=russell@asterisk/developer-and-stable-maintainer/drumkilla] has quit []
22:50|-|russellb [n=russell@12-214-191-64.client.mchsi.com] has joined #mythtv
22:57|-|cmorgan [n=cmorgan@68-116-193-70.dhcp.oxfr.ma.charter.com] has quit [Remote closed the connection]
22:58|-|Nem^ [n=Nem@dslb-084-056-230-028.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
22:59|-|Nem^1 changed nick to Nem^
23:00[~]Captain_Murdoch sees Tony Lill asking about that some form of that async DB patch going into -fixes as a bugfix for the recorded table contention.
23:08|-|sc00p [n=oldendic@cpe-071-076-001-155.sc.res.rr.com] has joined #mythtv
23:11<Captain_Murdoch>didn't we used to have a fsync() in the RingBuffer to prevent the OS from writing massive amounts of data at once and instead force data to disk every so often.
23:12<Captain_Murdoch>ah, in I TFW I guess.
23:13<Chutt>it's still there, no?
23:13<Captain_Murdoch>yeah
23:13<Captain_Murdoch> just wondering why this whole "pdflush is kiiling me" thread is going on if we're fsync-ing regularly.
23:14|-|gnome42 [n=obi@dsl-145-67.aei.ca] has quit [Remote closed the connection]
23:15<Chutt>i just got stuff working on this prototype hardware, and none of my co-workers are around for me to tell :(
23:15<Captain_Murdoch>slackers...
23:16|-|sc00p [n=oldendic@cpe-071-076-001-155.sc.res.rr.com] has left #mythtv ["Leaving"]
23:17|-|beata-- [i=beata@c-68-83-135-4.hsd1.nj.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
23:17|-|xris [n=xris@xris.forevermore.net] has joined #mythtv
23:17|-|beata [i=beata@c-68-83-135-4.hsd1.nj.comcast.net] has joined #mythtv
23:19|-|sc00p [n=oldendic@cpe-071-076-001-155.sc.res.rr.com] has joined #mythtv
23:25<Chutt>2048x1536 is 3 mp
23:25<Chutt>correct?
23:25<Chutt>yay.
23:25<Chutt>ok.
23:26|-|PointyPumper [i=Pintlezz@OL221-67.fibertel.com.ar] has quit [Read error: 104 (Connection reset by peer)]
23:28|-|PointyPumper [i=Pintlezz@OL221-67.fibertel.com.ar] has joined #mythtv
23:36|-|justinh [n=justin@spc1-salf3-0-0-cust227.bagu.broadband.ntl.com] has joined #mythtv
23:36|-|russellb [n=russell@asterisk/developer-and-stable-maintainer/drumkilla] has quit [Connection reset by peer]
23:36<justinh>morning folks
23:37|-|russellb [n=russell@12-214-191-64.client.mchsi.com] has joined #mythtv
23:39<justinh>I've been having a dig in the source of mythvideo to try & determine how I might go about adding a background theme element to the 'gallery' view and I've not had any luck. I figured it might be relatively trivial to add but I can't find any references to themed backgrounds in the source for either the list view or the browser
23:41<xris>justinh: in the code (i.e. adding a "specify background image here" kind of thing) or designing a theme?
23:42<justinh>xris: both. I'd like the video gallery view to be background-able like the other screens in mythvideo are
23:42|-|russellb [n=russell@asterisk/developer-and-stable-maintainer/drumkilla] has quit []
23:42<justinh>I thought (duh) it'd be a quick & easy thing to fix up but my rooting around hasn't come up with anything yet
23:42<xris>right. but are you trying to add an option so the USER can do it, or do you just want to do it within a theme?
23:43<justinh>I'd like to do it within a theme
23:44<xris>only think I could recommend is to ask juski. he's not a dev (yet), but knows a lot about theme design... That is, unless Anduin is awake and cares to respond.
23:44<justinh>hahaha
23:44<justinh>I'll go ask me then ;)
23:45<xris>oh. you changed your name?
23:45<justinh>adding a background element to the gallery screen in the xml file seems to be ignored, it's bugged me for a while & it's also bothering mr mepo-wide creator
23:45<xris>no wonder I saw people asking you earlier if you were juski. heh.
23:47<justinh>I can't remember how I ended up with the handle of juski & well, I thought it was time for a change. figured regulars would figure it out eventually ;)
23:48<justinh>I think being introduced on stage as 'juski' in front of a couple of hundred people brought it home but it's taken a while for that to eat away
23:50<justinh>I've spoken with Anduin about the background thing before, he said he might look at it if he ever got around to it (IIRC) but I wouldn't mind having a go. seems easy til you actually look in the code
23:50<xris>heh
23:50<xris>my coworkers all call me "ex-ris"
23:51<Chutt>additional background elements / etc are built in to mythui
23:51<Chutt>they'd have to be added specifically in the old stuff
23:51<xris>mmm.. tasty british beer.
23:52|-|degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
23:52|-|degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has joined #mythtv
23:52<justinh>ahhh
23:53<justinh> LayerSet *container = theme->GetSet("background");
23:54<justinh>videogallery.cpp doesn't have that but has other GetSet stuff in the code I have here
23:55<justinh>so I'd need to add code to get the background, draw the background & update it like the other pages do, not quite as trivial as I thought but may be within my capacity :)
23:56<xris>Chutt: thinking I should move the mythtv.org svn stuff to the root dir in svn instead of in trunk. thoughts? maybe under branches instead?
23:57<Chutt>i don't care =)
23:57<xris>lol, ok
23:58<xris>root dir it is
---Logclosed Thu Feb 08 00:00:30 2007