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

---Logopened Thu Sep 04 00:00:59 2008
00:09-!-xilet [] has joined #mythtv
00:10-!-foxbuntu [] has joined #mythtv
00:14<danielk22>Chutt: I dunno, I haven't looked much at the hdhomerun code in a while. It didn't used to require multiple tries, but then all it used to do was tune to the proper frequency -- current firmware can look at the actual stream and at more than just the pid.
00:14-!-JohnDesigner [] has joined #mythtv
00:14<Chutt>i've updated our version of the library to current
00:14<Chutt>seems to be working ok
00:14<Chutt>i'll let it go a few days, see what happens
00:15<danielk22>cool, i think they have better code to handle macs in their library.
00:16-!-leprechau [] has joined #mythtv
00:16<Chutt>only one mythtv code change required, aside from the .pro
00:16<danielk22>I don't know if their code handles inputting the ip of the device rather than the device id, i've needed that when the announcements didn't make it through some cheapo ethernet routers.
00:16<Chutt>it does both now
00:17<danielk22>:) sounds good
00:17<Chutt>well, all combinations, looks like
00:17<Chutt>i didn't update for new functionality
00:19<Chutt>i hope trunk is otherwise working ok
00:19<Chutt>since more new stuff starts next week :/
00:28<danielk22>I switched my production boxes to trunk a few weeks back and the backend is still crashing occasionally at the end of recordings, but I haven't updated since then, and it may be fixed now. (I don't see this on my dev box, but then that box isn't as busy.)
00:30-!-danielk22 is now known as danielk_Zzzzz
00:39<clever>danielk_Zzzzz: malloc abort()?
00:45-!-foxbuntu [] has quit ["Leaving"]
00:51-!-foxbuntu [] has joined #mythtv
01:01-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Read error: 113 (No route to host)]
01:22-!-ear9mrn [] has joined #mythtv
01:32-!-stoth [] has quit ["Leaving"]
01:41-!-bio___ [] has quit [Remote closed the connection]
01:41-!-bio___ [] has joined #mythtv
01:43-!-Dibblah [] has quit [SendQ exceeded]
02:13-!-avihayb_ [] has joined #mythtv
02:14-!-avihayb [] has quit [Read error: 104 (Connection reset by peer)]
02:17-!-avihayb_ [] has quit [Read error: 104 (Connection reset by peer)]
02:19-!-avihayb_ [] has joined #mythtv
02:25-!-gnome42 [] has quit [Remote closed the connection]
02:29-!-Dibblah [] has joined #mythtv
02:30-!-xris [] has quit ["Leaving"]
02:33-!-jk1joel [] has quit [Remote closed the connection]
02:34-!-jk1joel [] has joined #mythtv
02:45-!-edannenbe [] has joined #mythtv
02:48-!-foxbuntu [] has quit ["Leaving"]
03:27-!-noisymime [] has quit [Read error: 110 (Connection timed out)]
03:58-!-webman [] has joined #mythtv
04:02-!-bug1 [n=bug1@] has joined #mythtv
04:02-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
04:03-!-_gunni_ [] has joined #mythtv
04:11-!-anykey_ [] has quit ["Lost terminal"]
04:11-!-anykey_ [] has joined #mythtv
04:19-!-bug1 [n=bug1@] has left #mythtv ["Leaving"]
04:42-!-webman [] has quit ["Ex-Chat"]
04:43-!-xilet_ [] has joined #mythtv
04:53-!-noisymime [] has joined #mythtv
05:00-!-xilet [] has quit [Read error: 110 (Connection timed out)]
05:06<justinh>damn. got everything back to how it was yesterday, patch applied cleanly... glass-wide's menu-ui.xml is causing a segfault still
05:09<justinh>duh. plug brain in.. remember I still hadn't ran make install. works fine again
05:24-!-jk1joel [] has quit [Remote closed the connection]
05:24-!-jk1joel [] has joined #mythtv
05:34-!-jk1joel [] has quit [Remote closed the connection]
05:34-!-jk1joel [] has joined #mythtv
06:14-!-jk1joel [] has quit [Remote closed the connection]
06:14-!-jk1joel [] has joined #mythtv
06:27-!-Norrit_ [] has quit [Read error: 145 (Connection timed out)]
07:02-!-|chiz|_ [] has joined #mythtv
07:04-!-Norrit_ [n=okat@] has joined #mythtv
07:16-!-|chiz| [] has quit [Read error: 110 (Connection timed out)]
07:22-!-Dibblah [] has left #mythtv ["Kopete 0.12.4 :"]
07:39-!-Dibblah [] has joined #mythtv
08:18-!-noisymime [] has quit [Read error: 110 (Connection timed out)]
09:14-!-PointyPumper [n=pintlezz@] has quit [Read error: 110 (Connection timed out)]
09:15-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:22-!-famicom [] has quit [Read error: 110 (Connection timed out)]
09:23-!-famicom [] has joined #mythtv
09:31-!-Dibblah [] has quit [Remote closed the connection]
09:32-!-Dibblah [] has joined #mythtv
09:45<danielk_Zzzzz>clever: no, some kind of segfault
09:45-!-danielk_Zzzzz is now known as danielk22
09:48-!-gnome42 [] has joined #mythtv
09:57-!-stoth [] has joined #mythtv
10:20-!-famicom [] has quit ["Leaving"]
10:20-!-famicom [] has joined #mythtv
10:27-!-reynaldo [] has joined #mythtv
10:39<j-rod>janneg: merged all your latest changes. you rock.
10:43<j-rod>janneg: just killed all the externs in commandir.c
10:56<j-rod>still a few compile warnings from lirc_atiusb about ignoring ret vals from down_interruptible, easily fixed
11:07<janneg>j-rod: converting them to plain down is probably safer since the original auther never thought of returning without the lock
11:08<j-rod>hm, good point
11:09-!-rooaus [] has quit ["Leaving."]
11:09<j-rod>only one of the functions that calls it returns anything
11:12-!-foxbuntu_vm [] has joined #mythtv
11:13<j-rod>janneg: thoughts on the lirc_t typedef?
11:17-!-cattelan is now known as cattelan_away
11:17-!-cattelan_away is now known as cattelan
11:19<j-rod>hm... maybe I'm a touch overzealous with yanking the ivtv_reset_ir_gpio calls...
11:21<j-rod>janneg: you know anything about ivtv_reset_ir_gpio in lirc_zilog? mkrufky said something about it not being needed anymore, iirc
11:32-!-xilet_ [] has quit [Read error: 110 (Connection timed out)]
11:33-!-JohnDesigner [] has quit [Read error: 104 (Connection reset by peer)]
11:33-!-JohnDesigner [] has joined #mythtv
11:34<janneg>j-rod: I think lirc_t should go. i don't see the need to change it to something other than int
11:35<j-rod>sorta what I figured too
11:37<janneg>do you use the CVS keywords for syncing? otherwise they could be killed
11:38<janneg>but it might make sense to wait a little bit until in-kernel lirc is used
11:40<j-rod>I don't use the cvs keywords for anything, though some of them are used to gen version strings in printk output and whatnot
11:41<j-rod>hm... 'static lirc_t pulse = 0L, space = 0L;'
11:42<j-rod>wonder if that one should not be int, but long
11:42<janneg>yes, but that are two or three and the have to be replaced in the long run since git won't update them
11:43<j-rod>git won't, but if christoph keeps maintaining drivers in the lirc tarball (which last I checked, I think he wanted to do)...
11:43<j-rod>need to have (at least) one more conversation with him about maintenance plans going forward
11:47<janneg>yeah, in lirc_serial it's unclear what's the correct type for lirc_t is
11:49<janneg>OTOH int === long on x86
11:49<stuarta>that's no reason to assume it tho
11:50<j-rod>seems to be passing around ints in most places
11:51<j-rod>oh, haha
11:51<janneg>I think it makes sense to keep the CVS keywords for now
11:51<j-rod>frbwrite() passes space and pulse to rbwrite()
11:51<j-rod>rbwrite() is expecting an int
11:51<j-rod>I'll just make 'em all ints
11:52<j-rod>yeah, okay, will leave the cvs gunk for the moment
11:52<stuarta>you breaking lirc?
12:03<j-rod>very much so :)
12:03<j-rod>trying to break it enough that we can finally ship the mofo upstream
12:04<janneg>j-rod: rbwrite expects an lirc_t in lirc_serial an passes that after casting to void* to a function expecting unsigned char*
12:05<j-rod>ah, would help if I wasn't looking at code I'd already edited... :)
12:09*janneg guesses the lirc_t is result of overzealous software engineering and it is unchanged for at least the last 3 years
12:13-!-xris [] has joined #mythtv
12:16<j-rod>janneg: ok, my tree is now reporting 0 errors and 25 warnings, which are solely CVS crap and mutex-related
12:16<j-rod>and on that note, I'm going to disappear for about 2hr
12:17-!-foxbuntu_vm [] has quit [Remote closed the connection]
12:19<janneg>j-rod: I'm converting the semaphores to mutexes atm
12:20-!-Goga777 [n=Goga777@] has joined #mythtv
12:30-!-avihayb_ is now known as avihayb
12:50-!-edannenbe [] has quit [Remote closed the connection]
12:54-!-Chutt [] has quit [Remote closed the connection]
13:33-!-Dubstar_04 [] has joined #mythtv
13:36<janneg>j-rod: lirc_sasem was missing in the Kconfig, only 18 CVS keyword checkpatch warnings left
13:41*clever goes to check his ldd3 book to see what the diff is between semaphores and mutexes
13:42<janneg>both are sleeping locks. mutexes are simple. they are locked or unlocked
13:42<clever>i dont think ive ever had any locking related trouble with lirc
13:42<clever>other then when it locks up durring the insert and modprobe wont return
13:43<clever>my bigest kernel size lock problem is lvm
13:43<clever>it deadlocks under certain conditions
13:43<janneg>semaphores can have more states, for exapmle if you have many threads but don't want to run more threads than cpu cores
13:44<clever>i dont see why lirc needs many threads/cores :P
13:45<janneg>on a quadcore you would create a semaphore that looks only if it is taken 4 times
13:45<janneg>clever: that was just a stupid example
13:45<clever>my problem with lvm, if i run a pvmove while the volume is mounted
13:46<clever>it seems to be working with multiple locks, and gets them in a different order
13:46<clever>eventualy, the pvmove process and the one accessing the LV will hardlock on eachother
13:46<clever>and then anything that touches the LV will hardlock
13:47<clever>along with any debuger i might attach to the frozen processes
13:53<clever>it could be using down() instead of down_interruptible()
13:59<j-rod>clever: you mean like this? :) --;h=cbeb7591c93295ec89193d7b0446b78b82c3cff6
13:59<clever>yeah like that, but in LVM code
13:59<j-rod>janneg: d'oh, so I've not been building lirc_sasem in the fedora kernels for ... well, for ever... :)
14:00<j-rod>ah, sorry, you were still talking lvm
14:00*j-rod just sat back down
14:00<j-rod>janneg: good stuff
14:01<clever>last time i tried to track my bug down, i recompiled the kernel with debug info and when i ran it
14:01<clever>the nvidia drivers where dead
14:01<clever>which meant i lost my tvout on my main frontend
14:02<clever>i couldnt reproduce it either so i want back to the stock kernel
14:02-!-foxbuntu_vm [n=foxbuntu@] has joined #mythtv
14:02<j-rod>I simply avoid nvidia cards altogether these days
14:02<clever>its still better then ati
14:02<j-rod>I avoid ati even harder
14:02<clever>ati caused countless hardlocks and video corruption
14:02<j-rod>my frontend and my laptop are both intel graphics
14:03<clever>i have onboard intel in my xp system
14:03<clever>it cant even handle a simple game of portal
14:03<j-rod>although when I finally bring my appletv back home and hook it up to the other tv, it'll be nvidia...
14:04<j-rod>no computer games for me anymore, too much of a time sink, conflicts with having kids
14:04<j-rod>console gaming is another story
14:05<clever>my master crashed again
14:05<clever>QMutex::lock: Deadlock detected in thread -1416406128
14:06<clever>atleast my grep to track it down is working better
14:07<clever>now to grab a peice of the log
14:08-!-quentusrex [] has quit [No route to host]
14:08-!-Dubstar_04 [] has quit ["Ex-Chat"]
14:12-!-iamlindoro_ [n=iamlindo@] has joined #mythtv
14:20<j-rod>janneg: I think I'm going to drop the cvs tags that are restricted to comment blocks, but will leave the ones used in printk and modinfo output
14:23<janneg>j-rod: I wondered why gcc hadn't warned about an error in the sasem driver I made during the semaphore conversion
14:24<j-rod>heh, sorry 'bout that. :)
14:24<j-rod>part of me says lirc_parallel should be shot in the head...
14:25<janneg>j-rod: have you noticed that igorplugusb is always recompiled if something in the lirc directory was updated?
14:25<j-rod>hrm, no
14:26<janneg>I blame kbuild
14:26<j-rod>janneg: my typical routine is to make a bunch of changes, generate a diff, then do a full fedora kernel rpm build
14:27<j-rod>not the most efficient, but I have this 8-way opteron w/8G of RAM to build on :)
14:27<j-rod>so it only takes a few minutes anyhow
14:28<janneg>I did also a couple of commit and compiled before pushing them out
14:28<j-rod>0 errors, 4 warnings now
14:29<j-rod>all warnings for cvs crud
14:29<janneg>so now we only need people to test them. I can test lirc_serial
14:30<j-rod>I can beat on lirc_mceusb, lirc_mceusb2 and lirc_i2c
14:30<gbee>if you aren't in a hurry then I can test lirc_mceusb
14:31<gbee>ahh, well you don't need me then ;)
14:31<j-rod>any and all testing welcomed though
14:32<janneg>laga: can you test in-kernel lirc_igorplugusb?
14:33<j-rod>I'd really like to get a whole stack of receivers...
14:33<gbee>sure you can find no shortage or people to test lirc_mce* and lirc_serial, those being the two most commonly used by mythtv bods
14:33<j-rod>yeah, those are easy
14:33<clever>im using lirc_serial because lirc_i2c causes a kernel oops
14:33<clever>and lirc_i2c has never been able to blast
14:33<j-rod>lirc_i2c built into the ubu kernel?
14:33<j-rod>because I fixed that a while ago. :)
14:34<clever>added on the side by some automated compile tools
14:34<j-rod>I believe that fix is even in upstream lirc cvs
14:34<j-rod>was definitely post-0.8.3 though
14:34<clever>i forget what version i was on
14:34<clever>but 0.8.3 cant serial blast
14:35<clever>i had to revert to an older .ko file that i compiled months ago
14:35<j-rod>someone on the lirc list couldn't get serial receiving to work either just recently
14:35<j-rod>0.8.3 and current cvs were no go, but 0.8.2 worked
14:36<clever>i dont have a serial receiver
14:36<j-rod>so janneg, maybe something in lirc_serial is already destined to not work, regardless of any changes we made to it...
14:36<clever>i hooked a scope up to my non working serial in 0.8.3 and it looked like a valid signal
14:37<clever>so im guessing its either playing the code wrong or the timing is off
14:38<clever>the min_repeat also acted oddly, if i set it to 2, i get 3 codes for a send_once
14:38<clever>and when i did finaly get it working on the older driver, it would up registering as 2 key presses
14:44-!-trisooma [n=remko@] has joined #mythtv
14:46<laga>janneg: i could. mine is broken, but i think i can borrow one from a friend
14:47-!-foxbuntu_vm [n=foxbuntu@] has quit [Read error: 104 (Connection reset by peer)]
14:49<j-rod>clever: oh yah, I think christoph said something about some sampling interval change
14:49<clever>that could be it
14:50<clever>i tried to compare the working and broken signals to see how the freq was diff but i couldnt see it thru the noise
14:52<j-rod>i.e., the driver is sampling in 1ms intervals now, instead of some previous much smaller one
14:52<j-rod>haven't even looked into the code at all yet
14:52<j-rod>partially because I have no serial receiver, so low-prio for me. :)
14:53<j-rod>oh, and the driver needs to be sampling w/the smaller interval, 1ms is too coarse
14:57-!-Netsplit <-> quits: gbee, mace, Captain_Murdoch, stuarta, troldrik, j-rod, teprrr, forrestv, abqjp, Anduin, (+4 more, use /NETSPLIT to show all of them)
14:57-!-foxbuntu_vm [] has joined #mythtv
14:58-!-Netsplit over, joins: forrestv, abqjp, gbee, teprrr, sphery, Anduin, justinh, troldrik, stuarta, Snow-Man (+4 more)
14:58-!-famicom [] has quit ["Leaving"]
14:58-!-PointyPumper [n=pintlezz@] has joined #mythtv
14:59-!-foxbuntu_vm [] has quit [Remote closed the connection]
14:59-!-laga [] has quit [Remote closed the connection]
14:59-!-laga [] has joined #mythtv
14:59-!-Therock_ [] has quit [Client Quit]
15:02-!-foxbuntu_vm [n=foxbuntu@] has joined #mythtv
15:04-!-xris [] has quit ["Leaving"]
15:04-!-xris [] has joined #mythtv
15:07<gbee>server down?
15:11-!-jams [] has quit [Read error: 110 (Connection timed out)]
15:11-!-jpabq1 [] has joined #mythtv
15:12-!-danielk23 [] has joined #mythtv
15:13-!-jpabq [] has quit [Read error: 110 (Connection timed out)]
15:14-!-jarle [] has quit [Read error: 110 (Connection timed out)]
15:14-!-danielk22 [] has quit [Connection timed out]
15:14-!-jams [] has joined #mythtv
15:17<janneg>j-rod: I can't get lirc_parallel to build on amd64
15:17<j-rod>janneg: is CONFIG_SMP set?
15:17<janneg>ah, yes
15:18<j-rod>I don't think we've ever actually built it in fedora anywhere, mainly because of that
15:18<janneg>If overread the !SMP
15:18<j-rod>well, plus nobody has ever asked for it
15:18-!-jarle [] has joined #mythtv
15:18<j-rod>I don't recall why it isn't smp-safe
15:30-!-Therock_ [] has joined #mythtv
15:33-!-Goga777 [n=Goga777@] has quit [Remote closed the connection]
15:37-!-famicom [] has joined #mythtv
15:42<laga>gbee: sphery and I were discussing the xmltv config path patch again. you probably remember that we conlcuded that a DB schema update is not a good idea in -fixes because it'll break upgrades to trunk and the like.
15:43<laga>gbee: i propose to add the XMLTV path to the settings table, like XMLTVConfigPath.$name_of_videosource. for trunk, it can be done properly by adding a column to the videosource table. and some SQL magic to convert the entries in the settings table.
15:43<laga>does that sound sane?
15:54<laga>okay, i'll make these two patches then
15:58-!-iamlindoro_ [n=iamlindo@] has quit []
16:02-!-jackson__ [] has quit [Read error: 110 (Connection timed out)]
16:04-!-jackson__ [] has joined #mythtv
16:05-!-Chutt [] has joined #mythtv
16:21<j-rod>janneg: ok, fired off an email to lirc-list mentioning plans to submit upstream this weekend, along with some questions for christoph about future maintenance
16:22<gbee>upstream meaning linus kernel?
16:23<laga>janneg: ping me when you need the igorplugusb driver tested
16:23<gbee>cool, long overdue
16:23<janneg>j-rod: did you CC-ed me?
16:23<j-rod>janneg: d'oh, I suck
16:23<janneg>laga: ping
16:24<janneg>j-rod: np
16:25<laga>janneg: any ETA on a second review for the h264 patch? ;)
16:25<j-rod>use the email in your s-o-b?
16:25<janneg>laga: tomorrow or weekend
16:25-!-Dubstar_04 [] has joined #mythtv
16:25-!-Dubstar_04 [] has quit [Read error: 104 (Connection reset by peer)]
16:26<laga>janneg: great
16:26<laga>with some luck, i'll be able to get that receiver tomorrow morning so i can test at uni
16:26<laga>hum. i don't want to bring a remote so it'll be done at home ;)
16:28*j-rod has a lirc_mceusb2 receiver and remote at his desk in the office...
16:30*janneg watches his allmodconfig compiling slowly
16:31<j-rod>I'd let ya borrow my 8-core opteron if it weren't inside the corp firewall... :)
16:32<j-rod>I love this thing
16:32<j-rod>even cooler (or crazier, depending on perspective): I do all builds on it on an ext4-formatted firewire raid array
16:33-!-purserj [] has quit [Remote closed the connection]
16:33-!-|gunni| [] has joined #mythtv
16:35<j-rod>hm... wonder if an rc5-git5 kernel will actually work on this everex piece of crap laptop...
16:35<j-rod>~rc2, everything went completely out to lunch on it
16:36-!-iamlindoro_ [n=iamlindo@] has joined #mythtv
16:37<janneg>multiple firewire HDDs on a single bus?
16:38<bkero>Firewire can handle it.
16:39<bkero>I'm running software raid over USB. :)
16:39<janneg>yes, but the performance would suck
16:40<janneg>j-rod: I'm now subscribed on the lirc list
16:41<gbee>since no-one replied, I'll assume that the server is responding just fine for everyone else?
16:41-!-purserj [n=purserj@] has joined #mythtv
16:41<j-rod>janneg: ah, good (re: on lirc list)
16:42<j-rod>as for firewire, its a hardware raid array behind a fw800 bridge
16:42<j-rod>5x 250G drives in a raid5
16:42<bkero>Timing buffered disk reads: 68 MB in 3.09 seconds = 22.01 MB/sec = raid1 over usb
16:43<j-rod>though I've also done a 4x 120G software raid array, with each disk on its own bus
16:43<j-rod>I have waaaay too many firewire devices now
16:44<janneg>laga: re h264 merge, micheal committed today and yesterday fixes for h264.c
16:45<laga>janneg: i'll update the quilt series then. i'd like to point out that's not an excuse for you not to review the existing patches ;)
16:45<laga>thanks for letting me know
16:46<janneg>I have more dvb devices than I can use
16:47<janneg>laga: probably saturday
16:47<laga>no worries
16:48-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
16:57-!-PointyPumper [n=pintlezz@] has quit [Connection timed out]
17:00-!-foxbuntu_vm [n=foxbuntu@] has quit ["Leaving"]
17:02<j-rod>damn. everex lappy still go boom w/rc5
17:15-!-iamlindoro_ [n=iamlindo@] has quit []
17:17<j-rod>whoa, completely missing one driver in git
17:17<j-rod>newish lirc_ite8709
17:28-!-Dibblah [] has quit [Read error: 113 (No route to host)]
17:33<janneg>j-rod: another fix for lirc_serial
17:38*j-rod fetches
17:46-!-Dibblah [] has joined #mythtv
17:46-!-SHADOW__X [] has joined #mythtv
17:54-!-dekarl1 is now known as dekarl
18:00-!-SHADOW__X1 [] has joined #mythtv
18:01-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:05-!-stoth [] has quit ["Leaving"]
18:11-!-noisymime [] has joined #mythtv
18:16-!-Dibblah [] has quit [Read error: 113 (No route to host)]
18:16<j-rod>pulled and pushed
18:17<j-rod>along with some more merging of latest bits from lirc cvs
18:17<j-rod>left on my todo list is merging the latest lirc_imon bits and running checkpatch over lirc_ite8709.c
18:17<j-rod>(then testing, of course)
18:18-!-SHADOW__X [] has quit [Read error: 110 (Connection timed out)]
18:28<j-rod>ok, time to go home now...
18:33-!-trisooma [n=remko@] has quit ["Enuff for today"]
18:41-!-PointyPumper [n=pintlezz@] has joined #mythtv
18:47-!-danielk23 is now known as danielk22
19:07-!-huhlig [] has joined #mythtv
19:07-!-huhlig [] has quit [Read error: 104 (Connection reset by peer)]
19:20-!-noisymim1 [n=josh@nat/ibm/x-c90b056ce382df73] has joined #mythtv
19:23-!-cattelan is now known as cattelan_away
19:26-!-noisymime [] has quit [Read error: 110 (Connection timed out)]
19:31-!-noisymim1 is now known as noisymime
19:37<janneg>j-rod: do you know that fedora already patches its kernels with lirc? ;)
19:39-!-moodboom [] has joined #mythtv
19:41<janneg>j-rod: pushed compile fixes
19:46<janneg>ite8709 is already checkpatch clean
20:02-!-dekarl1 [] has joined #mythtv
20:07-!-dekarl [] has quit [Read error: 60 (Operation timed out)]
20:10-!-xris [] has quit ["Leaving"]
20:15-!-otwin [n=otwin@] has quit [Remote closed the connection]
20:15-!-otwin [n=otwin@] has joined #mythtv
20:17-!-ThatOtherGuy [] has joined #mythtv
20:18-!-netzapper [] has joined #mythtv
20:18<netzapper>is there a video capture card (not necessarily a tuner) that'll accept Y/Pb/Pr or DVI input?
20:18<netzapper>...and works with mythtv?
20:22<janneg>netzapper: read the topic, but the Hauppauge HD PVR is probably what you want
20:22<netzapper>ah, I figured this was the right place since I'm writing a patch for a custom mythtv product.
20:22<netzapper>I don't really care if it "works" like a user would, just whether or not I can get a stream in.
20:23<netzapper>but, thank you very kindly for your help.
20:23<janneg>why would you want to write a patch? mythtv already supports it
20:24<janneg>but it is still in development as the driver
20:25<netzapper>ah, I'm sorry. I'm not patching it for that, I'm patching mythtv to get modified (and flawed from a pvr-user's standpoint) behavior.
20:25<netzapper>how does the dev driver work?
20:25<netzapper>s/how/how well/
20:26<netzapper>wait, kernel driver or mythtv internal driver?
20:28<netzapper>nevermind, found the wiki page.
20:31<netzapper>another question: what is the exactly process of the commflagging? I see the commflag program. Is that called from the backend to do tagging, or is there internal code in the backend to handle that tagging?
20:31<netzapper>s/to handle/to help handle/
20:34<netzapper>I guess to be more clear: is all of the commflagging encapsulated within the mythcommflag program, or does some of it reside elsewhere?
20:34<janneg>that user questions
20:34<janneg>or questions for google
20:36<netzapper>I've found all sorts of stuff about how it's done, but almost nothing about where the code resides. Other than a vague mention on the architecture page (which looks kinda out of date) about "mythcommflag" being called by the backend. But, there's another phrase elsewhere that implies that some of the code resides in the backend codebase.
20:38<netzapper>Ah. it claims that mythcommflag is called after recording, but in the configuration guidelines it says that it can't do three of the four heuristics if the box isn't checked before recording time. If it's an offline tool, does it matter when you run it? Which implies some of the code is elsewhere.
20:39<netzapper>but, that's obviously a user's concern... which compilation unit some code is in... so, I'll go harass those guys about it.
20:48<clever>netzapper: ive manualy ran mythcommflag on .avi files a few times
20:48<clever>when following the README.txt in the commflag source dir
20:49-!-webman [] has joined #mythtv
20:49-!-webman [] has left #mythtv ["Ex-Chat"]
20:49<netzapper>right, I saw that you can do that. I'm just wondering if commflag implements the entire mythtv commflagging process, or if some portion of it is handled by some other piece of software.
20:51<clever>i think all the flagging is done by the mythcommflag process
20:51<netzapper>cool, thanks
20:51<clever>which mythbackend will start automaticaly after the recording
20:53-!-netzapper [] has left #mythtv []
21:15<iamlindoro>"Can I use mythcommflag to build my own commflagging software without having to learn about myth... and can I make it a bunch of DLLs and switch strings around so nobody will ever know?"
21:15<iamlindoro>There, fixed that for him
21:22<Chutt>lemme know if the hdhomerun library merge causes problems
21:22<Chutt>i've had mine recording all day without issue
21:24-!-xris [] has joined #mythtv
21:31-!-SHADOW__X1 [] has left #mythtv []
21:34-!-Chutt [] has quit [Remote closed the connection]
21:35-!-Chutt [] has joined #mythtv
22:12-!-cesman [n=cecil@pdpc/supporter/sustaining/cesman] has quit [Read error: 110 (Connection timed out)]
22:20-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
22:20-!-alcoheca [n=alcoheca@xbmc/gsoc/alcoheca] has quit ["sleeping"]
22:27-!-aneiane [] has joined #mythtv
22:43-!-iamlindoro [] has quit [Remote closed the connection]
22:50-!-iamlindoro [] has joined #mythtv
22:55-!-PointyPumper [n=pintlezz@] has quit [Read error: 110 (Connection timed out)]
23:07-!-cesman [n=cecil@] has joined #mythtv
23:43-!-famicom [] has quit ["Leaving"]
23:47-!-MavT [] has joined #mythtv
---Logclosed Fri Sep 05 00:00:41 2008