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

---Logopened Mon Jan 22 00:00:48 2007
00:08|-|gnome42 [] has quit ["Leaving"]
00:14|-|noddan [] has joined #mythtv
00:48|-|cmorgan [] has joined #mythtv
00:50|-|cmorgan [] has quit [Remote closed the connection]
01:09|-|kormoc [] has joined #mythtv
01:10<visit0r>kormoc: so my should do the following: get the video dir/file to find metadata for as an argument. If metadata found (by scanning a .nfo for imdb id or somehow other), return successfully without printing out anything, otherwise, print a list of number: title pairs for interacting with the user in php
01:11<kormoc>hrm, how to indicate if there was 0 matches found?
01:11<visit0r>kormoc: then the can be called with additional argument (in addition to the video file), the id
01:11<visit0r>kormoc: I can print out "No metadata found"
01:11<kormoc>that would work fine
01:11<visit0r>kormoc: or some other fixed string
01:12[~]kormoc nods
01:12<kormoc>yeah, that all sounds good
01:12<visit0r>kormoc: anyways, the inserts the data to MythDB if it finds it, overwrites old data only if forced with a switch (which your php probably wants to use)
01:13[~]kormoc nods
01:13|-|hads [] has joined #mythtv
01:18<visit0r>kormoc: oh yes, 3rd motivation for .metadata is that when you move the video/dir around, metadata in MythVideo does not get lost
01:18[~]kormoc nods
01:19<kormoc>wonder how orphaned metadata files should be handled.
01:20<kormoc>cause if they are .file, most people won't see them
01:20<visit0r>no they are not, they are [filenamebody].metadata or video.metadata for DVDs and "video rip folders"
01:20<visit0r>dvd-rip folders, I meant
01:20<kormoc>ahh, kk
01:24<hads>visit0r: How does .metadata help when you shift the original file? Doesn't that have the same problem (unless the user shifts the metadata file too obviously).
01:27<visit0r>hads: surely, but when you move the whole dir, the metadata comes along automatically
01:28<hads>True, if the user moves directories rather than files :)
01:29<kormoc>Readonly shares are going to have fun with it too
01:29<hads>Yeah, like my video share :)
01:29<visit0r>yep, that's why I'm going to implement the "insert to MythDB directly" switch
01:29<hads>Also, I'm anal and don't like other files in with my videos :)
01:30<visit0r>well I already have the subtitle files so it doesn't irritate me so much :)
01:30<hads>True, I have one subtitle file but Myth doesn't seem to read it - I haven't bothered to figure it out yet.
01:31<kormoc>heh, I'm a fan of embedded subs, like MVK files can do
01:31<hads>Yeah, that's cooler.
01:31<visit0r>hads: it has to be named similarly e.g. foobar.sub
01:32<visit0r>hads: with foobar.avi
01:32<hads>visit0r: Yeah, it's the same .srt from memory. I'm not really worried about it yet, I don't like that movie anyway :)
01:34<hads>Amarok does something interesting with music files - ATF I believe it's called - inserting a UID into the file and tracking it that way.
01:36<visit0r>yep, was thinking about the same thing
01:37<visit0r>basically it's a hash which is also stored in the file also
01:37<visit0r>then refer to that has instead of the file name
01:37<visit0r>in DB metadata tables
01:37<kormoc>hads, music files have areas dedicated to meta data, alas, video files don't
01:37<visit0r>kormoc: yep, but we could also use a hash to refer to the file instead, as they don't change like mp3s do due to ID3
01:38<hads>kormoc: Yeah, unfortunate, but ^^ what he said
01:38<kormoc>yeah, assuming myth is going to be the only thing browsing the files
01:38<hads>Unfortunately video files are large and take a long time to hash
01:39<hads>kormoc: Why would it matter if something else is browsing the files?
01:40<kormoc>hads, ooh, never mind
01:40<kormoc>hads, I thought you ment rename them to a uuid
01:40<hads>Ah, no way! :) I don't always use Myth to watch mine so that would be uncool
01:41<visit0r>hads: yep, of course we could hash only, let's say 10 blocks in several places in the file
01:41<hads>visit0r: Good thinking. Obviously your brain is working faster than mine.
01:42<visit0r>hads: not my idea, unfortunately ;-)
01:42<hads>I think some sort of auto-tracking would be nicer than any other method.
01:43<hads>(as in the hashing type deal) I'd be happy to collaborate on something like that (I can do Python and PHP, not C unfortunately)
01:43<hads>auto-tracking as in it doesn't matter if the file gets moved around.
01:43[~]kormoc nods
01:43<kormoc>that would be sweet
01:44<kormoc>would solve a lot of people's complaints
01:48<visit0r>hads: right, well it means hash instead of filename in DB pretty much...
01:52<xris>visit0r: re-scanning directories on view would be good, too... but with hashing, that could get slow
01:53<xris>of course, could probably seriously narrow things down by tracking filesize, too
01:53[~]kormoc nods
01:54<xris>of course, meta data files could help, too
01:59<kormoc>filesize + hash is my fav pick to be honest :P
02:00<xris>meta data files are mainly for the initial data import.
02:04<xris>visit0r: you'd still probably want to store a "last known path" in the db.. *especially* for when the backend starts being able to stream video files. You'd need to know where to go looking for the file.
02:06<hads>Good point
02:13<hads>So, I'm just having a play... for hashing parts of a file, I could divide the filesize into 8 or somthing and then read x bytes, add them together and hash that. Sound reasonable or is there a better way?
02:14[~]kormoc ponders
02:15<kormoc>I'd be tempted to say that if you read say 256 bytes each time it'd give you a nice bit
02:15<hads>Yeah, that's about the amount I was thinking
02:16<kormoc>well, that gives you a a full frame each snag if the bitrate is under 2,880 kbps
02:17<hads>I'm just hacking together a script to check out how fast it is and such.
02:17<kormoc>which should be fine
02:20|-|noddan [] has quit []
02:20|-|zigovr3 [] has quit [Read error: 110 (Connection timed out)]
02:21|-|Jymmm [n=Jymmmm@unaffiliated/jymmm] has joined #mythtv
02:23|-|Jymmm [n=Jymmmm@unaffiliated/jymmm] has left #mythtv []
02:35|-|noddan [] has joined #mythtv
02:40|-|slaine_ [n=glengray@] has joined #mythtv
02:45<hads>OK, that took just under 3 minutes to hash 200GB in 651 files on a P3 900 with the data mounted over NFS
02:46<hads>including printing the output to the terminal, which wouldn't slow it down much
02:47<hads>Oh, and over wireless.
02:47<hads>So it's not going to get too much slower.
02:51<hads>45 seconds on my Core 2 duo box with 100Mbit wired to the same NFS
02:53|-|zigovr [] has joined #mythtv
02:56<slaine_>Is it possible to passively cool a Core 2 Duo box ?
02:56<slaine_>CPU I should say, you'd obviously need case fan
03:00<xris>slaine_: wrong channel
03:00|-|xris [] has quit ["Leaving."]
03:00<slaine_>xris, Why, this is home of mythtv
03:00<slaine_>and most people would run that in some sort of htpc, so I would have thought it relevant. Oh, and you've buggered off
03:01<visit0r>slaine_: check the topic
03:02[~]slaine_ frowns
03:05|-|stuarta [n=stuart@unaffiliated/stuarta] has joined #mythtv
03:10|-|zigovr [] has quit [Read error: 110 (Connection timed out)]
03:10|-|zigovr [] has joined #mythtv
03:10|-|eskil [] has quit ["Leaving"]
03:26|-|gbee [] has joined #mythtv
03:46|-|Hoondie [] has joined #mythtv
03:59|-|kormoc [] has quit []
04:26|-|packetscan [] has quit [Read error: 104 (Connection reset by peer)]
04:26|-|packetscan [] has joined #mythtv
04:27|-|Toranaga71 [] has joined #mythtv
04:29|-|zigovr [] has quit [Read error: 110 (Connection timed out)]
05:05<stuarta>gbee: what sort of funky issues were you getting with those mythmusic changes?
05:06|-|DrNickRiviera [] has joined #mythtv
05:13<gbee>didn't see them personally - reverted it locally as soon as I heard, but people were getting failed autoexpiry, recordings which never ended, unable to play back recordings
05:13<gbee>backend or frontend hanging or losing connectivity
05:14<gbee>see Otto's email to the dev list just now, also Robin Gilks email "Backend hangups in r12594"
05:15<stuarta>yeah i did.
05:15<gbee>xris, GreyFoxx and a guy called wylie all saw problems
05:16<gbee>so all round, not good
05:16<stuarta>no, not good.
05:16<stuarta>i'll eyeball the patch later and see if there's anything i can see
05:17<gbee>I'm probably overlooking the obvious
05:20|-|Toranaga71 [] has quit [Read error: 110 (Connection timed out)]
05:22<stuarta>the changes to output.cpp look suspicious
05:22<stuarta>in that the complete set of listeners isn't notified.
05:24<gbee>heh - missed the "object = nextListener();" within the loop
05:24[~]stuarta slaps gbee with a trout
05:25|-|zig [] has joined #mythtv
05:25<stuarta>needs a DispatchToAllListeners() or equivalent
05:25[~]gbee passes the slap onto eskil
05:26[~]stuarta slaps gbee with the code review trout
05:26[~]gbee takes that one on the chin
05:27<gbee>ok, I'll fix that when I've got a free moment and test it thoroughly this time
05:28<stuarta>another set of eyes always helps :)
05:33|-|DrNickRiviera [] has quit ["Leaving."]
05:35|-|DrNickRiviera [] has joined #mythtv
05:43|-|zig [] has quit [Read error: 110 (Connection timed out)]
05:50|-|Toranaga71 [] has joined #mythtv
05:53|-|DrNickRiviera [] has quit ["Leaving."]
05:53<stuarta>gbee: did you ever revert from 0.20-fixes?
05:54<stuarta>haven't got to the bottom of my email yet :)
05:55|-|MrGandalf [] has quit ["Leaving"]
05:55|-|Toranaga71_ [] has joined #mythtv
06:08|-|Toranaga71 [] has quit [Read error: 113 (No route to host)]
06:52|-|lsobral [n=sobral@] has joined #mythtv
07:17|-|aevil [] has joined #mythtv
07:27|-|Toranaga71_ [] has quit [Read error: 113 (No route to host)]
07:31|-|Toranaga71_ [] has joined #mythtv
07:36|-|Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
07:41|-|noddan [] has quit []
07:42|-|noddan [] has joined #mythtv
07:53|-|kurre2 [] has quit ["leaving"]
07:53|-|tomimo [] has quit ["Gotta get going ..."]
08:00|-|beavis [] has joined #mythtv
08:30|-|zigovr [] has joined #mythtv
08:38|-|noddan [] has quit []
08:44|-|monteslu [] has quit [Read error: 110 (Connection timed out)]
08:45|-|Toranaga71_ [] has quit [Remote closed the connection]
08:50|-|noddan [] has joined #mythtv
08:54|-|Defend changed nick to defend
09:03|-|jgarvey [] has joined #mythtv
09:22|-|MrGandalf [] has joined #mythtv
09:24|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:25<MrGandalf>janneg: Have you completed your merge of the newest ffmpeg?
09:30<stuarta>there was a note on one of the tickets to that effect.
09:45|-|jmk_ [] has joined #mythtv
09:50<janneg>MrGandalf: unfortunately not. ffmpeg has major build system changes
09:53<janneg>and h264 playback isn't faster
10:04<MrGandalf>ah, I see
10:04<MrGandalf>that sucks.. oh well
10:26<Chutt>i'd want to do the merge.. it's tricky in places, since we have a bunch of local changes.
10:30|-|slaine_ [n=glengray@] has quit []
10:41<janneg>Chutt: I'm almost finished but I won't commit it
10:46|-|Caliban_ [] has joined #mythtv
10:48|-|zigovr [] has quit [Read error: 110 (Connection timed out)]
10:48|-|zigovr [] has joined #mythtv
11:01|-|Caliban [] has quit [Read error: 110 (Connection timed out)]
11:12|-|beavis [] has quit ["Ex-Chat"]
11:17|-|zigovr [] has quit [Read error: 110 (Connection timed out)]
11:18|-|zigovr [] has joined #mythtv
11:27|-|stuarta [n=stuart@unaffiliated/stuarta] has quit ["later"]
11:29|-|iresprite [] has joined #mythtv
11:29|-|iresprite [] has left #mythtv []
11:30|-|gnome42 [] has joined #mythtv
11:34|-|xris [] has joined #mythtv
11:40|-|rtsai [] has joined #mythtv
11:58|-|zigovr [] has quit [Read error: 110 (Connection timed out)]
11:58|-|zigovr [] has joined #mythtv
12:00|-|xris [] has quit ["Leaving."]
12:04|-|rtsai1111 [] has quit [Read error: 110 (Connection timed out)]
12:16|-|GBee1 [] has joined #mythtv
12:20|-|gbee [] has quit [Nick collision from services.]
12:20|-|GBee1 changed nick to gbee
12:32|-|MrGandalf [] has quit [Remote closed the connection]
12:33|-|robthebob [] has quit [Read error: 131 (Connection reset by peer)]
12:37|-|robthebob [] has joined #mythtv
13:10|-|zigovr changed nick to zigovr3
13:16|-|eskil [] has joined #mythtv
13:32<eskil>gbee, I found out some of the id3 tag craziness. Writing the id3v2 tag would still leave any existing id3v1 tag at the end of the file and unmodified, and most tools shortcut by first looking for a v1 tag.
13:33<gbee>could explain the problems I was having
13:36<eskil>gbee, yeah, very annoying. I'll submit a patch next time I have a clean tree.
13:37<eskil>gbee, about ticket 2557 (sigsegv in music)...
13:37<gbee>spotted the problem
13:38<eskil>gbee, what was it ?
13:39<gbee>the change in output.cpp
13:39<eskil>Yeah I saw your comment, but didn't quite get it.
13:39<eskil>Are you saying that it shouldn't notify all listeners anymore ?
13:39<gbee>wasn't handling all the listeners - the original iterates through them all, the patch doesn't
13:40<gbee>well tbh stuarta pointed that out
13:40<eskil>The patch calls MythObservable::dispatch, which should iterate over them.
13:40<gbee>haven't had time yet to look over it
13:41|-|stuarta [n=stuarta@unaffiliated/stuarta] has joined #mythtv
13:41<gbee>eskil: if that's the case, then it's not the problem ;)
13:42<eskil>gbee, yeah I don't think that's the culprit.
13:42<gbee>seemed credible at the time stuarta mentioned it, but I didn't double check
13:43<eskil>gbee, maybe the extra locking is causing havoc.
13:44<eskil>gbee, you should know better than anyone else to not trust people called Stuart.
13:44[~]stuarta hides
13:45<gbee>I seem to recall noting that dispatch handled the iteration when I first looked at the patch - but I'd forgotten
13:45<gbee>when I have some time I'll play around with it, right now I'm busy with work
13:46<eskil>Yeah, just thought I mention it while you were here.
13:46[~]eskil too has to work (= lunch...)
13:46<gbee>stuarta: nothing to worry about, just the changes in output.cpp aren't so obviously to blame
13:47<stuarta>fair enough. i was lacking source code to use as cross examination material when I found that.
13:47<stuarta>it just looked very suspicious.
13:48<gbee>yeah, well I didn't bother to check the source either and it sounded like a good reason :)
13:49<gbee>I just wasn't remembering that MythObservable::dispatch handles notifying the listeners
13:50<gbee>all the listeners, that is
13:53<gbee>eskil: not sure how the locking could be to blame, unless it's creating delays which cause other areas to hit timeouts
13:54<gbee>but I could be talking a lot of rubbish - should get back to what I was doing
13:57|-|cmcgee [] has joined #mythtv
13:58<cmcgee>Hello all
13:59<cmcgee>I was wondering if anyone has had any experience trying to performance optimize their mythtv systems?
14:00<gbee>cmcgee: #mythtv-users
14:00<cmcgee>gbee: Sorry
14:00|-|cmcgee [] has left #mythtv []
14:06|-|DrNickRiviera [] has joined #mythtv
14:06|-|xris [] has joined #mythtv
14:19|-|russellb [i=russellb@asterisk/developer-and-stable-maintainer/drumkilla] has quit [Remote closed the connection]
14:19|-|russellb [i=russellb@nat/digium/x-2c113c40b87453bf] has joined #mythtv
14:20|-|tkooda [n=tkooda@] has joined #mythtv
14:21<tkooda>can the development version of myth record from more than one ATSC channel (on the same frequency) at the same time?
14:22<tkooda>does myth use 3rd party binary to tune ntsc/atsc tuners, or it's own internal source?
14:22<GreyFoxx>it's own internal source
14:25<tkooda>I wrote this tiny app a few days ago (as a POC, but I use it daily), that might be of interest to any myth devs here: (just tunes a dvb card to a fequency and sets pes_filter's for 1 or more pids (so I can dump multiple atsc chans at once))
14:25<tkooda>..although I'm certain that the myth devs know how to do the same task already.
14:27|-|wylie [] has joined #mythtv
14:28<janneg>tkooda: getting the data from the card is simple. the hard part is to integrate it into the mythtv framework
14:29<janneg>but mythtv will support it soonish
14:31<tkooda>janneg, yah, I speculated the hurdle was well after the adding of the pes_filters.. -I noticed a hastle or two in my own stuff; in trying to sanely tie the proper pid streams in the ts back to a sane channel name, etc
14:31<tkooda>I'm getting sick of not having the scheduling so I'll probably give myth another whirl soon
14:39|-|niter3 [] has joined #mythtv
14:39|-|niter3 changed nick to mike3
14:40|-|mike3 [] has left #mythtv []
14:44|-|tkooda [n=tkooda@] has left #mythtv []
14:48|-|jmk_ [] has quit ["Leaving"]
14:58|-|Hoondie [] has quit []
15:03|-|MoRpHeUz [] has joined #mythtv
15:07|-|MoRpHeUz [] has quit [Client Quit]
15:38<janneg>configure is properly merged. mpegts playback has some issues. only the first playback works
15:40|-|georgy [] has joined #mythtv
15:40|-|georgy [] has left #mythtv ["Quitte"]
16:03|-|Anduin [] has quit ["Leaving."]
16:03<janneg>eskil, gbee: Re #2557. I would bet that it is a deadlock
16:05<eskil>janneg, you think ?
16:05|-|bsjeep [] has joined #mythtv
16:05|-|bsjeep [] has quit [Remote closed the connection]
16:06<stuarta>quite possible
16:06|-|bsjeep [] has joined #mythtv
16:07<Snow-Man>Chutt: The array's rebuilding.
16:07<eskil>I kinda doubt that. The lock is held while traversing and calling QApplication::postEvent, which shouldn't lead to a call back into mythobservable.
16:07<xris>Snow-Man: cool
16:08<Chutt>Snow-Man, did you get the guy to replace it?
16:08<eskil>Of course, when locks are added and things break... deadlock does seem like a plausible cause...
16:08<janneg>eskil: a deadlock is a good explanation for the errors
16:09<Chutt>the guy sent an email like 15 minutes ago, that was quick :p
16:09<Snow-Man>Chutt: yeah
16:10<Snow-Man>Chutt: It's all replaced and whatnot.
16:10<Snow-Man>np. It only took like 10 minutes once I showed up. :)
16:10<Snow-Man>It'll probably be overnight before the rebuild is done tho.
16:10<xris>Snow-Man: just make sure they send the old drive back. the support guys hate it when people don't
16:10<bsjeep>any reason why my .iso playback with Internal player broke with svn/trunk from last week?
16:10<Snow-Man>xris: He said it's alrady in the box
16:11<bsjeep>or maybe two weeks ago?
16:11<bsjeep>Anyone seen any bug submits on that recently?
16:12<bsjeep>2nd Q, anyone know offhand where the popup menu for done watching, delete? save? etc is in code?
16:14<eskil>janneg, I guess, I honestly know, having not used anything but MythMusic....
16:15<jwestfall>deadlock can be caused by MainServer::customEvent dispatching an event
16:22|-|lsobral [n=sobral@] has quit ["Leaving"]
16:24<eskil>jwestfall, but wouldn't MainServer::customEvent get called from the QT event thread, and not from MythObservable::dispatch ?
16:27<jwestfall>not always
16:27<jwestfall>i had a stack trace where it was direct
16:27<xris>Chutt: ever give much thought to implementing different queries (like the scheduler) for different versions of mysql. Was talking with kormoc just now and it seems that adding subqueries (mysql 5+) can speed the scheduler query up by a factor of 10 or more.
16:28<jwestfall>easiest was to test is to just gdb attach when things go crazy
16:28<jwestfall>and bt it
16:29<eskil>jwestfall, true.
16:42|-|noddan [] has quit []
16:42|-|tomimo [] has joined #mythtv
16:59|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
17:23|-|jgarvey [] has quit ["Leaving"]
17:32|-|MrGandalf [] has joined #mythtv
17:35<Chutt>xris, get some actual numbers and post it to the developers list
17:42<xris>he apparently also has some index-size changes that speed things up. I'll get a diff and list of changes and test them out on my own system, too
17:45|-|robthebob [] has quit [Read error: 104 (Connection reset by peer)]
17:46|-|eskil [] has left #mythtv ["Leaving"]
17:49|-|robthebob [] has joined #mythtv
18:06|-|aevil [] has quit [Remote closed the connection]
18:19|-|linxeh [] has joined #mythtv
18:28|-|DrNickRiviera [] has quit ["Leaving."]
18:39|-|obgynot [] has joined #mythtv
18:39|-|obgynot [] has left #mythtv ["Leaving"]
18:48<janneg>ah, I found the issue with broken playback after playback in the ffmpeg merge
18:59|-|rtsai1111 [] has joined #mythtv
19:03|-|Dibblah [] has quit [Remote closed the connection]
19:04|-|fysa [] has joined #mythtv
19:09|-|Dibblah [] has joined #mythtv
19:10|-|Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
19:10|-|linxeh [] has quit [Read error: 113 (No route to host)]
19:14|-|eskil [] has joined #mythtv
19:16|-|rtsai [] has quit [Read error: 110 (Connection timed out)]
19:20|-|rtsai [] has joined #mythtv
19:21|-|slushpupie [] has joined #mythtv
19:24|-|DIrEctQL [] has joined #mythtv
19:26|-|DIrEctQL [] has left #mythtv []
19:29|-|rtsai1111 [] has quit [Read error: 145 (Connection timed out)]
19:34|-|skamithi [] has joined #mythtv
19:44|-|stuarta [n=stuarta@unaffiliated/stuarta] has quit ["sleep required"]
19:48<briand>xris: I'm still running analysis, so I don't have hard/fast numbers or specifics yet.. but there seems to be some room for improvement in the SQL queries in general... my analysis software (mysqlard) indicates 21 "slow queries", several full-table scans, etc.
19:51<xris>briand: not surprising
19:51<xris>the scheduler query is almost assuredly the worst
19:52<xris>well, the worst that runs on a regular basis
19:52<briand>but, definitely a *big* spike in the graph once daily.... ;)
19:52<briand>..assuming my internet connection is up. ;)
19:52<xris>only once? you must not do much scheduling.
19:52<briand>oh, i do plenty of scheduling
19:52<briand>but the big spike seems to be mythfilldatabase
19:53<briand>the slow queries may be in the scheduler, tho
19:53<xris>oh, mfdb *would* be slow, yes.
19:53<briand>that's the full-table scan, methinks...
19:53<briand>if you're interested in peeking at the analysis, i'll pvt you the url
19:54<xris>maybe later when I'm not at work
19:55<xris>what's the name of the software you use to get that?
19:55<briand>sure, it's there, running whenever comcast decides to make my internet connection active. (they apparently think ISP means Intermittent Service Provider)
19:55<briand>link on the page, actually.. and really easy to set up/install
19:56<briand>you just create an account for it in mysql, and it logs into the server and checks the stats
19:57<xris>that's cool
19:57|-|slushpupie [] has left #mythtv []
19:58<briand>it's really a low cpu usage tool that seems to give lots of friendly info/advice...
19:58<briand>you do need to run it for a bit before it's analysis is valid, tho.. (they warn you of this, actually, on the results page)
19:59<xris>yeah, like any stats tool. could be really handy for work, and/or for a friend who is admining a mud with some query problems.
20:00|-|degreseven [] has joined #mythtv
20:00<briand>I happened across it while playing around with rrdtool, mrtg, et al
20:03<xris>annoying. doesn't seem to compile for me with the newer mysql libraries
20:05|-|gbee [] has quit [Excess Flood]
20:07<xris>wtf. builds on another system just fine
20:08<briand>what distro are you using?
20:09<xris>with non-fedora mysql packages
20:09<xris>make that fc4
20:09<xris>fc5 has mysql 5 packages by default
20:11<briand>i'm on fc5 here... hmm.
20:13<xris>yeah, compiles in fc5
20:13|-|skamithi [] has left #mythtv []
20:17|-|Dibblah [] has left #mythtv ["Kopete 0.11.1 :"]
20:18<xris>ok, upgraded mysql. looks like it was just an issue with 5.0.22
20:18|-|bsjeep [] has quit [Remote closed the connection]
20:24<briand>hmm. well, i think you'll like that tool.. pretty nifty, i thought
20:24|-|trend [] has joined #mythtv
20:25<trend>is the bttv the best linux driver for tv tuners?
20:25<trend>i am looking to buy a new pci tv tuner.. and need some help narrowing it down.. but it looks like bttv drivers are the most used.. so i should stick with a card that supports them
20:25|-|Dibblah [] has joined #mythtv
20:27<briand>it may or may not be, but this is probably not the best channel to ask that question on... check the topic
20:27|-|monteslu [] has joined #mythtv
20:28|-|beernutz [] has joined #mythtv
20:28<trend>hmm.. ok, I will ask in mythtv-users.. just thought i might get a better answer here.. anyways.. thanks for the heads up :)
20:44<Snow-Man>Chutt: rebuild finished.
20:46|-|beernutz [] has left #mythtv ["Leaving"]
20:50|-|gbee [] has joined #mythtv
20:51|-|gbee [] has quit [Remote closed the connection]
20:53|-|linx [] has joined #mythtv
20:53|-|eskil [] has quit ["Leaving"]
20:58|-|xris [] has quit [""]
21:11|-|defend changed nick to Defend
21:18|-|cmorgan [] has joined #mythtv
21:23|-|trend [] has quit ["BitchX-1.1-final -- just do it."]
21:30|-|klingon [] has joined #mythtv
21:30|-|linx [] has quit [Read error: 113 (No route to host)]
21:33|-|Anduin [] has joined #mythtv
21:43|-|xris [] has joined #mythtv
21:44<jwestfall>hey xris
21:45<jwestfall>sorry one sec
21:47<jwestfall>can you double check the 'Check for duplicates in' code for 'Only New Episodes' in mythweb
21:48<xris>what about it?
21:48<jwestfall>its setting dupin to 4, which doesnt look right since its 0x10 in the c++ code
21:48<jwestfall>all my 'only new episodes' end up selecting all episodes
21:49<xris>define('dupsin_newepisodes', 0x10);
21:51<xris>dunno. if I set "check in all" and "only new episodes" I get a value of 31, which is correct
21:52<jwestfall>let me make sure i am fully updated
21:52<jwestfall>doing a select in the database they all return 4
21:53<jwestfall>modules/tv/tmpl/lite/detail.php: if ($schedule->dupin == 4)
21:53<xris>lite doesn't work yet
21:54<xris>I'm surprised it works at all
21:55|-|xris [] has left #mythtv []
21:55|-|xris [] has joined #mythtv
21:55<xris>I'm still in the middle of an interface overhaul.. need to finish that before I migrate all changes to the lite template.
21:56<jwestfall>i must have had a bad version
21:56<jwestfall>sorry to bug you
22:06<xris>no, it's the correct/current version.
22:06<xris>lite is just not to be trusted at the moment.
22:12<jwestfall>dunno something else must have happened to
22:12<jwestfall>not like mythweb went and re-setup all my recordings
22:13<jwestfall>not sure how they all became 4
22:35|-|Nem^1 [] has joined #mythtv
22:39|-|briand [] has quit [Read error: 104 (Connection reset by peer)]
22:44|-|briand [n=brian@] has joined #mythtv
22:46|-|cmorgan [] has quit [Remote closed the connection]
22:52|-|Nem^ [] has quit [Read error: 110 (Connection timed out)]
22:52|-|Nem^1 changed nick to Nem^
23:01|-|klingon [] has quit ["Chatzilla 0.9.77 [Firefox]"]
23:12|-|degreseven [] has quit [Connection reset by peer]
23:13|-|CDev_ [] has joined #mythtv
23:19|-|rtsai [] has quit [Read error: 145 (Connection timed out)]
23:23|-|CDev [] has quit [Read error: 110 (Connection timed out)]
23:32|-|rtsai [] has joined #mythtv
23:35|-|degreseven [] has joined #mythtv
23:45|-|cattelan_away changed nick to cattelan
23:59|-|noddan [] has joined #mythtv
---Logclosed Tue Jan 23 00:00:30 2007