Back to Home / #mythtv / 2007 / 01 / Prev Day | Next Day
#mythtv IRC Logs for 2007-01-26

---Logopened Fri Jan 26 00:00:44 2007
01:13<xris>hmm, new firewire-detection code was very nice and WIPED my card info... not so cool.
01:14<Chutt>mentioned in the checkin and on the mailing lists
01:17<xris>just annoying, when it could theoretically be auto-updated
01:20|-|gnome42 [] has quit [Remote closed the connection]
01:25[~]xris patiently waits for his recording to finish so he can actually figure out which tuner is which.
01:26|-|Fooker [] has joined #mythtv
01:26|-|Fooker [] has left #mythtv []
01:28[~]xris wonders why he can't find the commit
01:30<xris>aha, finally
01:30<xris>must have been using an older rev than I thought
01:31<Chutt>i even knew about that, and i barely read the commits list :p
01:32<xris>trust me, I read it less than you. heh.
01:32<xris>I need to organize things better so that commits and tickets don't jumble up in the same mailbox.
01:39<siXy>Chutt, whats your view of using parts of myth in commercial applications?
01:39<siXy>subject to the erms of the GPL, obviously
01:40<Chutt>err, i don't care?
01:41|-|dgoodlad [] has joined #mythtv
01:41<Chutt>as long as the license is followed, everything's fine.
01:41|-|dgoodlad [] has left #mythtv []
01:42<siXy>would you like any special credits/ website links or anything? or are you completely not bothered?
01:42<xris>speaking of which, Chutt, do you have a preferred place that I can send (or not send) those people who keep asking about how to get in touch with devs about contract work?
01:42<Chutt>xris, not to me :p
01:43<Chutt>siXy, whatever you're willing to do.
01:43<xris>yeah, I think I've been saying to post once (and *only* once) to the -users list, but it seems like there should be a better place.
01:43<Chutt>most people using myth make it pretty obvious that they are.
01:43<Chutt>which is nice.
01:43<Chutt>xris, if it's a decent enough offer, the -dev list (once) would be appropriate.
01:44<xris>ok, cool.
01:44<xris>most of the time, they don't send any info about the offer.. rarely even a description of the job itsellf (justt enough that I usually know I'm not qualified).
01:44<Chutt>not one of those silly 'here's a 3 month idea that i'll pay someone $200 for'
01:45<xris>yeah, thatt's crap
01:46<Chutt>siXy, if you want to play nice, patches sent back are appreciated.
01:46<Chutt>siXy, and, no funny stuff trying to get around the gpl :p
01:47<siXy>heh :) we are likely to have a spare c programmer in the coming months who i was gonna get to take a look at the mythmusic interface - if that happens i will send back anything he does
01:50|-|zigovr3 [] has quit ["Client exiting"]
01:54|-|siXy changed nick to siXyGone
02:03|-|aevil [] has joined #mythtv
02:04<xris>Chutt: there's no special meaning for %% in a string in c++, is there?
02:04<xris>e.g: WHERE channel.channum LIKE '%1%%'
02:11<Chutt>means %
02:12<xris>it's not getting interpreted properly, then.
02:12<Chutt>that should translate to '1324%', i'd think
02:12<xris>line 2092 of libs/libmythtv/tv_rec.cpp
02:12<xris>shows up in some of the sql logs as %%
02:12<xris>-> WHERE channel.channum LIKE '5%%' AND
02:14|-|aevil [] has quit ["Verlassend"]
02:19<eskil>in QString %% means %
02:19<xris>eskil: except that for some reason it's not always getting parsed
02:20<xris>that's the only place in the code with that query, and the %% is definitely leaking through into the query.
02:21<eskil>my bad, I meant %% means %%
02:21<eskil>only %L?[0-9]+ gets parsed
02:21<xris>so it's a typo, then?
02:22<eskil>It's a C+ thing, when C and C++ meets and sweet love ensues... causes hellspawn code.
02:22<eskil>(so yeah, it should probably just be % if you want just %)
02:22<xris>it doesn't REALLY affect things, since mysql will optimize it away.. but it makes the query messy
02:22<xris>Chutt: thoughts?
02:23<Chutt>is it supposed to be <num>%?
02:24<xris>the %% means nothing to mysql
02:24<xris>it's redundant. only need one %
02:24<Chutt>that's why i asked if it was supposed to be <num>%
02:24<xris>I can only assume so
02:24<Chutt>so just change it to %1% or something
02:25<xris>yup. just wanted to double check before I changed something like that.
02:25<Chutt>bed time for me
02:25<Chutt>done with work. =)
02:25[~]xris has fears of breaking the c++ code by accident.
02:26<eskil>and with funny things like "%1%%2", you'll soon see why boost chose %n% for positionals...
02:26<xris>I like perl's plain and simple ? char
02:26<eskil>Chutt, night
02:27<xris>or something more complex like named parameters in braces, or something like that.
02:27|-|jmk [] has quit [Read error: 104 (Connection reset by peer)]
02:27<gbee>morning everyone
02:27<eskil>xris, I like perl - it's like smoking. It was really great, but I'm really happy that I quit and I don't ever want to go back.
02:27|-|jmk [] has joined #mythtv
02:27<eskil>gbee, 'morning
02:28<xris>eskil: I switched from perl to php. I have a love-hate relationship with both of them. I want perl6. when it arrives in 20 or so years, I'll be very happy. :)
02:28<gbee>not touched perl in a while, but still love it
02:28[~]xris still thinks in perl most of the time.
02:29[~]eskil backs off before he unleashes his perl hatred - each to his own.
02:30<eskil>oddly enough, my quitting smoking and dumping all our perl on the iterns coincided.
02:30<gbee>wouldn't exchange php for perl when it comes to web applications - php has been well crafted for that specific purpose
02:31<xris>gbee: "well crafted" and php don't go together in my mind.
02:31<xris>it does a good job, but perl can blow it away for many web things.
02:32<xris>the php devs have made a LOT of bad choices in some of their designs for php5 (currently still annoyed about binding parameters in mysqli stuff)
02:33<gbee>I'd disagree - perl is a lot more powerful yes, but php does what it does well imho
02:33<gbee>what about having to bind parameters or the way it's done?
02:33<xris>gbee: I mix and match. php is usually the best choice for most web projects, but there is a reason that groups like livejournal still use perl.
02:33<xris>the way it's done.
02:34<xris>proper method should be: prepare, bind, loop{ execute }, finish
02:34<xris>if you do that in php, you don't get errors, but your data will be f'd up...
02:34<xris>the "correct" way in php is: prepare, loop{ bind; execute }, finish
02:35<gbee>mysqli is a little clunky and yes, I've run into that 'bug' which is a f'ing pain
02:35<xris>which sort of defeats the purpose of binding, which is to get rid of that extra step of "assigning" values in the loop.
02:35<xris>wouldn't mind so much if the devs would at least trip a runtime error, or even a warning... but they just let it go through.
02:35<gbee>took me a while to work out
02:36<xris>took me 2-3 weeks of chatting with them in a bug report before anyone realized what the issue was.
02:36<xris>but there's a reason why my database library looks a lot like DBI. heh
02:37<gbee>so they acknowledge it as a design issue, not a bug? I'd always assumed it was a bug and would eventually be fixed :(
02:37<xris>they don't acknowledge anything other than that's the way that it works, and it's not going to change (nor will they add an error/warning)
02:38<xris>anyway, it's time for me to crash... 'night.
02:38|-|xris [] has quit ["Leaving."]
02:38<eskil>xris, night
03:24|-|stuarta [n=stuart@unaffiliated/stuarta] has joined #mythtv
03:28|-|slaine_ [n=glengray@] has joined #mythtv
04:10|-|eskil [] has quit ["Leaving"]
05:34|-|amccarthy [] has quit [Read error: 104 (Connection reset by peer)]
05:48|-|Skrot- [] has joined #mythtv
05:49<Skrot->Hi. How much does MythTV relay on Qt?
05:49<stuarta>a lot
05:49<Skrot->So it basicly uses it for all its drawing, or?
05:49<stuarta>interface as well as utility classes
05:49<Skrot->Okay, good :)
05:49<stuarta>ie. almost everything
05:50<Skrot->Are you a dev btw?
05:51<Skrot->okay, i've got a semi-related question. I read something about Qt4 being able to skin widgets using SVG, do you know anything about that?
05:51<stuarta>that's all well and good, but we use Qt3 and have not yet ported forward to Qt4
05:51<stuarta>since it's very involved
05:52<Skrot->I know, I was thinking in the future, if myth was ported to Qt4, wouldn't it be possible to make the buttons etc look more integrated rather than have them look like standard GUI-elements?
05:52<stuarta>*shrug* dunno, Isaac controls all the gui stuff
05:53<Skrot->okay :)
05:54<stuarta>but theoretically it should be....
05:55|-|LLyric changed nick to LLyricTV
05:56<gbee>if QT4 supports it then it's possible, but Isaac would probably be the one to decide
05:58<gbee>right not most of the GUI stuff involves custom mythtv wrappers round the QT widgets (correct me if I'm wrong) so it would require more than simply switching to QT4
05:58<gbee>s/right not/right now/
05:59<gbee>don't think it would be particularly difficult though, once the switch to QT4 is complete
06:01<gbee>after that snow the other day, today is suprisingly sunny and warm
06:02[~]gbee frowns
06:04|-|LLyricTV [] has quit [Client Quit]
06:12|-|MrGandalf [] has quit ["work"]
06:16<gbee>nope, maybe I'm being slow, but apart from a Japanese clown, enosun means nothing to me ... :)
06:17<stuarta>E = Error, NOSUN = No Sun :)
06:18[~]stuarta orders gbee more caffeine
06:18<gbee>need it
06:19<stuarta>btw. has commflagging changed in speed for you lately?
06:20<gbee>don't use it - haven't since 0.18 as it was useless for UK stuff then
06:21<gbee>I've been meaning to try it again, but never got around to it
06:21<stuarta>i suspect my speed increases i've noticed are due to moving from reiserfs to xfs on my recordings partition
06:22<stuarta>xris has been busy finding ways to reindex the DB
06:25<gbee>saw that
06:26<gbee>might prove beneficial to those using low powered systems, or with large program/recorded/record tables
06:28<stuarta>the more interesting one is the db blocking writes when scheduling
06:29|-|DrNickRiviera [] has joined #mythtv
06:30<gbee>yeah, that is interesting - I've not looked into it yet, but I'm curious what level locks are being used and why
06:39|-|Skrot- [] has left #mythtv []
06:43|-|Hamstaman [] has quit [Remote closed the connection]
06:44<gbee>no original ideas to solve the problem, breaking the scheduler query down into smaller queries and doing more of the work in code would obviously help, switching away from MyISAM to Innodb would also work but at the cost of overall speed
06:46<gbee>I'd opt for the first one - unless someone wants to benchmark MyISAM v Innodb and shows a minimal difference between the two for our purposes
06:47<stuarta>my thought would be to split out the in progress recording updates to a different table
06:48<stuarta>since it's the table lock giving trouble
06:49<gbee>it's worth a thought maybe
06:50<stuarta>though the knock on effect i suspect wouldn't be trivial...
06:51<gbee>I had a good idea for speeding up the current scheduler a while ago - by pre-flagging repeats
06:52<stuarta>doesn't mfdb do that?
06:52<gbee>well actually I can't remember if it was my idea
06:53<janneg>i think it does something similar for datadirect
06:53<stuarta>not that it would be any use when using EIT
06:54<gbee>should probably distinguish between repeats and duplicates
06:55<gbee>or even duplicates and previously recorded
06:55[~]janneg has fixed both issues Chutt found in the ffmpeg resync
06:56<stuarta>cool, any biggies?
06:58<stuarta>that going in in the near future or not?
06:58|-|nero__ [] has joined #mythtv
06:59<janneg>I'm testing it now and look again over the ffmpeg source log to create a changelog and commit it then
06:59<gbee>think the scheduler could benefit a lot by being split up and even having two versions - one low priority, running slowly scheduling future events and another high priority for immediate updates
07:00<gbee>the high priority scheduler would only look at programme data for the next few hours, the low priority would handle the rest
07:17|-|_nero_ [n=nero@unaffiliated/nero] has quit [Read error: 110 (Connection timed out)]
07:20<janneg>gbee: that's not that simple. the high priority has eventually to look much more forward.
07:21<janneg>otherwise it could start lower priority recording which will block the recorder for later high priority recordings
07:26<gbee>I don't seem that being a problem with the idea I have in mind, but it's only a rough outline at the moment
07:29<janneg>I'm not sure if it's a big problem or even if it is a problem at all if you schedule 6-12 hours
07:31<gbee>I wasn't imagining anything less than 12 hours - but that's still a significantly smaller dataset to process, which would make it much faster
07:33<janneg>yes, I have now 28 days with data for some programs due to --preferred-method allatonce
07:36<janneg>bah, reading ffmpeg changelog is boring
07:37<gbee>it would have to be more that simply applying the current scheduling query to a smaller range, the fast scheduler would re-use information from the slow scheduler to avoid scheduling a programme to record now that is repeated outside the 12 hour window, but I'm confident that it could be turned into a workable idea
07:40<gbee>something for me to think about over the weekend
07:59<janneg>would a component ffmpeg or libav* for tickets we are waiting for upstream support make sense? or should I close them as invalid: "feature request without patch"?
07:59<gbee>that's makes me sound like an owl ...
08:01<stuarta>janneg: or "upstream" like debian has
08:01<janneg>so you didn't want #2062 closed as invalid?
08:03<stuarta>no :-P
08:03<stuarta>if you are gunna do that, give the ticket back!
08:03<stuarta>it's a ticket to track that ffmpeg has issues :)
08:05<janneg>it's neither fixed by the sync nor by ffmpeg 7716
08:05<stuarta>still open & upstream then
08:07<janneg>do we really need a ticket to see ffmpeg has issues? the h264 decoder is not feature complete.
08:07<janneg>is the x264 decoder better?
08:07<stuarta>hmmm, i compiled my ffmpeg with x264
08:09<gbee>we only need a ticket if it was necessary to remind someone to re-sync ffmpeg - but that's already done every couple of months anyway
08:10<stuarta>it's a reminder to verify issues after the sync
08:10<janneg>or has x264 a decoder at all
08:10|-|okolsi [] has joined #mythtv
08:12<okolsi>who *
08:12<okolsi>heh.. learning IRC...
08:13<okolsi>but.. to the point.. janne: after latest ffmpeg sync, configure outputs: ./configure: line 769: !is_x86_slow_cmov_cpu: command not found
08:15<janneg>okolsi: thanks, I'll fix it. it's missing a space: ! is_x86_slow_cmov_cpu
08:16<okolsi>janneg: okay.. the build also fails on athlon.. but that might be because of this. I'll check.
08:17<stuarta>hi otto!
08:18<okolsi>stuarta: hi!
08:19<okolsi>hmm... did fix the configure.. make distclean etc.. still the build fails
08:20<janneg>okolsi: please paste the error
08:20<okolsi>.. -I../.. -I../libavutil -I/usr/lib/qt-3.3/include -o vp3.o vp3.c
08:20<okolsi>{standard input}: Assembler messages:
08:20<okolsi>{standard input}:4682: Error: no such instruction: `mftbu %ecx'
08:21<okolsi>this is from athlon.. similar also occurs with PIV
08:34|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
08:34<janneg>okolsi: please paste the configure command line and output to
08:37|-|MrGandalf [] has joined #mythtv
08:47|-|kvandivo [] has joined #mythtv
08:58<janneg>okolsi: I think I've fixed the issue but l'll wait with commiting until it's compiled and tested
08:59<okolsi>janneg: sounds good :)
09:01<gbee>../../libs/libavcodec/ undefined reference to `mpeg_xvmc_vld_decoder'
09:02<janneg>gbee: which architektuer? x86_64 with disabled XVMC?
09:13<janneg>gbee: should be fixed
09:16<janneg>compiling on the x86 computer takes ages
09:17<gbee>janneg: great :)
09:21<MrGandalf>odd, getting assembler errors when compiling snow.c
09:21<MrGandalf>about invalid instructions
09:21<MrGandalf>mftbu and mftb
09:22<janneg>no, I broke shared library building on x86_32
09:22<janneg>once my build is tested I could commit the fix
09:23<MrGandalf>janneg: you replying to me?
09:23<MrGandalf>ah, thanks
09:24<MrGandalf>those look like ppc instructions..
09:25|-|gnome42 [] has joined #mythtv
09:26<janneg>yes, I missed to define ARCH_X86_32
09:37<MrGandalf>that did the trick.. thanks
09:44<janneg>okolsi: committed
09:46<okolsi>janneg: working now, thanks
09:48<janneg>okolsi: you're welcome. It was my fault
09:50|-|jgarvey [] has joined #mythtv
09:56<janneg>gnome42: I'll use ff_find_start_code() for the various place were we use our own code. It doesn't look slower than your 3-byte version
09:57<janneg>it is in libavcodec/mpegvideo.c if you're interested in banchmarking it
10:00<gnome42>janneg: ok, thanks. I'll take a look.
10:06<gbee>heh - my new mouse claims upto 3 months battery life, after just 1 month the low battery indicator is flashing
10:09<stuarta>that'll be the "free" test battery
10:13<gbee>aye, duracell mind - not one of those unknown taiwanese brands
10:25|-|aevil [] has joined #mythtv
10:28<MrGandalf>[h264 @ 0xb74e0588]PAFF interlacing is not implemented
10:29<MrGandalf>craps out after that
10:29<stuarta>at least the've done MBAFF :)
10:30<MrGandalf>that really sucks
10:30<stuarta>there was a thread about implementing it
10:30<MrGandalf>I could upgrade in hopes that coreavc would work, but there's no guarentee
10:31<MrGandalf>it works now, but it's unwatchable
10:35|-|stuarta [n=stuart@unaffiliated/stuarta] has quit ["beer o'clock"]
10:36|-|beavis [] has joined #mythtv
10:39<MrGandalf>stuarta: what's the list URL?
10:48|-|gr8nash [n=andy@] has joined #mythtv
10:50<gbee>the mentioned thread might have actually been in ffmpeg-users, there is one back in December on the subject
10:51<janneg>MrGandalf: the whole stream is interlaced?
10:52<GreyFoxx>MrGandalf: Got a sample recording I could take a look at ?
10:55<janneg>MrGandalf: Julian is in #linuxtv
11:03|-|plb [] has joined #mythtv
11:06|-|xris [] has joined #mythtv
11:11|-|plb [] has quit ["Leaving"]
11:15<MrGandalf>lemme setup a recording schedule.. tough from work..
11:15<Chutt>janneg, hey, just checking, but we did have some added configure tests for various headers, iirc.
11:15<Chutt>janneg, those make it through the merge?
11:25<MrGandalf>janneg, GreyFoxx:
11:26<MrGandalf>files h264_i_1.mpg and h264_i_2.mpg
11:26<MrGandalf>The non-split file is h264_i.mpg
11:27|-|slaine_ [n=glengray@] has quit []
11:27<xris>did someone check something in in the last week or two that would affect livetv playback? I'm getting really skippy playback of (sd and hd) livetv with only 30% or so cpu usage. recorded tv works fine (even recorded while other stuff is recording)
11:28<janneg>Chutt: I hope so but I'll check
11:28|-|lcase [] has joined #mythtv
11:29<Chutt>couple soundcard headers for NVR.h
11:29<Chutt>couple things for stuff in libsoundtouch, iirc..
11:30<janneg>I've taken care of the soundcard headers
11:30<xris>Chutt: just out of curiosity, what's the reasoning for building all of that into mythtv instead of letting mythtv link against a different ffmpeg? configure stuff/etc?
11:30<Chutt>local changes.
11:31<Chutt>not having to have tons of backwards compatability stuff in myth
11:31<xris>good enough.
11:31<xris>the livna guys were asking awhile back, since they were on a big kick to get file sizes down by linking to a global ffmpeg.
11:32<gnome42>janneg: ff_find_start_code() performs very well! Right on par with the 3-byte version.
11:33|-|rtsai1111 [] has joined #mythtv
11:34<gnome42>janneg: Does it make sense to inline ff_find_start_code()?
11:36<janneg>gnome42: fine, patch is ready. I need only a window to test
11:37<xris>janneg: h.264 fixes?
11:38<janneg>I doubt that inlining will help much
11:39<janneg>xris: no, optimizations
11:39<xris>will they help with SD playback, too?
11:40[~]xris is hoping that something will fix the green bleeding that most of his h.264 encodes play on the left side.
11:40<janneg>if cpu usage is a problem of course
11:40<xris>heh, point taken. oh well, hopefully the ffmpeg sync will fix my issue.
11:42<xris>so is someone actually broadcasting in hd h.264 now?
11:43<janneg>yes, HDTV in europe is mainly h264
11:44[~]xris ponders moving to europe (for other reasons)
11:47<lcase>janneg: is it possible to view Pro7 HD with the latest sync? I know that i need a DVB-S2 card, but the rest should work?
11:47<MrGandalf>and US in places, unfortunately
11:49|-|rtsai [] has quit [Read error: 110 (Connection timed out)]
11:50<xris>MrGandalf: huh? that'd only be for satellite, which isn't legal to decode.
11:50<janneg>lcase: no, mythtv doesn't support a|the dvb-s2 api and dvb-s2 drivers are not really ready
11:51<MrGandalf>xris: Well, often times h264 feeds are FTA for a few days and at times for several months while Sat providers test. If it's in the open, I don't see anything illegal about viewing them.
11:51<xris>ahh, didn't know they did that. that's kind of cool
11:52<xris>I still need to get a dish/lnb so I can play with fta stuff
11:52<MrGandalf>Discovery HD on 148 was open for months.. might still be open in fact.
11:52<MrGandalf>they figure few people can actually decode the streams in realtime anyway..
11:53<xris>isn't that "decoding" the illegal bit?
11:53<MrGandalf>no, that decrypting
12:10|-|Skiingsean_out [] has quit [Read error: 110 (Connection timed out)]
12:17|-|hatlevip [] has joined #mythtv
12:24|-|sebrock|a [] has joined #mythtv
12:26|-|sebrock|a [] has left #mythtv []
12:29[~]xris wonders if his playback issues are RAM-related
12:29<xris>oops, wrong channel
12:31|-|andy__ [n=andy@] has joined #mythtv
12:31|-|gr8nash [n=andy@] has quit [Read error: 110 (Connection timed out)]
12:38|-|xris [] has quit ["Leaving."]
12:44|-|aevil [] has quit ["Verlassend"]
12:46|-|DrNickRiviera [] has quit ["Leaving."]
12:51<MrGandalf>interesting, mplayer on windows can almost play that h264 interlaced stream.. doesn't complain about it not being supported
12:52<janneg>MrGandalf: it uses ffmpeg h264 for decoding?
12:52<MrGandalf>probably a real old ffpmeg
12:53<janneg>do you have the sources?
12:53<MrGandalf>it probably doesn't know about PAFF and just continues on
12:53<MrGandalf>(with many many errors)
12:55<janneg>visible errors? some frames seems to have only half of the height?
12:56<MrGandalf>only shows one frame of video until you pause, then you get another
12:57<MrGandalf>and the frames look interlaced and not properly displayed.. looks like it's trying to display them as if their were progressive
13:00<janneg>I see such effects while ffmpeg complains about PAFF not being implemented
13:00<MrGandalf>in Myth the frontend segfaults
13:00|-|Cougar [] has quit [Read error: 110 (Connection timed out)]
13:00<janneg>not nice
13:01|-|Cougar [] has joined #mythtv
13:14|-|Skiingsean_out [] has joined #mythtv
13:20<MrGandalf>what's not nice is upgading to the latest coreavc codec and not being able to install it because it wants to access their server for a serial number and my firewall is blocking it.
13:24<gnome42>janneg: ff_find_start_code() lead me to look into the 'restrict' keyword, very interesting indeed. Are you aware of it already?
13:28|-|xris [] has joined #mythtv
13:40|-|nwahmaet [n=pjudge@] has joined #mythtv
13:43|-|nwahmaet [n=pjudge@] has left #mythtv []
13:44<janneg>gnome42: yes, but I think C++ ignores it
13:49|-|lcase [] has quit []
13:59|-|Honk changed nick to Honk^away
13:59|-|tzanger [n=tzanger@] has left #mythtv []
14:01|-|PointyPumper [] has quit [Read error: 104 (Connection reset by peer)]
14:02<gnome42>janneg: C++(g++) does ignore 'restrict' but does not ignore '__restrict__' (gcc extension) and I see restrict defined to __restrict__ in config.h
14:02|-|PointyPumper [] has joined #mythtv
14:03<gnome42>janneg: I've tried it in a few places in cpp files and judging by the compiler errrors it is not being ignored :)
14:10|-|hatlevip [] has quit ["Leaving"]
14:22|-|BULLE [n=bulle@] has quit ["leaving"]
14:26|-|Honk^away changed nick to Honk
14:39|-|okolsi [] has quit ["Leaving"]
14:49|-|Techboy74 [n=Techboy7@] has joined #mythtv
15:05|-|eskil [] has joined #mythtv
15:10|-|Hellaenergy [n=Hellaene@] has joined #mythtv
15:17|-|Hellaenergy [n=Hellaene@] has left #mythtv ["Leaving"]
15:23|-|MrGandalf [] has quit ["home"]
15:35|-|gnome42 [] has quit [Read error: 110 (Connection timed out)]
15:36|-|gnome42 [] has joined #mythtv
15:40|-|Techboy74 [n=Techboy7@] has left #mythtv []
15:44|-|scott [n=scott@oftc/staff/scott] has joined #mythtv
16:20|-|kurre2__1 [] has joined #mythtv
16:25|-|lsobral [n=sobral@] has quit ["Leaving"]
16:31|-|kurre2 [] has quit [Read error: 110 (Connection timed out)]
16:37|-|MrGandalf [] has joined #mythtv
16:43|-|luna6 [] has quit ["Leaving"]
16:46|-|rn114 [] has quit [Read error: 113 (No route to host)]
16:50|-|jgarvey [] has quit ["Leaving"]
16:52<MrGandalf>janneg: I think I'm going to persue getting the latest coreavc working with Myth instead of waiting for ffmpeg.. coreavc is a whole lot faster than ffmpeg anyway.
16:55<janneg>MrGandalf: are you sure? Micheal optimized h264 decoding in ffmpeg around october/november last year.
16:55<MrGandalf>I could be wrong.. I didn't know that
17:05|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
17:14<janneg>MrGandalf: it's probably still faster. I found a benchmark from august suggesting that coreavc is ~50% faster.
17:14<MrGandalf>I know I can almost play h264 on my 3200+
17:15<MrGandalf>there's a patch for coreavc 1.0/myth
17:15<janneg>iirc the numbers from the ffmpeg log it got 20-25% faster
17:27|-|beavis [] has quit ["Verlassend"]
17:45<Chutt>parts of it got that much faster.
17:45<Chutt>not overall.
17:46<Chutt>(from what i remember from the ffmpeg commits list)
17:48<janneg>yes, cabac got much faster which takes over 50% of the decoding
17:51<janneg>25% overall increase is maybe overrated
18:23<janneg>argh, I hate x86_32
18:32|-|moto125 [] has joined #mythtv
18:48|-|moto125 [] has quit ["(wIRC v4.5) download it @"]
18:59|-|robthebob [] has joined #mythtv
19:03|-|rn114 [] has joined #mythtv
19:04|-|robthebob [] has quit [Read error: 113 (No route to host)]
19:13|-|jams [] has quit [Read error: 104 (Connection reset by peer)]
19:13|-|jams [] has joined #mythtv
19:36<MrGandalf>janneg: can you further explain the PES assembler problem when you get a chance? Ever since winter started I've been plauged with corrupt streams. My dish is 36" and I get this when my other DirecTV dish, with a DTV receiver, I get perfect audio/video.
19:40<MrGandalf>nevermind.. could be hardware as well I suppose..
19:56|-|xris [] has quit [""]
20:00<janneg>MrGandalf: the PES assembler is only used for PSI data not for audio and video streams. the tuner in the STB could be better
20:01<MrGandalf>janneg: it was my mistake.. I keep dropping signal for some reason.
20:01<MrGandalf>I don't understand why
20:02<MrGandalf>the tuner I use is the same used in Dish Network receivers.. they can't be all that bad
20:02<MrGandalf>especially with a dish twice the size it needs to be
20:12|-|LLyric [] has joined #mythtv
20:19|-|nero__ [] has quit ["Leaving"]
20:55|-|cmorgan [] has joined #mythtv
21:25|-|skamithi [] has joined #mythtv
22:32|-|skamithi [] has left #mythtv []
22:36|-|Nem^1 [] has joined #mythtv
22:36[~]Captain_Murdoch wonders why people are assigning random tickets to him.
22:40|-|cmorgan [] has quit [Remote closed the connection]
22:54|-|Nem^ [] has quit [Read error: 110 (Connection timed out)]
22:54|-|Nem^1 changed nick to Nem^
23:24|-|eskil [] has quit ["Leaving"]
23:26[~]briand thinks they would like you to randomly fix the problems stated therein.
23:28<Captain_Murdoch>possible. I thought it was weird when someone assigned one ticket with a patch to me, but then I noticed another. for things I don't even touch like the uk_icons and firewire channel changer. Only thing I can figure is they mixed me up with xris again since he's working on that icon thing and does use firewire.
23:28<Captain_Murdoch>I could randomly close them. :)
23:28<Captain_Murdoch>well, "it", since I already committed one of them.
23:31<briand>maybe you should change your name, to avoid the confusion...
23:31<briand>like, i dunno... maybe isaac, or something?
23:31[~]briand ducks
23:31<Captain_Murdoch>that's what the GoToDev wiki page is for. :)
23:33<briand>i think you're asking a bit much of these users, aren't you? to actually read (and comprehend!), and perhaps click a link to actually learn something?
23:33<Captain_Murdoch>it used to be quite funny when some would assign tickets to "GoToDev" in trac.
23:34<briand>i haven't entered anything in trac lately... can the typical end-user even assign the dev any more? at one time, you couldn't...
23:34<Captain_Murdoch>used to be able to, can't now.
23:34<briand>i think everything went to ijr, and would get reassigned as needed
23:34<briand>ah, okay
23:35<Captain_Murdoch>does now and we pick ones we want or should be ours. I'm not sure if normal users can assign them.
23:36<briand>well, as i said, it's been a while since i submitted anything to trac... but i think normal users don't have that option any longer
23:36<briand>in fact, i think i submitted my first mythtv project patch after the change... and xris picked it up and committed it almost immediately.
23:37<briand>(hmm... or, maybe it was you)
23:37<Captain_Murdoch>if it was me, I'll go back and revert, just for that. ;)
23:37<briand>it was extremely trivial (thus the quick commit, no doubt)...
23:38<briand>the default font name in the menu xml file was typo'ed as 'Ariel' on one of the releases
23:39<briand>i believe the comment made on the commit was "remove cartoon fairy from myth ui" or somesuch.
23:41<briand>anyway, i had just about decided to get to work doing some -real- contribution to this project... found an area i'd like to play around in (that sorely needs it!), and i see paul h is playing around in there now. :) i guess i'll wait a bit and see what he comes up with
23:42<Captain_Murdoch>it's about time, we hate freeloaders. your little 'Ariel' patch wasn't going to cover you for too much longer. ;)
23:43<briand>well, since someone stole my idea for a 'Star Trek' theme, i had to bag that...
23:44<briand>ah, besides... playing around in xml files is fine ... but you can -really- mess things up in the compiled source files. <evil grin>
23:45<briand>sheesh.. i thought i had moved to florida.. it's freakin' 34 degrees outside!
23:45|-|scott [n=scott@oftc/staff/scott] has left #mythtv []
23:50|-|Jack3 [] has joined #mythtv
23:50|-|Jack3 [] has left #mythtv []
23:50<Captain_Murdoch>amazing how much better the MPEG-2 transcode looks when I don't try to encode it at a bitrate that I'd use for MPEG-4.
23:52<Captain_Murdoch>I have the lossy/NuppelVideoRecorder side of mythtranscode spitting out mpeg-ps files from a -ts source while scaling down the 1920x1080 to 640x368 and preserving the original AC3 audio. it's a bit of a hack, but is working and helping me learn a little more about libav*
23:53<briand>how long does the transcode take?
23:54<Captain_Murdoch>haven't done any timings, still messing with code. I don't think that the libavcodec mpeg-2 encoder is the fastest thing in the world but not sure how it compares.
23:55<Captain_Murdoch>and all the debug output I'm printing to stdout for each packet in the file doesn't help much either. :)
23:56<Captain_Murdoch>X + the xterm are 20% of cpu right now.
23:56<briand>probably not, but i wouldn't be surprised to learn that the debug printouts are contributing very little to the overhead
23:57<Captain_Murdoch>just saying they're using quite a bit of cpu and necessary context switches.
---Logclosed Sat Jan 27 00:00:28 2007