Back to Home / #mythtv / 2003 / 03 / Prev Day | Next Day
#mythtv IRC Logs for 2003-03-11

00:01-!-TheAsp [] has quit [Remote closed the connection]
00:05-!-Captain_Murdoch [~buy_more_@ip68-107-147-203.hr.hr.cox.net] has joined #mythtv
00:06<Captain_Murdoch>I love to spend 2-3 hours trying to track down a bug in Myth, reverting to old CVS versions, inserting printf statements, just to find out it's really a network problem with a flakey switch.
00:08<rkulagow>at least you figured out what the problem was! i hate transient errors that seem to have no cause and effect...
00:12<Captain_Murdoch>yeah. and I'm better off now anyway. went and made a longer cable so I could run the myth box straight to the main 100Mbit switch instead of hanging off another hub in the house.
00:19<inman>someone with multiple inputs wanna test a patch for me?
00:19-!-nziarek [] has quit [Read error: 110 (Connection timed out)]
00:19* inmangrovels.
00:40-!-Captain_Murdoch [] has quit ["X-Chat!"]
01:13<Chutt>inman, you do realize that that patch isn't against current cvs, right?
01:13<Chutt>and that the --ignore-whitespace option to diff makes the channel.cpp changes pretty much unreadable?
01:18<Chutt>your new TVRec::SwitchToInput() functions should not be doing anything to rbuffer or the nvr object
01:18<Chutt>those are for external changes, not internal ones
01:19<Chutt>and i'd really rather not add fields to the database that are being read, but not set anywhere.
01:23<inman>i thought you wanted the whitespace-diff stuff.
01:23<Chutt>no
01:23<Chutt>i wanted a readable diff
01:23<inman>are you sure the SwitchToInput stuff doesn't need to reset the buffer?
01:23<Chutt>without extraneous whitespace changes
01:23<Chutt>i'm absolutely positive.
01:24<inman>you do realize that the input changes may change the channel...
01:24<Chutt>it's already been reset when that's called
01:24<Chutt>that doesn't matter.
01:24<Chutt>it's already been reset by the time it gets that far
01:24<inman>okay, so i can just elide the Pre/PostInputSwitch from those?
01:24* inmanfrowns.
01:24<Chutt>you can just remove the pre/post stuff entirely, as it's just fluff
01:24<inman>i'm not sure that's true.
01:25<inman>who would have done it for us?
01:25<Chutt>how would it get there without it?
01:25<Chutt>it doesn't change channels by itself
01:25<Chutt>or inputs by itself
01:25<Chutt>it does it at the request of the user, or for recording
01:25<inman>when you switch inputs, it changes to the channel last visited on the given input.
01:25<Chutt>you broke recording, btw
01:25* inmangroans.
01:25<Chutt>it doesn't switch to the channel
01:26<inman>the existing code switches inputs
01:26<inman>but doesn't update anything regarding channels
01:26<Chutt>- channel->SwitchToInput(inputname);
01:26<Chutt>- channel->SetChannelByString(chanstr);
01:27<inman>the problem with this is that we're in a whole new world of channels after we switch inputs.
01:27<Chutt>+ SwitchToInput(inputname);
01:27<Chutt>anything missing?
01:27<inman>which function are you getting this from?
01:27<Chutt>that's probably from SetChannel()
01:27<inman>does setchannel get called by switch inputs?
01:27<Chutt>no.
01:27<Chutt>it gets called when it starts recording something
01:28<inman>doesn't this bother you?
01:28<inman>when you switch inputs, you don't know which channel you're on.
01:28<inman>you may need to retune the tuner.
01:28<Chutt>the fact that you took out the bit to make it switch to the correct channel on a recording bothers me
01:28<inman>that's a bug.
01:28<Chutt>really?
01:28<Chutt>i didn't guess
01:28<inman>yeah, i don't know what you're talking about.
01:29<inman>well, you make it sound like it was intentional. :-P
01:29<Chutt>i point it out, and you completely ignore me
01:29<inman>i thought it worked for me, but maybe i didn't test all inputs.
01:29<Chutt>it wouldn't work at all
01:29<inman>no, you said like 4 things and i am going through them 1 by 1.
01:29<inman>what did i do wrong?
01:30<inman>i also don't understand your 'external versus internal changes' comment.
01:30<Chutt>you're not setting the channel number anymore?
01:31<inman>huh?
01:31<Chutt>that might be the issue.
01:31<Chutt>those three lines i pasted, from your diff
01:31<inman>i may have removed 1 too many lines in SetChannelByString() if that's what you mean.
01:31<Chutt>where does it set the channel?
01:31<inman>from which function?
01:31<inman>SetChannel()?
01:31-!-Viddy [david@visp194-179.visp.co.nz] has joined #mythtv
01:31<Chutt>yes.
01:31<inman>the one that takes a QString?
01:32* inmanwaves to Viddy.
01:32<Chutt>the one that takes a bool
01:32<Chutt>the one you modified, you didn't touch the other one
01:32<inman>i didn't think i modified the one that takes a bool.
01:32<inman>the other one has me pre/post nonsense.
01:33<inman>btw, one problem i had is that i need to change the channel and set the input in the constructor for TVRec()
01:33<inman>lots of stuff is undefined there, like nvr/rbuffer.
01:33<inman>hence the pre/post stuff.
01:33<Chutt>it doesn't need to be defined there
01:33<inman>right, but i can't go pausing an rbuffer that doesn't exist yet.
01:33* inmangrins.
01:34<Chutt>you don't need to pause the rbuffer
01:34<Chutt>like i said above
01:34<inman>yes, but i didn't know that then.
01:34* inmannods.
01:34<inman>i'm removing it now.
01:34<Chutt>could've followed the code paths
01:34<inman>so the rbuffer/nvr stuff only happens where?
01:34<Chutt>that's all frontend/backend communication stuff.
01:35<inman>i thought it was there to prevent us from grabbing tuning trash
01:35<Chutt>it is.
01:35* inmanscratches his head.
01:35<inman>uh
01:35<inman>where does it go?
01:35<Chutt>you've _already done all that_ by the time you get into the Channel object, though
01:36<inman>oh, so it's only for init'ing?
01:36<Chutt>no
01:36<Chutt>geez
01:36* inmansighs.
01:36<Chutt>ok
01:36<Chutt>how does it know when to change the input
01:36<inman>are you asking me?
01:36<Chutt>that was phrased as a question
01:36<inman>it changes it in the constructor.
01:36<Chutt>and i'm talking to you
01:37<inman>there's this thing called a question mark...
01:37<inman>;-P
01:37<Chutt>the constructor doesn't matter
01:37<Chutt>the constructor is called once at startup
01:37<inman>it changes the input when the frontend tells it to.
01:37<Chutt>very good
01:37<inman>changing the input causes a channel change, or may, anyway.
01:37<Chutt>so the frontend sends a message to the backend
01:37<Chutt>the backend calls a function in TVRec
01:37<Chutt>which function does it call?
01:38<inman>SwitchInput?
01:38<inman>ToggleInputs?
01:38<Chutt>toggleinputs
01:38<Chutt>see the rbuffer->Reset() at the top of toggleinputs?
01:38<inman>uh, no, but my code is my code.
01:38<inman>i remember that it's there.
01:38<inman>are you saying that you want only toggleinputs to have it?
01:39<Chutt>i'm saying that since it was already done in toggleinputs
01:39<inman>what if we ever want to set the input directly via a frontend command?
01:39<Chutt>you don't fucking need to do it again a couple functions down
01:39<inman>i only do it once in toggleinputs().
01:39<Chutt>no, you don't
01:39<Chutt>you do it in toggleinputs
01:39<inman>yes.
01:39<inman>that's what i said.
01:40<Chutt>and you do it again
01:40<inman>toggleinputs() doesn't call switchtoinput() from tvrec.
01:40<Chutt>anyway.
01:40<inman>it's not as though the execution path runs the functions twice.
01:40<Chutt>what sets tunechan and startchan in the database?
01:40<inman>well, that's up to you.
01:40<inman>i can make the setup widget affect those values.
01:41<inman>right now the setup points to the DefaultTVChannel stuff.
01:41<Chutt>as is, you've got code reading them
01:41<Chutt>depending on values that are in them
01:41<Chutt>and nothing does
01:41<inman>yes, they have sensible defaults.
01:41<Chutt>empty?
01:41<inman>yes.
01:41-!-hurdel [] has quit [Read error: 60 (Operation timed out)]
01:42<Chutt>why don't you finish the patch
01:42<Chutt>then we'll talk about it more.
01:42<Chutt>this is half done, from what i can tell.
01:44<Chutt>the external command bit looks fine
01:45<Chutt>heh
01:45<Chutt>can Channel::SwitchToInput() really change the channel 3 times?
01:45<Chutt>or am i reading it wrong..
01:46<Chutt>ah, only twice
01:49<Chutt>possible to merge the inputChannel map and the input1stChannel map?
01:49<Chutt>seems like input1stChannel would only get used once, if that
01:50<Chutt>might as well just initialize inputChannel with those values and not need another datastruct to hold that information
01:51<Chutt>the tunechan stuff really should be a string, as there's crazy european channels like e5 and s1 and stuff
01:52<Chutt>not that they'd be using it over there, i wouldn't think, but it doesn't really make sense to limit it to only integer channels
01:54<inman>how do you want it to work?
01:54<inman>update the setup?
01:54<inman>throw away the DefaultTVChannel setting?
01:54<Chutt>sure
01:54<inman>it may tune the channel
01:54<inman>then it may need to change the channel normally.
01:54<inman>i suppose we could shortcircuit if we realize we're on the tuner input.
01:54<inman>that's a good point.
01:54<inman>you seem to be lagged... or I am.
01:54<inman>the rbuffer/nvr stuff gets duplicated twice in the code. if you're comfortable with that, great.
01:55<Chutt>one of us is lagged =)
01:55<inman>that's up to you.
01:55<inman>if you want to support saving them out and monitoring what we were originally given, then we may want both.
01:55<inman>at the moment, there is no pressing need for both. we can always set the inputchannel from the startchan in the db instead of init'ing it to "".
01:55<inman>actually, if the db is setup correctly, it will never change the channel twice.
01:55<inman>the TuneTo stuff reflects the channel we need to tune to for an external feed on the tv input.
01:55<inman>eg. a cable descrambler.
01:56<Chutt>right
01:56<inman>man it's pretty bad.
01:56<inman>okay, the 1stchannel is easy to eliminate.
01:56<inman>what tunechan stuff are you talking about?
01:56<inman>i can't think of anything i'm passing that isn't a string...
01:56<Chutt>it's defined as a tinyint in the db
01:57<Chutt>and you to a toUint() or whatnot on it
01:57<inman>--- Ping reply from Chutt : 219.83 second(s)
01:57<Chutt>to see if it should be used
01:57<inman>that's only used by the tv-tuner
01:57<inman>does it need to be a string?
01:57<Chutt>yeah
01:57<inman>okay
01:57<inman>that's a good bug.
01:57* inmangrins.
01:57<Chutt>their channel numbers are really e5 and stuff
01:57<Chutt>crazy people
01:57<inman>i know, but i didn't know it extended to the tuner, too.
01:58<Chutt>yup
01:58<Chutt>no more lag, anyway
01:58<inman>so what does that leave us with?
01:58<Chutt>fix up the setup stuff
01:58<Chutt>fix recording =)
01:58<inman>okay, that's the only thing i don't know anything about.
01:58<inman>what is the problem with recording, exactly?
01:58<Chutt>it's pretty easy
01:58<inman>will it be fixed by the other stuff we've discussed?
01:59<Chutt>go into your tv_rec.cpp
01:59<Chutt>line 580 or so
01:59<Chutt>you've got a SwitchToInput(inputname);
01:59<inman>right
01:59<Chutt>just make it SwitchToInput(inputname, chanstr);
01:59<Chutt>and that should work
01:59<inman>okay
01:59<Chutt>i think, at least, going by the rest of your code
02:00<Chutt>it just needs to set the channel for the recording somewhere
02:04<Chutt>anyway, i'm going to bed.
02:04<bigguy>night
02:05<inman>hmm, that could be "" if the db fails.
02:05<inman>can i if() it?
02:05<inman>i think it'd be bad if we switched to an input for which we doubt the channel...
02:05<inman>you're hosting the cvs on your dsl, arentcha?
02:05* inmansmirks.
02:05* inmanputs in a if(!chanstr.isEmpty()) ...
02:05<Chutt>well
02:05<inman>okay, thanks for the pointers.
02:05<Chutt>the recording would kind of fail
02:05<inman>--- Ping reply from Chutt : 233.03 second(s)
02:05<Chutt>if chanstr was empty at that point
02:09<inman>i think it'd fail anyway though, wouldn't it?
02:25-!-Viddy [] has quit [Remote closed the connection]
03:44-!-hurdel [~greg@wnpgmb08dc1-res-101-253.mts.net] has joined #mythtv
04:12<inman>hello
04:18-!-Viddy [david@visp194-179.visp.co.nz] has joined #mythtv
05:38-!-mdz [] has quit [Read error: 60 (Operation timed out)]
05:40-!-mdz [~mdz@216-15-124-77.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com] has joined #mythtv
09:14-!-schwin97 [~schwin97@12.207.2.227] has joined #mythtv
09:24-!-nziarek [~nathanzia@mke-24-167-222-150.wi.rr.com] has joined #MythTV
09:27<nziarek>who should I send the updated weather graphics to?
09:28<Chutt>me, for now
09:28<Chutt>moegreen's out of town for the week
09:33<nziarek>Chutt - this question seems silly, but...you are Isaac, right?
09:34<Chutt>yup
09:44<-- nziarekhas quit ()
11:02<Chutt>since when is 800x640 a standard resolution?
11:11<Chutt>ah, he's running at 1280x1024
11:11<Chutt>well, can't expect it to scale everything properly at non 4:3
11:16<mdz_>with or without Xv?
11:16<mdz_>say, what's that patch from andy davidoff supposed to do, with the channel changing?
11:16<mdz_>have a different initial channel for different inputs?
11:16<Chutt>yeah, and deal with it all better
11:16<Chutt>save the last channel you were on on a per input basis, etc
11:17<Chutt>i'm probably going to commit it soon, you be able to test it a little?
11:17<Chutt>mdz, and it's without xv, since it's the program guide =)
11:19<Chutt>fontsize is based off of the height of the screen
11:19<Chutt>but he's scaling the height more than the width, running at 1280x1024
11:19<Chutt>so it throws stuff off a little
11:20<mdz_>oh, is that what was breaking that guy's icons?
11:20<Chutt>well, basically
11:20<mdz_>I'm not able to test anything; I'm at the office
11:21<Chutt>the code was using hmult instead of wmult in one place
11:21<Chutt>which made the left side even smaller
11:21<Chutt>but, it still looks weird at that res, even fixed
11:21<Chutt>mdz, i meant eventually =)
11:21<Chutt>it all looks like it should work
11:21<mdz_>I don't exactly watch live tv
11:21<Chutt>yea yea
11:21<mdz_>:-)
11:23<Chutt>basically, it'll work for those silly people that insist on using their tuner input for an external cable box
11:35<mdz_>gah, lots of 500s from zap2it recently
11:39<thor_>Chutt: If you're there, a question on Key_Escape
11:46<Chutt>sure
11:49<thor_>Right now, Escape is sort of "pop back to previous level"
11:50<thor_>In my current (much changed) mythmusic, there's a mode to change the order of songs on a playlist
11:50<thor_>(yes .. this is all happening in one pane :-)
11:50<Chutt>heh
11:50<Chutt>and you think escape should exit out of it?
11:50<thor_>No, space exits out
11:50<thor_>Space changes the interaction so that you are "holding" a track
11:50<thor_>then up/down move it
11:51<Chutt>ah
11:51<thor_>space again "releases" the track
11:51<thor_>or the playlist (within a playlist)
11:51<thor_>I need a key for delete the song (not from All Music, just from the playlist
11:51<thor_>Was planning on using Escape
11:52<Chutt>hmm
11:52<thor_>It's arbitrary, but seems to feel right during use
11:52<Chutt>escape wouldn't quite make sense there, i don't think
11:52<thor_>Not sure waht other key people would easily glob onto
11:53<Chutt>hmm
11:53<Chutt>another key besides space for move?
11:53<thor_>to set move?
11:53<Chutt>and then space can delete, like it does in the all music tree
11:53<Chutt>right
11:53<thor_>Well, yeah, but it';s not a tree check
11:53<thor_>the song is on the playlist or it isn't
11:54<Chutt>hmm
11:54<Chutt>i dunno, then =)
11:54<Chutt>don't like my popup menus idea?
11:54<thor_>Yes, popups are good
11:54<thor_>Using them all over
11:54<thor_>But you can't use them to move
11:54<Chutt>just have delete in there?
11:55<thor_>And once a track is "held" for moving, seems the right place to delete
11:55<thor_>user "I selected it, but now i want to remove it"
11:55<thor_>Anyway ... this is not a high priority item ... I'll get some code soon and we can worry about key bindings later
11:56<Chutt>ok
11:56<Chutt>cool
13:10-!-TheAsp [asp@CDR13-117.accesscable.net] has joined #mythtv
13:13<TheAsp>chutt, updated my patch with lastnights change to volumcontrol
13:14<Chutt>i've already taken care of that
13:14<Chutt>just haven't gotten a chance to commit it yet
13:14<Chutt>thanks, though
13:16<TheAsp>ok
13:17<TheAsp>you going to school?
13:18<Chutt>heh, no
13:18<Chutt>i've been done with school for awhile :p
13:18<TheAsp>ah, just you are always here :)
13:19<Chutt>work outta my house
13:19<TheAsp>nifty
14:31-!-nziarek [nziarek@pcp010412pcs.unplugged.mu.edu] has joined #MythTV
14:32-!-nziarek [] has quit [Client Quit]
14:33-!-TheAsp [] has quit [Read error: 60 (Operation timed out)]
14:38<inman>why not use 'd' for delete, so people with remotes don't have to rebind stuff.
14:39<Chutt>because i'd like to stop using d for delete in the playback box eventually.
14:39-!-billytwowilly [~chris@h24-86-147-220.ed.shawcable.net] has joined #mythtv
14:39<inman>to reduce the number of buttons needed?
14:39<inman>i think we could take a que from tivo.
14:40<inman>they use the left/right buttons for navigating pages, like lynx.
14:40<billytwowilly>hey, anyone care to fill me in on what's happening with 0.8? the website says that it would probably be out by the end of february, and we're now 1/3 of the way through march.
14:40<Chutt>billytwowilly, read the mailing list
14:40<billytwowilly>Chutt: developer or user?
14:40<Chutt>either.
14:42<billytwowilly>ok, thanks.
14:42<billytwowilly>wow. nice archive setup.
14:43-!-nziarek [nziarek@pcp010412pcs.unplugged.mu.edu] has joined #MythTV
14:44<billytwowilly>os the xmltv uk stuff is holding things up?
14:44<billytwowilly>s/os/so
14:45<Chutt>hah
14:45<Chutt>no
14:45<Chutt>my having to work is holding things up.
14:45* inmanchuckles.
14:45<billytwowilly>oh ok. hehe, I search 0.8 in the users archive and I got a whole bunch of xmltv uk stuff;)
14:45<inman>vincent scott stole my quoting style.
14:46* inmansmirks.
14:46<Chutt>your quoting style is horrible
14:46* inmanshrugs.
14:46<inman>i guess you should inform vincent. :-P
14:47<Chutt>i've made a couple changes to your patch
14:47<Chutt>moved the startchannel db read into GetDevices(), like the defaultinput stuff was
14:47<Chutt>couple of the functions you added in channel.h didn't need to be public
14:47<Chutt>just minor stuff
14:47* inmannods.
14:48<inman>thanks.
14:48-!-toddm [~Todd@12-228-92-189.client.attbi.com] has joined #mythtv
14:49<Chutt>made channel::setchannelbystring call checkchannel, regardless of if it's a tuner or external input
14:51<Chutt>i didn't think it was doing the right thing there in TuneTo, especially with external channels
14:52<inman>post 0.8, would you include my patch for icons/previews in the db as mentioned last night?
14:52<Chutt>probably
14:53<Chutt>if all it was was for small images
14:54* inmannods.
14:54<inman>tuneto is only used to tune the tuner.
14:55<inman>after it's tuned, it never should be called again if we're using external channels.
14:55<inman>it's for, eg. changing to tuner-channel-3 if you're using a cable box for descrambling.
14:55<Chutt>right, but the input's changed, so the checkchannel in there would fail
14:55<inman>checkchannel just gets the finetuning?
14:56-!-rickter [~rickter@pixout.appriss.com] has joined #mythtv
14:56<Chutt>it also makes sure that the channel's in the db
14:56<Chutt>using the current input name and all that
14:56<inman>huh, i wonder if i reverted that patch.
14:56<inman>i'm pretty sure i hacked checkchannel up
14:57<inman>it's a bug, that's for sure.
14:57<Chutt>what i've got now should work fine
14:57<inman>cool.
14:58<inman>are you passing it the input string?
14:58<Chutt>no
14:59<Chutt>just only calling it when it should work =)
14:59<inman>where is that?
14:59<Chutt>just in setchannelbystring
15:00<inman>but we may need to finetune when using a cable descrambler.
15:01<Chutt>right, but that's fairly low priority
15:01<inman>?
15:01<Chutt>it'd be nice to have a gui to disable channels and set finetuning first =)
15:02* inmangrins.
15:02<inman>TuneTo() may as well be void.
15:02<Chutt>well, lemme get stuff checked in
15:03<inman>hmm, if we checkchannel when watching composite input, it won't get the channel number correctly.
15:03<Chutt>then if you have any issues with it, send in a patch
15:03<inman>the tuned number (3) isn't necessarily a valid external channel.
15:03<Chutt>the tuned number shouldn't be stored anywhere
15:03<inman>that's my point.
15:03<Chutt>it's not stored anywhere
15:04<inman>go ahead and check it in, i'll look at your changes.
15:04<Chutt>CheckChannel uses curchannelname
15:04<inman>i was amused to see your displaychanum change to the guide last night.
15:04<inman>it mirrored mine in all but case. ;-P
15:04<Chutt>which would've been set by SetChannelByString
15:04<Chutt>so the tuned channel is just tuned to, but not stored anywhere
15:04<inman>we don't use setchannelbystring for tuning, though.
15:05<Chutt>exactly
15:05<inman>are you saying this is a problem or not?
15:05<inman>without your source in front of me...
15:06<Chutt>i'm saying it's not a problem
15:06* inmannods.
15:06<inman>lemme know when it's committed, then...
15:07<Chutt>couple minutes
15:12<Chutt>heh, oops
15:12<Chutt>need to fix the playback settings screen size again
15:13<inman>should probably move the DefaultTVChannel setting into the Guide settings pages.
15:13<inman>really, it should just be removed.
15:14<Chutt>moved it there
15:14<Chutt>already
15:14* inmannods.
15:14<inman>do you think it's a useful setting?
15:14<Chutt>eh, i kinda like it
15:15<inman>okay. what did you think about the way i called channel's stupid StoreInputChannel() just in order to callback to TVRec()'s version?
15:15<Chutt>that's fine, really
15:16<inman>seems lame to me, since there's very little chance that we'll actually want to manipulate the values before sending them up to TVRec(), but okay.
15:16<inman>are you going to make qt-3.1 a requirement for 0.9? ;-P
15:17<Chutt>heh
15:31<-- toddm(~Todd@12-228-92-189.client.attbi.com) has left #mythtv
15:36<Chutt>heh
15:36<Chutt>the xrender extension is really slow
15:36<Chutt>at least for blending images
15:49<inman>tell me about it.
15:49<inman>and every time i upgrade X, they break xterm again.
16:35<Chutt>there, no more slowass xrender image blending
16:35<inman>booyah
16:36<Chutt>instead, use totally unoptimized software blending that manages to beat the pants off of xrender
16:36<nziarek>i'm confused - what does it speed up?
16:36<Chutt>the menu display
16:36<nziarek>ah
16:36<inman>is it committed?
16:36<Chutt>yup
16:36<inman>suhweeet.
16:36<Chutt>at least, for larger resolutions
16:37<inman>checkchannel is hideous.
16:37<Chutt>yes, that it is
16:37<inman>ah, maybe that's my problem -- 1600x1200 :-)
16:37<inman>not worth patching though, is it.
16:37<Chutt>but, you wouldn't believe how many people try to run stuff with broken databases
16:37<Chutt>so that why it's hideous
16:37<inman>i don't see why it does a query for null...?
16:38<Chutt>just to see if there's _something_ in the db
16:38* inmanfrowns.
16:39<Chutt>that's so it could handle people that half setup their db stuff
16:39<inman>okay, so it lets people tune by typing in a number?
16:40<Chutt>nope
16:40<Chutt>it lets people tune that managed to break their cardinput table
16:41<inman>it's very unlike you to want to support this behavior. :-)
16:42<Chutt>reduces the number of emails i get
16:42* inmangiggles.
16:57<inman>you don't like TVRec() to start with an arbitrary input/channel?
16:57<inman>does it ever get destroyed?
16:57<Chutt>nope, it doesn't
16:58<inman>okay, that makes sense, then. :-)
17:53<-- rickter(~rickter@pixout.appriss.com) has left #mythtv
18:00-!-rickter [~rickter@pixout.appriss.com] has joined #mythtv
19:00-!-nziarek [] has quit [sterling.freenode.net irc.freenode.net]
19:00-!-billytwowilly [] has quit [sterling.freenode.net irc.freenode.net]
19:00-!-mdz [] has quit [sterling.freenode.net irc.freenode.net]
19:00-!-hurdel [] has quit [sterling.freenode.net irc.freenode.net]
19:00-!-mirk_dt [] has quit [sterling.freenode.net irc.freenode.net]
19:00-!-sc00p [] has quit [sterling.freenode.net irc.freenode.net]
19:00-!-Edgan [] has quit [sterling.freenode.net irc.freenode.net]
19:00-!-moegreen [] has quit [sterling.freenode.net irc.freenode.net]
19:01-!-lichen [] has quit [sterling.freenode.net irc.freenode.net]
19:11-!-mirk_dt [~mirk_dt@204.210.224.95] has joined #mythtv
19:12-!-mdz [~mdz@216-15-124-77.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com] has joined #mythtv
19:20-!-Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv
20:00-!-lichen [lichen@vanquish.cohpa.ucf.edu] has joined #mythtv
20:04-!-hurdel [~greg@wnpgmb08dc1-res-101-253.mts.net] has joined #mythtv
20:12-!-nziarek [~nathanzia@mke-24-167-222-150.wi.rr.com] has joined #MythTV
20:21-!-nziarek [] has quit [Killed (clarke.freenode.net (sterling.freenode.net <- adams.freenode.net))]
20:21-!-nziarek [nziarek@pcp010412pcs.unplugged.mu.edu] has joined #mythtv
20:21-!-sc00p [~oldendic@129.252.132.142] has joined #mythtv
20:21-!-moegreen [~jdanner@pa-steclge-u2-c3a-154.stcgpa.adelphia.net] has joined #mythtv
20:25-!-nathanziarek [~nathanzia@mke-24-167-222-150.wi.rr.com] has joined #MythTV
20:29-!-sc00p [] has quit [Read error: 65 (No route to host)]
20:49<yebyen>hmm
20:49<yebyen>cap\\\\\\\\\\\\
20:49<yebyen>err, never mind
20:57-!-nathanziarek [] has quit [Read error: 60 (Operation timed out)]
21:01-!-nyquiljer [coyote@12-211-10-191.client.attbi.com] has joined #mythtv
21:58<inman>still having problems trying to delete a problem i've just watched from the delete dialog.
21:58-!-nyquiljer [] has quit [Read error: 104 (Connection reset by peer)]
21:58<-- rickter(~rickter@pixout.appriss.com) has left #mythtv
22:02<inman>s/problem/program/
22:03<mdz>works fine here
22:03<inman>permanently is mispelled, btw.
22:03<inman>mdz: you aren't using qt-3.0.5 are you?
22:03<inman>i think it could be the keyaccel bug.
22:03<Chutt>that only affected non-qt windows
22:04<inman>hmm. well, i can create the deletion windows. i just can't interact with them.
22:06<Chutt>i don't think there's anything special about the delete confirmation window
22:06<Chutt>they do the same setActiveWindow() call everything else does
22:06* inmanshrugs.
22:06<inman>the main deletion window is fine. i'm looking at the source now...
22:08<Chutt>i just deleted two recordings, one from the end of playback prompt, one from the exiting out of playback prompt
22:09<inman>i'm not doing it from a prompt
22:10<inman>i play a recording from the delete-recording screen, then when i return back to that screen (after exiting the recording), i try to delete it.
22:10<inman>if i don't watch first, then i can delete stuff all day long.
22:10<inman>huh, going back to the main menu and then trying to open delete-recordings again caused it to crash.
22:10<mdz>inman: yes, I am using Qt 3.0.5 on my myth box
22:11<mdz>and that works just fine for me
22:11* inmannods.
22:11<Chutt>yup, same here
22:11<inman>debian, presumably.
22:11<mdz>good news, AMD is sending me a new CPU
22:11<mdz>should be here Friday
22:11<Chutt>played with the p key, exited out, deleted with space
22:11<Chutt>mdz, nice
22:12<mdz>and none too soon...myth takes forever to compile
22:12<mdz>each new gcc in unstable seems slower than the last
22:12<Chutt>heh
22:12<Chutt>yup
22:12<Chutt>wait until 3.3
22:12<Chutt>it's even better
22:12<inman>what's worse is that it seems to be outstripping the processor manufacturers. :-)
22:13<inman>what ever came of the work to build myth with the intel compiler?
22:13<Chutt>i dunno
22:13<Chutt>it won't really help that much
22:13<Chutt>so i don't see the point
22:14<mdz>unless it builds faster
22:14<Chutt>it's slower, iirc
22:14<mdz>ccache helps me a lot, but I just upgraded gcc so I lost my cache
22:14<inman>yeah, i would expect it to be pretty slow.
22:15<inman>mdz: what kinda hardware are you using?
22:17<mdz>inman: 1.2ghz athlon right now
22:17<mdz>was an xp 2000 until it blew
22:17<mdz>will be again in a few days
22:18<inman>where are you located?
22:18<mdz>MA, US
22:18<inman>well if you want another xp for testing, let me know.
22:18<inman>i'm itching to replace my 2k.
22:19<mdz>my myth box is a 1.4ghz tbird, I think the board can take an xp
22:19<mdz>if you really want to get rid of it
22:19<inman>i wanna put a couple new chips in. what percentage of pricewatch do you want to pay?
22:20<mdz>yep, it can
22:20<mdz>lowest pricewatch is USD71
22:21<mdz>what are you replacing it with?
22:21<inman>i dunno, hadn't given it any thought.
22:21<mdz>heh
22:21<inman>it's in a SMP board with a single fat zalman cooler -- one of the fan-like copper units.
22:21<mdz>the 2200 is the price point these days
22:21<mdz>but that's not enough of an increase to really make an upgrade worth it
22:22<mdz>that's the other problem; I'm using a low-speed quiet fan on it
22:22<mdz>which won't cut it with a faster chip
22:22<inman>hmm, i have some extra heatsink/fans
22:22<inman>they are 60mm though.
22:23<mdz>I have no pressing need to upgrade it; I need a switch more than a new CPU
22:23<mdz>was it you that was recommending netgear?
22:23<inman>yep.
22:24<inman>let me know if you wanna take the chip off my hands. the heatsink/fans are sk-6.
22:24<mdz>do you know the difference between the FS-605NA and the FS105?
22:24<inman>nope.
22:24<mdz>similar prices
22:24<inman>i think the 105 is the bottom-of-the-line stuff.
22:24<inman>it doesn't have its own internal ps and whatnot.
22:24<mdz>I don't need more than 8 ports
22:25<inman>i know my 308 does. a nice, normal, 8 port fast ethernet switch.
22:25<mdz>probably that or the 608
22:25<inman>got a url?
22:25<mdz>http://www.emscomputing.com/ProductInfo.asp?v=F8&idProduct=12645050
22:25<inman>might wanna be careful the 105 supports 10bT, too. i know some of their smaller units don't.
22:25<mdz>AC adapter it says
22:25<mdz>the fs105 claims to be 10/100
22:26<inman>i wouldn't buy it unless you can't afford the 6xx.
22:26<mdz>308 is 3x as much as the 608
22:26<inman>but in any case, you can't go wrong with netgear.
22:26<mdz>$150 vs $50
22:26<inman>i just wonder what the extra $100 is buying you.
22:27<Chutt>mdz, you said that that time change conflict resolution stuff was broke, right?
22:27<inman>the 608 has a/c adapter and the 105 does not?
22:27<inman>weird.
22:27<mdz>Chutt: that is my considered opinion, yes
22:27<mdz>the 105 has an adapter too I believe
22:27<Chutt>since i disabled that earlier
22:27<Chutt>ok
22:27<mdz>I have never tried it but it cannot possibly work riht
22:27<mdz>right
22:28<Chutt>inman, did you see if the menus were any faster?
22:28<inman>i will check now.
22:30<inman>at 1600x1200 it takes about a second from when i hit an arrow key to see the cursor move, and it causes audio/video skips.
22:30<inman>it may be a little faster.
22:30<Chutt>heh
22:30<inman>i'm going to upgrade mysql to match your version.
22:30<Chutt>you're not supposed to use the menus while something's playing :p
22:31<Chutt>the redrawing is pure alpha blending time, now
22:31<inman>i'm talking about the channel preview pane, top right.
22:31<Chutt>i meant the menu, not the epg
22:32<Chutt>ah well
22:32<inman>uh
22:32<inman>menus have nothing to do with anything i just tested...
22:32<inman>anyway, the sluggishness isn't a priority for either of us.
22:33<inman>i may look at it later, with a stopwatch, but it's a mere annoyance at the moment.
22:33<inman>i thought the change you made would help the epg stuff. no?
22:33<inman>my menus have never been a problem. not much slower than tivo.
22:34<Chutt>they're really slow at 1280x960 and up
22:34<inman>only takes about .2 seconds, if that, to switch items.
22:36<mdz>if anybody wants a 10-page step by step description of how to install gentoo, just subscribe to mythtv-dev
22:36<Chutt>very very step by step
22:36<inman>heh
22:38<mdz>hmm, just had a backend crash
22:38<Chutt>doing what?
22:39<mdz>conflict resolution-
22:39<Chutt>wait, you're not doing master/slave stuff, so it wasn't something i just changed
22:39<mdz>going to try to reproduce it
22:39<mdz>yep
22:39<mdz>seems to be 100% reproducible
22:39<Chutt>excellent, get ye a backtrace =)
22:40<mdz>lemme get a debug build
22:40<Chutt>hm
22:40<Chutt>could be something i just did, anyway
22:41<Chutt>the scheduler's getting a tad on the complicated side
22:41<Chutt>ah well, for what all it does, i suppose that's expected
22:41<mdz>I haven't updated my myth box in a while though
22:41<mdz>so this is before the most recent batch of scheduler changes
22:41<mdz>the multicard stuff
22:41<Chutt>ah
22:41<Chutt>ok
22:41<mdz>I'm putting the latest stuff on it now for the debug build
22:42<Chutt>but, still be nice to see if it's fixed or not =)
22:42<mdz>dammit
22:42<mdz>happened twice in a row, now I can't get it again
22:43<mdz>might need to remove the conflict entries and try again with the same programs
22:43<inman>my bug looks like it may be in qt
22:43<mdz>cvs is slow
22:43<mdz>stop yer downloading
22:44<thor_>err ... sorry
22:44<mdz>Chutt: interested in the non-debug backtrace?
22:44<mdz>all I have so far
22:44<Chutt>where is it?
22:44<mdz>in Qt
22:44<mdz>segfault
22:45<Chutt>ok
22:45<mdz>bad free() by the looks of it
22:45<inman>#0 0x40638e59 in QGList::findRef(void*, bool) ()
22:45<inman> from /usr/lib/qt-3.0.5/lib/libqt-mt.so.3
22:45<mdz>probably not a myth bug unfortunately
22:45<Chutt>naw, it probably is
22:45<inman>sup thor
22:45<thor_>segfaults
22:45<mdz>here it comes
22:45<mdz>#0 0x408e6e9d in mallopt () from /lib/libc.so.6
22:45<mdz>#1 0x408e5e81 in free () from /lib/libc.so.6
22:45<mdz>#2 0x408448a4 in __builtin_vec_delete ()
22:45<mdz> from /usr/lib/libstdc++-libc6.2-2.so.3
22:45<mdz>#3 0x4059ebf7 in QStringData::deleteSelf () from /usr/lib/libqt-mt.so.3
22:46<mdz>#4 0x405a000d in QString::sprintf () from /usr/lib/libqt-mt.so.3
22:46<mdz>#5 0x40585ad3 in QTime::toString () from /usr/lib/libqt-mt.so.3
22:46<mdz>#6 0x403c4421 in QVariant::toString () from /usr/lib/libqt-mt.so.3
22:46<mdz>#7 0x40074809 in SimpleDBStorage::load () from /usr/lib/libmyth-0.8.so.0
22:46<mdz>really doesn't look like something our code should be able to cause
22:46<Chutt>well
22:46<Chutt>if it's a null
22:46<Chutt>how does QTime::toString() handle being passed a QString::null?
22:47<mdz>not like this I hope :-)
22:47<mdz>otherwise it would break quite a bit more often I would think
22:47<Chutt>heh
22:47<Chutt>kinda looks like that, though
22:47<inman>easy to test.
22:47<Chutt>yup
22:47<mdz>yeah, says you with your machine that can compile a C++ source file in less than a minute
22:48<Chutt>heh
22:48<mdz>takes me longer to compile the test program than to write it
22:48<inman>heh
22:48<Chutt>mdz, i've got several boxes at work with 10 dsp devices =)
22:48<Chutt>people with 5 or 6 just aren't trying
22:49<Chutt>'course, that's 5 cards, 2 dsps each
22:49<inman>Chutt: this crash of mine is reproducable.
22:49<mdz>Chutt: but you're not doing something silly like running mythtv on them, are you?
22:49<Chutt>naw, 'course not
22:49<Chutt>they're servers
22:50<mdz>why does QString::sprintf () call QStringData::deleteSelf()? yuck
22:50<Chutt>making a temp qstring or something
22:51<mdz>this version of qt sucks, I may have to upgrade
22:52<inman>in your window managers, are you able to focus to a window behind the current input?
22:52<inman>eg. with alt-tab or something?
22:52<Chutt>yup
22:52<inman>you have 3.0.5 installed now for testing, right?
22:52<Chutt>not on my main box, no
22:52<inman>okay
22:52<Chutt>the box i have 3.0.5 on is doing other stuff right now
22:53<mdz>hah
22:53<mdz>I ran out of disk space with the debug build
22:53<inman>my crash is in QWidget::raise()
22:54<Chutt>mdz, i've done that a couple times
22:54<mdz>it's huge
22:56<mdz>Chutt: all the recent db changes you added to the beginning of cvs.sql, right?
22:57<Chutt>yup
23:00<mdz>ick
23:00<mdz>the progfind code has tabs in it
23:01<Chutt>heh
23:01<Chutt>that's all moegreen's code, though
23:01<Chutt>'cept for the little bits i fixed
23:03-!-nathanziarek [~nathanzia@mke-24-167-222-150.wi.rr.com] has joined #MythTV
23:04<mdz>I'm going to fix up the key bindings in progfind a bit
23:05<mdz>add the same numeric page up/down used in the epg
23:05<mdz>and let space bring up the info in addition to 'i'
23:05<Chutt>ah
23:05<mdz>sound ok?
23:05<Chutt>yup
23:05<mdz>(right now space does nothing if you've drilled down all the way)
23:05<Chutt>makes sense
23:05<inman>how do you feel about having a letter typed on the keyboard jump to the appropriate section of the program list?
23:06<Chutt>might get in the way of other keybindings
23:09-!-Captain_Murdoch [~buy_more_@ip68-107-147-203.hr.hr.cox.net] has joined #mythtv
23:10<inman>evening cpt.
23:11<Captain_Murdoch>hey. just installed myth on my workstation so I can record and watch from 2 machines now when I finish configuring it. :)
23:11<Captain_Murdoch>now I see the advantage of non-fullscreen Xv mode.
23:11<mdz>heh
23:11<mdz>now it blows up in a different place in QTime::toString
23:11-!-stigrett [] has quit [Remote closed the connection]
23:11<mdz>in a strncpy()
23:12<mdz>called from a different place too
23:12<mdz>all my work to get a debug build, and myth isn't even on the stack
23:12<mdz>it's from the qt event loop this time
23:12<inman>we must be feeding it bad input somewhere.
23:12<inman>are the prereqs listed anywhere?
23:13<inman>seems like an obvious place to start...
23:13<mdz>prerequisites for what?
23:14<inman>the naughty Qt functions.
23:14-!-Captain_Murdoch [] has quit ["X-Chat!"]
23:14-!-Captain_Murdoch [~buy_more_@ip68-107-147-203.hr.hr.cox.net] has joined #mythtv
23:15<mdz>is QVariant::isNull() the thing that was missing in 3.0.x?
23:15<Chutt>yup
23:15<mdz>because that seems like what I need to work around this
23:16<inman>blah
23:16<inman>i'm building a gentoo box tonight.
23:17<Chutt>well, hmm
23:17<mdz>it would be a huge pain to upgrade this box right now
23:17<Chutt>how's it getting from qvariant::tostring to qtime::tostring?
23:18<mdz>qvariant knows that it's a time
23:18<mdz>probably a time column in the db
23:18<Chutt>ah, right
23:18<mdz>a NULL one
23:18<mdz>and we already know that Qt 3.0.5 complains about that a lot
23:19<mdz>hmm...one of those KDE 3.1 deb repositories for woody should have qt 3.1 debs
23:19<inman>it may be cleanest to just alter the sql to do ifnull(column, '')
23:23<mdz>I think isValid should work
23:23<mdz>there is more than one place it would have to be done though
23:24<Chutt>not too terribly many
23:24<mdz>the only things that will have null date/time fields in the record table are things that are converted from the old table
23:25<mdz>I think
23:25<Chutt>i think the timeslot recordings will have a null date field
23:25<mdz>could fix the conversion script to set it to some value
23:25<mdz>I think it fills it in with whatever happened to be there, and ignores it
23:25<inman>i may not be using the stock schema, but my record table disallows null.
23:26<mdz>null is explicitly allowed in the stock schema
23:26<mdz>QTime::setHMS Invalid time 28:08:00.000
23:26<mdz>QDate::setYMD: Invalid date 2935/93/02
23:26<mdz>such a mess
23:27<inman>well, disallowing it should fix that, should it not?
23:27<mdz>both fromstring and tostring on those classes are screwy
23:27<mdz>if it's set to NOT NULL, what will the NULL values already in the db become?
23:27<inman>you could use the db to do date conversion tricks if you needed to.
23:27<inman>null values will become 00:00:00 ...
23:28<inman>i have noticed that stupid date/time stuff in the past.
23:28<inman>it's a problem in mythmusic, too.
23:28<mdz>it seems to be all fine in Qt 3.1
23:29<inman>figures
23:29<inman>mdz: can you test this crash bug of mine under 3.0.5, if you have something you can delete?
23:30<inman>actually, you don't need anything to delete.
23:30<inman>just a recording.
23:30<Chutt>mdz, could you do the audio output stuff as well, then?
23:31<mdz>Chutt: yes
23:32<Chutt>cool, thanks
23:34<mdz>meant to, but forgot about it
23:34<mdz>the theme stuff may be able to use this too
23:35<Chutt>the theme stuff is already doing something similar
23:36<Chutt>it's looking for the preview and theme definition files in the dir, though
23:36<Chutt>would that work with the stuff you just wrote?
23:37<mdz>setting a value for the null columns in the db seems to fix both the ugly warnings and the crash
23:37<Chutt>nice.
23:38<mdz>fix 0-7-to-0-8.sql and be done with it?
23:38<Chutt>and mc.sql
23:38<Chutt>and cvs.sql, if possible =)
23:38<mdz>mc.sql shouldn't matter too much, since new installs will never have null values, but ok
23:39<Chutt>might as well be consistant
23:39<inman>i'd just use the ifnull(column, '') in the query, to be safest.
23:39<Chutt>and just define things as not null in the db
23:39* inmannods.
23:39<mdz>I was just going to use not null
23:39<mdz>it really should be OK for them to be null though
23:40<mdz>non-EPG recordings would make more sense
23:40<mdz>and it could catch bugs
23:40<Captain_Murdoch>are you talking about the recording table and the date/time fields being null?
23:40<mdz>Captain_Murdoch: yes
23:40<mdz>and Qt 3.0.5
23:40<Captain_Murdoch>all my rows have date null and they're recently scheduled recordings.
23:41<mdz>I don't believe you :-)
23:41<Captain_Murdoch>sorry, record table. :(
23:41<Captain_Murdoch>typed recording meant record
23:41<mdz>even so
23:42<mdz>that should only happen with recordings from before that table existed
23:43<Captain_Murdoch>not true. create a "record this program in this timeslot every day" show in mythweb.
23:43<Captain_Murdoch>I just did it again.
23:43<Chutt>ah
23:43<Chutt>mythweb
23:43<mdz>ahh
23:43<mdz>mythweb doesn't count
23:43<Chutt>heh
23:43<Captain_Murdoch>well, no start or end date cause it's a timeslot recording.
23:43* inmangiggles.
23:43<Chutt>yeah, better to just make it not null in the db, and be done with it all
23:44<inman>that's fine... as long as you trust the user to've run the update.
23:44<Chutt>they have to have.
23:45<Chutt>if they don't, i get to throw a rtf-commits list at them on the mailing list =)
23:45<inman>this is why a SchemaVersion setting is useful. :-)
23:45<inman>the lib can check the schemaversion upon init and bitch if it ain't right. then they can't run jack until they've updated the db.
23:46<Chutt>inman, it bitches quite loudly after, say, your patch i committed earlier if the update's not been run
23:46<Chutt>lots and lots of complaints =)
23:46<mdz>cvs.sql doesn't even have the record table in it
23:46<Chutt>i remove stuff from cvs.sql occasionally
23:46<mdz>ah
23:46<Captain_Murdoch>so the record table always has the date of the next occurance of a program even if it occurs daily?
23:47<Chutt>chris, no, it has the date of the originally selected item
23:47<Captain_Murdoch>oh, and the type indicates timeslot. now I get it.
23:47<Captain_Murdoch>was forgetting about the type field.
23:48<Captain_Murdoch>explains why all mine have blank dates cause I rarely schedule stuff from the tv, I use the web interface from work and home.
23:52<mdz>Chutt: committed the audio output device thing, should be correct but I can't really test it right now
23:52<Chutt>i'll check it out, thanks
23:53<mdz>it could probably get away with using *dsp* rather than dsp* and adsp* separately
23:53<mdz>but who knows
23:53<mdz>doh, up to date check failed
23:55<mdz>ok in now
23:56<mdz>I had already non-NULLed the values before I tested the alter table statements; I'd be interested if someone can confirm that they do the right thing
23:57<Chutt>geez
23:57<Chutt>forced to post to mythtv-users to correctly help some poor sap out
23:57<Chutt>since two other people just sent in totally wrong suggestions =)
23:58<inman>altering to null will cause the values that were null to assume the value closest to 0.
23:58<mdz>what date is "closest to 0"?
23:58<inman>you can alter it back if you want to test.
23:58<inman>for time, 00:00:00
23:58<mdz>date
23:58<inman>00-00-00
23:58<mdz>as long as it's not 2935/93/02 we should be OK
23:58* inmancackles.
23:59<Chutt>mdz, can you move those cvs.sql mods to the top of the file?
23:59<mdz>what date is 00-00-00?
23:59<mdz>Chutt: ok
23:59<inman>a long time ago.
23:59<thor_>On Unix/Linux, somwhere in the 1970's
23:59<mdz>for all we know, qdate will blow up on that
23:59<mdz>thor_: I don't think that's the same thing