Back to Home / #mythtv / 2003 / 02 / Prev Day | Next Day
#mythtv IRC Logs for 2003-02-25

00:14<rkulagow>chutt: i hope you don't end up using broadcast packets for the machines to find each other; last time i suggested something like that, mdz said, "lets not re-invent NetBIOS, badly" or something similar. :)
00:16-!-rkulagow_ [~mythtv@12.207.131.29] has joined #mythtv
00:16<-- rkulagow(~rkulagow@12.207.131.29) has left #mythtv
01:19-!-rkulagow [~rkulagow@12.207.131.29] has joined #mythtv
01:25<rkulagow>chutt, are you here?
01:44<moegreen>rkulagow: my zip code for mythweather was reset to 44031 (or something like that)
01:45-!-Edgan [edgan@24-205-202-17.rno-cres.charterpipeline.net] has joined #mythtv
01:45<rkulagow>moegreen: damn. that's the test zipcode that i was using to make sure that everything was working right. (it's the zipcode in cleveland) do you want the default back to Bahamas?
01:47<moegreen>well, it's fine, the problem is that the new code for per host settings didn't inherit my original zip code (I think)
01:48<rkulagow>wait; the new zip code should only take effect if it was null before, otherwise it should read what you already have.
01:48<rkulagow>oh, i see you type faster than i do.
01:48<rkulagow>yes, i think that's it.
01:49<moegreen>the main problem is changing it in the setting dialog is pretty hard because there doesn't seem to be a way to delete what's already in there --- or is there?
01:49<moegreen>(with a remote control at least)
01:49<rkulagow>really? you can't change it? i tabbed down to it and then typed in a few different zipcodes in setup to make sure it works.
01:50<rkulagow>right - i think maybe when andre gets his text entry widget uploaded you should be able to use a remote control.
01:50<rkulagow>hrmm. irxevent should be sending the keypresses to CurrentWindow though, right?
01:51<moegreen>right, I can add to it, but I have no button mapped to the backspace key because its never been necessary
01:52<moegreen>I guess I'm just wondering why it didn't use my value from the NULL hostname, or at least copy that value to my per host setting?
01:52<rkulagow>not sure. once you set it though and it associates with your hostname, it inherits it from then on, yes?
01:53<moegreen>yeah, I did an UPDATE with MySQL and now MythWeather is using that value
01:56<rkulagow>i just did a select * from settings and i see that there's lots of repeats of data, where in some cases hostname == NULL, and in others hostname == localhost.
01:57<moegreen>I just wonder if removing 'setValue("44106");' from the globalsetting.cpp would be a good idea (as this way, you can easily type in a zip code with the remote, and MythWeather will still complain if no zip code is set)
01:57<rkulagow>i'm perfectly fine with a blank default.
01:58<rkulagow>(besides, it's not my code anyway - do what you like!)
01:58<moegreen>nice work on the new config screen, btw
02:00<rkulagow>thanks. i'd like to get something going for mythmusic as well.
02:00<rkulagow>do you know if you want a dedicated mythweather setup screen instead of having it living in the TV module?
02:02<moegreen>it probably makes sense to have it's own settings screen (in the module). I've got just about every City and matching Area ID in a text file - I plan on making it so the user will be able to select their City from the GUI ... perhaps that will be a good start
02:03<moegreen>the file is about 200K zipped up (which is about the same size as the main startup graphic)
02:03<rkulagow>foreign countries as well?
02:03<moegreen>I still need to get 'M', 'S', and I think one more letter
02:03<moegreen>yeah
02:04<rkulagow>cool. mandrake does something similar during setup when you select your timezone. makes it easier to find "chicago" then to remember that i'm CST6CDT (or whatever)
02:04<moegreen>I went to msnbc.com and searched for cities using just 1 letter ... it returns on most every letter - except the ones with the most record I suppose. Then I parse the data out of the HTML
02:05<moegreen>I'll probably go Country->(pick first letter)->Pick City, but I'm not sure yet
02:05<moegreen>Maybe just first letter, then a list of Cities with the State/Country
02:07<rkulagow>you know, that just reminded me (but i'm not sure how) in mythprogfind, in the upper left quadrant, after you pick a show and it gives you the description of the episode, i don't believe that it displays channel information. am i remembering that correct? (it's the "friends" problem, where in syndication there are multiple channels showing episodes at the same time)
02:08<moegreen>It shows the channel in the upper right hand corner (in the black box)
02:09<moegreen>I didn't want it with the show times because it's pretty tight on space there
02:09<rkulagow>let me take another look.
02:23<rkulagow_>moegreen: it's definately not showing me the various channels that Friends is being shown on. big black box is an empty big black box.
02:47<moegreen>rkulagow: In your current theme's qtlook.txt file, are misChanIcon_bgColor and misChanIcon_fgColor both black? (or is one/both missing?)
02:48<rkulagow>standby
02:49<moegreen>brrr .. I bet they are both missing
02:50<rkulagow>str misChanIcon_bgColor=#000000
02:50<rkulagow>there is not misChanIcon_fg
02:50<rkulagow>(this is liquid theme)
02:51<moegreen>ok, add this str misChanIcon_fgColor=#(whatever color you want, probably just #ffffff)
02:53<rkulagow>ok, added; let me see if i can pull up mythprogfind in VNC (otherwise PC is in another room)
02:53<moegreen>I just updated progfind.cpp in cvs, this update should set those colors if they aren't in the qtlook.txt -> but that color should be defined anyways (for the program guide as well)
02:54<rkulagow>moegreen: that worked.
02:55<rkulagow>weird. is qtlook generated manually or programatically?
02:56<moegreen>manually
02:58<rkulagow>blue has it, as does iulius. looks like it got missed at some point.
03:00<rkulagow>think it's a problem to commit the update?
03:03<moegreen>No, go ahread and commit it - when I first did the alternate program guide, I had to add all the colors in - and probably just didn't enter in the one color on accident
03:05<rkulagow>done.
03:05<rkulagow>let me go see how my new eject code worked.
03:12<rkulagow>little thing, not sure that it matters. have you thought of somehow dividing the top of list / end of list in the second column? (btw, what are you calling your columns? letter, show, time? anyway) so, for example, when i go to "f" the first show in the center of the list is whatever is the first "f" show. but the one right above it is "futurama", since that's the last "f" show, and you've got a circular list. maybe a divider, or something? or have t
03:12<-- rkulagow(~rkulagow@12.207.131.29) has left #mythtv
03:14-!-rkulagow [~rkulagow@12.207.131.29] has joined #mythtv
03:17<moegreen>that could be added pretty easy, but I would guess it only really matters with the dates and times column right?
03:27<rkulagow_>i suppose. like i said, just wondering.
03:28<rkulagow_>my ejector didn't work like i thought it would. i submitted one that just uses the cdrom IOCTL to eject, but Chutt wanted me to use the libcdaudio function. it's not liking something, and i forgot to enable debug, so recompiling...
03:29-!-Soopaman [~soopaman@h24-66-55-163.wp.shawcable.net] has joined #mythtv
03:34-!-Soopaman [] has quit [Read error: 54 (Connection reset by peer)]
04:02-!-choenig [~choenig@pD9E09FE9.dip.t-dialin.net] has joined #mythtv
05:24-!-choenig [] has quit [Remote closed the connection]
06:45-!-choenig [~choenig@pD9E09FE9.dip.t-dialin.net] has joined #mythtv
09:46<rkulagow>duh. the ejector code for mythmusic was working fine. cd_close != cd_finish :)
09:46<Chutt>heh
09:46<Chutt>that got me a couple times, too
09:49<rkulagow>heh. you sure are forcing me to expand my horizons. had to learn a little gdb this morning to step through what was going on. it seems that it doesn't like QStrings though; when i do a printf is only works on standard C format strings and types. cerr and cout seem to adjust to QString types easily enough, but not gdb.
09:50<Chutt>yeah
09:50<Chutt>you can usually do a print string.ascii()
09:50<Chutt>if it's not dead at that point
09:56<rkulagow>chutt: this seems incredibly complicated: cdrom_fd = cd_init_device(QFile::encodeName(cddevice).data()); i couldn't get cd_init_device to accept cddevice.ascii() [complains of const char * errors]. the above snippet of code _works_, because as i stepped through the code i saw the cupholder come out and then get retracted on the next line of code because of my cd_close confusion. i've already changed my tree to cd_finish and i'm ripping now, so we'll s
09:57<Chutt>oh
09:57<Chutt>(char*)cddevice.ascii()
09:57<Chutt>should be fine
09:57<rkulagow>duh. yep, i should have cast. i'll check that next. i think my devel box is even slower than mdz's.
10:02<mdz>Chutt: yes, your playlist explanation is clear
10:03<mdz>rkulagow: try using a precompiled header
10:03<mdz>(singular)
10:03<Chutt>does it make sense?
10:03<mdz>yes
10:03<Chutt>ok, good
10:03<Chutt>thanks for slogging through that =)
10:03<rkulagow>mdz: i saw you guys were talking about it earlier; i'm running mandrake 9.1B3 on the devel box. what would i need to do to use a precompiled header?
10:04<mdz>I don't know what andy davidoff is saying with red, yellow, blue, green
10:04<Chutt>you can't, it's new g++ stuff
10:04<Chutt>and it's really not useful with a single precompiled header
10:04<mdz>rkulagow: it's very new, and it basically sucks
10:05<Chutt>since you basically have to have #include "all.h"
10:05<Chutt>or whatnot
10:05<Chutt>so any benefits you just gained by precompiling headers just got wiped out by having to have _all_ your header files precompiled
10:05<Chutt>together
10:06<Chutt>mdz, that's how i've wanted playlists to work ever since i worked on freeamp =)
10:06<Chutt>and never really got the chance to write em like that
10:09-!-rkulagow [] has quit [vinge.freenode.net irc.freenode.net]
10:09-!-rkulagow_ [] has quit [vinge.freenode.net irc.freenode.net]
10:09-!-jasongrichmond [] has quit [vinge.freenode.net irc.freenode.net]
10:10<mdz>uh oh
10:10<mdz>flamewar brewing on theora-dev
10:10<mdz>the "where the hell is development happening?" thread has begun
10:10<Chutt>heh
10:10<Chutt>"it's not, go away"
10:10<mdz>there are hints from time to time that people are working on things
10:10<mdz>but they aren't going into CVS
10:12<Chutt>yeah, closed open source development rocks
10:15<Chutt>if that guy actually finishes up a vp3 encoder/decoder for ffmpeg, that'd probably be best
10:17-!-rkulagow [~a@12.207.131.29] has joined #mythtv
10:22-!-rkulagow_ [~mythtv@12.207.131.29] has joined #mythtv
10:22-!-jasongrichmond [~jrichmond@216.91.143.73] has joined #mythtv
10:42<mdz>especially if it's fast
10:43<Chutt>main reason for putting it in ffmpeg would be to reuse a lot of the existing code
10:46<mdz>might even get ffmpeg into Debian
10:51<Chutt>they've already got a CONFIG_RISKY
10:51<Chutt>that turns off most stuff
10:53<mdz>it would need to be stripped out of the source too
10:54<mdz>dunno if that's set up to be easy or not
11:01-!-rkulagow [] has quit [Read error: 110 (Connection timed out)]
11:02<Chutt>could probably whip up automated stuff to do that
11:08<mdz>I think it's in DeMuDi
11:19-!-rkulagow [~a@12.207.131.29] has joined #mythtv
11:21<rkulagow>chutt, the cast in cd_init_device works. the default is to eject the cd when it's done; is that ok?
11:33-!-Tuscany0 [~username@66.54.186.1] has joined #mythtv
11:52-!-rkulagow [] has quit [Read error: 110 (Connection timed out)]
11:56-!-rkulagow [~rkulagow@12.207.131.29] has joined #mythtv
12:00<Chutt>yup
12:08<Chutt>anyone else seeing that position saved not letting you rewind past it thing reported by joe caputo just now?
12:23<rkulagow>chutt: i think i left behind a "using namespace std" in cdrip when i was debugging. i don't think it's going to hurt anything, but i'll take it out on the next commit.
12:25<Chutt>it doesn't hurt anything at all
12:25<Chutt>don't worry about it
12:25<rkulagow>ok
12:25-!-choenig [] has quit [Remote closed the connection]
12:26<mdz>it will add another few nanoseconds to my minute-long compile of that file
12:27<Chutt>cdrip.cpp?
12:39<rkulagow>don't you wish that all bug messages were like chris pinkham's?
12:39<rkulagow>(ie, they have solutions) :)
12:41<Chutt>yup
12:42<rkulagow>i know i'm as guilty as the rest, but i can certainly see development being better if more people had bug reports like his and that one guy you mentioned where he chased a bug down by printf'ing practically everything until he found it. (was it bruce?)
12:42<Chutt>yeah, that was bruce
13:01<shad_>Any of you know anything about vmware esx server?
13:11-!-choenig [~choenig@pD9E09FE9.dip.t-dialin.net] has joined #mythtv
13:33<rkulagow>chutt: if i'm not actively breaking anything in mythmusic, do you mind if i work on it a little, or do you want me to send you everything for review first?
13:34<Chutt>i'd like to know what you're committing before you do, if that's ok
13:40<rkulagow>of course. i added a check that we could open the cddevice; if not, there's no point in continuing. also added a closecd call in case the tray was still open. it's a 2K diff; i can mail it to you if you want to see it first.
13:41-!-orangey [~orangey@dsl-207-112-56-161.tor.primus.ca] has joined #mythtv
13:46<Chutt>where's it check to open the cd?
13:47<Chutt>or, just send off the diff, that's fine
13:51<Chutt>bbl, though
14:46-!-bigguy_ [bigman@h98.44.102.166.ip.alltel.net] has joined #mythtv
14:47-!-bigguy [] has quit [Killed (NickServ (Ghost: bigguy_!bigman@h98.44.102.166.ip.alltel.net))]
14:47-!-bigguy_ is now known as bigguy
14:55<Chutt>rkulagow, i'd kind of prefer it not to exit if it can't open the device
14:55<Chutt>how about just printing out the message and returning?
14:56<rkulagow>ok, i suppose that could work. what do you want to return to?
14:56<Chutt>just return where you've got an exit now
14:56<Chutt>also
14:56<Chutt>it rips like that?
14:56<Chutt>since you've got the dev open for the cdrom_fd
14:56<rkulagow>yes; it's ripping "crooners at christmas" now. do you see a problem?
14:56<Chutt>and then the cdparanoia stuff will try to open it again
14:57<rkulagow>well, if it's read only, then couldn't multiple devices open at the same time?
14:57<rkulagow>there's no exclusive, is there?
14:57-!-orangey [] has quit [Remote closed the connection]
14:57<Chutt>i dunno how it works =)
14:57<Chutt>if the kernel internals allow it and stuff
14:57<Chutt>if it's only being used to close and then eject the cd, though
14:57<Chutt>it'd probably be better to open it only when needed
15:09<poptix>it's a blocking call
15:10<poptix>thread will hang until the drive is available, responds, and actually opens the tray
15:15-!-choenig [] has quit [Remote closed the connection]
16:00<rkulagow>huh. the paranoia page sure doesn't appear to be terribly helpful with API information.
16:17-!-choenig [~choenig@pD9E09FE9.dip.t-dialin.net] has joined #mythtv
16:21<rkulagow>chutt: do you want me to go through the cdrom_init_device / action / cd_finish when i want to do something? meaning, in that diff that i sent you, if the initial cdrom_init works, we close the tray if it's not already, and hold open the cdrom_fd until it's closed as one of the last things in ripthetrack. you're saying, do an init / cdrom_finish for each action and don't maintain a global cdrom_fd, correct?
16:22<Chutt>yup
16:23<rkulagow>ok, so i'll undo the int cdrom_fd change i made in cdrip.h and just make it a local int in each routine. should i keep that initial check (you said to replace the exit with a return at that point.)
16:23<Chutt>yeah
16:23<Chutt>that'll work
16:23<rkulagow>ok
16:45<rkulagow>chutt, mailed you the diff. it's short, since part of this is already committed.
16:46<Chutt>rkulagow, yup, looks nice
16:46<Chutt>feel free to commit that whenever you want =)
16:47<rkulagow>ok, howabout..... (wait for it....) NOW!
16:48<Chutt>heh
16:48<Chutt>that tod detre guy on the mailing list
16:48<Chutt>i know him, kinda
16:49<Chutt>in my year at cwru, apparently still works there
16:49<Chutt>funky
16:50<rkulagow>The "which cards support btaudio" question? I wish there were a canonical list. I asked on the V4L list a few months ago. Zero responses. I guess it's a -devel list, and that was a -user question.
17:02<Chutt>http://www.mythtv.org/testsite/
17:03<Chutt>i need to fix some of the stuff, i don't like how he set all that up
17:04<choenig>hui, that looks nice :-)
17:04<Viddy>heh
17:04<Viddy>first vote!
17:13<-- rkulagow(~rkulagow@12.207.131.29) has left #mythtv
17:18<bigguy>oh that's nice, Chutt
17:20<bigguy>what backend is it using?
17:23<Chutt>phpnuke
17:23<Chutt>with most everything turned off
17:25<bigguy>ah
19:44<Chutt>blah
19:50<Chutt>rkulagow, hey, question about the docs generation
19:51<Chutt>would it be possible to make the index page use absolute urls?
19:52<Chutt>well, not absolute, but /docs/<blah.html> instead of just <blah.html>
20:09-!-choenig [] has quit [Remote closed the connection]
20:09<Chutt>hrm
20:09<Chutt>i dunno
20:13<moegreen>Chutt: it might be nice to have some small thumbnails of the screenshots (even at this point, changing the colors of those links - they seem to match the surrounding text)
20:14<Chutt>heh
20:14<Chutt>yeah, but i'm trying to keep bandwidth consumption down =)
20:14<moegreen>understandable ... isn't that what sourceforge is for =)
20:14<Chutt>true
20:15<Chutt>i could just host the thumbnails there, too
20:16<moegreen>the thumbnails I have on my website range from 17K to 50K, you could even go smaller than those too
20:17<Chutt>yeah
20:17<Chutt>something to do next, i guess =)
20:33<mdz>OUCH
21:12<Chutt>heh
21:26-!-choenig [~choenig@pD9E09FE9.dip.t-dialin.net] has joined #mythtv
21:33-!-toothpick [~bionic@pcp02025589pcs.plsntv01.nj.comcast.net] has joined #mythtv
21:33<toothpick>What is the name of the other linux pvr project...it isn't as far as this one...but had a neat name...
21:36<Viddy>freevo?
21:36<toothpick>Viddy...yes thanks.
21:36<toothpick>that was it.
21:36<Viddy>*cough*its ass*cough*
21:36<toothpick>I think that didn't need mysql support and I am an pretty ignorant on getting mysql working.
21:37<Viddy>i personally think this is a better implementation
21:37<bigguy>I thought freevo was just a mplayer frontend that does nothing
21:41<Chutt>now now, no need to mock the competition =)
21:41<toothpick>Chutt...the only thing it does is install easier because it has a tar you can just download and run.
21:42<Chutt>personally, i think that's extremely silly
21:42<Chutt>they're shipping their own libs for _everything_
21:43<Chutt>own ld.so, own libc, own everything
21:46-!-choenig [] has quit [Remote closed the connection]
21:47<toothpick>tv_grab_na where does it store its files?
21:47<toothpick>like a tv guide and such.
21:47<Chutt>config files?
21:47<Chutt>whereever you tell it to
21:48<toothpick>hmmm I didn't tell it where...
21:49<toothpick>just tv_grab_na --configure
21:49<toothpick>Gave my zip and stuff
21:49<Chutt>then in ~/.xmltv/
21:49<toothpick>then ran it tv_grab_na
21:49<toothpick>thanks Chutt
21:49<Chutt>i'm not sure where the guide info went, though
21:57<toothpick>I thought tvtime would show me the name of the channels
21:57<toothpick>I got something wrong here.
22:05<toothpick>ok trying to get mythtv again.
22:05<toothpick>Haven't tried it in a while.
22:05<toothpick>apt-get update && apt-get install mythtv
22:05<toothpick>doing that now.
22:06<toothpick>Depends: libmyth-0.7 but it is not going to be installed
22:06<toothpick> Depends: libqt3-mt (>= 2:3.0.3-1) but it is not installable
22:06<toothpick> Depends: libqt3-mt-mysql but it is not installable
22:06<Chutt>it's not installable on current debian unstable
22:10<toothpick>Man...I got kde 3.1 working too.
22:10<toothpick>And now I figured out where the tv listings get saved
22:10<toothpick>you specify a file name after runnign it.
22:14<toothpick>Will it run in testing?
22:14<Chutt>it'll run in current unstable
22:14<Chutt>the debs just won't install is all
22:15<toothpick>oh so just d/l as source then.
22:15<toothpick>gotcha
22:18<mdz>I need to build unstable packages
22:20<toothpick>get it included with knoppix ;)
22:21<mdz>you wouldn't be able to store much video in a ramdisk
22:23<Chutt>heh
22:25<Chutt>adding all the stories into the new website stuff is not fun
22:27<mdz>new website?
22:27<Chutt>http://www.mythtv.org/newsite/
22:28<Chutt>i'm still adding in the news, and the docs don't quite work right yet
22:28<moegreen>you mean /testsite/ right?
22:28<Chutt>sorry, yes
22:28<Chutt>http://www.mythtv.org/testsite/
22:28<moegreen>you've got the same story posted twice (August 1, 2002), btw
22:29<Chutt>gotta fix up all the news entries so they look like they were inserted on the right days
22:33<Chutt>thanks
22:33<Chutt>got reinserted when i reloaded a page =)
22:37<paperclip>what's MobileMythWeb?
22:38<Chutt>nothing, yet =)
22:39<moegreen>I think it's an idea at this point, with the aim to have a modified interface to mythweb which will work on a mobile device
22:39<paperclip>is it for pdas
22:39<paperclip>ahh
22:40<mdz>toothpick: I've put up unstable debs just now
22:40<mdz>toothpick: let me know if you test them
22:41<mdz>Chutt: what backend are you using for the new site?
22:41<Chutt>it's phpnuke
22:41<mdz>ah, phpnuke
22:41<Chutt>jeremy oddo did it all
22:41<mdz>just looked at the source
22:42<Chutt>send me a big tarball with a database dump and stuff
22:42<mdz>my only experience with phpnuke is the 50 messages on bugtraq about it every month
22:42<Chutt>heh, yeah
22:42<Chutt>i've got pretty much everything turned off
22:42<Chutt>should be safe
22:42<Chutt>well, hopefully
22:43<Chutt>if it's not, it's gone
22:43<mdz>probably the worst of it is cross-site scripting type stuff then, which shouldn't affect you really
22:44<mdz>are those votes in the poll real?
22:44<mdz>or tests?
22:44<Chutt>probably real
22:44<Chutt>i haven't used the poll
22:44<Chutt>i didn't even write the poll =)
22:46<mdz>clearly not
22:48<mdz>bah, 'Your message to mythtv-users awaits moderator approval'
22:48<Chutt>'sec
22:49<mdz>is it possible to subscribe to mythtv-users for posting purposes, but not receive the messages?
22:49<Chutt>i'm adding you as an accepted poster
22:49<mdz>oh, thanks
22:49<Chutt>the message you sent should be accepted as well
22:50<yebyen>ahem
22:50<toothpick>mdz ok
22:51<mdz>toothpick: same sources.list entry, except s/wood/unstable
22:51<mdz>er, woody
22:51<mdz>my brain is not operating at normal efficiency
22:51<toothpick>ok
22:51<toothpick>so change woody to unstable mdz
22:51<yebyen>it's a shame i can't get cygwin onto one cd :x
22:51<mdz>toothpick: correct
22:52<mdz>yebyen: what? cygwin fits on a CD
22:52<yebyen>mdz: my mirror of it is 1.1g...
22:52<yebyen>is there an iso of the more important stuff?
22:52<yebyen>including uhh, CVS
22:52<yebyen>heh
22:53<mdz>yebyen: that probably includes all the packages that are not part of cygwin
22:53<yebyen>yeah
22:53<mdz>like regina rexx and a ton of other crazy stuff
22:53<yebyen>mdz: where can I get only cygwin? heh
22:53<mdz>heh, and GNOME
22:53<yebyen>actually i'm not entirely sure
22:53<yebyen>i can't find either of those :)
22:54<yebyen>g* = gawk, gcc, gcc-mingw, gcc2, gdb, gdbm, gettext, ghostscript, gnugo, gnupg, gperf, grep, groff, gsl, guile, gzip
22:54<yebyen>that's it
22:54<toothpick>mdz yes it is installing fine.
22:54<toothpick>But I am sure I won't get mysql working with it...and I have to go to bed now.
22:55<toothpick>Thanks for updating it though I will play with mysql tomorrow.
22:55<toothpick>DBI connect('host=localhost;database=','root',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at -e line 5
22:55<toothpick>Can't call method "do" on an undefined value at -e line 6, <> line 1.
22:55<toothpick>dpkg: error processing mythtv (--configure):
22:55<toothpick> subprocess post-installation script returned error exit status 255
22:55<toothpick>Errors were encountered while processing:
22:55<toothpick> mythtv
22:56<mdz>toothpick: is mysqld running?
22:56<mdz>it looks like not
22:56<mdz>if you install mysql-server first, it sets everything up for you
22:57<toothpick>I'll check it I have to go to bed though...I'll check tomorrow afternoon...now
22:58-!-toothpick [] has quit ["Client Exiting"]
22:58<yebyen>mdz: there aren't any 0.8 debs yet, are there? :)
22:58<Chutt>no cvs bins
22:58<mdz>yebyen: there is no 0.8 yet
22:58<yebyen>"Chris Pinkham's contributed the beginnings of automatic commerical skipping, which is now in CVS. Seems to work fairly well, though it's still under development."
22:58<yebyen>!!!
22:58<yebyen>heh
22:59<mdz>0.8 is shaping up to be a very big release
22:59<Chutt>it's been 3 months
22:59<mdz>I've lost track of all the new stuff
23:02<yebyen>so
23:03<yebyen>my big question on the commercial detection stuff (damned revolutionary, if it works)
23:03<yebyen>which is more common right now: false positives or false negatives?
23:04<mdz>Chutt: so I'm logging all sendreceivestringlist calls now, to get some info about the blank playbackbox problem
23:04<moegreen>it's been working very well for me here
23:04<mdz>if I'm reading this right, and I'm not sure that I am, it looks like it sends a QUERY_RECORDINGS Play, and gets back RECORDING_LIST_CHANGE instead of the result
23:05<Chutt>ah
23:05<Chutt>the RECORDING_LIST_CHANGE was probably sent earlier
23:05<mdz>that would explain why it seems to happen every time when deleting from playbackbox
23:05<mdz>or the playbackexitmenu
23:05<yebyen>Chutt: difficult to turn the commercial detection on, or is it a checkbox? (that's a dumb question, isn't it.)
23:06<Chutt>you hit Z when it's playing
23:06<mdz>is RECORDING_LIST_CHANGE sent asynchronously?
23:06<Chutt>if you're in a commercial
23:06<Chutt>and it'll skip it
23:06<Chutt>mdz, this issue is qt's sockets are all async
23:06<yebyen>Chutt: oh, it doesn't just automagically watch for commercials?
23:06<Chutt>and i'm attempting to use them sync
23:06<mdz>hmm
23:06<Chutt>so
23:06<yebyen>well, can't win em all :)
23:06<Chutt>that messes stuff up sometimes
23:06<Chutt>yebyen, it will eventually
23:07<Chutt>this stuff's just written :p
23:07<mdz>how is RECORDING_LIST_CHANGE supposed to work? does it poll to see if there is a message there?
23:07<yebyen>awesome :)
23:07<yebyen>well, it's revolutionary stuff :)
23:07<Chutt>mdz, in the context
23:07<Chutt>there's a function that listens for messages from the backend
23:08<Chutt>i think the easiest way to fix things is going to be to add another connection between the two
23:08<Chutt>for backend->frontend communication
23:08<mdz>seems sane
23:09<Chutt>should be pretty easy to accomplish
23:09<-- paperclip(~joe@ip68-11-30-173.no.no.cox.net) has left #mythtv ("grits.. they aren't just for breakfast anymore")
23:09<mdz>does more than one thread talk to the backend over the same connection? what happens if requests are interleaved?
23:10<Chutt>mutex locked
23:10<Chutt>the only problem comes when the backend sends a message to the frontend, really
23:14<mdz>another option would be to differentiate between a response and a backend-originated message
23:14<yebyen>blum blum
23:15<Chutt>there is
23:15<Chutt>well, kinda
23:15<yebyen>making a cygwin iso, minus apache, xfree86, tetex, lilypond...
23:15<mdz>like, when the frontend reads a message from the backend, it could tell from the message if it was the response, or some other event to deal with
23:16<Chutt>hmm
23:16<Chutt>i wonder how difficult that'd be to do
23:16<mdz>one way would be to have a sequence number of some sort
23:17<mdz>when sending a request, say "this is request #1234", and attach that id to the response
23:17<mdz>then requests could be interleaved too
23:18<mdz>like if there was a request which took a long time to process
23:18<Chutt>hmm
23:18<mdz>maybe overcomplicated though
23:18<Chutt>the current code's not setup to deal with getting a response back later
23:18<Chutt>could just preface each backend->frontend communication with an id of some sort
23:18<Chutt>just something like "BACKEND_MESSAGE"
23:19<mdz>yep
23:19<Chutt>hmm
23:19<Chutt>lemme get this website stuff done first =)
23:19<mdz>I can't think of anything the frontend would want to know that the backend would take a long time to answer anyway
23:19<Chutt>well, it would be a better architecture
23:20<Chutt>making it all async
23:20<yebyen>borrowing from UDP?
23:20<yebyen>heh
23:21<mdz>the sendreceive stuff could manage the pending requests
23:21<Chutt>if i stick an id in front of each backend->frontend message
23:21<yebyen>i do all of this fun OpenGL coding at school
23:21<yebyen>HEH
23:21<mdz>like, when a message is received, see if it's for us, if not, push it back and let the next guy look at it
23:21<Chutt>sendreceive could check to see if it's a message
23:22<Chutt>if it is, dump it into the event queue, then read the next stringlist
23:22<mdz>register clients waiting for responses like you have listeners
23:24<Chutt>thing is, most queries need a response immediately
23:25<Chutt>especially in the recording stuff
23:25<mdz>the event listeners are global, right?
23:25<Chutt>yeah
23:25<mdz>so when an event comes from the backend, everyone gets it?
23:25<mdz>(everyone listening)
23:25<Chutt>right
23:25<Chutt>and they determine what they want to listen to
23:26<mdz>maybe sendreceivestringlist could do the event processing then
23:27<mdz>if when reading its response, it gets something it can identify as not the response, dispatch an event instead
23:28<Chutt>that's what i'm doing right now, kinda
23:29<mdz>it looked like sendreceivestringlist would read whatever was waiting on the socket, and return it as the response
23:29<mdz>without looking at it
23:29<Chutt>yup
23:29<Chutt>i just inserted some code to check if the first string in the list was "BACKEND_MESSAGE"
23:29<Chutt>and dispatch it as a message if it was, then read the next stringlist
23:29<mdz>oh, you mean that's what you're _doing_ right now
23:30<mdz>I thought you were saying that was what the code did right now
23:30<Chutt>ah
23:30<Chutt>heh
23:30<mdz>I am not entirely clear-headed
23:30<Chutt>would you be able to test this a bit if i check it in?
23:30<mdz>better loop it if you aren't already; it could even get multiple backend_messages before the response
23:31<mdz>hmm
23:31<Chutt>like, 2 more minutes or so
23:32<mdz>if I could run the backend on my desktop it would be easy
23:32<mdz>hmm, I could run a frontend on my desktop I suppose
23:32<mdz>yeah, I think I can test it
23:33<mdz>I don't want to turn on the TV or test in the living room; I'm the only one awake
23:33<Chutt>ah
23:33<mdz>I have not figured out the logistics of sleeping yet
23:33<Chutt>little tender?
23:34<mdz>I'm concerned about the drooling factor
23:34<mdz>that too, but the meds take care of that
23:34<Chutt>just doing a test compile
23:34<Chutt>and i'll run things real quick to make sure it all works still
23:36<mdz>heh, this means I will have to compile mythtv
23:36<mdz>no header changes, though, right?
23:36<Chutt>right
23:36<mdz>I'll start building now
23:38<mdz>are you going to commit it or send me a patch to try first?
23:38<Chutt>i'll just commit it
23:39<Chutt>it's in now
23:40<mdz>this will be a little perverse. I'll be running the frontend + mysql + NFS server on this box, and the backend on the diskless box
23:40<Chutt>heh
23:40<bigguy>I wish I had the stuff here to setup a few diskless machines
23:41<mdz>wow, that guy ran setup *35 times*
23:41<mdz>(still compiling)
23:42<Chutt>of course
23:45<mdz>word on theora-dev is that monty is fixing libogg not to do any in-memory copying, to get decent performance for video
23:47<Chutt>ah
23:47<mdz>of course, that didn't come from monty
23:47<mdz>so who knows
23:49<mdz>hmm, frontend segfault
23:49<Chutt>heh
23:49<mdz>ah, my fault
23:50<Chutt>damn people using my net connection when i'm trying to use it too
23:50<mdz>the address in backend_settings.txt is what it sends to the frontend to connect to, right?
23:50<Chutt>yup
23:51<Chutt>for tv and playback of remote stuff, of course
23:52<mdz>ok, works now
23:52<mdz>so I guess I need to delete something
23:52<Chutt>you can always edit mainserver.cpp
23:52<Chutt>comment out the db delete and the unlinks
23:52<Chutt>it's what i do for testing =)
23:53<mdz>I was just going to add something to the table
23:53<mdz>with no file
23:53<Chutt>or that works too
23:53<mdz>heh, Error: File Missing!
23:54<mdz>it highlights it like it's in progress...how does it determine that?
23:54<Chutt>highlights what?
23:54<Chutt>it was red?
23:55<Chutt>oh, if the starttime has passed and the end time hasn't come yet
23:55<mdz>SendReceiveStringList: send: QUERY_CHECKFILE myth://192.168.0.59:6543/var/lib/mythtv/1090_20030225110000_20030225120000.nuv
23:55<mdz>SendReceiveStringList: receive: RECORDING_LIST_CHANGE empty
23:55<mdz>SendReceiveStringList: send: QUERY_RECORDINGS Play
23:55<mdz>SendReceiveStringList: receive: 1
23:55<mdz>offset is: 1 but size is 1
23:55<mdz>Received a: 10 message from the backend
23:55<mdz>But I don't know what to do with it.
23:55<mdz>Received a: RECORDING_LIST_CHANGE message from the backend
23:55<mdz>But I don't know what to do with it.
23:56<Chutt>running the same backend you just compiled?
23:56<mdz>heh, no
23:56<mdz>is that required?
23:56<Chutt>yea
23:57<Chutt>there was a backend change as well
23:57<mdz>that means another compile unfortunately
23:57<Chutt>to add the BACKEND_MESSAGE stuff
23:57<Chutt>sorry
23:57<mdz>I have the old qt libs on the other boix
23:57<mdz>were you ever able to reproduce this?
23:57<Chutt>not easily
23:57<Chutt>and not on demand
23:57<Chutt>i really don't know why
23:58<mdz>I don't think I could reproduce it on demand, but it happens a lot
23:58<Chutt>it should be pretty easy to trigger
23:58<mdz>do you delete from the playback dialog ever?
23:58<Chutt>yeah
23:58<Chutt>occasionally
23:58<mdz>weird
23:58<mdz>it would happen pretty much every time I did that