Back to Home / #mythtv / 2003 / 08 / Prev Day | Next Day
#mythtv IRC Logs for 2003-08-04

00:03<bline>lirc is pissing me off
00:04<Chutt>sure
00:05<mikegrb>Chutt you sure have been busy today :-)
00:05<mikegrb>had inlaws visiting last weekend... they are jealous of my mythtv
00:06<Chutt>heh
00:10<bline>mind if I paste 6 lines of code?
00:12-!-rkulagow___ [] has quit [Read error: 110 (Connection timed out)]
00:15<Chutt>sure
00:16-!-poptix [poptix@2001:470:1f00:623:0:0:0:2] has joined #mythtv
00:17<bline> printf("Calling lirc_init\n");
00:17<bline> fd = lirc_init((char *)program.latin1(), 1);
00:17<bline> if (fd == -1)
00:17<bline> {
00:17<bline> printf("Error: %s %d\n", strerror(errno), fd);
00:17<bline> return -1;
00:18<bline> }
00:18<bline>err 7
00:18<bline>in lirc_init I have
00:18<bline> printf("lirc_lircd: %d\n", lirc_lircd);
00:18<bline> return(lirc_lircd);
00:18<bline>the output is
00:19<bline>Calling lirc_init
00:19<bline>lirc_lircd: 12
00:19<bline>Calling lirc_init
00:19<bline>Error: Success -1
00:19<bline>does this make any sence to you?
00:19<Chutt>nope
00:20<Chutt>sure you have it as a == there and not a =? =)
00:21<FryGuy>what's the prototype for lirc_init?
00:21<bline>lirc_init is called twice, and it shouldn't be
00:22<bline>int lirc_init(char *prog,int verbose);
00:22<Chutt>well, where is that code?
00:23<bline>MythMainWindow::Init calles static void *SpawnLirc(void *param) with pthread_create(&lirc, NULL, SpawnLirc, this);
00:23<FryGuy>well, it was worth a try :p
00:23<Chutt>is that getting started twice?
00:24-!-yebyen [] has quit [Remote closed the connection]
00:24-!-yebyen [yebyen@gripz.com] has joined #mythtv
00:24<bline>from the output it looks like it, and lirc stores some things as static globals
00:24<FryGuy>what's the definition of lirc_lircd?
00:25<FryGuy>int lirc_lircd;?
00:25<bline>static int lirc_lircd; in a global context
00:26<bline>I can't see why it is called twice though
00:26<bline>the first time it is successful, and the second it is not
00:26<Chutt>well, thing to do would be to figure out why it's getting called twice
00:27<bline>MythMainWindow::Init would have to be called twice from reading the code
00:28<Captain_Murdoch>is it getting called twice because the constructor calls Init() then mythfrontend's main.cpp calls Init() also.
00:28<Chutt>Init gets called all the time
00:28<bline>I guess I'll recompile mythtv with -g and muck around with gdb
00:28<bline>oh, my assumptions seem to be my downfall
00:29<bline>thanks for you help
00:34-!-hfb [~hfb@pool0266.cvx25-bradley.dialup.earthlink.net] has joined #mythtv
00:35<Chutt>do it in the constructor =)
00:37<bline>yeah, I just moved it there, thanks :)
00:38-!-courtlr [~trillian@66.52.250.16] has joined #mythtv
00:39<courtlr>What varible is the control for fine tuning?
00:40<-- courtlr(~trillian@66.52.250.16) has left #mythtv
02:05-!-jhurliman [~jhurliman@12-207-242-239.client.attbi.com] has joined #mythtv
02:34-!-bline [] has quit [niven.freenode.net irc.freenode.net]
02:34-!-term [] has quit [niven.freenode.net irc.freenode.net]
02:34-!-term [~term@pcp220974pcs.elkrdg01.md.comcast.net] has joined #mythtv
02:34-!-bline [~sbeck@24.84.93.233] has joined #mythtv
02:47-!-Timon [] has quit [Remote closed the connection]
02:47-!-hadees [~gremlin@pool-151-197-34-65.phil.east.verizon.net] has joined #mythtv
02:50-!-hfb [] has quit [Remote closed the connection]
03:13-!-mikegrb [] has quit [niven.freenode.net irc.freenode.net]
03:14-!-mikegrb [michael@pcp02798743pcs.goosck01.sc.comcast.net] has joined #mythtv
03:46<jhurliman>i just updated to the latest snapshots of v4l2, bttv9 and btaudio. fixed all of my problems (freezeups on channels with no reception, btaudio popping on channel change, poor reception), but i lost picture adjustments in myth :(
03:46<jhurliman>im using today's cvs, not sure if it's an already known issue or not
03:55-!-hadees [] has quit [Read error: 60 (Operation timed out)]
04:11-!-Viddy [~lsk@visp194-179.visp.co.nz] has joined #mythtv
04:12-!-choenig [~choenig@pD9FFAE6C.dip.t-dialin.net] has joined #mythtv
05:34-!-Markos [markl@CPE004005573530-CM014340008532.cpe.net.cable.rogers.com] has joined #mythtv
05:48-!-Viddy [] has quit ["Client exiting"]
05:51-!-Markos [] has quit [Remote closed the connection]
07:17<-- bma(~bma@tynian.net) has left #mythtv
07:26-!-jkolb [~jkolb@216-199-48-234.orl.fdn.com] has joined #mythtv
09:43-!-robertj [~robertj@c-24-98-40-6.atl.client2.attbi.com] has joined #mythtv
09:56-!-robertj [] has quit [Remote closed the connection]
09:57<-- berli(~rasch@user-10lf9nu.cable.mindspring.com) has left #mythtv
10:52-!-hfb [~hfb@lsanca1-ar2-4-60-012-255.lsanca1.dsl-verizon.net] has joined #mythtv
10:52-!-jkolb [] has quit [Read error: 104 (Connection reset by peer)]
10:52-!-choenig [] has quit [Remote closed the connection]
11:02-!-schultmc [~schultmc@zealot.progeny.com] has joined #mythtv
11:20-!-thor_ [1000@193.251.157.227] has joined #mythtv
11:21<Chutt>hey thor
11:21<thor_>hey
11:21<thor_>looking like 0.11 is coming ... ?
11:21<thor_>(lib changes)
11:21<Chutt>yeah, later this week
11:21<Chutt>heh, finally got around to doing that =)
11:21<thor_>cool
11:21<thor_>I'm cranking along here ... plannin on making a fairly large commit once everything is working
11:22<Chutt>cool
11:22<Chutt>timeframe?
11:22<thor_>.... cvs update is sloooowwww on 2.8 dailup :-(
11:22<Chutt>heh
11:22<Chutt>i can imagine
11:22<thor_>24-48 hours
11:23<Chutt>great
11:23<thor_>just fiddling with lots of transcode stuff
11:23<thor_>anything else waiting ... web2 ?
11:24<Chutt>i dunno
11:24<Chutt>i have to email him about that
11:24<Chutt>see if he thinks it's ready
11:25<thor_>few -dev complaints about mythdvd .... I'm assuming not many people realize it's there
11:25<thor_>(i have -user turned off)
11:25<Chutt>nothing major
11:26<-- panthar(panthar@d-216-195-180-117.metrocast.net) has left #mythtv
11:26<Chutt>only thing (i think) was that one guy that didn't install the -dev packages
11:27<thor_>yup, saw that
11:33-!-dopez [~unknown@dopez.xs4all.nl] has joined #mythtv
11:37<thor_>k ... got my updates done ... signing off
11:37<-- thor_(1000@193.251.157.227) has left #mythtv
11:45-!-rkulagow [~mythtv@12-206-148-147.client.attbi.com] has joined #mythtv
11:49-!-mikegrb [] has quit [niven.freenode.net irc.freenode.net]
11:52-!-mikegrb [~michael@pcp02798743pcs.goosck01.sc.comcast.net] has joined #mythtv
11:57-!-jkolb [~jkolb@216-199-48-234.orl.fdn.com] has joined #mythtv
11:59-!-StarHeart [edgan@64-42-21-228.atgi.net] has joined #mythtv
12:11-!-Drikus_ [~Drikus@cc45940-a.deven1.ov.home.nl] has joined #mythtv
12:11-!-mecraw [~mecraw@69.2.235.2] has joined #mythtv
12:19-!-mikekedl [fwuser@firewall.cti-pet.com] has joined #mythtv
12:20<-- mikekedl(fwuser@firewall.cti-pet.com) has left #mythtv
12:31-!-figgy [figgy@pm231-214.hansel.kua.net] has joined #mythtv
13:05-!-choenig [~choenig@pD9FFAE6C.dip.t-dialin.net] has joined #mythtv
13:05-!-jkolb [] has quit [Read error: 104 (Connection reset by peer)]
13:13-!-mechou [~mchou@152-pool1.ras10.capax.alerondial.net] has joined #mythtv
13:35<-- jhurliman(~jhurliman@12-207-242-239.client.attbi.com) has left #mythtv
13:36<-- mechou(~mchou@152-pool1.ras10.capax.alerondial.net) has left #mythtv
13:39<rkulagow_>chutt: are you here?
13:56-!-hadees [~gremlin@pool-151-197-34-65.phil.east.verizon.net] has joined #mythtv
14:04-!-jkolb [~jkolb@216-199-48-234.orl.fdn.com] has joined #mythtv
14:09-!-billytwowilly [~chris@h24-86-147-220.ed.shawcable.net] has joined #mythtv
14:10<-- billytwowilly(~chris@h24-86-147-220.ed.shawcable.net) has left #mythtv ("Client exiting")
14:14-!-hadees [] has quit [Remote closed the connection]
14:31-!-jhurliman [~johnjohn@spkndslgw6poolc139.spkn.uswest.net] has joined #mythtv
14:39-!-hadees [~gremlin@pool-151-197-34-65.phil.east.verizon.net] has joined #mythtv
14:44-!-dopez [] has quit [".."]
14:53<jhurliman>i think i'm going to do the recording on/off patch today, Chutt is it safe to destroy/create the scheduling thread to do this?
14:54<jhurliman>someone mentioned it on the mailing list, i didnt see a followup but it sounded like the way to go
15:11<Captain_Murdoch>jhurliman: that was me that suggested not starting the scheduler thread. I think that could be one of those settings that doesn't take effect until you restart the backend just like the capture cards when you setup those.
15:12<Captain_Murdoch>I don't think the scheduler is required. the tvlist is already generated and gets passed to the scheduler so if anything depends on the tv list, it will be there anyway.
15:14<Captain_Murdoch>in fact, on slave backends the scheduler doesn't get started either so it should be safe to just change that "if (ismaster)" to something like "if (ismaster && gContext->GetNumSetting("RunScheduler",1))"
15:14<Captain_Murdoch>forgot to say where.. it's around line 299 in mythbackend's main.cpp file.
15:22<jhurliman>Captain_Murdoch: can you restart the backend while mythfrontend is running and not skip a beat?
15:23<jhurliman>if not, i need to implement real-time creation/destruction of the scheduler thread otherwise the patch would be rather useless for my purposes
15:25<Captain_Murdoch>jhurliman: no, you have to restart the frontend's also.
15:26<jhurliman>hmm, need a more robust method then
15:26<jhurliman>i'm adding a menu option to launch tvtime
15:27<Captain_Murdoch>would maybe be better to give Myth a way to say "tuner X" is being used by an external program.
15:27<Captain_Murdoch>so you don't stop the scheduler, just make the tuner say it's being used already so the scheduler skips it when scheduling new recordings.
15:28<Captain_Murdoch>I thought you were the one wanting a way to carry a mythbox somewhere without an antenna and just use it to play recordings while out of town so the scheduler would be disabled.
15:28<jhurliman>well the other way i know of is adding an if() to the scheduler loop, which is doable but its overhead. i guess its probably negligible though
15:28<jhurliman>Captain_Murdoch: no i saw that post, not me though
15:29<jhurliman>portable myth box, hehehe
15:29<Captain_Murdoch>I could use that portable idea. I'm debating upgrading my car mp3 player so it can run Myth to play videos. it already has a 10Mbit ethernet in it for syncing mp3s, I could just copy videos onto it and have movies/TV as well on long trips.
15:31<jhurliman>Captain_Murdoch: i think once an sdl output mode is implemented and qt on directfb is a bit more stable that would be interesting to look in to
15:31<Captain_Murdoch>will what you're thinking of doing work for remote frontends as well?
15:32<jhurliman>what would it break?
15:33<jhurliman>the frontend tells the backend to record a show, the backend has a NO_RECORD flag set and doesn't do it
15:33<Captain_Murdoch>how would a remote frontend with a slave backend tell the master backend to stop scheduling recordings so you could use the tv card in the remote frontend/backend to run tvtime?
15:33<jhurliman>but i havent ran remote frontend/backend before so i might be missing something
15:34<jhurliman>hmmm
15:35<jhurliman>a new signal (or whatever the communication is called) needs to be added
15:35<Captain_Murdoch>that's why I"m thinking it would be cool if you could just have a menu option that would say "give me a local tv card to use temporarily". it would send a message to the master backend which would lock a tv card and send back the video and audio devices which could then be passed to tvtime or whatever.
15:35<Captain_Murdoch>then when tvtime exits the frontend tells the backend, "I'm done with that card now so you can use it to schedule stuff"
15:37<Captain_Murdoch>people could make a menu button to run gnomemeeting on their TV so they could talk to grandma... :)
15:37<Captain_Murdoch>anyway, just an idea I thought I'd toss out since you were looking at it.
15:37<jhurliman>i like that, but (at least for the first patch) the backend is only going to pass back SUCCESS/FAIL message, instead of video/audio handles
15:38<Captain_Murdoch>not a handle, just a device name. /dev/video0
15:38<jhurliman>ahh, ok
15:38<jhurliman>that works
15:39<jhurliman>any idea where the scheduler's main loop is? save me some time this evening if i know where to look
15:39<Captain_Murdoch>so master backend sees /dev/video0 is not in use on a frontend and it marks that tuner as in use then tells the frontend it can use /dev/video0. when the frontend is done it tells the backend so and the backend marks that tuner as unused. need to add a way to keep track of whehter a tuner is in use or not by another program.
15:40<Captain_Murdoch>mythtv/programs/mythbackend/scheduler.cpp around line 1140 in Scheduler::RunScheduler(). there's a while(1) that's the main loop.
15:41<jhurliman>well myth already has logic to track tuner's in use or not internally, this is just adding another way to set tuner's in use
15:41<jhurliman>cool thanks :)
15:41<Captain_Murdoch>if you're messing with messages that's in mainserver.cpp in the same directory.
15:42<Captain_Murdoch>yeah, it can see whether a tuner is busy, but you'd want to have another internal flag to say busy just to keep track of what's busy recording and what's busy with something else.
15:42<jhurliman>i havent looked at that code yet so im kind of guessing here, but couldnt you mark an externally used tuner "in use" the same way mythtv marks tuners in use internally?
15:43-!-choenig [] has quit [Remote closed the connection]
15:43<jhurliman>i mean, does it need a separate variable?
15:43<Captain_Murdoch>then the people who run listings grabbers that have to use a tuner to grab can have some external program that connects to a backend and locks a tuner then unlocks when done.
15:43<jhurliman>yeah it opens up a lot of possibilites... i see mythtv as a system interface, lots of things can be integrated in to it
15:44-!-dopez [~unknown@dopez.xs4all.nl] has joined #mythtv
15:46<jhurliman>off-topic: does tvtime support btaudio?
15:46<Captain_Murdoch>dunno, does tvtime support audio or does it just unmute whatever dsp device you give it? :)
15:46<jhurliman>i've tried a couple different tuner cards and it seems the only way to get bearable audio is through the digital btaudio interface
15:47<jhurliman>Captain_Murdoch: i don't know but i'll be exploring the mythtv<->tvtime relationship this week
15:48<Captain_Murdoch>rather than going all the way back to the encoder object the way the current code does, you could just add SetBusyExternal() and IsBusyExternal() methods in encoderlink.cpp and then just check IsBusyExternal inside the scheduler code that assigns recordings to tuners.
15:48<-- jkolbhas quit ()
15:48<jhurliman>that might be the way to go
15:49<jhurliman>im not interested in tearing apart the backend to add one new feature
15:50<Captain_Murdoch>look in scheduler.cpp for the function isLowOnFreeSpace(). that's the code I added to stop scheduling recordings on a tuner if it's backend's disk fills up. you could just add another check right below my isLowOnFreeSpace() check that would check if the tuner was busy externally.
15:50* Captain_Murdochthinks that's a lotta checks....
15:51<jhurliman>well, this patch is only doing an if(bool), so the overhead isn't too immense
15:51<Captain_Murdoch>:) the code only gets run when the scheduler recomputes so it's no big deal to check then. whenever you get a "NEED-ENCODER" or "FREE_ENCODER" message you could tell the scheduler to recompute by setting the flag in the DB.
15:51<jhurliman>which flag is that?
15:52<Captain_Murdoch>look for ScheduledRecording::signalChange() in mainserver.cpp. it's how you tell the scheduler to recompute. just pass it a db connection and that's it.
15:53<jhurliman>thx
15:53<Captain_Murdoch>yw, glad to help.
15:53<Captain_Murdoch>glad to see more people who can code taking an interest in adding features.
15:54<jhurliman>well, it's my job :-)
15:54<jhurliman>http://www.focustheater.com/
15:57<jhurliman>but im off to lunch break now, i'll drop back in this evening
15:58<jhurliman>hopefully i can get that patch to the mailing list tonight, you cut down a night's worth of code digging to a couple lines here and there :) thx again
15:58-!-jhurliman [] has quit ["Signing off"]
16:02<bline>Chutt: just sent in my native lirc patch
16:13-!-figgy [] has quit ["Client Exiting"]