Back to Home / #mythtv / 2008 / 02 / Prev Day | Next Day
#mythtv IRC Logs for 2008-02-12

---Logopened Tue Feb 12 00:00:38 2008
00:07-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
00:08-!-xris [] has quit []
00:23-!-xris [] has joined #mythtv
00:27-!-xris [] has quit [Client Quit]
00:30-!-xris [] has joined #mythtv
00:35-!-djc__ [n=djc@] has joined #mythtv
00:37-!-djc_ [n=djc@] has quit [Read error: 110 (Connection timed out)]
01:05<Anduin>I'll save applying to release for tomorrow
01:05<hads>Sweet. Thanks Anduin
01:07<Anduin>I didn't change much, let me know if you see something I've broken. Oh, and thanks for getting it this far.
01:30-!-superm1 [n=superm1@ubuntu/member/superm1] has quit [Read error: 104 (Connection reset by peer)]
01:33-!-grokky [n=grokky@] has quit [Read error: 110 (Connection timed out)]
01:47-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
01:47-!-xris [] has quit []
02:07-!-JoeyBorn [] has joined #mythtv
02:11<Chutt>Anduin, merging stuff like that's fine.
02:11<Chutt>i would just expect things to be tested a _little_ more than if it was just trunk =)
02:11-!-jamesd [] has quit [Read error: 104 (Connection reset by peer)]
02:11-!-jamesd_ [] has joined #mythtv
02:20<hads>Yay :)
02:25-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
02:26-!-jhulst_ [n=jhulst@unaffiliated/jhulst] has joined #mythtv
02:33-!-jhulst__ [] has joined #mythtv
02:40-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Read error: 110 (Connection timed out)]
02:40<hads>Anduin: You could probably remove the bindings/python/build dir and svn ignore it.
02:44<Anduin>hads: done
02:44<hads>Cool :)
02:46-!-jhulst_ [n=jhulst@unaffiliated/jhulst] has quit [Read error: 110 (Connection timed out)]
02:48-!-foo8ar [] has joined #mythtv
02:48-!-jhulst__ is now known as jhulst
02:55-!-gnome42 [] has quit [Remote closed the connection]
03:23-!-grim[GameOp]_ [] has quit []
03:31-!-otwin [n=otwin@] has quit [Read error: 104 (Connection reset by peer)]
03:31-!-otwin_ [n=otwin@] has joined #mythtv
04:04-!-ahbritto [] has quit [Client Quit]
04:08-!-mykeul [n=mykeul@] has joined #mythtv
04:08-!-eharris_ [] has joined #mythtv
04:14-!-eharris__ [] has joined #mythtv
04:14-!-eharris [] has quit [Read error: 110 (Connection timed out)]
04:15-!-czth_ [n=dbrobins@nat/microsoft/x-869571cc761cd66f] has joined #mythtv
04:21-!-foo8ar_ [] has joined #mythtv
04:29<stuarta>um todays stupid question
04:29<stuarta>why is the branch called release-0-21-fixes and not release-0.21-fixes ???
04:30-!-czth__ [n=dbrobins@nat/microsoft/x-6fd654e301a3b240] has quit [Read error: 110 (Connection timed out)]
04:30-!-eharris_ [] has quit [Read error: 110 (Connection timed out)]
04:31-!-jhulst [] has quit [Read error: 113 (No route to host)]
04:31-!-mykeul [n=mykeul@] has left #mythtv []
04:31-!-mykeul [n=mykeul@] has joined #mythtv
04:34-!-foo8ar [] has quit [Read error: 113 (No route to host)]
04:35<canatella>hi. When developing with mythui, you don't need to mess around with signals and slots ? Just implement the virtual keyPressEvent method of MythUIType ?
04:44-!-eharris__ [] has quit [Read error: 104 (Connection reset by peer)]
04:47-!-eharris [] has joined #mythtv
04:49-!-grokky [] has joined #mythtv
04:52<justinh>canatella: look at mythappearance.cpp & mythcontrols for examples
05:07-!-eharris_ [] has joined #mythtv
05:12-!-MaverickTech [] has joined #mythtv
05:12-!-eharris [] has quit [Read error: 110 (Connection timed out)]
05:28-!-rtsai [n=rtsai@] has quit [Read error: 110 (Connection timed out)]
05:28-!-MavT [] has quit [Read error: 113 (No route to host)]
05:31-!-rtsai [] has joined #mythtv
05:34-!-beavis [] has joined #mythtv
05:41-!-grokky [] has quit []
05:48-!-otwin_ is now known as otwin
05:51-!-mattwire [] has joined #mythtv
05:59<Dibblah>Since we're heading towards release, has anyone run a few valgrind / etc tests on trunk?
06:05<rooaus>Dibblah: I have a serious leak in the frontend that exhausts swap (1G) and ram (1G) overnight. Does not seem to be a common problem though. Can't replicte the problem on my laptop though.
06:05<Dibblah>When you leave it at the main menu?
06:06<rooaus>Dibblah: yeah
06:06<Dibblah>Or is it the preview window again?
06:09<rooaus>Dibblah: Do you mean the video preview in watch recordings? I disabled the video preview anyway.
06:10<Dibblah>Yes, that's what I meant.
06:11<Dibblah>Are you doing anything funky with the network remote port?
06:11<Dibblah>Or the LCD stuff?
06:12<Dibblah>And are you absolutely sure it's the frontend - There is a known issue with backend preview generation.
06:12<rooaus>Dibblah: Nah, just a combined BE/FE without the LCD or any Network stuff, just using mythweb but rarely (if ever) use the recorded programs screen.
06:15<rooaus>Dibblah: Top shows "VIRT" for mythfrontend of around "1900M" IIRC.
06:22-!-zagibu [] has joined #mythtv
06:22-!-zagibu [] has left #mythtv ["Leaving"]
06:22<hads>I use telnet control a lot and don't see any leaks that I'm aware of.
06:24<stuarta>rooaus: have you done a complete distclean rebuild of everything?
06:24-!-_gunni_ [] has joined #mythtv
06:26<rooaus>stuarta: Yeah, even used svn-clean script on the WC, removes *all* non version controlled files, identical to a rm -rf && svn co
06:31<rooaus>I logged process usage for a few hours, it seemed that it was increasing every 74/75 minutes by around 64M. I think EIT scanning is disabled but I should check.
06:31<stuarta>that won't affect the frontend
06:31<stuarta>EIT scanning is a backend only process
06:32<rooaus>stuarta: Wouldn't have thought so but was running out of ideas, maybe the media monitor but not sure why?
06:33<stuarta>if you have cpu to spare run it under valgrind.
06:33<stuarta>bit painful, but it might help
06:36<rooaus>stuarta: I think I will valgrind it tonight, it seems to do it when it is idling at the main menu. I didn't have any luck on the laptop trying to replicate it.
06:37<stuarta>ask if you need any valgrind voodoo :)
06:37<stuarta>i have posted some voodoo to the -dev list before
06:37<stuarta>may have even ended up in one of the documents
06:40<rooaus>stuarta: I have your vodoo :) I think paulh linked to a mailing list post of yours about it.
06:40-!-|gunni| [] has quit [Read error: 110 (Connection timed out)]
06:42<rooaus>Just for kicks, I will post a smaps report from the other day. I can't say what rev it was, but it would have been only a few weeks old. I grabbed this just before I killed the frontend.
06:45-!-splat1 is now known as splAt1
06:45<janneg>backend was 2-3 weeks ago pretty clean in valgrind
06:46<stuarta>my backend graphs are flat now
06:59-!-MrGandalf [] has quit ["work"]
07:10<gbee>just fired up the frontend under valgrind
07:10-!-TelnetManta [] has quit ["Ex-Chat"]
07:10<gbee>not expecting to get anything useful though
07:10*stuarta watches gbee's laptop melt
07:18<gbee>well found a 1K leak in mythgesture, MythGesturePrivate isn't deleted when we destroy MythGesture
07:20<gbee>might be worth a few of us just clearing up these tiny leaks, if only so that the valgrind output is easier to read
07:22<GreyFoxx>holysh*t it works
07:22<gbee>settings stuff indicates a lot of leaks, but those seems to be mistakes in valgrind, stuff that is cleaned up elsewhere
07:23<GreyFoxx>now we can grab screenshots from the FE remotely
07:23<gbee>/MythFE/ << Shouldn't that be /Myth/ ?
07:23<GreyFoxx>that tied into mythweb using the telnet controls makes for a sweet little management console
07:23<GreyFoxx>gbee: Nope, a new controlurl since this is for FE controls only
07:24<justinh>what's with all this stuff for making themers lives easier ? =D
07:24<GreyFoxx>I can make them match of course, but for the moment I made them different
07:24-!-sphery [] has joined #mythtv
07:24<GreyFoxx>I have a global screenshot function added to mythmainwindow
07:24<GreyFoxx>and I have it mapped to a global key so now anywhere I hit ALT+F12 I get a screenshot
07:24<GreyFoxx>currently hardcoded to /tmp/moo.png
07:25<justinh>no more users moaning that they don't know how to take screenshots when asked to help report theme problems :)
07:25<GreyFoxx>Is there a way to properly define a true global key? Mine doesn't do anything if I'm in a plugin
07:25<gbee>does that work for video as well? Or should the screenshot function just call the existing video screenshot stuff when we're playing back video?
07:25<GreyFoxx>(but the httml method works everywhere since it's not using a keystroke)
07:25<GreyFoxx>justinh: yeah
07:25<stuarta>ah moo, great name for a file
07:25<GreyFoxx>gbee: I haven't tried it on a video
07:25<gbee>GreyFoxx: Global context keys should work everywhere
07:26<GreyFoxx>gbee: but there is another function for video screenshots we can use as well
07:26<GreyFoxx>gbee: hmm
07:27<gbee>GreyFoxx: yeah, that's what I was refering to, so if (playingvideo) {nvp->screenshot()} etc
07:27<gbee>actually, you probably just want to send an event, since you won't have access to nvp/tv from mythmainwindow
07:29<GreyFoxx>RegisterKey("Global", "SSHOT", "Take a Screenshot", "F12");
07:29<GreyFoxx>That looks right for defining a global key?
07:29<GreyFoxx>(I lateer changed it to ALT+F12 in mythcontrols since my mac was grabbing F12 on me)
07:30<GreyFoxx>It works in the menus and watch recordings,m but if I go in to the plugins it doesn't seem to get called
07:30<GreyFoxx>Sory let me rephrase
07:30<GreyFoxx>is there a better way to define a global key that calls a function without having to add it to every keyProcessEvent routine in each plugin ?
07:31<GreyFoxx>sorta like a jumppoint that just calls the function and dumps you can to normal no matter where you are when you call it ?
07:35*stuarta joins the valgrind party
07:36<gbee>ah, well Paul recently modified the jumppoints so that you could define one which doesn't move you from your current location, might be what you need
07:37<stuarta>dammit. why is the OSX build always failing when it tries to assemble libmythmusic...
07:37<GreyFoxx>gbee: That soudns perfect
07:38<gbee>he used it for the music mini player, so you can probably dig up the details from that commit or by looking at mythmusic/main.cpp for the jumppoint registration
07:39<GreyFoxx>yay, image scaling works too. So we can get "icon" screenshots
07:42<justinh>this playlist autoexpire thing couldn't have been this simple. can't wait to get home to try it out now
07:43<gbee>can't understand why valgrind is reporting some of these things as leaks, unless for all this time I've misunderstood something
07:44<stuarta>it has a tendency to do that
07:44<stuarta>it becomes a bit of an artform to decipher what is and isn't a leak
07:45<justinh>they make gdb output look like Janet & John eh? ;)
07:46<gbee>well there are cases where I can clearly see why valgrind has got it wrong, e.g. function returning a pointer to an object which is then parented to a new object and cleaned up when the parent is destroyed - valgrind can't follow that thread so assumes we leaked
07:48<stuarta>it also doesn't like static initalized data that never gets freed
07:51<gbee>libs/libmyth/mythmedia.cpp -- line 66, leak or no leak?
07:51<gbee>I would have said leak a few weeks ago but someone told me that I was wrong
07:52<gbee>still think it's good practice to get into the habit of calling delete on everything which was created with new, even if it's not necessary
07:53<stuarta>what donut named that variable fi
07:53<gbee>stuarta: QT docs use fi a lot, so whoever wrote that probably just copied it from there
07:53<stuarta>makes searching for use of the variable a bitch
07:54<stuarta>i can't see any delete *fi; anywhere can you?
07:55<gbee>doesn't exist, fi is local to that constructor so delete should be inside that function
07:56<stuarta>definitely a leak methinks
07:56*stuarta checks his valgrind logs
07:58<gbee>thought I was right, shouldn't have listened to what this guy was saying because he almost had me convinced
07:59<stuarta>==29731== by 0x7102044: MythContext::CacheThemeImagesDirectory(QString const&, QString const&) (mythcontext.cpp:2243)
07:59<stuarta>==29731== by 0x71025EE: MythContext::CacheThemeImages() (mythcontext.cpp:2172)
07:59<stuarta>==29731== Address 0x421926b is not stack'd, malloc'd or (recently) free'd
08:03<gbee>any objections to this patch for mythmedia then?
08:04<stuarta>looks good to me
08:04<stuarta>although what is the failure condition the null pointer check is looking for?
08:06<gbee>there isn't one
08:07<gbee>if the file doesn't exist we will still return an instance of the class instead of a null pointer
08:07<gbee>you have to test for the files existance with fi.exists() if you want to be sure it's there
08:08<stuarta>well in that case the null pointer check is stupid, and it's definitely a leak
08:12<gbee>committed two fixes to trunk, will move them over to fixes when I'm happy that I've fixed all the leaks I can find
08:12<gbee>would be nice if you could ask valgrind to ignore all leaks under 1k
08:14<gbee>valgrind suggests that all the FREQ macro calls in frequencytables.cpp are leaking, and together they would add up
08:15<gbee>think I've pointed that one out before, but someone, either janneg or danielk22 said that valgrind was wrong
08:16<gbee>I can't see where we're iterating through freq_table_map_t to delete those objects
08:17<stuarta>we don't delete it
08:17<stuarta>it's just statically allocated
08:18<stuarta>so it won't grow or shrink
08:18<stuarta>(last time i remember discussing it)
08:20<gbee>ok, think I need to refresh my memory on c++ memory handling
08:27<gbee>from looking at the code it it seems to me that we'd leak that memory, it's not going to cause a growth in memory but we'd lose it every time you started/closed mythfrontend - but like I said, my memory is a little hazy on these issues and I probably need to go back to the books
08:27<justinh>I read a little bit about it the other night. bored me to tears
08:30<gbee>huh? mythfrontend will no longer update the database?
08:31<gbee>makes sense I suppose, but what if I'm not running a backend?
08:32<justinh>if you don't run a backend you become annoyed by all the 'could not connect to backend' popups ;)
08:34<gbee>justinh: only on things like the watch recordings screen, if I just used mythfrontend for mythmusic/mythvideo etc then I wouldn't need a backend (some people do use mythtv this way because they don't have any tuners)
08:34<janneg>gbee: mythfrontend -u
08:34<gbee>janneg: cheers
08:35<justinh>gbee: and exiting mythfrontend
08:35<gbee>now that you've mentioned it, I remember the commit message
08:42-!-BleedAway [] has quit [Remote closed the connection]
08:43-!-czth__ [n=dbrobins@nat/microsoft/x-6fe8ecaf57275738] has joined #mythtv
08:57-!-Merlin83b2 [] has joined #mythtv
08:59-!-czth_ [n=dbrobins@nat/microsoft/x-869571cc761cd66f] has quit [Read error: 110 (Connection timed out)]
09:01<gbee>hmm, can see the new database backup stuff causing problems for my combined fe/be, if I restart the maching after upgrading then the backend will be busy creating the backup and the frontend won't start because it's expecting the new schema
09:23*gbee raps himself on the knuckles for causing one of the mem leaks
09:25<gbee>two thirds of the reported mem leaks in mythfrontend are in frequencytables.cpp - whether or not it actually leaks, it's cluttering up the valgrind report so I'll take a look at it
09:25<jams>3x3 menu support works! time to take blue for a walk.
09:25-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:26<Captain_Murdoch>gbee, I'll take a look at that the combined FE/BE issue. perhaps we can move the shemalock lock up before the backup and test for that in the frontend and if it exists, we can loop for a little while waiting for it to go away.
09:27-!-afm [] has joined #mythtv
09:27-!-afm [] has left #mythtv []
09:28<gbee>Captain_Murdoch: that would be good, I don't consider it a serious problem but definately inconvenient
09:28<gbee>jams: 3x3 menu?
09:29<jams>oop 3 rows 2 columns
09:29<jams>help if i could count =)
09:29<gbee>still clueless :)
09:30<jams>taking screenshots of the blue theme
09:30<gbee>ahh, yeah, I remember you saying now that it had trouble navigating those menus?
09:31<Captain_Murdoch>gbee: yeah, I think that will be trivial to implement so I'll take a look.
09:31<jams>yes, the navigation is different between 2x3 and 3x2 and vertical.
09:52-!-SpeedEvil [n=mauve@tor/regular/SpeedEvil] has joined #mythtv
09:53-!-SpeedEvil [n=mauve@tor/regular/SpeedEvil] has left #mythtv []
10:05-!-jgarvey [] has joined #mythtv
10:26<GreyFoxx>gbee: That REG_JUMPEX stuff used in mythmusic works to let me execute my stuff from everywhere
10:26<GreyFoxx>1 problem is that if I do it from outside a plugin my jumppoint gets called once.... if I do it from inside a plugin such as mythvideo it gets called 3 times ?
10:27<jams>so it takes 3 captures?
10:27<GreyFoxx>at the moment I have it writting to a hardcoded filename
10:27<gbee>odd, can't explain that but it sounds like a bug
10:27<GreyFoxx>it's consistant, only happens in plugins
10:28<GreyFoxx>but otherwise webgrabbed screenshots and scaling work, and the jumppoint grab works
10:28<gbee>I'd ask Paul
10:28<GreyFoxx>video playback is just the blank/XV screen, but I'll look at the other video screenshot code and tie into that if we happen to be in playback at the time
10:28-!-cattelan [] has quit ["This computer has gone to sleep"]
10:29<GreyFoxx>then I suppose I shouldlet users define the directory/name to save screenshots and make it smart enough to increment then by 1 if they take multiple
10:32<GreyFoxx>now just to integrate this into the mythweb remote
10:32<jams>can't wait to try it, it should be a drop in replacement for my snap command.
10:34<GreyFoxx>though I have not done much more than a bare look at mythweb so that part might take longer than the screenshot code itself took heh
10:35<GreyFoxx>(6548 is a port forward from my office desktop past my home firewall to 6547 on the FE I'm working on )
10:48-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit [Remote closed the connection]
10:48-!-MrGandalf [] has joined #mythtv
10:49-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
11:10-!-foo8ar_ [] has quit []
11:50-!-mykeul [n=mykeul@] has left #mythtv []
12:09-!-xris [] has joined #mythtv
12:09-!-xris [] has quit [Read error: 104 (Connection reset by peer)]
12:09-!-xris [] has joined #mythtv
12:10-!-xris [] has quit [Client Quit]
12:10-!-canatella is now known as canZzZz
12:14*gbee checks out the 0.21-fixes branch
12:15<Anduin>You can use svn switch
12:17<gbee>really? Didn't know it could be used that way, thought it was just to change the path of the repository
12:17<beavis>svn switch 0.21-fixes <- this way?
12:17<gbee>guess I'll check out the docs
12:17<Anduin>You need the full url, I just did it, cp -r my trunk copy, svn switch svn+ssh://etc
12:18<justinh>what difference does doing that make though?
12:18<Anduin>saves time
12:19<Anduin>There are only a handful of differences between trunk and release currently, so minimal files transfered
12:19<justinh>ahh I spose it only gets the differences between them
12:19<gbee>looks a lot faster than a complete checkout
12:19<beavis>these python bindings only I guess
12:20<justinh>I can live with the stuff I'm playing with not making it into 0.21
12:20<Anduin>There are other changes, and the bindings will make it to release soon
12:20<stuarta>oh wtf won't it build on OSX
12:23<gbee>whole lot of mythweather changes, a few ticketed bugs to be fixed
12:23-!-foo8ar [] has joined #mythtv
12:24-!-sphery [] has quit [Remote closed the connection]
12:24<stuarta>arse. OSX build is always dying around the libmythmusic link
12:24-!-sphery [] has joined #mythtv
12:27-!-mzb [] has quit [Read error: 113 (No route to host)]
12:29-!-gnome42 [] has joined #mythtv
12:29-!-catinpan is now known as catinpan_away
12:29-!-catinpan_away is now known as catinpan
12:32<gbee>janneg: just noticed a thread on linux-dvb which seems to be about the same bug I was seeing with the second tuner failing after those patches were applied
12:34-!-onyxsoft [] has quit [Read error: 110 (Connection timed out)]
12:35-!-onyxsoft [] has joined #mythtv
12:35-!-MrGandalf [] has quit [Read error: 110 (Connection timed out)]
12:35<gbee>actually at least three threads, though not a lot of dev response and no-one has explicitly connected the problem to that patch
12:37-!-Dave123 [] has quit [Read error: 110 (Connection timed out)]
12:38-!-Dave123 [] has joined #mythtv
12:38<gbee>looks like I might have to start subscribing to the list :/
12:39<mattwire>gbee: any idea how much work would be required to write a mythprogressdialog replacement for mythui?
12:43<stuarta>4641 is interesting, not sure about the delete pat in mpegtables.cpp
12:45<gbee>mattwire: not much, might make it one of the first things I do for mythui after I've finished working on fixes for 0.21
12:49*justinh laughs. the author of the c++ book I found on my desk last week went on to write a book on why c++ is evil
12:51<gbee>heh, wonder what he advocates instead
12:51-!-mykeul [] has joined #mythtv
12:52<justinh>python, ruby...
12:54<stuarta>those languages suck
12:54<stuarta>who wrote it?
12:55<justinh>russel winder
12:55<justinh>remembered how it ended up on my desk. I was going to be groomed to become a softie when I joined here but was hijacked for other things
12:56<justinh>what use c++ would be on a realtime OS based on Nucleus in C would have been is anybody's guess
12:57<stuarta>even the concept is wrong
12:59-!-mattwire_ [] has joined #mythtv
13:00-!-mattwire [] has quit [Read error: 113 (No route to host)]
13:01<gnome42>stuarta: Hiya! Looking at that delete PAT. It kinda looks sane to me ... if we return 0 there and don't delete the PAT, we won't have a handle for the newly created PAT and will leak that memory?
13:03-!-lcase [] has joined #mythtv
13:03-!-TelnetManta [n=benwilli@] has joined #mythtv
13:06<stuarta>gnome42: hiya, it's quite possibly valid. i'd have to do fair bit of reading to decide for sure
13:09<gnome42>Yeah, it's not a big deal. I can't recall ever seeing that error message.
13:11-!-Merlin83b2 [] has quit [Read error: 104 (Connection reset by peer)]
13:16<gbee>think I'll do some more valgrinding of the frontend
13:18<gbee>might try valgrinding the stuff we don't normally look at like mfdb, mtd, mythlcdserver and mythtranscode too
13:32-!-xris [] has joined #mythtv
13:32<gbee>xris: what do you think of quicksilver? Any good?
13:33<xris>gbee: I love it
13:33<gbee>if the answers yes, then sure, I'm could be the bloke who wrote it (nobody knows what he looks like, do they?)
13:34<xris>different stuart morgan, or you just interested in it?
13:34<gbee>I had to google just to find out what Quicksilver was and I don't even own a mac
13:35<gbee>different Stuart Morgan - of course I'm the original, the rest are just wannabes ;)
13:36<xris>it's a slick app nonetheless... someone should write one for linux/windows
13:41-!-nordenm [] has quit []
13:43<gbee>danielk22: are we leaking db_vdisp_profile (VideoDisplayProfile()) in videooutbase.cpp ?
13:44<gbee>*sigh* why does the news of a release suddenly mean everyone submits the patches they've been sitting on for months?
13:44<stuarta>that's why it's a release *candidate*
13:45<stuarta>did i miss the actual announcement? haven't seen it
13:46<Anduin>It would be nice to have an official announcement, and maybe a call for translators.
13:46<gbee>haven't made one, but anyone following the commits list will know by now
13:47<stuarta>that's a good thing
13:47<stuarta>anyone following -commits should at least have a half decent idea about programming
13:47<stuarta>or possibly vague
13:47<gbee>I'm just amused that people don't bother to submit patches until they are pushed to do it
13:47<stuarta>as opposed to none
13:48<stuarta>guess that's why we need to release more often
13:49*stuarta needs food
13:49-!-fuhgawz [] has joined #mythtv
14:01<gbee>think a few other people should get involved in valgrinding, I'm finding what look like genuine leaks but I need a second opinion
14:02<gbee>xvmc_buf_attr < in videoutput_xv.cpp ? Should probably be deleted in VideoOutputXv::DeleteBuffers()?
14:02<stuarta>can't help there. nov xvmc around here
14:02-!-nordenm [] has joined #mythtv
14:08-!-beexwax [] has joined #mythtv
14:15<gnome42>gbee: I don't have xvmc around here either. But I would guess that deleting xvmc_buf_attr in the destructor is slightly better because xvmc_buf_attr is allocated in the constructor not in CreateBuffers().
14:16-!-MrGandalf [] has joined #mythtv
14:18<gbee>gnome42: fair point
14:19<gbee>I'm still not sure if it needs deleting though, someone more familiar with the videooutput code might though
14:21-!-fuhgawz [] has quit [Read error: 110 (Connection timed out)]
14:21-!-beexwax is now known as fuhgawz
14:36<danielk22>gbee: leak in videodisplayprofiles?
14:38<jams>danielk22- wanted to thank you for commiting that settings change to allow dynamic help. That really helped me out.
14:38<danielk22>jams: you're welcome :)
14:39<gbee>an instance of VideoDisplayProfile is created in VideoOutputBase and referenced by the db_vdisp_profile pointer, but doesn't seem to be deleted
14:40<gbee>I'm playing around with valgrind on the frontend and there are a couple of reported leaks in the VideoOutput classes which I'm not sure about
14:40<danielk22>yep that appears to be a leak
14:41<gbee>the other is xvmc_buf_attr in videoutput_xv
14:41<danielk22>that one looks like a valid leak as well
14:41-!-cattelan [] has joined #mythtv
14:43<gbee>most of the leaks reported are erroneous, checking them all out is slow and tedious :)
14:45-!-cattelan [] has quit [Client Quit]
14:46<gbee>I'll fix those two then, they are only tiny but a leak is a leak
14:46<stuarta>backend is nice and stable these days
14:47<gbee>wish valgrind reported the line numbers accurately
14:49<stuarta>generally does
14:58<xris>GreyFoxx: so you got screenshot stuff working?
14:59<xris>does it work while playing video, too?
15:02-!-trisooma [n=remko@] has joined #mythtv
15:03<gbee>stuarta: in about 50% of cases the line numbers are between 10 and 30 lines out - think it's ignoring the headers
15:09<stuarta>only time i've seen that is when source != binary
15:09<GreyFoxx>xris: Works great. ALT+S anywhere in myth gets a shot, and a webcall where you can specify width/height too
15:09<GreyFoxx>video playback however is anothermatter. I'll look at pulling the screenshot stuff Anduin put in for during playback
15:10<GreyFoxx>but it looks like if you use the OpenGL renderer it will get the video+osd
15:10<GreyFoxx>It's just XV that wont
15:10<xris>yeah, I think the current screenshot stuff actually pulls straight from the video
15:10<GreyFoxx>yeah it does
15:10<Anduin>GreyFoxx: think that was bjm
15:10<xris>web call to the frontend?
15:10<GreyFoxx>Anduin: ahh ok, I thought it was you
15:10<GreyFoxx>xris: yup
15:11<justinh>ugh. gonna take most of the night to build a recent svn up
15:11<GreyFoxx>xris: I added a new upnp extension tothe frontend for it
15:11<GreyFoxx>Gonna add another method for grabbing window info and other stuff too
15:12*xris curses the unstable firewire stuff
15:12-!-davilla [n=davilla@] has joined #mythtv
15:13<xris>I wonder if it's the card, mythtv, or the cable boxes
15:13<GreyFoxx>xris: Mine works perfectly
15:13<GreyFoxx>I have had maybe 2 glitches in months
15:14<GreyFoxx>Though I expect I'll be stressing it more soon
15:14<GreyFoxx>with the new projector and tv coming this week
15:14<GreyFoxx>so I'll be recording for HDTV
15:15<xris>probably 3/4 of my recordings fail
15:15<xris>zero bytes
15:15<xris>or big patches of messed up data
15:16<xris>sometimes when myth tries to start a recording, the cable box changes to the wrong channel (lately it powers off/on instead), and I get a zero-byte file
15:16<GreyFoxx>What kind of stb ?
15:16<xris>motorola 6200 or whatever it is
15:16<GreyFoxx>hmmm same here
15:17<GreyFoxx>different firmware maybe ?
15:17<xris>I'm sort of wondering if the comcast OS upgrade a few months back changed something to do with the IR codes.
15:17<GreyFoxx>Are you using a blaster ?
15:17<xris>but I was under the impression that the IR codes were just issued over firewire to control it
15:17<xris>or something like that
15:17<GreyFoxx>I thought it was actualy dv1394 defined commands
15:17<GreyFoxx>but I haven'tread that bit of code
15:18<justinh>seems I had a modified viewscheduled.cpp stored in my checkout. wonder wth I was up to in there
15:18<justinh>ahh now I remember
15:22<xris>GreyFoxx: I think it's probably time that I test things with a different firewire card. I *think* that the PCI slot in my machine is available.. (only one PCI slot on this new machine -- everything else is PCIe)
15:29<Cardoe>xris: GreyFoxx: it's actual dv1394 codes, not IR codes
15:33<xris>Cardoe: thx.. so not that, then. either something's screwed up in the myth code (unlikely because greyfoxx's stuff works), my firewire driver, my firewire card, or the cable box
15:34<Cardoe>xris: well there are two different ways to send the codes afaik
15:34<Cardoe>I don't know how MythTV handles that
15:34<Cardoe>but the 6200ch has a command line option for it
15:34<Cardoe>I believe
15:35<Cardoe>basically send the whole number or individual digits
15:35<Cardoe>might be worth it to try the command line program
15:35<xris>well, whatever it is, it's not just the channel change stuff.
15:36<gbee>danielk22: any thoughts on the stuff in frequencytables possibly leaking? Though fmap is static and therefore on the heap, the pointers it contains point to objects which may be on the stack? I'm not sure what actually happens in the case of a static map containing pointers to objects. but valgrind thinks we're leaking those ~480k+
15:36<xris>zero-byte recordings are common... and seem to be more and more common the longer I go between reboots (both mythbox and cable boxes, or things get really screwed up)
15:36<Cardoe>well that's normal, unless you're using the external stabilization script
15:37<Cardoe>basically setting broadcast and trying some packets across then setting p2p
15:37<danielk22>gbee: I'm not terribly worried about it... this is really only used by the channel scanner..
15:38<danielk22>memory leaks in the frontend and backend worry me more than ones in mythtv-setup..
15:39<gbee>danielk22: I'm valgrinding the frontend and that's what is reporting the frequency tables stuff leaking
15:40<stuarta>i've seen that before too
15:42<gbee>if we want to ignore it for now, that's fine by me, I'll concentrate on the others for now
15:42<janneg>I've looked at it couple of months ago and came to the conclusion that it doesn't leak, but I don't remember why
15:43<stuarta>i seem to remember it's because it's allocated once and that's it
15:45<gbee>I stuck in a debugging statement to the FrequencyTable destructor just for the fun of it, but didn't see any output (not sure it's significant)
15:46<Anduin>gbee: It isn't, it will never be called, but that will only happen when libmythtv is unloaded (currently only done when a program is exiting)
15:46-!-mattwire__ [] has joined #mythtv
15:47<gbee>Anduin: yeah, know that - I exited but whether cerr will still output that late into the program execution I don't know
15:47<stuarta>often not
15:47-!-mattwire_ [] has quit [Read error: 110 (Connection timed out)]
15:48<Anduin>gbee: Sure, but there is no way for the dtor to be called anyway
15:48<stuarta>it will be output, but whether it makes it out of the stdout,stderr buffer is a different question
15:48<gbee>if both janneg and stuarta think it's fine, then I'll accept their opinions, greater minds etc
15:48<Anduin>You would need some ugly thing like QPtrMap
15:49<stuarta>gbee: it still disturbs me to see it valgrind, but i can't see it leaking
15:50<Anduin>It does leak, it is just at the end of the program, you were never going to see that memory again anyway.
15:50<danielk22>when a program exits, it does not normally run all the dtors, this would take too long..
15:50-!-saucisson [] has joined #mythtv
15:51<Anduin>Some programs choose to exit early, but C++ requires them to run (the order across modules isn't defined though)
15:52-!-dekarl [] has joined #mythtv
15:54<danielk22>anduin: really? Even java doesn't require dtors to run, and I've never seen a C++ program do it for statics without magic..
15:55<Anduin>danielk22: Yeah, there is a lot of junk done atexit() to make sure statics are destroyed. Ugly trick like TerminateProgram used to be used in a certain C++ compiler to make the exit time seem fast.
15:56<Anduin>In this case it doesn't actually make a difference though, QMap would never delete the contents anyway.
15:56<gbee>glad I brought it up anyway, it's educational at least :)
15:57<gbee>we might replace it with something like QPtrList with autodelete on, or just iterate over the map - but if the dtor isn't run then we wouldn't have the opportunity to do that anyway
15:58<gbee>I think the best point and one which I didn't really consider is that there is little point fixing a leak which occurs at program termination anyway
15:58-!-kahrytan [] has joined #mythtv
15:58<Anduin>or a container safe smart pointer to hold, or just stop newing them and suck up the copy cost.
15:58-!-kahrytan [] has left #mythtv ["Leaving"]
16:00<gbee>if the frequency tables are only used in mythtv-setup, is there an alternative to making them static which means we aren't wasting that memory with mythbackend/mythfrontend/mythfilldatabase/mythtranscode etc (if you call half a meg waste)
16:01<stuarta>fancy surgically removing it from libmythtv?
16:01<danielk22>it could be a singleton that is only created when needed...
16:01<danielk22>It really takes half a meg though?
16:02<stuarta>according to valgrind it does
16:02<gbee>danielk22: I'm suprised and a little dubious of the figure, but that's what valgrind reports
16:02<danielk22>*shrug* I guess we have a lot of tables in there?
16:03<gbee>it's not that important, maybe just something to look at again on a rainy day
16:03<janneg>yeah, the macros let it look pretty small
16:07-!-ahbritto [] has joined #mythtv
16:21-!-mykeul [] has quit ["Leaving."]
16:23<gbee>think I'll have to try removing that alsa muting patch to see if it's reponsible for the audio being randomly muted when I try to watch a recording/dvd
16:28-!-MrGandalf [] has quit [Remote closed the connection]
16:30-!-fuhgawz [] has quit [Read error: 110 (Connection timed out)]
16:36-!-renatofilho^_ is now known as renatofilho
16:36<justinh>Anduin: at the rate my dev box is compiling you might be better doing the change to blootube if you want it done today ;)
16:37-!-renatofilho is now known as renatofilho^_
16:37<Anduin>justinh: Oh no, no rush :)
16:38<justinh>Anduin: just as well :)
16:38<Anduin>Not building myth on the machine I ran it on was one of the best things I ever did.
16:39<justinh>I need to sit down & think about that one day soon. or just get a decent dev platform
16:39<Anduin>Yeah is it nice to go from nothing to done in about 10 minutes.
16:39<justinh>wouldn't care but even ccache isn't helping with all the major lib changes of late
16:42-!-lcase [] has quit []
16:43<justinh>anyway might aswell ponder some things while I'm waiting. like whether there's any existing containers/windows I can re-use for my expiry list idea
16:43<justinh>would that be ok btw? instead of creating a new window in ui.xml - to re-use one if it fits the bill?
16:45<justinh>maybe a new context for the playback window.. if groups can be got out of the way
16:46-!-TelnetManta [n=benwilli@] has quit ["Ex-Chat"]
16:46<justinh>nah. something more along the lines of upcoming recordings would do better
16:49<justinh>gbee: can you remember what I was babbling on about last week that'd be a 'nice exercise' ? can't recall what it was. sometimes I just say stuff when an idea comes to me & I forget it
16:50<gbee>well one of them was moving the autoexpire list out of the status page
16:50<justinh>heh that's one I had last night - still fresh & now written down ;)
16:51<gbee>oh, that's the one you are talking about -heh
16:51<gbee>sorry, was AFK
16:51<gbee>can't remember right now, might come back to me later
16:52<justinh>was something about possibly making the mythui porting easier by combining/rationalising stuff. maybe it was trying to make more of ui.xml common
16:53<justinh>aha! I can look in the logs. if I can find em
16:53<gbee>well we were talking with skamithi about reusing existing windows, at the time you were rationalising fonts
16:54<justinh>can't remember the login detail though. that'd be in the log too :P
16:54<justinh>must also look into logging on my own box
16:59<janneg>Chutt: trac misses some commits. [15917] and [15951] for example
16:59<justinh>ahhh.. "<justinh> come to think about it, 2 or 3 (or even 4) areas in ui.xml could be merged into one.". memory not so bad after all
17:00<janneg>reference ticket weren't updated
17:01<gbee>it was being a bit slow just now, I was receiving trac generated emails out of sequence
17:04-!-mzb [] has joined #mythtv
17:09-!-grokky [n=grokky@] has joined #mythtv
17:16<janneg>Chutt: happened again with [15961]
17:17-!-mzb [] has quit [Read error: 104 (Connection reset by peer)]
17:18-!-richards [] has joined #mythtv
17:18-!-mzb [] has joined #mythtv
17:21-!-Anduin [] has left #mythtv []
17:25-!-Bukwheat [] has quit ["leaving"]
17:29-!-Anduin [] has joined #mythtv
17:33-!-czth_ [n=dbrobins@nat/microsoft/x-2adf3582802627ef] has joined #mythtv
17:34-!-bio_ [] has joined #mythtv
17:35-!-dekar1 [] has joined #mythtv
17:39<gbee>previewgenerator headers could be cleaned up, sys/types.h and sys/stat.h both appear twice
17:42-!-dekarl [] has quit [Read error: 145 (Connection timed out)]
17:48-!-grokky [n=grokky@] has quit [Read error: 110 (Connection timed out)]
17:50<Chutt>janneg, looks like the email just didn't go otu
17:54-!-czth__ [n=dbrobins@nat/microsoft/x-6fe8ecaf57275738] has quit [Read error: 110 (Connection timed out)]
17:59-!-jgarvey [] has quit ["Leaving"]
18:01-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:04-!-beavis [] has quit ["Verlassend"]
18:08-!-leprechau [] has quit [Remote closed the connection]
18:10<xris>GreyFoxx: anything special to do to turn on upnp in the frontend?
18:14-!-trisooma [n=remko@] has quit ["Enuff for today"]
18:16-!-MavT [] has joined #mythtv
18:17-!-richards [] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.8/20050624]"]
18:19<Anduin>The hard part is turning it off
18:27<justinh>finally! I can test my new idea
18:29-!-imperfect- [] has joined #mythtv
18:29-!-MaverickTech [] has quit [Read error: 110 (Connection timed out)]
18:30<imperfect->Any developers now what cause this error when launching the front end:2008-02-02 10:42:29.302 Switching to square mode (Iulius)
18:30<imperfect->mythfrontend: Fatal IO error: client killed
18:30<imperfect->Mutex destroy failure: Device or resource busy
18:42<justinh>blimmin typo in my patch. wanted to disable autoexpire not enable it. derr
18:42<justinh>that menu is maybe looking a bit big now though :-\
18:46-!-leprechau [] has joined #mythtv
18:49<justinh>maybe this'd be better in the new expiry list screen I've thought about
18:50<justinh>any thoughts?
18:56-!-knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has joined #mythtv
18:56-!-|gunni| [] has joined #mythtv
18:57<justinh>maybe this'd tie in with another idea I had about a confirmation dialog about deletion - i.e. have one delete button in the playlist options menu and say "no, keep it - yes, delete - yes delete & allow re-record" as a confirmation instead
18:59<justinh>hmmm or there's plenty room in the recording list menu. maybe a playlist playback entry & a playlist operations entry instead...
19:01<justinh>without disable autoexpire there are already 9 menu items in playlist options - maybe that's too many already
19:04<gbee>any ideas why I might be ending up with a blue tinted image when grabbing a frame through "GetCurrentFrame()" in NVP?
19:04<gbee>videoOutput->GetLastShownFrame() << Blue Tinted, videoOutput->GetLastDecodedFrame() << Fine
19:05<justinh>gbee: driver output methods?
19:07<gbee>nah, something else, might be that the one frame has been converted to another format before I'm receiving it
19:08<justinh>gbee: got a shot? might be the colour channels mixed up
19:08-!-TelnetManta [] has joined #mythtv
19:09<justinh>sounds like the frame is in the wrong format but how it ended up that way - now that's the question
19:09<gbee>justinh: I think that's it, just checking to see if I can use GetLastDecodedFrame() instead
19:09<justinh>I dunno what to do with this thing for the best. feel like I've opened a can of worms again
19:10<gbee>justinh: may be that we change the colour format so "decodedframe" is "shownframe" but in a different format for display
19:10<justinh>big lists of menu items are bad, but submenus & submenus aren't that much better
19:11<justinh>gbee: I'd only be speculating but that sounds like what happens
19:12<justinh>and then I'm only saying that because of having to use the ATI hack in videooutputxv.cpp once
19:13<justinh>hmmm splitting up the playlist menu wouldn't be too much work. options for playback, options for operations. no harm in patching it up & taking it for a test drive soon
19:14-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
19:15<gbee>heh, no, I think the problem is that I was using LastDecodedFrame with using_null_videoout but in the later stuff I was trying to grab the frame as decoded for XV - so I just need to figure out what format XV uses and convert accordingly
19:16-!-Dorward_ [n=Dorward@] has joined #mythtv
19:18-!-cesman [n=cecil@pdpc/supporter/sustaining/cesman] has joined #mythtv
19:18<cesman>howdy folks
19:18<justinh>hey cesman
19:19-!-MrGandalf [] has joined #mythtv
19:19<cesman>I've been contacted by a company looking to create a set-top box
19:19<cesman>hi justinh
19:19<justinh>very tempted to send out a -dev list mail to ask opinions on this menu issue but I've been there before
19:20<justinh>ach to heck. I'll do it, see what folks think. not much work either way
19:20<cesman>they would like to use MythTV/KnoppMyth and have a need for a VOD plugin and a means to register users thru the current web interface
19:20<cesman>if any one is interested in discussing this, please PM me
19:21<justinh>cesman: funny, somebody was talking about that on the -dev list a while back
19:21<justinh>maybe not the same company
19:21<Anduin>cesman: televid?
19:21<cesman>Anduin: yes
19:22<Anduin>cesman: Robert K forwarded something, I don't know if anyone took it up.
19:24-!-Dorward_ [n=Dorward@] has left #mythtv []
19:25-!-imperfect- [] has left #mythtv []
19:27-!-grokky [n=grokky@] has joined #mythtv
19:29-!-|gunni| [] has quit ["KVIrc 3.2.4 Anomalies"]
19:29-!-Anduin [] has left #mythtv []
19:29-!-davilla [n=davilla@] has left #mythtv ["Leaving"]
19:32-!-Anduin [] has joined #mythtv
19:32<gbee>I might have to admit defeat on this, digging myself a hole :( I assume that the colour/frame format is going to vary depending on the video renderer, so I can't just use one value and stick to it - I need a way to get an RGB image from the current video frame and I don't know that the methods exist in videooutput to make that possible
19:37-!-mattwire__ [] has quit ["Leaving"]
19:44<knowledgejunkie>Does recording conflict resolution in current head allow a user to choose 'Never Record' in addition to 'Don't Record' to mark the programme to never record, as is possible for non-conflicting programlist entries?
19:50<xris>Anduin: those python libs seem to build even without --with-bindings
19:50<xris>maybe I need a --without-bindings to disable them (for packaging)
19:50<hads>Don't the Perl binding build by default too?
19:51<xris>hads: I think they do... maybe I haven't updated my spec properly
19:52<xris>yup, I need to update my spec
19:54<xris>now to figure out why they're not getting added to the spec
19:55<Anduin>Yeah, I almost defaulted the python stuff to off, less vital at this point than the perl stuff
19:56<hads>Shouldn't do much harm having it on though.
19:56<danielk22>gbee: there is no way to get an RGB out of videooutput that will always work. Some renders, like xvmc and dvdv just don't provide a method to see the final rendered image.
19:57<xris>Anduin: yeah, but might as well have all of the bindings on by default
19:57<xris>less hassle for users later
19:58<danielk22>gbee: BUT you can get any frame from the NVP using GetScreenGrabAtFrame()
19:58<gbee>danielk22: only on stuff we aren't currently playing though right?
19:58<danielk22>gbee: The NVP opens the file again using a separate decode..
19:58<danielk22>gbee: no it works if we're currently playing the video..
19:59<danielk22>you just create another NVP instance
19:59<gbee>yeah, won't work in this case - that was my first attempt, I'm trying to get a frame/screen grab from a DVD and there is no way to reliably jump to the exact same frame
20:00<danielk22>in that case it won't work :(
20:03-!-davilla [] has joined #mythtv
20:05<xris>wow... mythtv actually asks if you want to upgrade the db now
20:05<justinh>oh ffs got missing images in blootube
20:05<gbee>what format is the processed XV image anyway? I wouldn't mind getting this working at least with XV even if I can't get it back into mythtv later
20:08*xris kicks macos mythfrontend compile problems
20:09<danielk22>gbee: it is in either YUV, YVU, with the stride(pitches) and buffer offsets that you see in frame.h
20:09<gbee>danielk22: ok thanks
20:09<justinh>Anduin: got the filter in blootube sorted out now. need to do the rest I guess. oh I love maintenance me :)
20:11<danielk22>OSDSurface::BlendToARGB() should give you the needed info for converting to RGB, or you can use one of the ffmpeg functions..
20:12<gbee>I've already modified the preview generator so that it can be used to automatically grab a screenshot of the DVD menu in 95% of cases - I was hoping to implement a screen grab option which would allow the user to create their own image for the other 5%
20:13<gbee>eventually it might have ended up in mythvideo for getting preview images for videos/dvd and it still could, but that 5% of cases where we end up grabbing a blank frame spoil it ;)
20:14<justinh>wow the breakage in here - either nobody uses filters in these themes or nobody running trunk uses them
20:16<hads>Anduin: has some dodgy whitespace at lines 84 and 94 failing compilation.
20:17<Anduin>hads: Still? Thought I cleaned that out.
20:17<justinh>Anduin: blootube & ProjectGrayhem are up to speed
20:17<Anduin>may want to check again, make sure you are updated
20:18<Anduin>justinh: Yeah, now to watch every other theme maintainer miss it :)
20:18<hads>Hmm, I'm at 15968 and I see it. Let me check on a checkout on another box.
20:19<justinh>Anduin: I'm interested to see how 3rd party themers are gonna keep up with their one-size fits all method :P
20:19<justinh>it's past the point where that's even remotely possible now I think. breakage here we come
20:19<Anduin>hads: Hmm, I see them, must have slipped back in during my svn mv and patch, I'll fix it soon.
20:19-!-grokky [n=grokky@] has quit []
20:19<hads>Anduin: Sweet, thanks.
20:36<justinh>Anduin: did the cast filter change make it into the 0.21 branch?
20:36<Anduin>justinh: Yup, it was there pre-branch
20:37<justinh>right so I'll need to merge my latest changes in then
20:37<justinh>or no
20:37<justinh>there's no 'themes' in the branch
20:37<justinh>duh yes there is!
20:39<justinh>too much for my feeble brain right now. it can wait a while
20:40-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
20:41<justinh>this reminds me of something that'd be nice in mythui. do away with the separate text & button definitions in stuff like this filter
20:47-!-mzb [] has quit ["Time to quit"]
20:48<jams>justinh- what do you mean by "one size fits all method" ?
20:48<justinh>jams: I mean one theme for trunk and -fixes
20:49<justinh>when 0.21 is out obviously things'll straighten out for a spell but not for long
20:50-!-mzb [] has joined #mythtv
20:52<justinh>wow. feel like I've done some work now
20:53-!-ryan_ [] has joined #mythtv
20:57-!-feiner [] has joined #mythtv
20:57-!-ryan_ [] has quit ["Leaving"]
20:59-!-feiner [] has quit [Remote closed the connection]
21:01<gbee>seperate text and button definitions?
21:03<gbee>oh you mean labels for form elements?
21:03<justinh>gbee: yeah
21:04<gbee>yeah, I had a vague idea that form stuff would include a label element but I've not given it much thought
21:04<justinh>not urgent of course but it'd greatly simplify themes
21:05<gbee>well I've only written one form element so far (ignoring buttons) and that's some way from being ready to commit
21:06<justinh>oh man. 2am. if that compile had only finished 2 hours sooner..
21:07<gbee>eep, I'm off to bed - can't stay up this late 3 nights in a row, leaves me knackered for the rest of the week
21:07<justinh>going to have a stab at splitting the playlist menu into 2 tomorrow to reduce the number of buttons in one place. should make room for more functions should they be needed
21:08<justinh>aye night gbee.
21:30-!-knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has quit ["Leaving..."]
21:34<justinh>hmm can't seem to be able to svn switch to the new branch
21:34<justinh>or check it out
21:34<justinh>should be svn co svn+ssh:// shouldn't it?
21:38<Anduin>username in there as well
21:39<justinh>made a ssh config file so should be using my username
21:40<justinh>it's connecting now but asking for my password once, and then again.. then again..
21:43<justinh>gonna have to leave it. need sleeeep
21:46<cesman>rest well
22:03<superm1>what additional things should the python bindings be depending upon?
22:04<hads>erm... python-mysqldb is probably the only thing.
22:05<hads>superm1: They will handle it if it's not there but they aren't that useful without it.
22:06<superm1>hads, should i make the frontend or backend depend upon these, or any particular plugin?
22:06<superm1>or just have them available but not installed with myth by default
22:07<hads>Well nothing is dependant on them really. from mythvideo uses them though.
22:07<Anduin>superm1: They are currently only used by some of the scripts in the mythvideo/scripts directory.
22:07<superm1>Anduin, hads okay, then i'll make mythvideo depend upon them but not installed by default otherwise
22:08<Anduin>superm1: Where did you put the perl ones?
22:08<superm1>they get installed with the backend right now
22:09<Anduin>Ah, my used only by me rpm, has a common that has things like libmythtv etc, so there for frontend/backend. For now though, limiting to MythVideo only seems reasonable.
22:10<superm1>we need to get this perl upnp library in apt last minute too it looks like
22:10<superm1>or the perl ones dont get along well
22:23-!-felix_da_catz [] has joined #mythtv
22:27<superm1>would anyone have an objection to a patch like this: ?
22:27<superm1>I think it would help many people using packaged versions that include OSS and ALSA, since ALSA is more prevalently used
22:32-!-mntmst [] has joined #mythtv
22:48-!-nsaspook [] has quit [Read error: 110 (Connection timed out)]
22:50-!-ahbritto [] has quit [Client Quit]
23:01-!-ahbritto [] has joined #mythtv
23:30-!-poua [] has joined #mythtv
23:31-!-JoeyBorn [] has quit ["try to be back soon, putting PingPong to bed"]
23:32-!-JoeyBorn [] has joined #mythtv
23:34-!-JoeyBorn [] has quit [Client Quit]
23:36-!-mzb [] has quit ["Time to quit"]
23:37-!-mzb [] has joined #mythtv
23:37-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Remote closed the connection]
23:45-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
23:50-!-PointyPumper [i=Pintlezz@] has quit [Read error: 104 (Connection reset by peer)]
23:53-!-jhulst_ [n=jhulst@unaffiliated/jhulst] has joined #mythtv
23:54-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Read error: 113 (No route to host)]
---Logclosed Wed Feb 13 00:00:20 2008