Back to Home / #mythtv / 2007 / 12 / Prev Day | Next Day
#mythtv IRC Logs for 2007-12-20

---Logopened Thu Dec 20 00:00:22 2007
00:10|-|dman [] has joined #mythtv
00:25|-|hatchmt [] has joined #mythtv
00:28<hatchmt>I have been unable to compile svn r14830+ using procopt on my athlon system. r14829 compiles just fine, and r14830+ compiles fine if I remove procopt and use march=i386. Has anyone else run into problems with compiling svn past that release? The changeset says the linker is now using the mythav* libs when linking mytharchivehelper (where my compile fails).
00:30<hatchmt>I am using a somewhat non-standard method of compiling it, however... My configure line is as follows:
00:30<hatchmt>./configure --compile-type=release --enable-mmx --prefix=/usr --libdir-name=lib --x11-path=/usr/include --enable-joystick-menu --enable-ivtv --enable-firewire --enable-dvb --dvb-path=/usr/include/v4l/ --enable-audio-oss --enable-audio-alsa --enable-audio-arts --enable-audio-jack --enable-x11 --enable-xrandr --enable-xv --enable-xvmc --enable-xvmc-vld --enable-xvmc-pro --enable-opengl-vsync --disable-directfb --enable-libdts --enab
00:30<hatchmt>le-proc-opt --with-bindings=perl
00:31<hatchmt>this worked perfectly pre-14830
00:32|-|dman [] has left #mythtv []
01:05|-|zdzisekg [] has joined #mythtv
01:14|-|zdzisekg [] has quit ["Easy as 3.14159265358979323846..."]
01:32|-|reynaldo_ changed nick to reynaldo
01:35|-|nsaspook [] has quit [Read error: 110 (Connection timed out)]
01:36|-|scant [n=scant@] has quit []
01:37|-|clever [] has quit [Remote closed the connection]
01:38|-|clever [] has joined #mythtv
01:40|-|kormoc [n=kormoc@unaffiliated/kormoc] has quit []
02:26|-|jhulst [n=jhulst@unaffiliated/jhulst] has quit [Read error: 113 (No route to host)]
02:27<stuarta>that's a bit rude
02:27<stuarta>asked mythtranscode to use a profile with audio set to mp3/44.1k and it comes out as mp3/48k
02:28|-|aevil [] has joined #mythtv
02:49|-|dlblog [] has quit [Read error: 110 (Connection timed out)]
02:50|-|CDev [] has quit [Read error: 110 (Connection timed out)]
02:54|-|gnome42 [] has quit [Remote closed the connection]
03:26|-|hatchmt [] has quit [Remote closed the connection]
03:27|-|justinh [] has joined #mythtv
03:32|-|clever [] has quit [Remote closed the connection]
03:32|-|xris [] has quit ["Leaving."]
03:34|-|clever [] has joined #mythtv
04:00|-|aevil [] has quit [Remote closed the connection]
04:02|-|dlblog [] has joined #mythtv
04:30|-|anykey_ [] has quit ["Lost terminal"]
05:07|-|Chutt [] has quit [Remote closed the connection]
05:07|-|superm1 [n=superm1@ubuntu/member/superm1] has quit ["Leaving"]
05:11|-|Chutt [] has joined #mythtv
05:39|-|DaveMorris [] has joined #mythtv
05:39<DaveMorris>which database table holds the path for where recordings are stored on the backend?
05:40<DaveMorris>found it, thanks anyway
05:41[~]DaveMorris had already spent 10 mins looking
06:20|-|andy151 [] has joined #mythtv
07:10<clever>DaveMorris: yeah there is a bit too many tables:P
07:10<clever>DaveMorris: i just -v database and guess from what it looks at
07:25<gbee>there aren't _enough_ tables, if we were to truly rationalise the database there would be several more
07:45<DaveMorris>then why don't you?
07:46<stuarta>work in progress is the database for myth
07:50<stuarta>hmmm, that was kinda yoda that statement
07:51<DaveMorris>I noticed
07:51<DaveMorris>is there a list of the planned work?
07:51[~]stuarta checks to see if his brain rolled under the desk
07:52|-|CDev [] has joined #mythtv
07:52<stuarta>list? not really, just a general consensus of what needs doing to what bit
07:56<DaveMorris>I wanna patch my version of mythtv to keep tvlistings in the program table for longer than is currently set. Can someone give me some pointers of the top of my head where I should start looking in the code?
07:57<stuarta>housekeeper, iirc programs/mythbackend
07:58<clever>the guide in my digital box keeps NOTHING from the past
07:58<clever>i cant even tell what show just ended 30 seconds ago
07:58<clever>useless crap:P
07:59<stuarta>that's by design ;-)
07:59<clever>in mythtv i can easily go back a day or more in the guide
08:00<clever>and DaveMorris's patch will probly let him go back even further
08:00<clever>at the expense of slower resched's
08:00<clever>and ive found a flaw in the sheduler design
08:00<stuarta>probably a feature
08:00<DaveMorris>yeah I wanna see how much it affects it
08:00<clever>ive set a show to keep at most 2 recordings and to stop recording after the limit is reached
08:00<clever>stuarta: yet its clearly shedules atleast 6 episodes to record
08:01<stuarta>not for me
08:01<clever>what revision number?
08:01<stuarta>head from last 2 days
08:02<clever>15192M trunk
08:02<janneg>clever: I don't think we have that feature
08:02<clever>then why does it do that on stuarta's box:P
08:02<stuarta>janneg: we do have that. it's great.
08:02<stuarta>clever: i'll update and recheck my schedule.
08:03<clever>ive also noticed a bug in the auto expire
08:03<clever>it appears to have moved to the deleted group then actualy deleted it
08:03<janneg>I think we have only auto expire older recordings and always keep the x newest
08:04<clever>also the 0mb it deleted was actualy way more and was falsely deleted for being a peice of crap left by a livetv
08:04<clever>this looks more like cleanup of the 500 2mb files livetv may tend to make
08:04<clever>but was actualy a normal recordign that got interupted(ctrl+c'ed)
08:04<stuarta>clever: have you actually recorded the 2 shows yet?
08:05<clever>stuarta: no i have 0 copys of that show recorded
08:05<stuarta>thats why
08:05<clever>stuarta: but once 2 record its going to stop all the others
08:05<clever>so why even show them as being scheduled:P
08:06<stuarta>because they are all candidates until you hit max episodes
08:06<gbee>anyone who thinks as much of python as I do, might find this amusing:
08:06[~]DaveMorris wonders if RT could do sql injection to drop the mythconverg database?
08:07<clever>gbee: seen it before
08:07<clever>DaveMorris: RT?
08:08<gbee>DaveMorris: no, we use prepared statements
08:08<janneg>clever: where is the bug in the pastebin auto expire log snippet?
08:08<gbee>clever: figured that a few people had seen it before, but that I might not be the only one who hadn't
08:08<janneg>gbee: not everywhere
08:09<stuarta>i hadn't
08:09<clever>janneg: it appears to have deleted the same chunk of the show twice(to the deleted group then realy deleted)
08:09<janneg>clever: which one?
08:09<gbee>janneg: no, not everywhere but those places we don't are a minority and generally get fixed when someone sees them
08:10<clever>janneg: lines 3 and 8
08:11<janneg>clever: no that are two different files
08:11<DaveMorris>clever: radio times
08:11<clever>DaveMorris: never heard of them
08:11<DaveMorris>they do tv listings for the UK
08:11<janneg>due to the signalmonitor design two recordings are created
08:12<stuarta>that we need to fix
08:12<clever>janneg: lines 3 and 8 are both 1020 '20 02:00:00 2007' which apears to be referencing the same time
08:13<clever>lines 1/2 are a seperate file for the rest of the show
08:13<janneg>gbee: the BUSQ don't use prepared statements evertwhere
08:13<clever>the backend was having problems so i restarted it durring a comercial cuting it off mid recording
08:13<clever>and it resumed when it started back up
08:13<janneg>clever: but the filesizes differ
08:13<clever>then went and deleted both halves on me:P
08:14<clever>yeah thats because its in 2 halves
08:14<clever>the 0byte one was 90% of the show
08:14<gbee>janneg: hadn't remembered that, but that's one query I won't get near enough to convert
08:14<clever>janneg: if you look closely youll see the 21mb one being deleted twice
08:14<gbee>shame though, since there is supposed to be some performance benefit to using stored prepared queries
08:15<janneg>gbee: me neither
08:17<janneg>clever: no, it's not delting the 21mb file twice. and the autoexpirer doesn't move to the deleted
08:18<clever>but it is showing 2 lines referencing the 21mb one and delete
08:18<clever>a few 10th's of a second appart
08:19<janneg>and it is showing these two lines for every other recording too
08:51|-|nrpil [] has quit ["leaving"]
08:57<GreyFoxx>gbee: Well now I know why I see a upnp regrab for mysql data anytime mythweb triggers a preview screenshot to be made
08:58<GreyFoxx>we are building a commandline in the PreviewGenerator and then exec() ing a call to launch mythbackend to generate it rather than call the code directly
08:59<GreyFoxx>and so for everytime PreviewGenerator::Run() is called we rediscover the DB info :)
09:00<GreyFoxx>At least that's my theory so far :)
09:00<stuarta>well that's just plain nasty
09:01|-|nsaspook [] has joined #mythtv
09:10|-|reynaldo [] has quit [Read error: 110 (Connection timed out)]
09:12<GreyFoxx>we have a --disable-autodiscovery for frontends, but no such command for the backend to ask it to skip that
09:12<GreyFoxx>If we get to the point of calling it in the preview generator then we obviously already have the info so we don't need to keep discovering just to generate a preview
09:13|-|aevil [] has joined #mythtv
09:15<stuarta>isn't someone working on re-doing the preview thread stuff?
09:16<GreyFoxx>Maybe. That stuff tends to get patched a lot
09:16<janneg>generating the preview image in a seperate process is good but we should use fork
09:17<janneg>the seperate thread was a recent change from daniel
09:19|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:21|-|AriX_ [] has quit ["Leaving..."]
09:45|-|XChatMav [] has joined #mythtv
09:57|-|rooaus [] has left #mythtv []
09:58|-|aevil [] has quit [Remote closed the connection]
10:02|-|MavT [] has quit [Read error: 110 (Connection timed out)]
10:14|-|hatchmt [] has joined #mythtv
10:37|-|mtnbkr [] has joined #mythtv
10:38|-|cattelan [] has joined #mythtv
10:38|-|mtnbkr [] has left #mythtv ["Leaving"]
10:43|-|nsaspook [] has quit [Read error: 110 (Connection timed out)]
10:46|-|mr_claus [] has joined #mythtv
10:47|-|mr_claus [] has left #mythtv ["Verlassend"]
11:12<Anduin>gbee: What a dark path you've sent me down
11:12<gbee>heh, sorry :)
11:13<Anduin>I assume there will be no objections to me fixing the ugly corners problem (also fixes a, doesn't draw the damn background proble)
11:13|-|andy151 [] has quit [Remote closed the connection]
11:15<gbee>no objections, I was was just going to deal with it as part of the move to mythui but if you want to do it now that's fine
11:16<Anduin>Yeah, it is a bonus to proper background painting
11:17|-|beavis [] has joined #mythtv
11:21<hatchmt>Has anyone else reported difficulty compiling mythtv with --enable-proc-opt since svn r14830? I am unable to compile on my athlon machine with r14830+ unless I remove proc-opt and compile for i686.
11:22<hatchmt>It crashes when working on mutharchivehelper
11:24<gbee>hatchmt: compiling just fine on 1x 32bit Athlon and 2x 64bit Athlons (one of those a Turion)
11:26<hatchmt>the configure line I'm using is as follows:
11:26<hatchmt>./configure --compile-type=release --enable-mmx --prefix=/usr --libdir-name=lib --x11-path=/usr/include --enable-joystick-menu --enable-ivtv --enable-firewire --enable-dvb --dvb-path=/usr/include/v4l/ --enable-audio-oss --enable-audio-alsa --enable-audio-arts --enable-audio-jack --enable-x11 --enable-xrandr --enable-xv --enable-xvmc --enable-xvmc-vld --enable-xvmc-pro --enable-opengl-vsync --disable-directfb --enable-libdts --enab
11:26<hatchmt>le-proc-opt --with-bindings=perl
11:26<hatchmt>which has always worked before
11:26<hatchmt>but is somewhat non-standard
11:27<hatchmt>I'm going to try to compile it just running configure with no operands
11:30<gbee>hatchmt: shouldn't need to force mmx, it should be enabled automatically if your CPU supports it - not that I think it's causing the problems here
11:31<hatchmt>I didn't remove that when I appended my script to use proc-opt
11:31<gbee>nor should you need to enable firewire/dvb or most of those options since they are enabled by default, again, that won't cause the problems you are seeing
11:32<gbee>it will just cleanup your configure args
11:33<hatchmt>Well, I'm building it with just 'configure --enable-proc-opt' just to see what happens
11:37|-|gnome42 [] has joined #mythtv
11:41<Snow-Man>ERROR: record type has not been registered
11:44|-|xris [] has joined #mythtv
11:55<hatchmt>You know, mythtv compiles fine -- it's crashing while compiling mythplugins. Here's the configure for that:
11:55<hatchmt>./configure --prefix=/usr/src/redhat/BUILD/mythtv-0.21/temp/usr --libdir-name=lib --enable-opengl --enable-mytharchive --enable-create-dvd --enable-create-archive --enable-mythbrowser --enable-mythcontrols --enable-mythflix --enable-mythgallery --enable-exif --enable-new-exif --enable-mythgame --enable-mythmovies --enable-mythmusic --enable-libvisual --enable-fftw --enable-sdl --enable-aac --enable-mythnews --enable-mythphone --en
11:55<hatchmt>able-mythvideo --enable-mythweather --enable-mythzoneminder
11:56<hatchmt>ignore the prefix and libdir-name -- those are just there to work with my script.
11:56<gbee>Snow-Man: any context for that error? :)
11:57<gbee>hatchmt: can't see a problem there, but have you tried installing the mythtv libs first then building against them? Instead of pointing at the build location?
11:58<hatchmt>not yet -- shall try now.
12:00|-|DaveMorris [] has quit ["Leaving."]
12:16|-|nsaspook [] has joined #mythtv
12:22|-|splat1 [] has quit []
12:26<gbee>stuarta: want this one? or should I just close it as a feature request without patch?
12:27[~]stuarta looks
12:28<stuarta>not a lot of info there.
12:30<stuarta>is it possible to close it and leave it in need info?
12:30<stuarta>doubt it
12:30<stuarta>gotta run.
12:30<stuarta>back tomorrow
12:38<hatchmt>gbee: it does seem to succeed by installing the mythtv libs first and compiling against that as opposed to the build directory.
12:38<hatchmt>the problem is
12:38<hatchmt>I compile against the build location because it builds an rpm.
12:40<gbee>hatchmt: do you run make distclean first? I suspect that there may be some cruft in your build directory
12:41<hatchmt>the spec file removes the build directories first, then does an svn checkout and goes from there. A distclean shouldn't be necessary
12:49<hatchmt>here's what the spec does:
12:50<hatchmt>it builds mythtv as usual
12:50<hatchmt>then it creates a directory 'temp', sets temp=`pwd`/temp
12:50<hatchmt>then 'make -C mythtv-%{version} install INSTALL_ROOT=$temp'
12:51<hatchmt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$temp%{_libdir}
12:51<hatchmt>cd mythplugins-%{version}
12:51<hatchmt>and then configure and make as usual
12:52<hatchmt>that's where the prefix in the configure points to /usr/src/redhat/BUILD/mythtv-0.21/temp/usr
12:57|-|reynaldo [] has joined #mythtv
13:00|-|reynaldo [] has quit [Client Quit]
13:00|-|reynaldo [] has joined #mythtv
13:38<gbee>hatchmt: no ideas
13:38<hatchmt>me neither
13:38<hatchmt>I'm thinking that I'm gonna ditch the rpm thing for now
13:39<hatchmt>until I can figure it out. Thanks for your help, though.
13:39<gbee>you could probably save a _lot_ of time by not wiping out the build dir or checking out a new copy each time, if you stick with using the rpm build script
13:39|-|janneg [] has quit [Remote closed the connection]
13:39<hatchmt>It would be more of an issue on a DSL line, but I can checkout the code in a little under a minute, so it's not so bad.
13:40<hatchmt>but I agree completely
13:40<hatchmt>rather than co, do an svn up. :)
13:40|-|janneg [] has joined #mythtv
13:40<gbee>svn update + make with ccache installed would in theory take just take a couple of minutes depending on the number of changes
13:59<Snow-Man>gbee: err, wrong channel.
13:59<gbee>Snow-Man: ahh, heh ;)
14:01|-|janneg [] has quit [Read error: 60 (Operation timed out)]
14:03|-|janneg [] has joined #mythtv
14:20|-|melunko [n=hmelo@] has joined #mythtv
14:44<hatchmt>Will I notice any improvement in performance by using march/mtune=athlon-xp vs. athlon?
14:44<hatchmt>since the xp has full sse implementation?
14:49|-|CDev_ [] has joined #mythtv
14:51|-|janneg [] has quit [Remote closed the connection]
14:51|-|janneg [] has joined #mythtv
14:52<gbee>Shouldn't volume up/down be global bindings?
14:58<Chutt>now that there's music elsewhere, yeah
15:01|-|ahbritto [] has joined #mythtv
15:01|-|melunko [n=hmelo@] has quit [Read error: 110 (Connection timed out)]
15:02|-|CDev [] has quit [Read error: 110 (Connection timed out)]
15:05|-|bendailey [] has joined #mythtv
15:05|-|reynaldo [] has quit [Read error: 113 (No route to host)]
15:07|-|kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
15:14|-|kormoc [n=kormoc@unaffiliated/kormoc] has quit []
15:17<CDev_>What's the recommended IPC approach for linux?
15:18|-|kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
15:19|-|superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
15:20<Cardoe>you could use D-Bus
15:20<CDev_>Is that widely available in all distributions now?
15:22[~]CDev_ goes and reads more about D-Bus
15:23<hads>CDev_: I believe that's what Gnome uses and what KDE4 will use so it should be fairly widely available.
15:24|-|melunko_ [n=hmelo@] has joined #mythtv
15:24<CDev_>thanks... still reading about it, but it looks promising.
15:26<CDev_>Chutt: would you be ok with mythtv being dependant on D-Bus?
15:26|-|bendailey [] has left #mythtv []
15:33|-|ahbritto [] has quit [Client Quit]
15:37|-|reynaldo [] has joined #mythtv
15:46|-|hatchmt [] has quit ["Leaving"]
16:14<clever>CDev_: you could just use msg queues but those might be more complex
16:15<gbee>this came up 18 months ago, in a discussion about replacing myth protocol
16:15<clever>CDev_: i beleive msgqueues let you throw structs onto a queue then pull them off
16:15<clever>the que id is made based on the inode of a selected file+a uniq id
16:16<clever>msg queues and dbus i dont think work over a lan
16:16<gbee>CDev_: what are you thinking of using it for?
16:16<clever>yeah it seems simple to just stuff more into the myth protocol
16:17<janneg>CDev_: D-Bus should wait for qt4 port
16:17<janneg>the simplest and probably most common IPC for are pipes
16:18<clever>depends on the task mainly
16:20<Chutt>i'd prefer to get qt4 in there first, then we'd just use the qt dbus stuff
16:21<clever>sounds good:)
16:21<laga>maybe jochen can be of some assistance :)
16:22<sphery>GreyFoxx: . Daniel just committed hte patch that makes preview generation a separate process (so that an ffmpeg crash doesn't take down the backend) in [15029] (2 weeks ago).
16:24<clever>ive never had ffmpeg tear the backend down
16:24<clever>but i have noticed those seperate procs are segfaulting on there own alot more lately
16:25<sphery>GreyFoxx: It seems that the current approach (even after fixing the recursively recursive searches) has some issues--especially since MythWeb now uses its own previews rather than the ones used by the frontend
16:25<clever>also when i open mythweb
16:26<CDev_>sorry for the delay... had a meeting I had to go to.
16:26<clever>mythbackend starts sucking system cpu usage
16:26<sphery>GreyFoxx: so going to the MythWeb Recorded Programs page will generally causes a ton of preview generation requests (through the UPnP code). I don't know if it's the process creation or UPnP client create/destroy that's killing it. Hope this helps.
16:26<clever>and doesnt stop till i restart it
16:27<CDev_>I want to change the upnp SSDP functionallity to be a daemon so it can be used by many processes.
16:28<clever>ive got dos running on my 1.8ghz core2 duo
16:28<clever>with an old qbasic prog i made to render in 3d
16:28<clever>and its still takes several seconds to render!
16:28<clever>probly needs more sse/mmx:P
16:29<clever>wait that was loading
16:29<clever>it actualy redraws pretty fast
16:29<Dibblah>"therwise I will have to install another program instead of mythtv" - Oh, yes, emotional blackmail really works when... Noone else cares ;)
16:29<Dibblah>clever: Don't you want to be in -users?
16:29<clever>im just bored:P
16:29[~]clever goes to play with it silently
16:30<sphery>GreyFoxx: I suppose fixing the UPnP/autodiscovery stuff (related to preview gen) should be the first thing. If that doesn't fix it, maybe we need a Myth Preview Daemon started automatically by mythbackend and re-started in the event of a crash, with the preview generation queue managed by the backend or in a new table in the DB (since we don't have enough tables :)
16:33<CDev_>I guess I missed some of the discussions as to why the preview generation was changed to exec the backend multiple time? Wasn't it working fine when it was handled in the main process?
16:34<Anduin>CDev_: occasionally ffmpeg would crash while generating the preview, killing the whole backend
16:35<sphery>Right. See
16:36<CDev_>Wouldn't proper exception handling take care of the rare crashes?
16:36<Anduin>and no SEH
16:37<CDev_>Seems like a extream solution. I'd rather find and fix why ffmpeg crashes.
16:37<Chutt>that's... difficult :p
16:37<Chutt>but, yeah, would be better
16:40[~]CDev_ feels like he has been away for a long time!
16:41<CDev_>upnp in SVN head is definitly broken.
16:41<sphery>Does it make sense to also have the backend auto-generate a MythWeb-sized preview after recording (as it does now for the frontend preview)? This, of course, assumes there's a standard (per-system?) size for MythWeb previews.
16:41<CDev_>I just hope I can find the time to fix it before the release date.
16:41|-|splat1 [] has joined #mythtv
16:42<CDev_>sphery: The webmethod allows generation of any size... I know mythweb uses at least 2 different sizes. (I don't know if it's user changable)
16:43<janneg>CDev_: fixing code operating on random data is hard
16:43<CDev_>janneg: Isn't that what makes programming fun! :-p
16:44<sphery>Yeah, but since MythWeb requests a lot of previews at once when going to Recorded Programs, if it uses standard sizes, we could pre-generate them. We did that for the frontend because of the UI delay when scrolling through the Watch Recordings screen.
16:44<CDev_>I would think if we could find an example of when it crashes, there would be a possiblity of it being re-creatable.
16:44<janneg>forking the preview generator thread instead of exec a new backend should avoid the overhead and work too
16:45|-|jarle [] has quit [Read error: 110 (Connection timed out)]
16:46|-|jarle [] has joined #mythtv
16:47<CDev_>Chutt: Does it make sense to wait until after the next release to continue the QT4 port? with all the changes being made, it will take all of my time just to keep the branch up-to-date.
16:48<Chutt>whatever you want to do with it, really
16:49<sphery>I'd expect far more people would be interested in UPnP for 0.21 than for QT4 for 0.21. :)
16:49<janneg>CDev_: that was my original plan but I plan to work on the qt4 branch in the next two weeks
16:52<CDev_>Personally, I would like to see (after the release) the buy in of all the developers to bite the bullet and merge the branch with trunk sooner rather than later. There are just too many changes to keep in sync with head.
16:53<CDev_>sphery: I agree... That is why I'll try to spend time (what little I have) on the upnp code until the release.
16:54<sphery>All the users on the list complaining about UPnP not working in PS3 or TV recordings being in the Music section and not playable in XBox 360 will be very pleased with that decision.
16:55<CDev_>I can help with the PS3, but I don't have an XBox360 to test with.
16:56|-|H00chster [] has quit [Read error: 110 (Connection timed out)]
16:57<sphery>I've got a 360, but was hoping to get a patch finished up soon after family visiting for the holidays leaves--though it's probably too late to get that patch in before the release, so let me know if you need some specific testing.
16:58<sphery>I'm thinking, though, that's it's likely different symptoms (for different clients) of a larger problem related to the large number of changes to the UPnP code for the autodiscovery/Mac port/etc.
16:59|-|ead [] has quit ["Ciao!"]
17:00|-|ead [] has joined #mythtv
17:00<CDev_>Agreed. I'll be looking into the main problems, I will look to you (or anyone with an xbox 360) to help pin-point it's specific problems one upnp is working again for the majority of the clients.
17:00<CDev_>one == once
17:00|-|melunko_ [n=hmelo@] has quit ["Ex-Chat"]
17:01<sphery>Cool. Even if I don't respond right away, I should get any messages you leave here.
17:04<CDev_>janneg: are you making the preview changes (creating the fork)?
17:06<janneg>yeah, working on it now
17:08<CDev_>Not sure how forking works, but please make sure that the backend doesn't tear down the upnp stack when it's done with the preview generation.
17:08|-|jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
17:09[~]CDev_ heads home.
17:09<janneg>it won't. forking in a multithreaded app forks just the calling thread. i.e. the new process is a singlethreaded preview generator
17:10<janneg>CDev_: bye
17:16|-|MavT [] has joined #mythtv
17:16<gbee>sphery: the point of the upnp preview gen as used by mythweb is that it can ask for any size image, mythweb uses a couple of different sizes I think, one for the recordings list and another for the details page (just catching up on scrollback, so if I'm repeating what's already been said, sorry)
17:20<gbee>btw, I hope no-one minds me triaging some of the tickets so that outstanding segfaults get looked at before 0.21 goes out the door
17:28<janneg>gbee: not at all
17:33|-|XChatMav [] has quit [Read error: 110 (Connection timed out)]
17:33|-|jmk_ [] has quit [Read error: 110 (Connection timed out)]
17:33|-|jmk_ [] has joined #mythtv
17:40|-|reynaldo [] has quit [Read error: 110 (Connection timed out)]
17:59|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:07<gbee>sphery: any thoughts on ?
18:09<sphery>The backend crash when hitting the HTML/XML status page happened before my changes that removed the libsensors stuff.
18:10<sphery>And still happens after. It may (hope not) be slightly more likely now with the changes I made.
18:10|-|rooaus [] has joined #mythtv
18:11<sphery>It's definitely likely to occur for users that are polling the status through the HTTP port.
18:12|-|\S2 [] has joined #mythtv
18:12<laga>it'd be great if that was fixed. we'll have a status icon application in mythbuntu 8.04
18:12<laga>which will poll the built-in httpd
18:12<sphery>If my changes did increase the frequency of the crashes, I'm pretty certain it's due to the QProcess stuff (which I basically copied from your mythfilldatabase/XMLTV capabilities stuff).
18:12<sphery>laga: What type of status?
18:13<justinh>ubuntu wins my heart ever more
18:13<gbee>sphery: ok, not sure what's going on there, I don't see any indication that your changes influenced the frequency of crashes but you've looked at that code more recently than anyone else here
18:13[~]Daviey has a hilight on when justinh says good things about ubuntu.. doesn't hilight often :D
18:14|-|\S2 [] has quit [Remote closed the connection]
18:14<laga>sphery: i think it'll show if the backend is recording and what shows will be recorded next
18:14<sphery>laga: I wrote 2 and use the Perl bindings to retrieve the info using Myth protocol (which is much more stable).
18:14<laga>sphery: oh. that's good news.
18:15<laga>sphery: i'll forward that to the code monkeys
18:15<sphery>I'm making changes now that will allow the backend to provide info about whether anything is currently recording and what jobs are running, etc. I'll probably make that available through the protocol, and in the Perl bindings.
18:16<sphery>the scripts are currently in contrib/misc_status_info (as they were examples of how to create scripts to add additional information to the backend status page).
18:16<laga>since it'll be written in python, there might be a python port soon. not sure what they're planning to do
18:16|-|\S2 [n=\] has joined #mythtv
18:17<sphery>gbee: Yeah. I didn't take it personally--just confessing that there may be some QProcess instability for those using the misc status script as I saw a couple of crashes during testing (but didn't have good BT's for them), so I can't tell if it's the "normal" crashes or new ones... :)
18:18<sphery>I just finished setting up a real dev system (finally--should have done that years ago), so I'll be much more cavailier about my testing (and more likely to be using a debug build when I get a crash).
18:19<sphery>laga: If my changes get committed before 0.21, the changes required to get recording/job status with the Python bindings would be as straightforward as the changes for the Perl bindings (so someone with Python experience could easily add it to Python bindings).
18:20<sphery>gbee: Did you notice any instability when you used QProcess for the tv_find_grabbers stuff?
18:20<gbee>we use QProcess in mythfilldatabase and mythtv-setup for the xmltv, I've not heard of any problems with it but then those apps are run repeatedly in a short timeframe
18:21<gbee>not seen any instability, not a single crash when I was testing and none have been reported
18:22<janneg>has someone the url to retrieve pixmaps over xml handy?
18:22<sphery>Yeah. That's part of why I didn't ask when I was testing my code--since it's run very infrequently, it may not have had ample opportunity to crash.
18:22<janneg>doesn't work
18:22<sphery>Perhaps I should set up a script to poll my dev server until it crashes.
18:23<gbee>janneg: need a Myth/ after the port and before GetPreviewImage
18:23<sphery>janneg: new namespace...
18:24<gbee>sphery: how did you dig that up so fast?
18:24<sphery>wow... I was much slower than gbee with that one.
18:24<janneg>sphery: while 1; do wget http://localhost:6544/ -O /dev/null; done
18:25<sphery>easier than a script. :)
18:25<sphery>I guess I really don't need to keep the output (which is why I thought I'd need a script).
18:26<gbee>sphery: just happened to have IRC front and centre that time, lately it's been consigned to the background which is why my replies can often seem very lagged :)
18:26<sphery>gbee: Vague recollection of the wording coupled with a search. :) You went from memory, though, which is much more impressive.
18:26|-|\S2 [n=\] has quit [Remote closed the connection]
18:27<janneg>sphery, gbee: tried that earlier since I copied it first from mythweb
18:27<janneg>I should check if the startime is correct and the correct format
18:28|-|beavis [] has quit ["Verlassend"]
18:30<sphery>janneg: uses a completely different format (though I can't say I've tried it that way)
18:30<gbee>janneg: format is wrong for starttime - should be in the format: YYYY-MM-DDTHH:MM
18:31<sphery>That's like the one in the message I gave, but it uses YYYY-MM-DDTHH:MM:SS (with seconds)
18:33<gbee>seconds aren't required
18:33<gbee>don't think it does any harm to add them though
18:33<gbee>the T is a literal character, not a token
18:33<gbee>so 2005-04-14T10:20:00
18:34<janneg>omitting the seconds probably only works if the starttime has yero seconds
18:35<janneg>s/has yero seconds/is on a full minute/
18:53|-|reynaldo [] has joined #mythtv
19:13|-|Hoochster [] has joined #mythtv
19:14|-|cattelan [] has quit ["This computer has gone to sleep"]
19:15|-|splat1 [] has quit []
19:17<sphery>A watched myth will never crash.
19:17|-|reynaldo [] has quit [Read error: 110 (Connection timed out)]
19:30|-|jmck2 [] has joined #mythtv
19:31|-|neo_genpix [n=neo_genp@] has joined #mythtv
19:49|-|neo_genpix [n=neo_genp@] has quit []
19:53|-|xris [] has quit ["Leaving."]
19:59|-|XChatMav [] has joined #mythtv
20:02|-|MaverickTech [] has joined #mythtv
20:17|-|MavT [] has quit [Read error: 110 (Connection timed out)]
20:19|-|XChatMav [] has quit [Read error: 110 (Connection timed out)]
20:34|-|jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"]
20:53|-|PointyPumper [i=Pintlezz@] has quit [Read error: 110 (Connection timed out)]
20:59|-|xris [] has joined #mythtv
21:21|-|jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
21:22|-|jmck2 [] has quit ["Ex-Chat"]
21:32|-|reynaldo [] has joined #mythtv
21:36|-|BleedAway [] has quit [Read error: 110 (Connection timed out)]
21:36|-|Chutt [] has quit [Remote closed the connection]
21:43|-|Chutt [] has joined #mythtv
21:51|-|rooaus [] has left #mythtv []
22:36|-|PointyPumper [i=Pintlezz@] has joined #mythtv
23:09|-|jhatch [] has joined #mythtv
23:15|-|kormoc [n=kormoc@unaffiliated/kormoc] has quit []
23:23|-|Timelord__ [] has joined #mythtv
23:25|-|Timelord_ [] has quit [Read error: 110 (Connection timed out)]
---Logclosed Fri Dec 21 00:00:56 2007