| 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 | * inman | grovels. |
| 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 | * inman | frowns. |
| 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 | * inman | groans. |
| 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 | * inman | waves 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 | * inman | grins. |
| 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 | * inman | nods. |
| 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 | * inman | scratches 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 | * inman | sighs. |
| 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 | * inman | grins. |
| 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 | * inman | smirks. |
| 02:05 | * inman | puts 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 | <-- nziarek | has 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 | * inman | chuckles. |
| 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 | * inman | smirks. |
| 14:46 | <Chutt> | your quoting style is horrible |
| 14:46 | * inman | shrugs. |
| 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 | * inman | nods. |
| 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 | * inman | nods. |
| 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 | * inman | grins. |
| 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 | * inman | nods. |
| 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 | * inman | nods. |
| 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 | * inman | frowns. |
| 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 | * inman | giggles. |
| 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 | * inman | shrugs. |
| 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 | * inman | nods. |
| 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 | * inman | nods. |
| 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 | * inman | giggles. |
| 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 | * inman | cackles. |
| 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 |