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

---Logopened Wed Jan 09 00:00:01 2008
---Daychanged Wed Jan 09 2008
00:00-!-rtsai [n=rtsai@] has quit ["leaving"]
00:10-!-leprechau [] has quit ["Leaving"]
00:12-!-leprechau [] has joined #mythtv
00:15-!-guest_ [] has quit [Client Quit]
00:18-!-rtsai [n=rtsai@] has joined #mythtv
00:24-!-PointyPumper [] has quit [Read error: 110 (Connection timed out)]
00:31-!-xris [] has quit [Remote closed the connection]
00:31-!-xris [] has joined #mythtv
00:53-!-feiner [] has quit [Remote closed the connection]
00:53-!-feiner [] has joined #mythtv
00:54-!-iotis [] has joined #mythtv
00:55<iotis>got a nexus-s question if some can help
00:56-!-feiner [] has quit [Remote closed the connection]
00:56-!-iotis [] has left #mythtv []
00:57-!-feiner [] has joined #mythtv
00:59-!-feiner [] has quit [Remote closed the connection]
01:04-!-feiner [] has joined #mythtv
01:04-!-cattelan [] has joined #mythtv
01:05-!-feiner [] has quit [Remote closed the connection]
01:05-!-feiner [] has joined #mythtv
01:20-!-cattelan [] has quit ["This computer has gone to sleep"]
01:41-!-mzb [] has quit ["Time to quit"]
02:01-!-PointyPumper [] has joined #mythtv
02:04-!-davilla [] has quit ["Leaving"]
02:07-!-Puhi [] has joined #mythtv
02:14-!-gnome42 [] has quit [Remote closed the connection]
02:20-!-xris [] has quit []
02:22-!-psm321 [] has quit [Read error: 110 (Connection timed out)]
02:29-!-xris [] has joined #mythtv
02:29<rooaus>Anduin: np, I probably should have done it that way first time round. :)
02:38-!-xris [] has quit []
02:41-!-Chutt [] has quit ["Leaving"]
02:51-!-reynaldo [] has quit ["Lost terminal"]
02:56-!-psm321 [] has joined #mythtv
02:58-!-Chutt [] has joined #mythtv
03:04-!-Chutt [] has quit ["Leaving"]
03:09-!-degreseven [] has quit [Remote closed the connection]
03:12-!-htpcdvbs [] has quit [Read error: 104 (Connection reset by peer)]
03:17-!-Chutt [] has joined #mythtv
03:18-!-kuil [] has joined #mythtv
03:20-!-kuil [] has left #mythtv []
03:33-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"]
03:40-!-rn114 [] has joined #mythtv
04:18-!-rn114 [] has quit [No route to host]
04:22<laga>that guy in bug #147440 probably shouldn't be running gutsy..
04:22<laga>err, hardy
04:24<janneg>we might have to many open tickets but that bug number is more than one order of magnitude off
04:27<laga>darn, wrong channel
04:28*laga needs to wake up before going on irc
04:29<laga>no caffeine for me :)
04:29<stuarta>i need a cup of tea
04:29<stuarta>haven't had any caffiene yet
04:56-!-Beirdo [n=gjhurlbu@unaffiliated/beirdo] has quit [Read error: 110 (Connection timed out)]
04:59-!-adamsweet [n=adam@] has joined #mythtv
05:00-!-adamsweet [n=adam@] has left #mythtv ["Leaving"]
05:20-!-johnp__ [] has joined #mythtv
05:26-!-Dave123 [] has quit [Read error: 110 (Connection timed out)]
05:28*justinh waves
05:28<justinh>nice to be back at work again, happy happy joy joy :-\
05:42*johnp__ considers submitting YA eit patch
05:42<johnp__>yet another
05:43<stuarta>haven't started testing 10 yet, so if you are planning to then i'll skip straight to 11
05:44<johnp__>it might be worth holding off a bit, it's a bit of a major rewrite
05:44-!-Dibblah [] has quit [Remote closed the connection]
05:44<johnp__>I could just break it down into sub patches ?
05:44<stuarta>what's on the cards?
05:46<stuarta>redoing the [S,SL,AD] handling would be 1
05:46<johnp__>I think it just removes those at the moment. (I use mythweb)
05:47<stuarta>now that we pick up those from the eit descriptors it's probably wise to just rip them out
05:47<stuarta>except for the SL handling
05:47<stuarta>that's not described in the EIT descriptors AFAIK
05:48<johnp__>Ah right.
05:48<stuarta>not that it's terribly accurate ATM
05:48<stuarta>there seems to be an awful lot of stuff being tagged as SL
05:49<stuarta>when i wouldn't expect it to be.
05:49<stuarta>but, as i'm not near a telly during the day, it's hard to check
05:49<johnp__>(dunno about you but I get loads of stuff marked as HD ready)
05:50<stuarta>i didn't yesterday
05:50*stuarta checks again
05:50<stuarta>non of the ironsides
05:51<janneg>that's an error in the code and it looks like it is a compiler error
05:51<stuarta>nah, mine still fine
05:51<stuarta>perhaps we need to rewrite it to get around the compiler bug?
05:52<johnp__>I even get radio shows marked as HD :)
05:54<janneg>johnp__: have you tried the patch I offered yesterday
05:54<johnp__>janneg:No difference
05:56<johnp__>Actually I'm not sure it's in the backend, I think it's probably in the translation to mythweb
05:56<janneg>ok, then it's triggered at a different place
05:57<janneg>no, it's the DBEvent constructor being miscompiled
06:05<gbee>johnp__: I've not seen the problem here with mythweb and I've been using the properties from xmltv for a few months, so it's more likely to be the bug Janneg is describing
06:06<johnp__>agreed, just checked the actual status on the backend and it concurs.
06:13-!-zedman4068 [n=hannah@] has joined #mythtv
06:17<johnp__>stuarta: what about "deaf signed" ?
06:18<gbee>information doesn't seem to be in EIT data as a component descriptor
06:18<stuarta>deaf signed = SL
06:20<stuarta>gbee: that's most likely since it's not actually a component :)
06:22*stuarta mumbles about the strange little person in the corner of the screen
06:30<janneg>johnp__: please try this patch with a debug build
06:36-!-Dibblah [] has joined #mythtv
06:39*johnp__ recompiling
07:03<johnp__>janneg: assert audioProps < 0x40 failed
07:12<janneg>it shouldn't. please generate a bt
07:18<stuarta>janneg: your on 64bit same as me aren't you?
07:18<stuarta>johnp__: you running 32 or 64bit?
07:19<stuarta>okolsi: 32bit or 64bit?
07:19<johnp__>just got a slightly different error, now on the videoProps
07:19<johnp__>I'll generate a bt
07:20<okolsi>stuarta: 32bit
07:21-!-grokky [] has joined #mythtv
07:23<stuarta>so it's possible it's a 32bit vs 64bit thing
07:27*stuarta wanders off to lunch
07:39<janneg>johnp__: thanks
07:40<janneg>looks different from what I was seeing with my optimized debug build
07:40<janneg>yes, I'm on 64bit
07:41-!-_splat1 is now known as splat1
07:43-!-lsobral [n=sobral@] has joined #mythtv
07:51-!-i3ooi3oo [] has quit [Read error: 110 (Connection timed out)]
08:00-!-grokky [] has quit []
08:04<janneg>johnp__: please apply too. if the asserts in this don't trigger I have look at the object code
08:10<johnp__>just on it's own ?
08:15<janneg>johnp__: no in addition to the other patch
08:16<johnp__>hang on, need to recompile :)
08:28<johnp__>janneg:mythbackend: eithelper.cpp:298: void parse_dvb_component_descriptors(desc_list_t, unsigned char&, unsigned char&, unsigned char&): Assertion `audio_properties < 0x40' failed.
08:43<janneg>argh, try initializing
08:43<janneg>subtitle_type, audio_props, video_props with 0 in eithelper.cpp line 335
08:44<janneg>johnp__: ^^^
08:46<janneg>or just svn up
08:55-!-i3ooi3oo [] has joined #mythtv
08:58<johnp__>janneg:seems to be a lot better.
09:05<janneg>yeah, it was obvious but I was seeing a different issue yesterday
09:08*johnp__ wandering off into the distance
09:19-!-Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:26-!-ivor_ [n=ivor@kde/developer/ivor] has joined #mythtv
09:26-!-ivor_ is now known as ivor
09:40-!-Beirdo [n=gjhurlbu@unaffiliated/beirdo] has joined #mythtv
09:44-!-moodboom [] has joined #mythtv
10:33-!-fstxx [] has joined #mythtv
10:33-!-jgarvey [] has joined #mythtv
10:35-!-reynaldo [] has joined #mythtv
10:39<stuarta>stupid server at
10:39<stuarta>sending me spam challenge emails
10:40<stuarta>they can f3$% right off
10:59-!-dekar1 [] has joined #mythtv
11:08<Daviey>stuarta: better than challenge/response emails to a fscking mailing list!
11:08<Daviey>which happend to a uk lug
11:10<stuarta>all i did was post to -dev
11:13<stuarta>and if they can't be bothered to sort there cfap out them i'm not going to approve myself
11:14<djc_>CR is spam
11:15-!-dekarl [] has quit [Read error: 110 (Connection timed out)]
11:36-!-xris [] has joined #mythtv
11:46-!-gnome42 [] has joined #mythtv
11:50-!-peoples [] has joined #mythtv
12:14-!-peoples [] has quit ["Leaving"]
12:45-!-xanium4332 [] has joined #mythtv
12:52-!-feiner [] has quit [Remote closed the connection]
13:03-!-foxhunt [] has joined #mythtv
13:10-!-rbellamy [n=rbellamy@pdpc/supporter/silver/rbellamy] has joined #mythtv
13:10-!-rbellamy [n=rbellamy@pdpc/supporter/silver/rbellamy] has quit [Client Quit]
13:14-!-rbellamy [n=rbellamy@pdpc/supporter/silver/rbellamy] has joined #mythtv
13:21-!-rbellamy [n=rbellamy@pdpc/supporter/silver/rbellamy] has quit [Read error: 104 (Connection reset by peer)]
13:28-!-foxhunt [] has quit ["Leaving"]
13:38-!-czth [n=dbrobins@nat/microsoft/x-534974e1013f7929] has joined #mythtv
13:44<janneg>does someone use "record only this showing" rules? I've heard reports they don't get deleted after successfully finishing
13:44<Chutt>mythfilldb should clean them up
13:46<gnome42>janneg: I use that all the time for testing ... let me check
13:49<janneg>Chutt: which is bad for EIT only users and we have moved the cleanup of recording rules to the housekeeper
13:52<gnome42>judging from my record table they are being cleaned up by something. I do run mythfill daily though.
13:54<janneg>gnome42: that doesn't count but I assume for now that the move to the housekeeper was after 0.20 and the user uses 0.20*
13:54<gnome42>oh, ok
13:55<janneg>even if he doesn't answer that question
14:01<gbee>janneg: I had a suspicion that they weren't being cleaned up, but I've never got around to checking
14:02<xanium4332>have the recent patches for h264 playback (BBC HD) been integrated yet?
14:04<GreyFoxx>janneg: I use those type of recordings a lot
14:04<gbee>anyone know the dupmethod or other identifying columns for "record only" and "find one" rules? I don't have time to look them up, but can check the database directly
14:14<janneg>gbee: find one rules are cleared
14:15<janneg>the user uses 0.20-fixes from gentoo
14:16-!-jgarvey [] has quit ["Leaving"]
14:16<sphery>Yeah. For 0.20-fixes, users should still run mythfilldatabase occassionally--even EIT-only users.
14:16<sphery>Some of the cleanup got moved to housekeeper in -fixes when j-rod was fixing channel scanning, but I don't think the record table cleanup did.
14:17<j-rod>doesn't ring a bell, no
14:18<janneg>sphery: thanks
14:18*j-rod just got done converting lirc_dev to use kthread, the last major obstacle before the lirc drivers are ready to head to lkml for review...
14:18<j-rod>(well, I still need to test to make sure it actually works... but hey, it compiles!)
14:19<j-rod>superm1: ^^^
14:19<sphery>When you were fixing channel scanning in -fixes and trying to figure out what all had changed and you spent many days (> a week?) on it, and it was easier to merge a group of revs than to test all the changes. Then again, I may be wrong (going from memory). But, however the cleanup got to -fixes, it's probably a good thing for many.
14:20<j-rod>yeah, ended up being a fairly large chunk of stuff. I've since stopped paying much of any attention to 0.20 tho...
14:20<gbee>I can't figure out where the rectype for recording rules is stored ...
14:20<janneg>j-rod: that's enough. I've commited last night after I fixed all conflicts in mythtv-qt4 and the second commit was after it compiled successfully
14:20<j-rod>cool, good
14:21<gbee>heh, overloked the "type" column in record ...
14:21<gnome42>gbee: not the second field (type) in the record table?
14:21<j-rod>I'm afraid my involvement with mythtv of late hasn't been much more than building the latest svn trunk once every few weeks
14:21<janneg>gbee: libs/libmythtv/recordingtypes.h
14:21<gbee>gnome42: yeah, it is, I just couldn't see the wood for the trees
14:21<xris>grumble.. irc client is messed up
14:21<j-rod>(well, and beating on lirc and firewire in the kernel)
14:21-!-xris [] has left #mythtv []
14:21<gnome42>gbee: :)
14:21-!-xris [] has joined #mythtv
14:21-!-xris [] has left #mythtv []
14:21-!-xris [] has joined #mythtv
14:22<gbee>janneg: thanks, I'd already got that and the values, just couldn't find the column I was looking for
14:22<xris>ah, much better
14:22-!-Chutt [] has quit ["Leaving"]
14:22<janneg>yeah, I misread your question
14:22-!-Chutt [] has joined #mythtv
14:23-!-ivor [n=ivor@kde/developer/ivor] has quit [Read error: 110 (Connection timed out)]
14:25<gbee>ok, assuming I'm mapping the correct integer value to the enum, all the "record this showing" rules have been cleaned up, but there are a number of Find One rules which haven't
14:26<gbee>it was the "find one" rules which originally got me thinking about this, let me just crosscheck those rules
14:26-!-foxhunt [] has joined #mythtv
14:27<janneg>find one should be 6, please check if the you have a recording for the old find one rules
14:27<gnome42>j-rod: chat in -users? Re: bttv irq errors
14:28<sphery>My find one's are getting cleaned up--except when the schedule changes and the show (usually a movie) isn't aired (i.e. it hasn't been recorded, yet).
14:28-!-lsobral [n=sobral@] has quit [Read error: 104 (Connection reset by peer)]
14:28<gbee>janneg: so find one rules aren't deleted so long as the recording still exists?
14:29<gbee>sphery: I'm seeing titles I know have been recorded still listed
14:29<j-rod>gnome42: I stay away from -users if I can help it. :)
14:29<j-rod>unfortunately, that sounds a bit like the problem we've got a customer hitting...
14:29<sphery>Mine are deleted even though the shows exist.
14:29*j-rod joins
14:31<janneg>gbee: no, they aren't cleaned if no recording was made
14:31<gbee>sphery: well it makes more sense for them to still be around so that you can do "delete and allow re-record"
14:31-!-lsobral [n=sobral@] has joined #mythtv
14:31<janneg>gnome42, j-rod: why not chatting in #linuxtv?
14:31<gbee>janneg: no, I'm talking about shows that are in my list of recordings (still on the drive) but the "find one" rule is still in the record table
14:32<j-rod>janneg: would actually be #v4l for this one... I asked around there a while ago, didn't get anywhere
14:32<j-rod>main thing I'm trying to do right now is reproduce the problem, not actually actively working on it beyond that
14:32<gbee>but aside from those examples, I can't find anything in the list of "find one" rules that I'm certain were previously recorded, watched and deleted
14:32<janneg>j-rod: sure, me too
14:33<janneg>gbee: the only find one rules in my database are future rules and 2 or 3 missed recordings
14:35<gnome42>The v4l people do not want to acknowledge this issue :/
14:35<sphery>j-rod: You're off the hook. Guess it wasn't you who moved the cleanup... It got moved over because the version in mythfilldatabase in 0.20.x was not MySQL 3-compliant. [11458]
14:35<gbee>janneg: 90% of my find one rules are missed recordings (didn't record because of conflicts), 5% are films which recorded and are still available and the other 5% I'm not sure about
14:35<j-rod>sphery: yay me! :)
14:36<janneg>gnome42: is there anyone actively working on bttv?
14:36<gbee>I've 166 findone rules
14:37<janneg>I have only 18
14:39<sphery>gbee: ./programs/mythbackend/housekeeper.cpp +542
14:39<sphery>Don't know if that includes find one rules
14:39<sphery>Guess find one is on +550
14:41<gbee>hmm, is it just me or is the problem line 566?
14:41<gnome42>janneg: not sure about that. There are regressions being introduced and it is obvious that the v4l patches aren't even getting basic sanity check before being sent to the kernel. Kinda sad :(
14:41<sphery>It keeps it for 14 days... I remember Bruce saying why on a post, but don't remember the why. I'll see if I can find it.
14:42<beata>is there anyway to do a mass delete of recordings from mythweb?
14:42<GreyFoxx>beata: nope
14:42<gbee>sphery: yeah, I'm just seeing potential for a problem where oldfind it cleared out and that stops the query on 551 from returning results, resulting in orphaned find one rules
14:43<gbee>"oldfind.findid IS NOT NULL"
14:43<beata>hmmm *makes mental note to see if he can implement that
14:44<sphery>gbee: ?
14:44<sphery>(not the one I was talking about, but maybe you got some bad rules during the period it was broken)
14:45<justinh>I imagine any 'mass delete' button needing a serious load of confirmation popups to prevent mistakes...
14:46<gbee>sphery: just checked, I have a few :) ~51
14:47<sphery>can you tell if there were around the time it was broken?
14:48<gbee>sphery: I've fixed them already, so not easily
14:49<gbee>the one I noted in particular was created in mid-December though, it recorded and was deleted, but that could just be the odd one out
14:49<sphery>gbee: I think this is the reason for the 14 days... (David and Bruce's parts of the message)
14:50<sphery>Might be a bug in the rule creation in MythWeb or mythfrontend (though I think I've used MythWeb on my recent ones).
14:50<gbee>sphery: right
14:51<gbee>none of the rules in my record table match anything in oldfind, suggesting they've all been orphaned there
14:52<gbee>well the ones I know have been recorded anyway
14:54<GreyFoxx>bill: what do you want to know ?
14:54<sphery>My production system has no find one's, but my dev system (with a DB snapshot from a month ago) has 6. The 6 shows were recorded on my production system and the rules cleaned up. Though I am running mfdb on production, I didn't see any code deleting from record in there.
14:54<gbee>I'll assume for now that the issue in #452 was the cause of the problem, I don't have time to go bug hunting right now
14:55-!-xanium4332 [] has quit [Remote closed the connection]
14:56<sphery>I'm more interested in the other stuff you've been working on, anyway. (Selfish of me since I don't have any find one issues... ;)
14:58-!-xris [] has quit []
14:59-!-xanium4332 [] has joined #mythtv
15:13-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
15:13-!-johnp__ [] has quit [Read error: 104 (Connection reset by peer)]
15:14<gbee>Chutt: btw, fixed that mythuibutton background bug, mythuistatetype wasn't preserving object visibility on copyfrom
15:35-!-foxhunt [] has quit ["Leaving"]
15:40-!-ivor [n=ivor@kde/developer/ivor] has joined #mythtv
15:46-!-moodboom [] has quit [Remote closed the connection]
15:47-!-mattwire [] has joined #mythtv
15:58-!-moodboom [] has joined #mythtv
15:59-!-mattwire_ [] has joined #mythtv
16:02-!-guest_ [] has joined #mythtv
16:05-!-moodboom [] has quit [Remote closed the connection]
16:10-!-ivor [n=ivor@kde/developer/ivor] has quit [Connection timed out]
16:11-!-xris [] has joined #mythtv
16:12*stuarta twiddles his thumbs
16:13-!-mattwire [] has quit [Read error: 113 (No route to host)]
16:13<GreyFoxx>stuarta: Was it you that was graphing the memory usage of the myth apps?
16:14<GreyFoxx>What fields from /proc/PID/stat were you grabbing ?
16:14<GreyFoxx>I resetup cacti on my systems and figured I'd graph use of the backend and frontend processes too
16:14<stuarta>VmRSS, VmSize, VmPeak
16:15<GreyFoxx>just looking at the CPU usage when playing QAM recordings versus PVR recordings was a shock
16:15<GreyFoxx>The 3 peaks in the middle are PVR recordings being played (720x480) with the yadif deinterlacer
16:16<GreyFoxx>the rest around it are QAM (528x480) with yadif
16:16<stuarta>what's different about the QAM recordings
16:17<stuarta>both of those output mpg streams
16:17<stuarta>don't they?
16:17<GreyFoxx>ummm, PVR are 720x480, mp2v, mp2a mpeg2ps
16:17<GreyFoxx>QAM are mpeg2ts, 528x480, mp2v, ac3
16:18<GreyFoxx>granted bitrate on the PVR recordings is likely higher, so maybe that;s it
16:18<stuarta>ac3 audio takes more cpu to downmix tho
16:18<stuarta>(i think)
16:19<GreyFoxx>I'm gonna pick 1 QAM recoridng, and setup a recording profile to record something on the PVR card with the same resolution/bitrate
16:19<GreyFoxx>and then compare them
16:20<GreyFoxx>I was just a little shocked at how different it was between the two when I first noticed it last night
16:21<Chutt>less noise in the qam stuff
16:26*stuarta wanders off to the couch
16:31-!-ivor [n=ivor@kde/developer/ivor] has joined #mythtv
16:43-!-jgarvey [] has joined #mythtv
16:58-!-xanium4332 [] has quit ["Bye!"]
17:01-!-nullsmack [] has joined #mythtv
17:27-!-onixian [] has joined #mythtv
17:35<justinh>anybody in the UK noticed anything perculiar with recordings from channel 4 - my new FE is stutterring before & after ad breaks for a couple of secs. weird. gonna have to take a really good look at it this weekend I think
17:36<justinh>might even spot something we can use to give commflagging a helping hand
17:39<justinh>nothing in the frontend log about buffer problems or anything. got -v playback enabled too
17:39-!-lsobral [n=sobral@] has quit ["leaving"]
17:39-!-xanium4332 [] has joined #mythtv
17:40-!-tailsfan92 [] has joined #mythtv
17:40-!-tailsfan92 [] has left #mythtv []
17:42-!-tulbreak [] has joined #mythtv
17:43-!-moodboom [] has joined #mythtv
17:44-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
17:46-!-tulbreak [] has quit [Remote closed the connection]
17:47-!-i3ooi3oo [] has quit [Connection timed out]
17:48-!-purserj [] has joined #mythtv
17:51-!-Dibblah [] has quit [Remote closed the connection]
17:52-!-xanium4332 [] has quit ["Bye!"]
18:00-!-Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:04-!-xian__ [] has joined #mythtv
18:05-!-Dibblah [] has joined #mythtv
18:10-!-Dave123 [] has joined #mythtv
18:13<Chutt>xris, around?
18:13-!-onixian [] has quit [Read error: 110 (Connection timed out)]
18:14-!-mattwire_ [] has quit [Read error: 110 (Connection timed out)]
18:19-!-Chutt [] has quit [Read error: 104 (Connection reset by peer)]
18:19-!-rn114 [] has joined #mythtv
18:25-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
18:26-!-Chutt [] has joined #mythtv
18:36-!-xian__ [] has quit ["This computer has gone to sleep"]
18:39-!-purserj [] has joined #mythtv
18:39<clever>justinh: digital on channel 4?
18:41<clever>count be an odd contentration of key frames causing a short spike in the bitrate
18:43<clever>if you where to splice from a digital show to a digital comercial you could just basicaly start feeding the video at a key frame
18:43<clever>posibly right after a key frame to handle the fade to black
18:46-!-MrGandalf [] has joined #mythtv
18:51-!-zedman4068 [n=hannah@] has quit [Read error: 104 (Connection reset by peer)]
18:55<gbee>justinh: probably along the lines of what clever suggested, related to problem I've seen for a while on my low power frontend with near black (or white) scenes, large change in bitrate causes problems
18:56<gbee>it's especially a problem in my case with fade to black scene changes or programme<>ad transitions
18:56-!-reynaldo_ [] has joined #mythtv
19:01-!-reynaldo1 [] has joined #mythtv
19:14-!-reynaldo [] has quit [Read error: 110 (Connection timed out)]
19:15-!-moodboom [] has quit [Remote closed the connection]
19:16-!-ss3 [] has joined #mythtv
19:19-!-reynaldo_ [] has quit [Read error: 110 (Connection timed out)]
19:19<sphery>justinh, gbee: Do you have "Extra audio buffering" enabled (DecodeExtraAudio)
19:20<gbee>not afaik, let me double check though
19:21<sphery>It seems to work for me. I think the "hardware encoding" part of the help text should be removed as it seems useful on MPEG-2 from DVB.
19:21<sphery>(though I haven't traced to code to verify it's being used)
19:22-!-ss3 [] has left #mythtv []
19:22<sphery>oh, and I don't have UK channel 4, so ...
19:22<gbee>I'll give it a go :)
19:22<gbee>not tonight though, but I'll let you know how it works out
19:23<gbee>UPDATE settings SET data='1' WHERE value = 'decodeextraaudio';
19:24<sphery>and if anyone goes through the UI to set it, make sure you don't confuse it with "Aggressive Sound card Buffering" (which is generally a bad thing)
19:35<gbee>looks like it was enabled on all my other frontends, so I'm not sure why it was disabled on that one
19:36<gbee>are there any negative side effects to the setting, anyone know?
19:37<gbee>the help text seems to suggest there is no reason to disable it and a good reason to have it enabled ....
19:38<gbee>a bit like the setting below it, "warn if no audio output" ... what reason _wouldn't_ you want that enabled?
19:42<sphery>I don't think there's a reason to disable it. It does default to enabled. Perhaps it allows disabling it for low-powered hardware or something?
19:42<xris>Chutt: ping
19:43<gbee>sphery: I'll search commits tomorrow to find out, I'm curious
19:44<gbee>I may find out that I disabled it for a reason when I try it, but I really hope that it solves the problem
19:45<gbee>g'night all
19:47-!-ivor [n=ivor@kde/developer/ivor] has quit [Read error: 113 (No route to host)]
19:49-!-jgarvey [] has quit ["Leaving"]
19:53<sphery>gbee: From some guy named Isaac ;) (rest of thread has more info on why OP disabled it)
19:56<sphery>Oh, wait. OP needed it enabled.
20:00-!-rn114 [] has quit [Read error: 113 (No route to host)]
20:12<justinh>lemme just check that audio bufferring doozy
20:12-!-czth [n=dbrobins@nat/microsoft/x-534974e1013f7929] has quit [Read error: 104 (Connection reset by peer)]
20:13<justinh>disabled here. I'll tick it on & see how I go tomorrow
20:26-!-xris [] has quit []
20:34-!-dabtech [] has joined #mythtv
20:37-!-reynaldo1 [] has quit [Read error: 110 (Connection timed out)]
20:39-!-davilla [] has joined #mythtv
20:50-!-xris [] has joined #mythtv
21:02-!-reynaldo [n=rverdejo@] has joined #mythtv
21:04-!-reynaldo [n=rverdejo@] has quit [Client Quit]
21:08-!-rmeden [] has joined #mythtv
21:11-!-dabtech [] has quit []
21:22-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
21:56-!-Dein [] has joined #mythtv
21:59-!-jarle [] has quit [Read error: 110 (Connection timed out)]
21:59-!-jarle [] has joined #mythtv
22:11-!-cattelan [] has joined #mythtv
22:12-!-jamesd [] has quit [Remote closed the connection]
22:21-!-Dein [] has quit [Read error: 113 (No route to host)]
22:29-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
22:42-!-carvajal [n=carvajal@] has quit [Success]
23:05-!-davilla [] has quit ["Leaving"]
23:25-!-mzb [] has joined #mythtv
23:26-!-jamesd [] has joined #mythtv
23:26-!-loops [] has quit ["Leaving"]
23:40-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
23:46-!-PointyPumper [] has quit [Read error: 104 (Connection reset by peer)]
23:47-!-rmeden [] has quit ["Leaving."]
---Logclosed Thu Jan 10 00:00:40 2008