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

---Logopened Sat Jan 12 00:00:21 2008
00:14-!-davilla [] has joined #mythtv
00:37-!-davilla [] has quit ["Leaving"]
00:42-!-okolsi [n=mythtv@] has joined #mythtv
00:48-!-MavT [] has joined #mythtv
00:51-!-guest_ [] has quit [Client Quit]
01:01-!-ahbritto [] has joined #mythtv
01:02-!-cattelan_away is now known as cattelan
01:03-!-okolsi [n=mythtv@] has quit [Read error: 110 (Connection timed out)]
01:04-!-ahbritto [] has quit [Client Quit]
01:04-!-ahbritto [] has joined #mythtv
01:06-!-MaverickTech [] has quit [Read error: 110 (Connection timed out)]
01:13-!-erik__ [] has joined #mythtv
01:17-!-cattelan is now known as cattelan_away
01:31-!-XChatMav [] has joined #mythtv
01:50-!-MavT [] has quit [Read error: 110 (Connection timed out)]
01:56-!-tmk [] has joined #mythtv
01:56<tmk>anyone around this evening?
01:57*tmk pokes Chutt
02:05-!-tmk [] has quit ["Leaving"]
02:33<clever>xris: you there?
02:35-!-hachi [] has joined #mythtv
02:35<hachi>the howto really... badly... in section 8 needs to mention that lirc_i2c is dead and... dead
02:36<hachi>I just wasted a week of my evenings trying to get lirc_i2c working... never finding any sign that it's not even what I'm supposed to use
02:36<hachi>following the mythtv instructions, checking the lirc docs and screaming when my kernel would panic or the module wouldn't even compile
02:39<GreyFoxx>nothing in that section seems to give specific details on your remote
02:40<xris>clever: ?
02:40<GreyFoxx>You still would want lirc installed
02:40<GreyFoxx>just using input events
02:40<hachi>yes, after a week someone finally told me this
02:40<hachi>and said it's on the v4l wiki
02:41<hachi>but why would I ever look on the v4l wiki to find out that lirc kernel modules are not what I need
02:41<clever>xris: hold on while i try and remember
02:41<clever>ahh yeah
02:41<hachi>I'm asking the person for where this sort of information comes from, but I haven't gotten any answers
02:41<clever>xris: when SD does start hosting the guide data would it be posible to dl the ENTIRE range your fetching in 1 big go?
02:42<GreyFoxx>I would think, though I've never looked at it, that the most logical place to look would be LIRC + the ivtv docs themselves. And IVTV was recently merged into the V4L/KErnel stuff
02:42<hachi>it HURTS to know that I've wasted a week on a problem that was perfectly solved, but I couldn
02:42<clever>1 massive dl would probly go faster then 500 small downloads
02:42<hachi>'t get anyone in #mythtv-users (till now) or #debian, or couldn't find any matches with google or on the wiki
02:43<xris>clever: you can do that now
02:43<xris>that's a mythtv limitation.
02:43<clever>xris: currently mythfilldatabase appears to make a large number of wget calls
02:43<clever>and each needs multiple round trips before it even starts to fetch data
02:43<xris>yeah. that's mfdb
02:43<xris>because it wants to grab today+tomorrow+last-day-out
02:43<xris>instead of "everything"
02:44<clever>cant it get today+tomorow in 1 grab
02:44<clever>then 2days->14days in a 2nd grab
02:44<clever>in larger chunks
02:44<clever>but the zap2it servers are able to serve multiple days in a single query?
02:45<GreyFoxx>hachi: Dunno what to tell ya, if I had been paying attention one of the times you were asking I would have mentioned it, but just think of everything you got to learn along the way :)
02:45<GreyFoxx>clever: Yes
02:45<GreyFoxx>You tell it the start and endtime you want data for
02:45<GreyFoxx>mfdb just breaks it into daily chunks
02:45<clever>so its a defect within mfdb mostly
02:46<clever>any button on mfdb to make the chunks larger?
02:46<hachi>I'm trying to impart how important it is to have this information in the docs
02:46<GreyFoxx>clever: No
02:46<GreyFoxx>hachi: Then document it. Be part of the solution
02:46<clever>hachi: ir receiving with a pvr card?
02:46<GreyFoxx>document it in the wiki
02:46<clever>hachi: which method?
02:47<GreyFoxx>submit a trac ticket (with a patch) if you feel something needs to be changed on that part of the sites docs
02:47<hachi>I don't even know anymore
02:47<clever>im using lirc_i2c
02:47<hachi>I've read so many different things that I have to forget now
02:47<clever>ive got a few minor bugs with lirc receiving
02:47<clever>certain buttons on the ui dont work right
02:48<GreyFoxx>back on topic :
02:48<clever>ok is properly connected to 'select' but some buttons seem to push in and get stuck in
02:48<clever>and then the remote is totaly ignored till i get up and hit enter on a keyboard
02:48<GreyFoxx>For any of you out there using a DSM based upnp player can you try it with recent trunk? Specifically video playback of avi files?
02:49<GreyFoxx>The one I have for testing keeps complaining about being unable to handle the codec in the file, but if I use ushare it plays the same file just fine
02:49<clever>no upnp players here anywhere
02:49<clever>only things using upnp are routers,mythtv,utorrent
02:49<GreyFoxx>and I've now changed libmythupnp to return as far as I can tell identical http headers and content but it still complains
02:49<clever>still ushare and clone its headers maybe
02:50<clever>sniff i mean
02:50<GreyFoxx>unfortuntely tomorrow I have to give my dad back his player :)
02:50<GreyFoxx>clever: been there done that
02:50<clever>i copyed the IE headers ages ago before i learned any of them
02:50<clever>caused some problems later on when i tried to dl a page that the server gzip'ed on me
02:50<clever>text only lib i made was claiming to accept gzip encoding:P
02:53<clever>a livetv i set to not expire is missing
02:53<clever>auto expired:P
02:53<clever>2008-01-12 03:40:26.328 autoexpire: Expiring Program: Expiring 7 MBytes for 1002 @ Sat Jan 12 03:35:00 2008 => Paid Programming
02:53-!-okolsi [n=mythtv@] has joined #mythtv
02:53<clever>why must myth ignore what i tell it!!!
02:54<GreyFoxx>clever: move it to another recording group
02:54<clever>i'll have to do that after i record it
02:55<clever>if it doesnt expire it while im in the middle of moving it
02:56<GreyFoxx>hit Record while it's recoring an it should be automoved to the default recording group
02:56<clever>like that!
02:56<clever>i was 1 key away from putting it in default and it disapeared!
02:57<clever>its in default now and set to not expire
02:58<GreyFoxx>how long was the recording ?
02:58<clever><10 seconds
02:58<GreyFoxx>if it's under 2 minutes those get expired almost immediately
02:58<clever>just a sample of the horid quality of the tuner in the pvr150
02:58<clever>but channels up near 45 are noticable better
02:59<clever>the cable goes from the poll to the corner of the house where it splits in 2
02:59-!-gnome42 [] has quit []
02:59<clever>no 3
02:59<clever>one goes up to the living room and splits(one to the main digital box)
02:59<clever>the other goes to the computer desk where it splits again(one to the 2nd digital myth uses)
03:00<clever>and the last leg goes to the pvr150 itself
03:00<clever>3 spliters and 4 cables in total from the poll to the pvr150
03:01<clever>yet the digital tuner it normaly records thru is the exact same distance away and perfect quality
03:01<clever>(for SD)
03:01<GreyFoxx>the digital tuner likely is recording a digital version of the analog channel
03:02<clever>it isnt
03:02<GreyFoxx>here all analog channels have digital counterparts that the digital stb's use instead of the analog version
03:02<clever>if i pull the cord out of the digital box while on a 'analog' channel
03:02<clever>it goes to plain old static
03:02<clever>if i rip it out on a 'digital' channel it freezes
03:02<clever>posibly with some mpeg macroblocks messed up
03:03<clever>i can also feed in a channel3/4 from a game console
03:03<clever>and put it on 3
03:03<clever>and it pulls the analog 3 without a problem
03:04<clever>some cochannel problems are also visible on 5 with the pvr150
03:07<clever>GreyFoxx: and how much work would it be to allow overlaping recordings on the same channel+input?
03:11-!-purserj [] has quit [Remote closed the connection]
03:11-!-purserj [] has joined #mythtv
03:49-!-kvandivo [] has quit [Remote closed the connection]
03:49-!-kvandivo [] has joined #mythtv
03:55-!-loops [] has quit ["Leaving"]
04:07-!-ahbritto [] has quit [Client Quit]
04:09-!-ivor_ [n=ivor@kde/developer/ivor] has joined #mythtv
04:15-!-ivor [n=ivor@kde/developer/ivor] has quit [Read error: 110 (Connection timed out)]
04:15-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"]
04:16-!-ivor [n=ivor@kde/developer/ivor] has joined #mythtv
04:28-!-ivor_ [n=ivor@kde/developer/ivor] has quit [Read error: 110 (Connection timed out)]
04:51-!-grokky [] has joined #mythtv
05:23-!-xris [] has quit []
05:36-!-beavis [] has joined #mythtv
06:15-!-MavT [] has joined #mythtv
06:34-!-XChatMav [] has quit [Read error: 110 (Connection timed out)]
06:46-!-grokky [] has quit []
06:53-!-beavis_ [] has joined #mythtv
07:05-!-robthebob [] has joined #mythtv
07:09-!-beavis [] has quit [Read error: 110 (Connection timed out)]
07:19-!-turbo [] has quit [Read error: 110 (Connection timed out)]
07:51-!-turbo [] has joined #mythtv
07:56-!-mru [] has joined #mythtv
08:12-!-turbo [] has quit [Read error: 110 (Connection timed out)]
08:17-!-turbo [] has joined #mythtv
08:27-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
08:27-!-purserj [] has joined #mythtv
08:45-!-briand [] has joined #mythtv
08:45-!-robthebob [] has quit [Read error: 113 (No route to host)]
08:45-!-rn114 [] has joined #mythtv
08:46-!-turbo [] has quit [Read error: 110 (Connection timed out)]
08:51-!-\S2 [] has joined #mythtv
08:51-!-\S2 [] has quit [Remote closed the connection]
08:52-!-\S2 [] has joined #mythtv
08:52-!-RogerM [n=chatzill@] has joined #mythtv
08:53-!-\S2 is now known as S2
09:10-!-briand [] has quit [Read error: 110 (Connection timed out)]
09:11-!-briand [] has joined #mythtv
09:36-!-turbo [] has joined #mythtv
09:37-!-briand [] has quit [Connection timed out]
09:37-!-beavis [] has joined #mythtv
09:41-!-beavis [] has quit [Client Quit]
09:49-!-beavis_ [] has quit [Remote closed the connection]
10:04-!-Toxicity999 [n=bryan@unaffiliated/Toxicity999] has quit [Read error: 113 (No route to host)]
10:05-!-Toxicity999 [n=bryan@unaffiliated/Toxicity999] has joined #mythtv
10:09-!-Dibblah [] has quit [Read error: 113 (No route to host)]
10:11-!-viz1 [] has joined #mythtv
10:29-!-Toxicity999 [n=bryan@unaffiliated/Toxicity999] has quit [Read error: 104 (Connection reset by peer)]
10:33-!-Toxicity999 [n=bryan@unaffiliated/Toxicity999] has joined #mythtv
10:38-!-Dibblah [] has joined #mythtv
10:53-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
10:55-!-PointyPumper [] has quit [Read error: 104 (Connection reset by peer)]
11:00-!-dekarl [] has joined #mythtv
11:02<gbee> sphery: the backend crashing from http requests, I've completely forgotten what you found when looking at that the other week?
11:04-!-turbo is now known as briand
11:05-!-dekar1 [] has quit [Read error: 60 (Operation timed out)]
11:10<janneg>GreyFoxx: upnp playback of recordings seems to be broken on the ps3
11:11<mru>to elaborate on that, it starts receiving the TS, but almost instantly, without displaying any video, declares that "The data is corrupted"
11:12<laga>didn't get that broken by a firmware update?
11:13<mru>I suspected it could be a firmware thing too
11:13<mru>but the ps3 isn't too happy about downgrading...
11:19<janneg>mru: it seems to be a bug in the 2.10 firmware:
11:20<janneg>mpeg4 streaming over upnp works according to one post in that thread
11:20<mru>avi files play fine here
11:21<janneg>but I doubt mythtv's nuv files will play
11:21<mru>mpeg4 is a bit ambiguous...
11:21<gbee>mpeg4 part 14
11:22<janneg>mpeg4 part 2
11:22<janneg>part 14 is h264 aka AVC
11:23<mru>the curious thing is, if I dump the data stream with tcpdump, and save it on a flash stick, the resulting 2-second TS fragment plays perfectly fine on the ps3
11:23<gbee>err, yeah, getting the two confused ;)
11:23<mru>part 14 is the mp4 file format
11:23<gbee>or three, part 14 is the container ...
11:24<mru>like I said, mpeg4 is an ambiguous term
11:24-!-gnome42 [] has joined #mythtv
11:25-!-Dave123 [] has quit ["Leaving"]
11:29<mru>the copy trick works here too
11:29-!-cattelan_away is now known as cattelan
11:30<mru>I guess it's just a matter of waiting for a fix from sony
11:32<janneg>mru: btw libavcodec's bitrate management does not happen to be one of your development subjects?
11:33<mru>I'm afraid not
11:33<janneg>the mpeg4 encoder does not adhere to the requested bitrate
11:33<janneg>and outputs streams witrh almost double bitrate
11:33<mru>did you set qmax or lmax?
11:33-!-rn114 [] has quit [Read error: 104 (Connection reset by peer)]
11:34-!-rn114__ [] has joined #mythtv
11:34<mru>you can't do that if you want rate control to work
11:34<mru>you also need to set a vbv buffer size
11:34<janneg>I think so, but I'll check
11:34<mru>rc_buffer_size or something
11:35<mru>I recommend experimenting with the ffmpeg command line until you have something that works, then apply the same settings in your code
11:40<janneg>ffmpeg command line works. I'll compare the options. thanks so far
11:41<gnome42>Hi janneg, I've seen reference to that double bitrate problem but don't think I've ever seen it here. Is there something that triggers that?
11:42<janneg>gnome42: I can reproduce it with a mpeg4 transcode
11:42<gnome42>oh, transcoding. I was thinking just soft encode
11:44<janneg>I have no framegrabber installed but there shouldn't be a difference
11:48<gnome42>checking my current files I have roughly 20 mpeg4 files going back to Dec. 2006 and the sizes don't look abnormal too me.
11:48-!-PointyPumper [] has joined #mythtv
11:48-!-PointyPumper [] has quit [Remote closed the connection]
11:51<gnome42>I use v4l2 api instead of v4l, but I don't think I changed anything in the encoder.
11:52-!-Dave123 [] has joined #mythtv
11:54<gnome42>janneg: Let me know if I can check anything for you.
11:59-!-Syphn [] has joined #mythtv
12:00*gnome42 tries a mpeg2 -> mpeg4 transcode
12:03<gbee>if anyone is interested in fixing the mjpeg playback issue in #4275 I'd appreciate it, I'd like to commit a patch to allow mythgallery use of the internal player but since mjpeg is a common format for camera to use there is little point until the internal player can handle them
12:10<gnome42>gbee: I would if I could :)
12:11<gbee>thanks gnome42 ;)
12:11<gnome42>yeah, I'm very helpful
12:12<gnome42>gbee: I assume you got the player working from the gallery? (for other formats)
12:12<gbee>I would too if I had time between now and 0.21 to learn the ins and outs of ffmpeg and the possible areas of NVP which might be causing the problem
12:13<gbee>gnome42: actually no, I ran into a weird bug but I'm pretty sure that I'll fix that when I get a couple of hours to look at it
12:14<gbee>but the player can't handle these mpjeg files when used directly
12:14<janneg>gbee: I'll look at it
12:15<gbee>janneg: thanks, I appreciate that
12:17<janneg>I think I promised that already
12:17<gnome42>janneg: the transcoded file is abnormally large 1.2G -> 1.7G at 2200 bitrate
12:17<gbee>janneg: I think you did, sorry, I'd forgotten that
12:18<janneg>it's even my ticket
12:18<gbee>so it is ... now I feel stupid
12:20<janneg>I'll look at it tommorrow after hopefully solving the bitrate problem
12:21<sphery>superm1: Though I don't know which changeset fixed #4174, I'm certain that it's fixed in current trunk (but not in -fixes). If the user is using a miscellaneous status information script, though, the patch on #4381 is required (or the backend will crash).
12:22<sphery>gbee: I'm pretty certain that #4174 is fixed--HTTP requests from port 6544 will not cause the backend to crash.
12:22<gbee>sphery: ok, sorry for needing a reminder, guess my memory hasn't been too good lately
12:22<sphery>However, I don't know if the TCP check on port 6543 will cause a crash (that wouldn't surprise me). Perhaps someone using monit can test current trunk (with patch from #4381).
12:23<sphery>No problem. There's way too much going on to remember it all.
12:24-!-rn114 [] has joined #mythtv
12:24-!-rn114__ [] has quit [Read error: 104 (Connection reset by peer)]
12:24*sphery just lost mythtv-commits and tickets folders (and the reminders inside) on his IMAP server when he dropped the mouse connected to his laptop
12:25<sphery>the part that really annoys me (as the reminders will eventually become unimportant) is that I can't figure out where it went (if a delete, it somehow confirmed the delete, too)...
12:26<gbee>maybe that cautionary tale will finally make me setup a backup cron job for my imap mail folders
12:26<sphery>Yeah. I should probably do the same.
12:27-!-foxhunt [] has joined #mythtv
12:27-!-tafsen [] has joined #mythtv
12:28<gbee>I'm using cached IMAP, so there are copies on the other machines I use to read my email, but I can't rely on that as a backup since any folders or mail deleted on the server will be deleted from the client the next time it connects
12:28<sphery>Do you by any chance know how monit does a TCP check on a port? I don't feel like installing monit, but I have a feeling that the port 6543 check will actually crash the backend, so with a command-line equivalent, I can check.
12:29<sphery>heh. my laptop was the only one with the local cache (so the worst one for it to happen on)
12:30<sphery>It really seemed more like a move (didn't see a confirm dialog), but I can't find the folders anywhere. I've been trying to reproduce the issue, but can't.
12:32<superm1>sphery, this being the case, backporting it seems like a moot point (as long as its fixed in trunk)
12:33<sphery>Yeah. It seems 0.21 might be out quickly enough it's not an issue.
12:33<superm1>i was planning on switching the hardy builds to trunk later this month
12:33<superm1>under the assumption that things should be ready by late march
12:34<jams>.21 will be released when duke nukem forever is.
12:34<laga>there was a new duke nukem forever trailer
12:34<sphery>we should make a teaser trailer for 0.21...
12:35<tafsen>Are you guys working on making it possible to search in Video Manager?
12:37<tafsen>Because it really sux when you got a big libary
12:42<janneg>jams: I would even say 0.21 will be released before Duke Nukem Forever
12:43<janneg>I'm missing that for the "watch recordings" but haven't got around implementing something like search as you type
12:44<sphery>gbee: for #4460, rather than marking as a dup of #4174 (since #4460 is using TCP checks rather than HTTP requests), I'd ask for more info and have someone test TCP checks on each of the ports individually (at least 6543 and 6549) to see which cause crashes and/or deadlocks. Oh, and a good debug bt would be nice... ;)
12:45*janneg curses kmail which can't handle suspend to ram while being connected
12:45<sphery>It seems monit just does a select on the TCP port checks so I can write a little program to do that without monit, but it will probably be at least a month before I get a chance.
12:45-!-dash [] has joined #mythtv
12:45-!-dash [] has left #mythtv []
12:46<sphery>(I have other myth things at higher priority.)
12:47<jams>sphery- what do you want checked?
12:47<gbee>sphery: feel free to make that request yourself, I'm happy to do it, but I'm sure no-one would mind if you did
12:48<gbee>I'd like to know whether the issue can be replicated with trunk, so many thinks have changed since 0.20
12:50<sphery>jams: on #4360, someone reported what sounds like a deadlock when doing monit TCP checks on ports 2422 (mtd), 6543 (mbe), 6544 (mbe HTTP status), and 6549 (UPnP). I'd like someone to test each port individually to see which causes crashes/deadlocks. Ideally, the tester would be running current trunk with the patch on #4381 applied (and would be able to get a backtrace when it fails).
12:50<sphery>oops, yeah. what he said
12:51<jams>so the patch is already in trunk or it must be applied?
12:52<gbee>not in trunk yet
12:52<sphery>The patch on #4381 needs applied. If you disable the miscellaneous status information script, testing without that patch is not a problem.
12:53<sphery>Oh, and really we only need a test on trunk, not on 0.20-fixes.
12:54<jams>i will see if the port checks can be added to my hobbit instance.
12:58<jams>any mention of how long it takes to lock?
12:58<sphery>From my read of the ticket, it sounds like it happens really fast.
12:58*jams reads the ticket
12:59<sphery>which port are you trying first? I'd do the mtd port last (2422)
13:00<jams>i'm going to try them all at once to check that I can reproduce it. then go from there
13:00<sphery>that's a /very/ good idea. :)
13:00<jams>how does one didable the miscellaneous status script?
13:02*gbee updates his checkout of multirec
13:02<sphery>make sure there's no script name in "Miscellaneous Status Application" in mythtv-setup (by default there is none). If you want to check via MySQL, ensure SELECT data FROM settings WHERE value = 'MiscStatusScript'; returns a blank string
13:03<jams>yep it's empty
13:03<sphery>Cool. Then you won't get hit with the bug in the misc. status stuff.
13:04<jams>just did a fresh test install, so you had decent timing.
13:04-!-tafsen [] has quit ["Konversation terminated!"]
13:05-!-Bullzeye [] has joined #mythtv
13:11<sphery>jams: any deadlocks?
13:11<jams>not yet
13:12<jams>still working on adding mtd though
13:12<sphery>According to , the TCP check issue may actually be fixed in trunk, too.
13:13<sphery>I'm starting to think--based on that and your testing--that #4460 can be closed (fixed in trunk/won't fix 0.20.2)
13:14<jams>had the wrong port for mtd..but it's going now
13:15<sphery>Sorry. Didn't look it up--just went on what the ticket said.
13:16<jams>just going to let this run for a bit. it does a check every 5 minutes.
13:18<sphery>Ooops. Ticket was right. I can't type.
13:18<jams>yeah i noticed that but wasn't going to say anything
13:18<mru>would you like a copy of my lighttpd configuration for mythweb? I see the sample is still blank in svn
13:19<sphery>Wow, you're doing the test for me and not correcting me when I'm wrong. You're way too kind.
13:19-!-S2 [] has quit [Remote closed the connection]
13:19<sphery>mru: attach it to a ticket with component MythWeb ( )
13:20<gbee>just seen an new error, watching a recording and halfway through it exits with "Failed to reinit video"
13:21<gbee>looks like the video was corrupted at that point, can seek past it and everything is fine ...
13:22<jams>oops this test is invalid.
13:22<jams>i'm only scanning the output of netstat..not really actively hitting the ports
13:22<jams>i will fix that and get back to you
13:23<sphery>oh. monit does a select. Is that an option with hobbit?
13:23<jams>i would have to write the test
13:24<sphery>"monit will open a connection to this port (TCP or UDP) and check that it is possible to send and recieve data from the port (via the select system call or test for an ICMP error in case of udp)
13:24-!-reynaldo [] has quit ["leaving"]
13:24<sphery>It seems the nagios check_tcp does a similar thing
13:24-!-reynaldo [] has joined #mythtv
13:28<jams>found the spot.
13:28<jams>one moment while i add everything in.
13:32-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
13:33<jams>actively checking the ports, now to wait
13:34-!-reynaldo [] has quit ["leaving"]
13:39<gbee> and wait ...
13:39<sphery>I compiled (didn't install) nagios, and have it running check_tcp against 6543 in a loop, and it's not locking (though it seems the response time is continually increasing)
13:39<sphery>It's probably hit it 10k times or so...
13:40<sphery>up to 0.009s. Started at more like 0.00002s
13:41<gbee>not sure I see the need for monitoring post 0.21, I can't remember the last time my backend crashed, must be at least 8/9 months
13:44<sphery>Yeah, but some seem to monitor everything. I don't monitor and my system is rock-solid stable (after I finally gave up on trying to make do and replaced a motherboard with a bad chipset--before and after that bad M/B, it's never had problems).
13:45<sphery>I was wondering if it was the check_tcp program causing the increased response time, but I stopped and restarted check_tcp and it resumed at the same response time. Restarted mbe, and the response time went back down.
13:45<sphery>I'm back to 0.01s
13:46<jams>sphery- it looks fine here.
13:46<jams>no increase in repsonse time no locks
13:49<sphery>gbee: It sounds like #4460 should be closed as a dup of #4174 based on and jams's tests with a comment that it won't be fixed in 0.20-fixes and that using a full HTTP request check against 6544 should be more stable in -fixes (though it may crash eventually)
13:49<sphery>heh... each time check_tcp hits the backend, it outputs: 2008-01-12 13:49:29.020 Unknown socket closing
13:50<jams>gbee- i only monitor cause it falls in line with other stuff i'm doing. Plus everybody loves graphs!
13:50<jams>sphery- yeah i see those to
13:51<sphery>log file is 2.5MB already and only 3834 bytes in other lines... :)
13:52-!-foxhunt [] has quit [Read error: 110 (Connection timed out)]
13:52<jams>backend memory usage went up slightly with those checks running.
13:52<jams>i'm just going to let it run for a while.
13:53<sphery>Yeah. I'm seeing a slight increase, too.
13:54<jams>oh time to renew my linux pro subscription
13:55<sphery>I'll check to see the response time/whether it's deadlocked after mowing the lawn...
13:57<jams>mowing the lawn? sheesh mines covered with snow/ice
13:58<mru>mine would be covered in rain if I had one
14:00<jams>mru did you also open 4462?
14:05<mru>forgot to add my email address
14:06<mru>do as you wish with the patch; I figured recording the information somewhere might save someone else's hair being pulled out in the future
14:07<sphery>jams: Florida. Only have to mow 12mos/yr. :)
14:10<mru>now if only mythtv-setup would work over ssh...
14:21<gbee>sphery: is there an increase in memory usage as well, or cpu?
14:22<gbee>doh, didn't finish reading scroll back
14:22<jams>for me it was just memory, but that seems to have leveled off.
14:27<gbee>ok, good enough for me, I'll close the ticket as fixed
14:28-!-reynaldo [] has joined #mythtv
14:28<gbee>it may be spawning new threads to deal with concurrent requests and then reaching a limit on the number, but that's just speculation until I actually look at it
14:29<gbee>the increasing reponse time doesn't fit that theory, so maybe not
14:35-!-dekarl [] has quit [Read error: 54 (Connection reset by peer)]
15:03-!-feiner [] has quit [Read error: 110 (Connection timed out)]
15:18-!-xris [] has joined #mythtv
15:22<gnome42>janneg: A little something I noticed while cruising transcode.cpp
15:46<sphery>gbee: It was definitely increasing memory usage. I started at < 6% (of 512MB) RAM and when I killed the polling loop, it had gotten to 14.9%.
15:46<sphery>CPU was maxed at 100% (had been at about 60% when started), and was getting very small response time (0.0002s) about 4 times, then very large (1s) one time, repeating.
15:47<sphery>Memory increase seems to fit the thread leak theory. The response time was rising linearly when I first started, but seemed to have changed when the CPU maxed out.
15:48<sphery>But, now that I killed the tcp_check loop, it's running just fine--listening on 6543, clients can hit the backend and it serves things as fast as always and CPU has gone back to normal (almost nothing).
15:49<sphery>Granted, mine was a torture test (with millions of tcp_check pings), so it's not likely to be much of an affect on any real-world usage.
15:53-!-mattwire [] has joined #mythtv
15:56-!-xris [] has quit []
15:56-!-xris [] has joined #mythtv
15:56<sphery>If gdb would see all the leaked threads, it's not a thread leak--only 17 threads (which should be about right). So, perhaps just a mem leak in the code that handles the network. May have to valgrind it.
16:07<gnome42>janneg: No need to look at the "[mythtv-users] Live TV problem in multirec" thread. Problem was elsewhere.
16:11-!-feiner [] has joined #mythtv
16:18-!-_gnome42 [] has joined #mythtv
16:19-!-gnome42 [] has quit [Read error: 104 (Connection reset by peer)]
16:21<sphery>Hmmm. There are many places in mythtv-setup that no longer work at 800x600.
16:22-!-_gnome42 is now known as gnome42
16:23<jams>just like the recent deinterlace screen doesn't fit 800x600
16:24<sphery>Yeah. I'm sure mythfrontend settings has many, also.
16:26<mru>who would use 800x600 anyway?
16:27<mru>it's too high for an SD TV and lower than anything else
16:29<sphery>anything lower than 800x600 won't work, either (though IME the NVIDIA TV out did better with the GUI rendered at 800x600 or 1024x768)
16:30<jams>sphery- think the port test has run long enough? memory usage has levelled out and no deadlocks have occured
16:32<mru>sphery: it is possible to craft an X modeline that outputs a tv-compatible signal on the vga port
16:32<sphery>Yeah. I think closing #4460 is good--I'm much more comfortable saying so thanks to having your test as well as mine. So, thanks for helping.
16:32<sphery>I may look into whether I have found a mem leak, but it's low priority
16:33<sphery>mru: with drivers that work right... :)
16:36-!-inkynoo1 [n=stuporgl@] has joined #mythtv
16:36-!-inkynoo1 [n=stuporgl@] has left #mythtv []
16:37-!-Bentley__ [] has joined #mythtv
16:38-!-Bentley__ [] has left #mythtv ["Leaving"]
16:42<sphery>Ooops. Guess mythtv-setup's fine at 800x600. Just the frontend settings that have issues.
16:45-!-erik__ [] has quit ["Lämnar"]
17:03<tuppa>hi all, who's the best person to talk to with modifying OSD menu entries?
17:09<sphery>tuppa: what kind of mod?
17:10<tuppa>sphery: adding more entries in
17:10<sphery>that do what?
17:10-!-guest_ [] has joined #mythtv
17:12<gbee>tuppa: adding new entries is easy, it's what they do which might be harder and are you asking here because you want to write the code, or because you want someone else to do it?
17:12<tuppa>I'm looking at writing/changing the code myself
17:13<tuppa>just for experimenting around atm
17:13<sphery>If it's just adding things that are easily accessible through the keys, you may find resistance since the OSD menu is already huge enough.
17:14<gbee>from memory you want to look at osd.cpp/h and/or osdtypes.cpp/h in libmythtv
17:14<tuppa>gbee: thanks, will have a look there
17:16-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"]
17:20-!-mattwire [] has quit [Read error: 113 (No route to host)]
17:22-!-mattwire [] has joined #mythtv
17:28-!-Syphn [] has quit []
17:38-!-mattwire [] has quit [Read error: 113 (No route to host)]
17:40-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
17:43-!-mattwire [] has joined #mythtv
17:47-!-foxhunt [] has joined #mythtv
18:01-!-mzb [] has quit ["Time to quit"]
18:02-!-mzb [] has joined #mythtv
18:04-!-mattwire [] has quit [Read error: 110 (Connection timed out)]
18:06-!-mattwire [] has joined #mythtv
18:07-!-davilla [] has joined #mythtv
18:09-!-foxhunt [] has quit [Remote closed the connection]
18:09-!-RogerM [n=chatzill@] has quit [Read error: 104 (Connection reset by peer)]
18:17<gbee>multirec crashed my backend :/
18:19-!-Dibblah [] has quit [Read error: 104 (Connection reset by peer)]
18:22-!-Dibblah [] has joined #mythtv
18:26-!-mattwire [] has quit ["Leaving"]
18:39<gnome42>gbee: misbehaving for you again? It was a bit of a train wreck last time too as I recall. :/
18:39-!-grokky [] has joined #mythtv
18:39<gnome42>got any info? logs etc.
18:39<GreyFoxx>gbee: crashed the process or the entire box died ?
18:40<gbee>the process
18:40<GreyFoxx> So far I've had no problems at all with it in months
18:40<GreyFoxx>hopefully it's something you can reproduce
18:40<gbee>gnome42: logs, I'll check that now and if I can reproduce it tomorrow I'll get a backtrace
18:41<gbee>dual tuner system, at the time two scheduled recordings were in progress and I was changing channels in livetv
18:41<gnome42>gbee: cool. No time ATM but I'll look later/tomorrow.
18:43<gbee>are the " seconds until" messages normal? log is full of them
18:43<gnome42>yeah, it's not perfect in that whole livetv while recording channel surfing area. But shouldn't crash obviously :)
18:44<gnome42>yeah daniel recently reenabled that debugging stuff
18:44<gnome42>not sure if he meant to or not though :)
18:45<gnome42>gotta run.
18:46-!-FyreFoX [] has joined #mythtv
18:48<gbee>log is worthless, I'll try to reproduce, a backtrace would be more valuable
18:49<FyreFoX>hi is there a way to make mythtv auto refresh the video list instead of having to goto setup/video manager each time .. ?
18:49<sphery>FyreFoX: try #mythtv-users
18:50<FyreFoX>oh. oh sorry! I didnt even read the topic.
18:50-!-FyreFoX [] has left #mythtv []
18:51<gbee>one of the reasons I'd like to see multirec in trunk soon is so that there is more time to spot any problems with a wider test group
18:53<gbee>when trying to change to an unavailable channel you just get bounced to a previous channel with no explanation, shouldn't be hard to use the existing status container to flash up a "channel unavailable" message
19:07-!-jason [n=jason@] has joined #mythtv
19:07-!-jason [n=jason@] has left #mythtv ["Leaving"]
19:08-!-Bullzeye [] has quit ["get satisfied! • :: ««« (Gamers.IRC) »»» ::"]
19:09-!-rn114 [] has quit [Read error: 104 (Connection reset by peer)]
19:09-!-rn114 [] has joined #mythtv
19:46-!-mzb [] has quit [Read error: 110 (Connection timed out)]
19:48-!-candrews [i=candrews@gateway/tor/x-070c51485bfbb5ef] has joined #mythtv
19:51-!-mzb_d800 [] has quit ["Time to quit"]
19:52-!-mzb_d800 [] has joined #mythtv
19:53-!-davilla [] has quit ["Leaving"]
19:55<candrews>I'm hoping one of you fine fellows will be able to help me complete the mythcontext restructure patch
19:55<candrews>unfortunately, my ninja skills are not terribly applicable to this build process.
19:55<candrews>The ticket is at:
19:58<candrews>don't all raise your hands at once :-)
19:58<candrews>Well, I'm dying to get this straightened away, as it prevents me from using Mythtv, and I'm sure it bugs lots of distro managers too.
19:58<candrews>I'm reachable on the mailing list, and there is some discussion there too.
20:01-!-Ice_Wewe [] has joined #mythtv
20:01<Ice_Wewe>can someone help me? I'm trying to run mythtranscode from the command line and it isn't properly detecting the aspect ratio. The aspect ratio on the original video is 4:3 and on the encoded it's 6:3
20:02-!-reynaldo_ [] has joined #mythtv
20:04-!-MavT [] has quit ["Leaving"]
20:10-!-Ice_Wewe [] has left #mythtv ["Ex-Chat"]
20:14-!-reynaldo [] has quit [Read error: 110 (Connection timed out)]
20:23-!-briand [] has quit [Read error: 110 (Connection timed out)]
20:24-!-briand [] has joined #mythtv
20:34-!-reynaldo_ [] has quit ["leaving"]
20:34-!-reynaldo [] has joined #mythtv
21:02-!-jadams_ [n=jadams@] has joined #mythtv
21:02-!-jadams_ [n=jadams@] has left #mythtv ["Leaving"]
21:24-!-reynaldo [] has quit ["leaving"]
21:25-!-reynaldo [] has joined #mythtv
21:41-!-candrews [i=candrews@gateway/tor/x-070c51485bfbb5ef] has quit [Remote closed the connection]
21:41-!-rn114 [] has quit [Read error: 113 (No route to host)]
22:18-!-grokky [] has quit []
22:22-!-beandog [n=sdibb@gentoo/developer/beandog] has joined #mythtv
22:23-!-guest_ [] has quit [Client Quit]
22:31-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"]
22:34-!-mzb [] has joined #mythtv
23:04-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
23:05-!-jhatch [] has joined #mythtv
23:17-!-rtsai [n=rtsai@] has joined #mythtv
23:30-!-Chutt [] has quit [Remote closed the connection]
---Logclosed Sun Jan 13 00:00:15 2008