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

---Logopened Wed Mar 07 00:00:16 2007
00:07|-|user4324454165 [] has left #mythtv ["Leaving"]
00:09|-|daMaestro [n=jon@fedora/damaestro] has quit ["Leaving"]
00:31|-|frag_spawn [] has quit [Remote closed the connection]
00:58|-|ratbert90 [] has joined #mythtv
01:37|-|rbellamy_ [] has joined #mythtv
01:43|-|luna6 [] has quit [Read error: 104 (Connection reset by peer)]
01:43|-|luna6 [] has joined #mythtv
01:47|-|gnome42 [] has quit [Remote closed the connection]
01:54|-|rbellamy [n=rbellamy@pdpc/supporter/silver/rbellamy] has quit [Read error: 110 (Connection timed out)]
02:13|-|robthebob [] has joined #mythtv
02:29|-|xris [] has quit ["Leaving."]
02:47|-|flatronf701B [n=flatronf@] has quit [Read error: 128 (Network is unreachable)]
02:50|-|kormoc [] has quit []
02:54|-|robthebob [] has quit [Read error: 148 (No route to host)]
03:14|-|tomimo [] has quit [Remote closed the connection]
03:27|-|Dibblah [] has quit [Read error: 113 (No route to host)]
03:28|-|Dibblah [] has joined #mythtv
03:34|-|Dibblah [] has quit [Remote closed the connection]
03:47|-|celston [] has left #mythtv []
03:50|-|Dibblah [] has joined #mythtv
03:51|-|celston [] has joined #mythtv
03:53|-|celston [] has quit [Client Quit]
03:57|-|LLyric [] has joined #mythtv
03:59<gbee>odd, patch isn't working
04:02|-|degreseven [] has quit [Remote closed the connection]
04:03<gbee>is there an alternative to patch?
04:03<stuarta>patch, as in patch < diff.file ???
04:04<gbee>just stopped working on my backend, which makes testing things difficult
04:04<stuarta>check it's not dos encoded
04:05|-|splAt1 changed nick to splat1
04:05<gbee>not working even with older patches I know to work, besides which I only created this patch 5 minutes ago on my linux laptop
04:05|-|splat1 changed nick to splAt1
04:06<gbee>ah-ha, for some strange reason it worked when I added --verbose
04:08<gbee>before that it just hung until I killed it
04:12<gbee>suspect it's something to do with the upgrades I made yesterday in an effort to get my new tuner working
04:13<stuarta>new toy!
04:13<gbee>I wish, seems to be faulty :(
04:13<stuarta>tried in windows?
04:14<gbee>don't have a windows machine - although I've got an XP disk somewhere
04:14<stuarta>it's the only reason i actually have windows
04:19<gbee>wonder if I've got an old drive around that I can install windows on
04:22<gbee>huh, just found a couple of drives I didn't even remembering owning - 20Gb and 40Gb
04:24<gbee>actually no I remember the 40Gb now, it's an IBM Deskstar which sounds like a Jet taking off
04:24<stuarta>sounds like a perfect candidate...
04:25<gbee>aye, just hooking it up now
04:29|-|celston [] has joined #mythtv
04:33|-|melunko_ [n=hmelo@] has quit [Read error: 110 (Connection timed out)]
04:33|-|melunko__ [n=hmelo@] has joined #mythtv
04:34|-|melunko_ [n=hmelo@] has joined #mythtv
04:34|-|melunko [n=hmelo@] has quit [Read error: 110 (Connection timed out)]
04:36<gbee>this time I try it with the power cable attached
04:37<gbee>ahh bugger, OEM copy of WinXP only works with the laptop - time to find the Win2K disk
04:45|-|celston [] has left #mythtv []
04:51|-|Dibblah [] has quit [Read error: 113 (No route to host)]
05:16|-|Dibblah [] has joined #mythtv
05:21|-|JoeBorn [] has quit [Read error: 110 (Connection timed out)]
05:59|-|gbee [] has quit [Excess Flood]
06:06|-|aevil [] has joined #mythtv
06:07|-|gbee [] has joined #mythtv
06:10|-|JoeBorn [] has joined #mythtv
06:12|-|MrGandalf [] has quit ["Leaving"]
06:18|-|DrNickRiviera [] has joined #mythtv
06:35|-|melunko_ [n=hmelo@] has quit [Read error: 110 (Connection timed out)]
06:37|-|melunko__ [n=hmelo@] has quit [Read error: 110 (Connection timed out)]
06:43|-|JoeBorn [] has quit [Read error: 110 (Connection timed out)]
06:49|-|Dibblah [] has quit [Remote closed the connection]
06:54|-|Dibblah [] has joined #mythtv
06:56|-|MoRpHeUz [n=morphbr@] has joined #mythtv
06:58|-|Topis [] has quit [Read error: 131 (Connection reset by peer)]
07:08|-|Dibblah [] has quit [Remote closed the connection]
07:10|-|melunko [n=hmelo@] has joined #mythtv
07:10|-|melunko_ [n=hmelo@] has joined #mythtv
07:11|-|melunko_ [n=hmelo@] has left #mythtv ["Leaving"]
07:11|-|melunko [n=hmelo@] has left #mythtv ["Leaving"]
07:17|-|tomimo [] has joined #mythtv
07:21|-|gbee [] has quit [SendQ exceeded]
07:32|-|Dibblah [] has joined #mythtv
07:32|-|gbee [] has joined #mythtv
08:11|-|okolsi [] has joined #mythtv
08:22|-|xian__ [] has quit ["Leaving"]
08:25|-|onixian [] has joined #mythtv
08:29|-|onixian [] has quit [Client Quit]
08:31|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
08:35|-|Dibblah [] has quit [Remote closed the connection]
08:41|-|okolsi [] has quit ["Leaving"]
08:46|-|ratbert90 [] has quit [Client Quit]
09:05|-|CDev [] has quit ["Trillian ("]
09:11|-|Cougar [] has quit []
09:13|-|CDev [] has joined #mythtv
09:19|-|Cougar [] has joined #mythtv
09:25|-|luna6 [] has quit [Read error: 104 (Connection reset by peer)]
09:34|-|jgarvey [] has joined #mythtv
09:37|-|okolsi [] has joined #mythtv
09:42|-|luna6 [] has joined #mythtv
09:50|-|flatronf701B [n=flatronf@] has joined #mythtv
09:57|-|rbellamy_ [] has quit ["Don't follow me"]
09:58|-|noddan [] has quit []
10:04|-|noddan [] has joined #mythtv
10:32|-|[shodan] [] has joined #mythtv
10:36|-|beavis [] has joined #mythtv
10:40|-|shodan- [] has quit [Read error: 60 (Operation timed out)]
10:48|-|gnome42 [] has joined #mythtv
10:53|-|MoRpHeUz [n=morphbr@] has quit [Read error: 104 (Connection reset by peer)]
10:54|-|MoRpHeUz [n=morphbr@] has joined #mythtv
11:03|-|[shodan] [] has left #mythtv ["Leaving"]
11:07|-|Dibblah [] has joined #mythtv
11:07|-|doobe [] has joined #mythtv
11:10|-|aevil [] has quit [Remote closed the connection]
11:15|-|onixian [] has joined #mythtv
11:25<sphery>gbee: Did you test [12964] against a blank database using mfdb to populate channels for an analog source? At first glance it looks to me like it will now just skip the source (didn't look too deeply, though)--meaning users couldn't use mfdb to populate the channels table.
11:25<sphery>Gotta admit I'm afraid to upgrade because of #3031, otherwise, I'd just test it.
11:26|-|prg3 [] has quit [Remote closed the connection]
11:26|-|prg3 [] has joined #mythtv
11:27<gbee>bah, forgot people still used it for populating the channel table
11:28<gbee>ok, lets try again
11:30|-|abarbaccia [] has joined #mythtv
11:32<abarbaccia>hello all - i have a question to those out there regarding mythwelcome, mythshutdown and the date format passed to nvram-wakeup. Apparently there is a bug that was introduced to svn where time_t no longer is the correct format which breaks nvram-wake up prevents mythtv from shutting down with the mythshutdown command
11:35|-|jmk_ [n=jmk@] has quit ["Leaving"]
11:36<sphery>gbee: Is it good enough to just put a "big" warning in there that if the user does not want to use DD or xmltv to populate the source, he should enable eitonly or no grabber?
11:38<gbee>nah, I've just removed the "continue" I added, the main fix for that bug was making sure endofdata was reset for each grabber
11:39<gbee>it will work fine without skipping but it's just a waste of cycles to go through the grabbing process if no channels have an xmltvid defined
11:39<sphery>Cool. Thanks.
11:39<sphery>We had a period a while back where it was impossible to populate the channels data with mfdb for analog sources.
11:39<sphery>Didn't want that mess, again. :)
11:40<gbee>yeah, thanks for pointing it out
11:40|-|doobe [] has left #mythtv []
11:40<sphery>I did the easy part. You wrote the bug fix(es)--I'm just a back-seat driver, here. :)
11:40<gbee>at some point I'd like to reorganise mythfilldatabase so that the channel/programme logic is seperated a little better
11:41<sphery>Yeah, mfdb is a mess. Better now that it's no longer just one big file, but...
11:41<sphery>Did I notice your xmltv capabilities stuff is in there, now?
11:42<gbee>yep, has been for a couple of months or more
11:43<sphery>Sweet. So, now there's no more list of "approved" grabbers?
11:43<sphery>That will be a /very/ good thing for users.
11:47<gbee>no more list :)
11:48<sphery>Well, from me--and I think I speak for all the users who will also benefit--thanks.
11:49<gbee>well not our list anyway, they have to comply to some basic xmltv standards
11:49<gbee>the other bit of that job, the apiconfig stuff I'm thinking of leaving until after 0.21, but it all depends how far away 0.21 is
11:52|-|MoRpHeUz [n=morphbr@] has quit [Read error: 110 (Connection timed out)]
11:53|-|MoRpHeUz [n=morphbr@] has joined #mythtv
11:57<sphery>Wow. Just looked up what that is. That would mean non-US users would also be able to do configuration through mythtv-setup?
12:02|-|cattelan [n=cattelan@] has joined #mythtv
12:10|-|jmk_ [] has joined #mythtv
12:15<abarbaccia>anybody experience my nvram problem? I think there is an error in mythshutdown or mythwelcome (possibly both) dealing with the time format passed to nvram-wakeup
12:19<gbee>sphery: sorry went to eat, yes that's what it means - doesn't really alter the setup much but just integrates it into mythtv better
12:23|-|jebel [] has joined #mythtv
12:24|-|choenig [] has joined #mythtv
12:44|-|xris [] has joined #mythtv
12:55|-|kormoc [] has joined #mythtv
12:56<lucas2>abarbaccia: I think chris pinkham changed that time format very recently. Maybe he missed mythshutdown & mythwelcome.
12:56<lucas2>he'd probably welcome a patch with fixes for those two.
12:58|-|luna6 [] has quit [Read error: 104 (Connection reset by peer)]
12:58|-|luna6 [] has joined #mythtv
13:22|-|bdale [] has quit [Read error: 110 (Connection timed out)]
13:29|-|mark__ [] has joined #mythtv
13:34<stuarta>tonights crazy idea, why don't we put a set of "use cases" on the wiki or somesuch
13:35<stuarta>what i mean by that is, they ways channels are setup (mfdb or scan), program info data (eit or grabber) etc etc
13:35|-|Dibblah [] has quit [Read error: 113 (No route to host)]
13:37<stuarta>since it's quite easy to forget that in some far away part of the world they need A C & F for a functioning myth
13:37<stuarta>when you happen to use A B & D
13:40<xris>stuarta: do you use xmltv?
13:47<gbee>stuarta: might be useful
13:49<gbee>xris: he doesn't
13:49<gbee>I do though
13:51<xris>gbee: have you run the new channel icon grabber thing?
13:51<xris>I'm only seeing numeric values for xmltvid, and I want to make sure that something isn't broken.
13:51<gbee>not yet but I can do it now
13:55<xris>let me know when it's done so I can go look
13:57<gbee>hmm, it got stuck in a loop just now, 'Skip channel' just kept showing me the same one, over and over
13:58<gbee>and this error seems to be missing something - "ERROR: No icon found for xmltvid:"
14:00<xris>you fully up to date?
14:02<xris>yeah, plenty
14:02<gbee>hitting E for exit gives me "Use of uninitialized value in concatenation (.) or string at ./ line 223, <STDIN> line 4."
14:03<gbee>and it doesn't exit
14:03<xris>um, you're definitely not up to date
14:03<xris>wait, maybe not
14:03<gbee>although it behaves like Skip should
14:04<xris>looks like a bug. svn up and try again, please. :)
14:09<gbee>working through them now :)
14:10<gbee>one thing, would be good to print the channel detail again after the list of possible matches - it get's pushed right off the screen before I get to see it
14:11<gbee>get's? my English teacher is turning in his grave
14:12|-|Netsplit <-> quits: LLyric
14:13<xris>well, the cli version is just a proof of concept.
14:13<xris>I'd like to see this added to mythtv-setup and mythweb
14:14<xris>but before I can do it in mythweb, I need some way to tell the backend to grab the icons
14:14|-|jebel [] has quit [Connection reset by peer]
14:14|-|jebel [] has joined #mythtv
14:15|-|jk1joel [i=nobody@] has quit [Remote closed the connection]
14:15<gbee>it's pretty sophisticated, very nice work
14:15|-|jk1joel [i=nobody@] has joined #mythtv
14:17|-|DexterF [] has joined #mythtv
14:18|-|DexterF [] has left #mythtv ["I can't hide but I can run"]
14:22|-|okolsi [] has left #mythtv []
14:22<stuarta>i'm back now, damn network outage...
14:23|-|Netsplit over, joins: LLyric
14:23|-|Dibblah [] has joined #mythtv
14:25<gbee>you know that if this doesn't work I'm not doing it all over? :p
14:25<gbee>66 icons? there aren't 66 channels are there??
14:26<stuarta>there more than that.
14:27<gbee>well I skipped a few of the data channels, no icons or at least not worth messing with
14:27<gbee>hurrah, EIT monkeys are finally providing data for Virgin Radio - of course this would be less than a week before I stop using EIT completely
14:27<stuarta>been doing that for a while iirc.
14:28<stuarta>not a *huge* while...
14:29<gbee>first time I've seen it
14:29<stuarta>btw, did you come up with something for the film/movie thing with EIT data, or shall i have a bash?
14:30<gbee>not yet, haven't even looked
14:31|-|malban [] has joined #mythtv
14:49|-|LLyric [] has quit ["Leaving"]
14:51|-|S2 [] has joined #mythtv
14:51|-|clehmann [n=Miranda@A171222.N1.Vanderbilt.Edu] has joined #mythtv
14:52<xris>gbee: thanks. your xmltv stuff came in just fine, which means that someone in .nl has weird values for xmltvid.
14:53<gbee>btw S still wasn't skipping, but E was so I used that instead
14:53<gbee>is it submitting the DVB data as well?
14:54[~]sphery just spent 90 minutes tracking down a bug in his patch that turned out to be a typo in his test data
14:54<xris>it should
14:54<Snow-Man>xris: Hey, uh, I installed that thingy you asked for on that other day, k
14:54<Snow-Man>er, -;
14:54<xris>Snow-Man: cool, I'll try to rerun the lyngsat scanner again, thanks.
14:55<Snow-Man>xris: Like, I did it a while ago, but you weren't around to tell
14:55<Snow-Man>xris: So, uh, stay on IRC all the time, damnit.
14:55<xris>I ended up just running it on my local box and and copying the db back over to the server.
14:55<Snow-Man>xris: :)
14:55<xris>gbee: the dvb data is all numeric, so I'm going to wait for more data to show up before approving icons.
14:56<xris>but eventually, users will just run the script and it'll auto-import all of their icons.
14:56<stuarta>xris: what needs to be done on the admin side of that???
14:56<xris>clicking a link. heh
14:56<Snow-Man>uh, can we chill with the punctuation, hmm?
14:57<xris>I'm happy to set up logins for anyone with commit access
14:57[~]Snow-Man remembers the days when shit like that drew an automatic kick/ban
14:57[~]Snow-Man eyes xris
14:57<xris>the "???" part?
14:57<stuarta>er that was me :P
14:58<Snow-Man>Not on this channel, or network, but, there was a time.. :)
14:58[~]kormoc laughs
14:58<Snow-Man>stuarta: Yes, I know.
14:58<stuarta>yeah, before the www. i remember it well
14:58<Snow-Man>I was eye'ing xris with the whole 'set up logins' bit...
14:58<Snow-Man>xris: Just don't be doing anything I wouldn't do, mkay? :P
14:59<xris>Snow-Man: it only applies to the channel icon editor stuff.
14:59<xris>separate htdigest file, etc.
15:00<Snow-Man>What's it granting access to do, exactly?
15:00<gbee>xris: will send you the htdigest stuff
15:00<xris>gives you access to the editor to approve/deny icons
15:00<Snow-Man>And you wrote the editor?
15:00<Snow-Man>And it runs as www-data?
15:00<xris>all of it
15:00<xris>I didn't do any suexec weirdness
15:00<Snow-Man>xris: You writing it isn't *actually* what I'd consider good or bad, by itself.. :)
15:01<Snow-Man>xris: I presume there's a 'view' side as well?
15:01<xris>worst a compromised account could do is royally f*ck up the icon db.
15:01<Snow-Man>Which doesn't require access?
15:01|-|mark__ [] has quit [Read error: 104 (Connection reset by peer)]
15:01<xris>the view side is public
15:01<gbee>I want to break the server and setup an illegal porn site ;)
15:01<xris>unfortunately, the dvb data is just numeric so I have noway to differentiate
15:01<Snow-Man>xris: Uhm, come on, www-data being compromised could potentially do a whole crapload of bad things
15:01[~]xris grumbles about gaim and copy-paste
15:02<Snow-Man>xris: Not the least of which would be to exploit an existing local hole or some such and gain root.
15:02<xris>Snow-Man: yeah, but that has nothing to do with the htdigest stuff.
15:02<Snow-Man>err, where did I say that it did..?
15:02<xris>you didn't, but it sounded like you were implying it
15:03<Snow-Man>I'm just trying to understand the parameters of the stuff running on the system.
15:03<Snow-Man>xris: I don't really like www-data having write access to anything. :/
15:03<Snow-Man>xris: Were you going to move this into PG or something eventually?
15:04<xris>well, you and Chutt were the ones who told me to use sqlite instead of mysql
15:04<Snow-Man>Where we could have somewhat more fine-grained controls?
15:04<Snow-Man>xris: Honestly, that was before I knew you were going to be allowing users on the web to do modifications..
15:04<Snow-Man>I thought it was a mostly-fixed database that'd be updated by ssh access or something.
15:04<xris>yeah, needs some way for users to submit their findings... like a wiki
15:05<Snow-Man>Or maybe updated off some other remote data set using a script running as an unpriviledged user.
15:05<Snow-Man>(yes, I really have nfc what it is you're doing :D)
15:05<Snow-Man>xris: Uhm, and who's the user set we're talking about here..?
15:05<xris>there's an sqlite file in a directory owned/writable by www-data
15:06<janneg>21:57 < xris> I'm happy to set up logins for anyone with commit access
15:06<Snow-Man>People with commit access have shells
15:06<xris> handles both searches and submissions from mythtv users, and then there's the edit side of thing which is where the submissions are approved/denied by admins/devs.
15:06<xris>not on www, they don't
15:07<xris>and it's really hard to view a .jpg file through ssh.
15:07<Snow-Man>No, but you could propagate it across periodically using some mechanism
15:07<xris>would still need write access somewhere to take user submissions
15:07<janneg>but submitting is everyone
15:08<Snow-Man>Yeah, uh, 'everyone' is a big number
15:08|-|onixian [] has quit [Read error: 110 (Connection timed out)]
15:08<Snow-Man>And implies that there's going to be alot of changes..
15:08<gnome42>janneg: Thanks for applying my DTV LiveTV reset patch :)
15:08<xris>Snow-Man: it
15:08<gnome42>janneg: I agree with the audio scan code thing too
15:08<janneg>gnome42: thanks for the patch
15:08<xris>it's true.. that's why I requested mysql. it's faster.
15:09<Snow-Man>xris: I really thought this was going to be a limited-update thing...
15:09<Snow-Man>xris: sqlite isn't going to work worth a hill of beans when you have alot of concurrent updates going on..
15:09<gnome42>janneg: I think there is still a problem with the PosMap in Livetv ...
15:09<Snow-Man>(Then again, neither will mysql, heh)
15:10<Snow-Man>xris: Are users going to have some kind of account?
15:11<xris>Snow-Man: there are a finite number of tv channels. once they're defined, there won't be that many submissions.
15:11<gnome42>janneg: I think we are still missing the final save of the PosMap. I have a solution but not sure if its correct.
15:11<xris>access to the lookup stuff is public
15:11<Snow-Man>I don't mind read-only access being public, that's fine
15:12<Snow-Man>And sqlite for that would probably be alright
15:12<Snow-Man>xris: Is there a reason submissions have to be done through the webpage..?
15:12<Snow-Man>xris: Also, would those submissions effect an immediate change on the site?
15:13<kormoc>Snow-Man, how else would you have submissions go?
15:13|-|onixian [] has joined #mythtv
15:14<Snow-Man>kormoc: uh, email?
15:14<Snow-Man>Or bugs in trac or something?
15:14|-|onixian [] has quit [Client Quit]
15:14<kormoc>Snow-Man, I would think that having a few thousand 'bugs' via trac would get annoying rather quick for the devs
15:15<Snow-Man>kormoc: If these are channels, couldn't you pre-populate the majority of them up-front?
15:15<Snow-Man>It's not like they're hidden
15:15<xris>Snow-Man: thousands of channels via email, often with "pain in the neck for users to get at" data about the channels?
15:15<gbee>half the benefit of this new setup is that devs don't have to commit dozens of iconmap patches
15:16<xris>Snow-Man: you could at least take a look at the system to see how it works.
15:16<xris>gbee: and also that the iconmap only deals with callsigns, which aren't really used in most of the world
15:17<kormoc>Snow-Man, the idea is they'll get auto-populated right off of the bat for the majority of people when the data is into the system, thus limiting changes in the future. But for now, the data needs to get imported in, and having it manually done should prevent/limit errors
15:17<Snow-Man>xris: Where would I go to look at it..?
15:17<gbee>so long as the input is properly checked and escaped it's safe
15:17<xris>I've pasted the lookup URL a dozen or so times here (most recently about 5 mins ago)
15:18<xris>Snow-Man: I pm'd the URL for the edit link. you'll need to create an htdigest entry for yourself
15:18<xris>a lookup URL looks something like:
15:18<Snow-Man>Yeah, take me to task for not hacking up your auth system to look at your system
15:18<kormoc>Snow-Man, really, this code is much safer then the wiki code is. It can be understood in a few minutes of looking it and reviewed in under a hour. It's a rather simple setup.
15:19<xris>I sent a howto out to the developers mailing list explaing what to do for htdigest
15:19<Snow-Man>I don't follow any of the lists directly, sorry.
15:19<xris>brb, need to deal with mess in the office.
15:20<Snow-Man>kormoc: It's not like I'm a huge fan of the wiki, heh.
15:20<Snow-Man>Pointing to something else and saying "but that's bad!" doesn't make it good.
15:20<kormoc>heh, just saying personally, it's not nearly as large of a hole as others could be
15:21<kormoc>Snow-Man, well, if you really don't like it, you should review the code, I'd be happy to answer any questions on what things are doing and all that jazz, and I'm sure xris would be as well
15:22[~]Snow-Man sighs.
15:25<Snow-Man>kormoc: I don't want to *do* a code review. I want to understand how the system is secured, runs with minimal privileges, and minimizes chances that an exploit would cause serious damage.
15:26<Snow-Man>kormoc: Are submissions reviewed before their posted..?
15:26<kormoc>Snow-Man, yes
15:26<kormoc>they get put into a review section, people with htaccess can then view them and approve them or not
15:28<Snow-Man>The icons aren't stored locally at all?
15:29<Snow-Man>I really hate www-data, just a side-comment.
15:30<Snow-Man>Are the results going to be used by an automated system?
15:30<Snow-Man>(The lookup results, that is...)
15:30<Snow-Man>I'm guessing as part of mythtv?
15:31<kormoc>well, the client sends a request for channel blah, and gets back the approved icon or a list of possable matches. Then the user can pick and then submit back which one they picked
15:31<kormoc>that's the idea, hopefully into mythtv-setup and/or mythweb
15:31<kormoc>I don't think it's been worked on as of yet, just the app that xris wrote
15:32<Snow-Man>hrmpf, so this'll be completely automated from another system? Not used directly on the site through a browser..?
15:32<kormoc>that's the idea
15:32<Snow-Man>Well, I guess mythweb involves a browser, heh.
15:32<Snow-Man>hmm, hmm.
15:33<kormoc>the only thing the site will send out is match or matches and will accept back in what the user picked for review
15:33<Chutt>so, i need some help answering some email interview questions
15:34<Chutt>the guy's been calling me bugging about it, so i probably should..
15:34<Snow-Man>I do have some concerns that someone could submit one thing for a jpeg on a site which they control, and then use that to exploit some number of machines which uses it.
15:34<Snow-Man>kormoc: The icons are downloaded to the local machine during mythtv-setup?
15:34<Snow-Man>Or mythweb setup or whatever?
15:34<gbee>we're only accepting lyngsat aren't we?
15:34<kormoc>Snow-Man, yes, but all icons are hosted on lynsat. a user can't submit their own icon
15:35<Snow-Man>oh, erm..
15:35<Snow-Man>If all icons are hosted on lynsat, then don't you have a finite set of possibilities?
15:35<kormoc>they can only send back, for channel 43 (fox) I picked lyngsat icon blah
15:35<kormoc>well, yes and no
15:35<kormoc>there's a finite set of icons to map to
15:36<kormoc>but a unknown number of channels/id's to lookup
15:36<gbee>and we download local copies
15:36<Chutt>"What makes MythTV unique? How is it different from other similiar PVRs?"
15:36<Chutt>Snow-Man's a security weenie. =)
15:36<Snow-Man>Chutt: It doesn't suck ass.
15:36<Snow-Man>Chutt: Security weenies keep you from getting sued. :D
15:36|-|clehmann [n=Miranda@A171222.N1.Vanderbilt.Edu] has quit [Read error: 104 (Connection reset by peer)]
15:37<Snow-Man>And it's not (entirely) my fault that the gov't makes me go through C&A's and shit.
15:37<gbee>so unless there is some unknown problem with the handling of images in QT (injecting executable code through image files is pretty rare these days)
15:37<Snow-Man>gbee: Using a known-trusted site helps a great deal with that..
15:38<Snow-Man>gbee: Especially since it's not only the image handling but also the URL requesting/result parsing, etc.
15:38[~]kormoc nods
15:39<Snow-Man>Of course, you're sending the full URL to the client...
15:39<Snow-Man>Unless the client checks that it's a lyngsat URL, they could be sent elsewhere unwittingly.
15:40<Snow-Man>I appriciate the flexibility it gives but it does make the security of the source of the URL more important.
15:41<Snow-Man>Could you have the client bitch if it's not a lyngsat url?
15:41<kormoc>Sure could
15:42<Chutt>could the server just not accept them?
15:42<Snow-Man>Chutt: You misunderstand, if the server is compromised...
15:42<gbee>well a few things would have to break down for that to happen - i.e. the database or script would have to be compromised for a non lyngsat url to be sent to the client, or the client's initial request would have to be intercepted (which we can do nothing about anyway)
15:42<Chutt>if the server is compromised, there's worse things going on than the client code
15:42<Snow-Man>gbee: Except you *can* do something about it on the client.
15:42<Chutt>if the _server_ is compromised, then the mythtv source is suspect, and the client's fucked anyway.
15:42<kormoc>Chutt, right, currently it wont' accept them, but having a client check wouldn't be too hard as well
15:42<Snow-Man>Even if the request is intercepted.
15:43<janneg>we could switch to relative URL + hostid if we want to have the possibility to have mare hosts than lyngsat
15:43<gbee>the client would only treat the file as an image, whatever it was sent
15:43<Snow-Man>Chutt: That's not necessairly true since the source could have checks against it, or could be from a package which checks its contents, etc.
15:43<Chutt>where are the checks going to be stored?
15:43<Chutt>on the server? :p
15:43<Snow-Man>gbee: The point is that the client-side could check the URL it's given to make sure it's one it expects.
15:44<Chutt>if the client checks urls, then you can't ever expand to other websites.
15:44<Snow-Man>A trivial thing to do, and the source code could be updated should you need to change sites later.
15:44<Chutt>it's a tad harder to push out a client update than to update data on the server
15:44<Snow-Man>Chutt: The client could issue only a warning but still allow its use, and as I said, you could maintain a list and update it as necessary.
15:44<Snow-Man>Chutt: This is for setup though, no?
15:45<Snow-Man>Not every time the channel list is displayed
15:45<Chutt>worrying about this is silly.
15:45<gbee>I'm not saying that extra security isn't a good thing, just the the possibility for damage is almost non-existant
15:45<Snow-Man>gbee: Then why force it to just be lyngsat logos?
15:46<Chutt>you might as well worry about the lyngsat website being compromised.
15:46<Snow-Man>Chutt: Sure, but there's not a whole lot I can do about that. :)
15:46<gbee>so I download an executable instead of an image, it would have the executable flag set and myth won't attempt to run it, it would just see it as a corrupt image file
15:46<Snow-Man>gbee: uhm.
15:47<Snow-Man>gbee: Perhaps you missed the point of how the code-in-jpeg stuff worked, heh.
15:47<Snow-Man>It wasn't the whole outlook-is-dumb issue.
15:48<gbee>no, that was my earlier point regarding the QT image handling
15:48<Snow-Man>Which you're assuming is, and always will be, perfect.
15:48<Snow-Man>Along with the rest of the code involved in connecting to and downloading the image.
15:49<Chutt>is there a list of places that sell myth boxes on the wiki?
15:49<Snow-Man>It'd be nice if there was a way to check that the request/etc is coming from an actual client, heh.
15:50<Chutt>sphery, a list of distros?
15:50|-|MoRpHeUz [n=morphbr@] has quit ["Leaving..."]
15:51<janneg>Snow-Man: not possible. anyone can look at the code and generate a query which looks like a query from the client
15:51<Snow-Man>yes, I know.
15:51<gbee>Snow-Man: I'm assuming that for every flaw in QT, there are probably a hundred or more in MYthtv and yet I'm not worried
15:52<Chutt>it's just as likely that lyngsat gets compromised than the situation that Snow-Man is worried about
15:52<Snow-Man>Chutt: I'm worried about a number of possible cases where bad things(tm) could happen.
15:52<gbee>for an individual to a) compromise the server b) exploit an unknown, unpatched QT flaw - the odds have to be astronomical
15:52<Chutt>Snow-Man, why aren't you worried about the wiki, then?
15:53<gbee>they might manage one - but both seems far fetched imho
15:53<Chutt>jams, thanks
15:53<sphery>Chutt: Don't know about that one. My best guess is and possibly a ref to and/or to week out the extras
15:53<Snow-Man>gbee: You mean kind of like exploiting a hole in the blackberry gateway servers to compromise a company's M$ exchange server? Nah, could never happen...
15:53<sphery>FAQ doesn't mention minimyth, though
15:54<Snow-Man>Chutt: Who said I wasn't?
15:54<Snow-Man>Chutt: I've never liked the wiki, but I don't see that actually changing things much.
15:54<Chutt>you don't insist that user uploads be disabled?
15:54<Snow-Man>I'd rather the damn thing be read-only. :P
15:55<Chutt>compared to that, this channel icon thing is absolutely nothing.
15:56<Snow-Man>meh, the channel thing could much more directly impact a large number of systems.
15:56<Chutt>but what if firefox has a jpg executing bug?
15:56<Snow-Man>It doesn't hurt to consider ways to improve security.
15:56<Chutt>there's more people visiting the website
15:56<Snow-Man>It sucks?
15:56<Snow-Man>I can't really stop that.
15:56<Chutt>dude, it's simple, managed url lookup table.
15:56<Chutt>random people don't get to add to it.
15:58<Snow-Man>If it's going to be getting updated remotely by joe-blow, I'd rather there be a more fine-grained access control on it.
15:59<lucas2>xris: fyi: my .nl xmltv grabber returns channelid looking like "" "" which aren't really very good descriptions of the channel names either actually.
15:59<Snow-Man>But, hey, it's not my stuff so I suppose I shouldn't really care.
15:59<Chutt>it's _not_ going to be updated remotely by joe-blow
16:00|-|aevil [] has joined #mythtv
16:00<Chutt>i thought that was the whole point? :p
16:00<Snow-Man>Chutt: erm, every submission gets into the database, of which there's only one, and that www-data has access to..
16:00<Chutt>ok, so now you're worried about sqlite having a remote exploit?
16:00<Snow-Man>That's how I understood it from everyone else anyway, the choice that's made is sent back to the server and stuck in the db and whatnot.
16:01|-|xris [] has quit [Read error: 104 (Connection reset by peer)]
16:01|-|xris [] has joined #mythtv
16:01[~]xris grumbles about network outtages...
16:01<xris>Snow-Man: fyi, lyngsat is not the only icon source in the system
16:01<Snow-Man>Chutt: That the code running as www-data could be exploited in some way to much up the db when running only as a user or whatever.
16:02<Chutt>yeah, ok.
16:02<Snow-Man>'muck up' I think was the intent there.
16:02<xris>Snow-Man: if there is an exploit for this stuff that could affect the whole system, it's a bug in perl, not in the code.
16:03<xris>the code is available in the svn-www repo if you want to see it
16:03<Chutt>(which isn't public, iirc)
16:03<xris>Chutt: no, it's not
16:03<xris>devs can get at it, but that's it.
16:04<xris>only the user side of the query code is in the public repo
16:04<Snow-Man>The approach I'd take, if it was me, would be to stick the database in Postgres and have 'read-only', 'submitter', and seperate accounts for those who can actually make changes, in it.
16:04|-|choenig [] has quit [Remote closed the connection]
16:04<xris>Snow-Man: except that "read only" and "submitter" are the same script.
16:04<Snow-Man>When auth happens, it happens to the database, and privs are granted in the database only to what are necessary.
16:05<Snow-Man>xris: I probably wouldn't do it that way, and I'd seperate out the login information into seperate files such that the credentials wouldn't be in the actual script.
16:05<gbee>escaping/validating those submissions is extremely simple and very secure - it's hard to inject SQL if the only valid and accepted input is a 1 digit int or a purely alphanumeric string of no more than 20 chars
16:05<Snow-Man>It seems unlikely to me that the read-only and submitter would have to be the same script for some technical reason..
16:06<Snow-Man>gbee: It should be using prepared queries.
16:06<gbee>it should, I've not seen the code
16:06<xris>Snow-Man: yeah, that's always a good idea. I personally put them in the vhost config
16:07<xris>gbee: proper use of perl DBI makes sure of that.. all the data is escaped
16:07<Snow-Man>The question shouldn't even come up, use prepared queries. heh.
16:07<Snow-Man>xris: eh? vhost config?
16:08|-|S2 [] has quit [Remote closed the connection]
16:10<xris>Snow-Man: with environment variables.
16:10<Snow-Man>erm, if you have more than one..
16:10<gbee>rejecting all input which doesn't match a strict criteria e.g. length, acceptable characters is as safe (best done in addition to using prepared queries)
16:10<xris>Snow-Man: you can set env variables per file, directory, location, vhost, etc within apache
16:11<Snow-Man>The database should have appropriate constraints.
16:11<xris>gbee: which it pretty much does
16:11<gbee>xris: assumed it would :) you know what you're doing
16:12<xris>Snow-Man: fyi, read only and submit are in the same script because it's easier to maintain a single script. If they were separate scripts, they would still have to share a large portion of their routines.
16:12<Snow-Man>xris: Interesting idea, I'm not sure if I like it entirely or not, honestly..
16:12<Snow-Man>xris: erm, routines can be modularized..
16:12<xris>Snow-Man: um, yes, that's usually a given
16:13<xris>Snow-Man: web files are usually readable by world (so the db passwords would, too). apache conf files can be restricted to apache-only (or I think also to root-only, depending on how you set apache up to chuser)
16:14<Snow-Man>xris: erm, you don't have to have files readable by www-data be readable by world, heh.
16:15<Snow-Man>I'm not sure if the apache config can be root read-only. If so then I could see that being an advantage.
16:15<xris>you either make www-data own everything, which prevents users on the box from administering their own pages, or you put the user in the www group (or vice versa), which gives all users access to all other users' files.
16:16<xris>actually, giving www-data access to the user's default group would be the security way around that, but you don't hae things set up that way.
16:16<Snow-Man>You assume someone other than those who have root have access on the box.
16:16<xris>Snow-Man: I'm speaking in general terms here..
16:17<Snow-Man>guess I don't run general servers then. :)
16:17<xris>if the only users on the box are root, then you shouldn't have security issues like users reading data files with passwords in them.
16:18<Snow-Man>You can still have issues with scripts ending up being spewed out to a client as text.
16:18<xris>which is why the vhost config is a good idea. :)
16:19<Snow-Man>Or have the pws in a seperate file, but I do like the vhost config idea.
16:19<xris>it's all about setenv. :)
16:19<Snow-Man>Generally we don't store any credentials on the web server (all users have accounts in the DB, which handles all authentication and authorization)
16:20<xris>yeah. it's fine for most stuff. ht auth is just a lot simpler to get up and running in a short period of time since it doesn't require writing a whole auth/cookie subsystem.
16:21<Snow-Man>Anyway, I'd think you'd want to use PG for performance anyway, since it's going to be getting what sounds like a fair bit of updates and whatnot..
16:21|-|aevil^aw [] has joined #mythtv
16:21<xris>updates will taper off dramatically after awhile
16:22<xris>once the logos are approved, the clients will just use them rather than sending data back.
16:22<Snow-Man>I don't quite understand that.. submitters will continue to submit, regardless of if the entry exists or not..
16:22<Snow-Man>Erm, how will you effect that change?
16:22<xris>right. but the code only submits icons that had to be manually corrected.
16:23<Snow-Man>Then there really is value to seperating the read-only from the submitter, since you should have fewer and fewer submitters eventually.
16:23<xris>there's a script (eventually to be merged into mythtv-setup and mythweb) that walks the user through picking icons.
16:23<xris>some value, but it's completely minor. a lot easier on the dev (me) to keep everything in one place
16:23<Snow-Man>Right, I gathered that, but thought it always sent back whatever was picked.
16:23<Snow-Man>yeah, 'cause you know that's *exactly* what us security weenies concern ourselves with... :P
16:24|-|lsobral [n=sobral@] has quit ["Leaving"]
16:25<xris>no.. the process is: client sends channel list to server and gets a list of "exact + best guess" matches... if there are any non-exact matches, the user is walked through best-guess options and/or manual searches to pick the icon.. any manually-assisted matches are then posted back to the server for approval
16:26<Snow-Man>yea, I get it now
16:26<xris>then there's the admin interface where certain people can go in and approve/deny icons by type (xmltvid, callsign, dvb id, atsc id)
16:26<Snow-Man>No update is done to running systems tho, I assume?
16:26<Snow-Man>I mean, this process is only done once at setup time.
16:27<xris>or manually after the fact, yes
16:27<Snow-Man>Once the icons are picked, they're downloaded locally and used from then on forever until another 'setup' stage happens.
16:27<xris>yeah. unless isaac changes something in mythtv.
16:27<xris>and the icons are all stored offsite.
16:28<Snow-Man>xris: Heh, any plans to ask the user before sending their response or whatever? :)
16:29<Snow-Man>I don't know that it's really necessary, but some people do get ansy about that kind of stuff. :)
16:29<gbee>it does
16:29<xris>Snow-Man: it already does
16:29|-|aevil [] has quit [Read error: 145 (Connection timed out)]
16:29<Snow-Man>ok, ok. :)
16:29<Snow-Man>You could do one of those 'are you human' tests. ;)
16:29<xris>well, the proof of concept script does.
16:29<Snow-Man>a'ight, I need to get outta here.
16:30<xris>lol. please type in what you see here: 123abc
16:30<xris>hard to do gif/etc in a shell. :)
16:30<gbee>xris: being cautious about the change in that diff, was looking for Captain_Murdoch or someone to point out the obvious flaw which I'm no doubt missing ;)
16:30<xris>wow, Captain_Murdoch is still here... he's supposed to be getting on a plane soon (assuming his visa showed up)
16:31<gbee>yeah? didn't know he was going anywhere :)
16:31<janneg>xris: it's probably only his irc client
16:31<xris>well, I don't think he's scheduled to leave until tomorrow or friday
16:36|-|robthebob [] has joined #mythtv
16:37<Captain_Murdoch>wouldn't leave until Saturday if the visa ever shows up, but so far it hasn't shown up on the USPS tracking site.
16:37<xris>have you called?
16:38<xris>or have THEY (the conference people) called?
16:39<Captain_Murdoch>it has only been there a week and the webite says it takes 15 working days. they tried calling before and said they just got the answering machine. I waded through menus last week but they weren't very helpful, just repeated the line "it takes 15 days for mail-in apps"
16:39<Captain_Murdoch>I'm thinking it's not going to happen.
16:40<Captain_Murdoch>a couple weeks earlier and we'd have been good.
16:42[~]sphery wonders if that means Captain_Murdoch might have some time to talk about housekeeper changes...
16:43<xris>yeah. they definitely need some organizational help for the next one.
16:43<Captain_Murdoch>after the DST patchfest is over at work.
16:43<sphery>Cool. I'll catch you later Captain_Murdoch .
16:44<sphery>perhaps after my XBox 360-fest at home ;)
16:44<Captain_Murdoch>I'm sure yours is more fun and doesn't have to be done during 3AM-6AM. :)
16:45<sphery>Yeah. Unfortunately, sometimes it does continue into those hours... :)
16:46<xris>all we had to do here was cp the new timezone file into place on the servers. heh
16:51<Captain_Murdoch>yeah, mainly that here, but a few apps need patching and we have 900+ devices counting network gear, load balancers, etc.. close to 800 of those are servers with probably 40%-40%-20% split Linux-Windows-Solaris.
16:52<gbee>Captain_Murdoch: where are you going, if I may ask?
16:52<GreyFoxx>Captain_Murdoch: Yeah I feel your pain. I'll be spending alot of the weekend doing that
16:53<GreyFoxx>switches, routers, voip phones, etc etc
16:53<GreyFoxx>and then a couple hundred servers
16:53<Captain_Murdoch>gbee, possibly to the
16:53<Captain_Murdoch>GreyFoxx: we use Opsware for managing most of our servers, so that makes things much easier. Only thing is I get stuck with the servers where we can't do that. :)
16:54<gbee>sphery: just attached another mythfilldatabase patch to #2992 if you want to point out any mistakes (I'm pretty tired so there is bound to be one)
16:54<GreyFoxx>Captain_Murdoch: hehe
16:55<gbee>Captain_Murdoch: looks interesting and the setting is pretty good :)
16:55<sphery>gbee: If it's the same as the one in your pastebin, it looks pretty good. But, again, just a quick glance, so far.
16:55<GreyFoxx>I make my own packages for all of the linux boxes (95% are Slackware), and the Solaris machines and push them out over ssh via a script I use for mass pushing out updates, but Thgere are a lot of devices I need to manually change/update :(
16:56<GreyFoxx>thankfully out of the 350 servers I should be able to do about 320 automagically, the big effort with be the routers and switches
16:57<gbee>basically the same, just does the same to the --file stuff in main.cpp
16:57<jams>my solaris 8 boxes were painful as they required single user mode for some of the timezone related patches.
16:58<GreyFoxx>the 30 I can't do automatically are legacy gentoo/redhat machines I inherited that noone is willing to touch heh
16:59<gbee>actually there is a mistake in there, don't know what damage it does though - what purpose does the manualid column serve?
16:59<GreyFoxx>that reminds me... *runs windows update on this machine*
17:01|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
17:04[~]GreyFoxx wonders just how much of the code is MySQL specific
17:05<sphery>gbee: On second thought...
17:06<sphery>gbee: It looks like you're only reporting the value for the final source.
17:06<GreyFoxx>jams: yeah
17:07|-|skamithi [] has joined #mythtv
17:07<gbee>sphery: see that's why I asked ;)
17:08|-|jgarvey [] has quit ["Leaving"]
17:09<sphery>gbee: Don't we need to do something like check GuideDataAfter == GuideDataBefore within the loop and or it with some failure boolean (or possibly just use the int failures).
17:10<sphery>We could probably even simplify the whole externally handled thing (which I put there so we wouldn't get the failure message for all eitonly/null users).
17:10<sphery>The current implementation just looks for any increase in the listings data.
17:11<sphery>With yours, it would check for changes on a per-source basis allowing us to report a failure for one source even though another may have increased data.
17:12<gbee>sphery: sorry, I went away and did exactly what you went on to suggest
17:12<gbee>great minds
17:13<sphery>So, you've simplified the externally handled stuff, too?
17:13<gbee>not yet - can't type that fast
17:13|-|beavis [] has quit [Remote closed the connection]
17:14<gbee>but I've moved the after/before check into the loop and created a new bool to track it
17:14<gbee>just trying to decide how we'd report the failure to the end user - if one fails and another succeeds
17:15<sphery>Yeah. No way to do that now.
17:15<sphery>Would probably require modifying the function declarations and everything...
17:16<gbee>could just keep it simple and say "no new data was inserted for 1/2 sources"
17:16<gbee>1 of 2 would be less confusing than implying that a half source exists
17:17<gbee>so like 'failures' just use an int to count the number of successful runs
17:18<sphery>So, just modify the log message, and not the DB/function/mythbackend status page/mythfrontend System Status page?
17:18<sphery>Probably the best bet (unless you're really motivated). ;)
17:20<gbee>log message for now, maybe at a later date I'll be inclined make it fancier
17:21<sphery>I'm now thinking that we can't simplify the failures/externally handled thing...
17:21<gbee>hmm, wonder if that string should be translated as well
17:22<sphery>failures isn't necessarily a 1:1 count of failed video sources...
17:22<sphery>The boolean approach you used is probably best.
17:22<sphery>So, we'll still need externally_handled, too.
17:23<sphery>Well, as far as translations, if you don't translate it, it's no worse than before. :)
17:24<sphery>Hey, we actually put the status message into the DB, so it will show up on the status pages...
17:24<sphery>But, that's kind of an argument for translating it...
17:25<gbee>updated version, might be a typo or two in there
17:26<gbee>it should be translated because it's not an ordinary error message, it's shown *within* mythtv
17:28<sphery>Yeah. Translation would be good.
17:28<sphery>I like it, though.
17:29[~]sphery deletes the "To Do" tagged ticket #2992 from his tickets folder
17:29<sphery>Procrastination pays off, again!
17:29<stuarta>ha, can't even find to attempt my tickets :(
17:29<gbee>just fixed the one mistake I could see
17:32<gbee>I did actually spend an hour on a much more elaborate fix - until I realised that modifying the after/before queries to take the sourceid into account would be a simple and effective solution
17:32|-|PFalcon [] has joined #mythtv
17:33<sphery>I'm jealous that you can replace files in Trac, so the world doesn't see your typos...
17:34<sphery>My ticket #3113 will have two broken patches once I post the one I did today (which I'll do after talking to Captain_Murdoch).
17:34|-|psyco-obiwan [n=cschnee@2001:4060:4419:b1:0:0:0:2] has quit [Connection timed out]
17:34<gbee>sphery: It's bad enough when I commit the typos - can't hide them then as Bruce has so kindly reminded me in the past
17:36<gbee>heh, still forgot the manualid checks
17:36<sphery>Did I ask about that?
17:36<sphery>Does the "fake" program data for a manual recording even get associated with a source?
17:36<gbee>don't think so
17:36[~]gbee scrolls back
17:36<sphery>I guess I can make a manual rule and find out...
17:36<sphery>probably typed it and cleared it...
17:37<sphery>I get distracted more quickly than I type.
17:40<sphery>Nvm. It's necessary.
17:40<gbee>updated patch
17:41<sphery>Yeah. Since the fake program has a chanid, it will be associated with a source.
17:41<sphery>Since the fake program may exist months in the future, it could prevent our seeing the change to the guide data...
17:41<sphery>Now to delete my new rule.
17:44|-|onixian [] has joined #mythtv
17:47<gbee>just ran mythfilldatabase to be sure there were no major kinks, can't do a proper test though as I've only one source to start with
17:47<sphery>I only have one source, too.
17:48<sphery>You could easily create a no grabber source.
17:48<gbee>hopefully the ticket submitter will try it out - I don't see there being a problem though, the change is almost too simple
17:48<sphery>(I'm still afraid of #3104, so I'd have to backport the change to do any testing.)
17:49<sphery>Yeah. I like the approach. It ended up much less intrusive than I initially thought it would be when I saw the ticket.
17:49<sphery>That's much of the reason for the procrastination, too.
17:50|-|PeregrineFalcon [] has quit [Read error: 110 (Connection timed out)]
17:50<gbee>music_artists sort key?
17:50<sphery>I did one for videos before Anduin's major rewrite.
17:51<sphery>Didn't go in, but his other changes addressed the issue in the ticket for which I wrote the patch.
17:52<gbee>I completely mis-read the ticket the first time I read it - he starts off with a completely different explaination for the problem and a very quick glance at the code seemed to agree
17:52<stuarta>skamithi: was closing 2748 (an already closed ticket) a typo?
17:53<skamithi>huh did i make a typo. :)
17:54<skamithi>meant to close 2978..closing it now
17:55<gbee>one of those days
17:57<sphery>Oh, yeah. briand already wrote the patch for music sort key...
17:57<gbee>yep, thought you were referring to it - (23:48:58) sphery: (I'm still afraid of #3104
17:57<stuarta>hehe, that's not even close :-P
17:58<gbee>seemed a little strange to be afraid of an uncommitted patch to mythmusic
18:00|-|onixian [] has quit ["This computer has gone to sleep"]
18:00<gbee>typos for all
18:00|-|robthebob [] has quit [Read error: 113 (No route to host)]
18:01<gbee>2007-03-07 23:48:13.089 mythfilldatabase run complete.
18:01<gbee>Segmentation fault
18:02<gbee>hmm, that can't be related?
18:05<gbee>segfaulted a second time - I'm going to bed
18:09<sphery>gbee: Oh. Figured it out... You wondered why I was afraid of music sortkey... Sorry. Wront ticket. I'm afraid of #3031.
18:09<gbee>makes more sense
18:10<sphery>Guess you're not the only one who's tired.
18:10<sphery>Sorry for the confusion.
18:13|-|[Spctr]PFalcon [] has joined #mythtv
18:13<gbee>decided to grab a backtrace on this segfault before I go to bed, can't make out the problem though, so this time I'm really going
18:14<sphery>gbee: wanna post the bt?
18:14<sphery>to pastebin?
18:18<sphery>thx. gn.
18:18|-|onixian [] has joined #mythtv
18:20|-|PeregrineFalcon [] has joined #mythtv
18:21|-|PFalcon [] has quit [Read error: 145 (Connection timed out)]
18:22|-|DrNickRiviera [] has quit ["Leaving."]
18:22|-|cattelan [n=cattelan@] has quit ["This computer has gone to sleep"]
18:27|-|PFalcon [] has joined #mythtv
18:37|-|[Spctr]PFalcon [] has quit [Read error: 110 (Connection timed out)]
18:41|-|skamithi [] has left #mythtv []
18:45|-|PeregrineFalcon [] has quit [Read error: 110 (Connection timed out)]
18:49|-|Dibblah [] has quit [SendQ exceeded]
18:50|-|Dibblah [] has joined #mythtv
18:58|-|kali67 [] has joined #mythtv
19:04|-|jebel [] has quit [Read error: 110 (Connection timed out)]
19:08|-|jams [] has quit [Read error: 104 (Connection reset by peer)]
19:09|-|jams [] has joined #mythtv
19:49|-|Voting [] has quit [Read error: 113 (No route to host)]
19:51|-|abarbaccia [] has quit ["Leaving"]
19:54|-|aevil^aw [] has quit ["Verlassend"]
20:36|-|rtsai [] has joined #mythtv
20:37|-|rtsai1111 [] has quit [Read error: 145 (Connection timed out)]
21:07|-|daMaestro [n=jon@fedora/damaestro] has joined #mythtv
21:12|-|onixian [] has quit ["This computer has gone to sleep"]
21:13|-|cattelan [n=cattelan@] has joined #mythtv
21:17|-|xris [] has quit [""]
21:27|-|ryanr23 [] has joined #mythtv
21:32|-|cattelan_ [] has joined #mythtv
21:41|-|cattelan [n=cattelan@] has quit [Read error: 145 (Connection timed out)]
21:52|-|malban [] has quit ["Chatzilla 0.9.77 [Firefox]"]
21:56|-|eille-la [] has joined #mythtv
22:11|-|xris [] has joined #mythtv
22:11|-|ratbert90 [] has joined #mythtv
22:11<ratbert90>ugh, has anybody actually made lirc work on a new kernel?
22:12<ratbert90>2.6.20 is what I have, and while the new lirc compiles, it doesn't see a remote :(
22:15<xris>ratbert90: advice: read topic before speaking into an irc channel
22:16|-|rbellamy [n=rbellamy@pdpc/supporter/silver/rbellamy] has joined #mythtv
22:17|-|kali67 [] has quit []
22:18|-|ratbert90 [] has left #mythtv ["Leaving"]
22:39|-|eille-la [] has quit ["Leaving"]
22:40|-|jebel [] has joined #mythtv
22:46|-|kormoc [] has quit ["Done with work, yay! ( )"]
22:49|-|luna6 [] has quit [Read error: 104 (Connection reset by peer)]
22:49|-|luna6 [] has joined #mythtv
22:52|-|psyco-obiwan [n=cschnee@2001:4060:4419:b1:0:0:0:2] has joined #mythtv
23:02|-|adante [] has quit ["Lost terminal"]
23:03|-|adante [] has joined #mythtv
23:03|-|jebel_ [] has joined #mythtv
23:04|-|jebel [] has quit [Read error: 104 (Connection reset by peer)]
23:17|-|kormoc [] has joined #mythtv
23:20|-|kali67 [] has joined #mythtv
23:29[~]xris grumbles about now much this channel icon db could be if there was another way to host the icons.
23:36|-|russellb [] has joined #mythtv
23:40|-|russellb changed nick to drumkilla
23:47|-|kali67 [] has quit []
---Logclosed Thu Mar 08 00:00:59 2007