Back to Home / #mythtv / 2003 / 03 / Prev Day | Next Day
#mythtv IRC Logs for 2003-03-01

00:02-!-Timon [] has quit ["My damn controlling terminal disappeared!"]
00:07-!-Timon [~nunya@157-11-237-24.gci.net] has joined #mythtv
00:10-!-PeteCool [] has quit ["Client Exiting"]
00:36-!-Timon [] has quit [Read error: 104 (Connection reset by peer)]
00:41<schwin97>time to sleep
01:00-!-rkulagow [~Robert@12.207.131.29] has joined #mythtv
02:35-!-FredFunk [~bog@ip68-100-194-106.nv.nv.cox.net] has joined #mythtv
02:37-!-Soopaman_Hussien [~soopaman@h24-66-55-163.wp.shawcable.net] has joined #mythtv
02:55-!-rkulagow [] has quit [Read error: 110 (Connection timed out)]
04:44-!-FredFunk [] has quit [Read error: 60 (Operation timed out)]
04:55-!-FredFunk [~bog@ip68-100-194-106.nv.nv.cox.net] has joined #mythtv
05:18-!-choenig [~choenig@pD952CB2D.dip.t-dialin.net] has joined #mythtv
05:40-!-Soopaman_Hussien [] has quit [Read error: 60 (Operation timed out)]
06:36<thor>Chutt: you up
08:55-!-Bog [~bog@ip68-100-194-106.nv.nv.cox.net] has joined #mythtv
08:57<Chutt>thor, i'm awake now
09:03-!-FredFunk [] has quit [Read error: 60 (Operation timed out)]
09:42<choenig>and, Chutt, how is it about the scheduler stuff?
09:43<choenig>I will make the thing ip aware early next week, i think
11:14-!-Bog [] has quit [Read error: 110 (Connection timed out)]
11:43-!-FredFunk [~bog@ip68-100-194-106.nv.nv.cox.net] has joined #mythtv
11:44<schwin97>had a segfault when I tried to skip a commercial at the end of a recording
11:44<schwin97>is this being looked at or fixed already?
11:44<Chutt>get a backtrace
11:44<schwin97>will do...
11:44<Chutt>send it to the list, or if you know what you're doing, fix it and send a patch to the list
11:49<schwin97>sent the backtrace... Now will see if I can figure out what is going on
11:52<schwin97>is there a way to find out where the end of a recording is?
11:52<Chutt>yup
11:57<schwin97>and I'm guessing that is through totalFrames in NuppelVideoPlayer
11:59<Chutt>yup
11:59<Chutt>but that only works for files, there's another method for live tv stuff
12:00<schwin97>this happened with a recording so that is where I am looking first
12:02<schwin97>what is a method to print something on the osd... I see that you can do it with startpause, but that looks like you then need to unpause
12:03<Chutt>no, you don't
12:21-!-Edgan [] has quit ["Client Exiting"]
12:40-!-rkulagow [~Robert@12.207.131.29] has joined #mythtv
12:43<rkulagow>chutt, are you here?
12:46<Chutt>yup
12:59<rkulagow>sorry - on the other line with moegreen. have you considered setting the default resolution to 640x480 in setup? i set X for 640x480, but since the default is 800x600, i can't even see the "setup" option in mythfrontend to try to change the appearance, and even if i knew the settings, i'm making a lot of the blindly since practically everything is offscreen at the time.
12:59<Chutt>heh
12:59<Chutt>good call
12:59<Chutt>i'll change that
13:01<rkulagow>thanks. i was going to start on a fancy routine that determined the X parameters for height and width and automatically adjust, but that's hard, and setting the default to 640x480 is easy.
13:01<Chutt>i could just set the default to fullscreen
13:02<rkulagow>and that would be irrespective of the X width and height?
13:02<Chutt>it'd set it to whatever x was set to
13:02<rkulagow>ok.
13:20<mdz>Chutt: do you buy this LIRC/system clock stuff?
13:20<Chutt>i have no idea what it is
13:21<rkulagow_>i have no idea if it's system clock related, but i do know that i still have focus problems when irxevent sends an ESC (CurrentWindow seems to have the wrong focus)
13:22<rkulagow_>(this is on KDE 3.1, Click To Focus is set)
13:22-!-Timon [~nunya@157-11-237-24.gci.net] has joined #mythtv
13:29-!-chuckf [~chuckf@12-235-155-167.client.attbi.com] has joined #mythtv
13:44<FredFunk>rkulagow_ I've got the same problem
13:45<FredFunk>rkulagow_ strnage thing is the keyboard has the right focus (i can use the arrow keys still) but I need to use Alt-Tab to get irxevent's focus back
13:46<mdz>it's probably just a bug in irxevent that makes it not work sometimes
13:48<Chutt>heh
13:48<Chutt>lotsa people having problems with the neuros
13:51<Chutt>mdz, i added support for a recording profile that's the same name as the machine name for a quick hack in my last commit
13:51<Chutt>it'll just use that profile in preference to default/live-tv if it exists
13:52<Chutt>i need to decide if the slave backends should initiate connections with the master, or the other way 'round
13:55<mdz>Chutt: I had been thinking about creating a per-host setting containing the name of the profile to use for recordings, and one for live tv
13:55<Chutt>i just did this as an extremely quick hack
13:55<mdz>but I really have no use for it, so I haven't done anything about it
13:56<mdz>yeah, I know
14:08<Timon>Chutt, thanks for you help last night. I'm gaining a better grasp on pointers.
14:27-!-rkulagow [] has quit [Read error: 110 (Connection timed out)]
14:49<Chutt>can someone either help the "Systems Analyst" that's posting to mythtv-dev, or smack him around a bit for posting the same help request over and over and over
14:49<Chutt>i really don't care which =)
14:49<Timon>haha
14:50<Chutt>he's quite obviously linking against a qt that was compiled against a different version of gcc than what he's using to compile mythtv with
14:51<Timon>I just game him a simple answer. . . Switch to mandrake :-)
14:51<Timon>Actually, I should have said slackware =)
15:12<mdz>he's probably using slackware already; that's why he 's compiling everything
15:13<Timon>he said he was using deb. "Is it because I'm using a libqt3-dev package from debian?"
15:14<mdz>if he were running stable, it would work. If he were running unstable, it would work. he's obviously mixing things up and doesn't know how to handle it
15:16-!-Timon_ [~nunya@157-11-237-24.gci.net] has joined #mythtv
15:16-!-Timon [] has quit [Read error: 104 (Connection reset by peer)]
15:16-!-Timon_ is now known as Timon
15:46-!-paperclip [] has quit ["grits.. they aren't just for breakfast anymore"]
15:47-!-danc_ [~danc``@c66-235-37-121.sea2.cablespeed.com] has joined #mythtv
16:13-!-danc_ [] has quit [Read error: 104 (Connection reset by peer)]
17:11-!-rkulagow [~Robert@12.207.131.29] has joined #mythtv
17:11-!-chuckf [] has quit [Read error: 104 (Connection reset by peer)]
17:13<rkulagow>moegreen: i'm back, if you want to do anything.
17:14<rkulagow>ah, wait, nevermind. duty (baby) calls.
17:57<mdz>Chutt: is there any reason why bookmarking is disabled while watching a recording in progress other than that it doesn't have a seek table yet?
17:58<Chutt>that's the only reason
17:58<mdz>hmm
17:58<mdz>it would be useful if that worked
17:58<mdz>maybe it could ignore the bookmark on resume if there is no seektable?
17:58<Chutt>sure
17:59<mdz>does it work that way in order to handle old recordings, or potentially interrupted recordings?
17:59<Chutt>both, really
17:59<mdz>I guess it would have to print a warning or something if it allowed the user to do it
18:00<mdz>which isn't too nice
18:00-!-Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv
18:00<mdz>I've started seeing some choppiness when simultaneously recording and playing back, even though I have plenty of CPU available
18:00<Chutt>any reason why ScheduledRecording::signalChange is protected?
18:00<mdz>wondering if it's related to enabling the jitter stuff
18:01<mdz>but I can't save my place and change it to test, because I'm watching a recording in progress. which is why I asked :-)
18:01<Chutt>heh
18:01<mdz>I think I only meant for it to be called by member functions...is there some reason to do differently?
18:01<Chutt>i want to call it from the server code
18:01<Chutt>so i just removed the protected
18:02<mdz>won't break anything of course
18:02<mdz>I was just trying to keep all of the code that worked with the scheduling data in one place
18:02<Chutt>yeah
18:02<mdz>when I went to change it in the first place, it was hard to follow because it was spread out
18:15<Chutt>hrmph
18:15<Chutt>trying to make sure that the backend<->backend communication doesn't have that same bug in it
18:16-!-rkulagow [] has quit [Read error: 110 (Connection timed out)]
18:46<mdz>CPU is 42% idle, network is ~80% idle...something must be blocking somewhere
18:46<Chutt>yup
18:46<Chutt>try turning off the aggessive audio buffering if that's on
18:47<mdz>I should map the jump key to something
18:47<mdz>takes a long time to skip an hour into a recording using 30 second skips
18:47<mdz>I turned the aggressive audio buffering back on; it didn't work for me anyway
18:47<mdz>er, back off
18:48<Chutt>ok
18:48<mdz>heh, I have 3 of every setting in the settitgs table now
18:48<mdz>since I ran the frontend on my desktop
18:49<mdz>when it's playing an in-progress recording, does it go over the network or from the file?
18:49<mdz>(assuming the file is local)
18:49<Chutt>from the file
18:49<Chutt>er
18:49<Chutt>maybe not
18:49<Chutt>i think it's from the file, though
18:49<mdz>with the jitter stuff on, if anything, I'd think that the backend would be losing the cycles since it busywaits sometimes
18:50<mdz>but with almost half the CPU idle, I wouldn't think it would even matter
18:50<Chutt>it goes by the file, but gets some data from the network
18:51<mdz>same thing happened when I was watching an earlier recording while it was recording something else anyway
18:53<mdz>http://dijkstra.csh.rit.edu:8088/~mdz/mythtv/mythtv-net.png
18:53<mdz>shows network utilization for mythtv
18:53<mdz>using NFS
18:53<Chutt>heh
18:53<mdz>with a 3000kbs bitrate
18:55<mdz>all of the reads are done in the decoder thread, right?
18:56<mdz>maybe a buffer would help
18:56<mdz>and a reader thread
18:56<Chutt>yeah, it doesn't buffer raw disk reads
18:56<Chutt>qt buffers socket reads internally, though
19:02<mdz>maybe ringbuffer should just use a stdio stream or an fstream
19:02<mdz>rather than raw read()s
19:02<mdz>that might smooth things out
19:05<mdz>I think that buffers on input, not sure though
19:08<mdz>only up to 1k it seems
19:08<mdz>it should be reading bigger chunks than that anyway
19:08<Chutt>most of the time, yeah
19:09<Chutt>heh
19:10<Chutt>one little change to programinfo.h
19:10<Chutt>and the entire beast has to get recompiled
19:14<mdz>gcc 3.3 is coming to unstable soon
19:14<mdz>maybe it will have support for precompiled headers^H
19:14<Chutt>heh
19:14<Chutt>that's pretty funny
19:15<mdz>if I wanted to experiment with adding some buffering on that side, do you think it would make more sense to make the ringbuffer buffer reads, or to have the player buffer frames?
19:16<Chutt>ringbuffer buffer reads
19:16<mdz>it would be easier to move it into a separate thread in the player
19:17<Chutt>the player's frames are shared mem
19:17<Chutt>going to run out of them
19:17<mdz>I mean compressed frames
19:17<Chutt>hmm
19:17<mdz>separate from the existing buffer
19:17<Chutt>i think it'd be easier to have the ringbuffer buffer data
19:17<mdz>have one thread filling a buffer with compressed frames, then the main thread just taking each in turn and passing it to the decoder
19:18<mdz>hmm
19:18<mdz>the ringbuffer wouldn't know how far to buffer ahead
19:18<mdz>I guess a couple of megs would be ok in any case though
19:18<Chutt>right
19:19<mdz>there's no seeking unless the user requests it, right?
19:19<mdz>it won't seek to skip over data it doesn't want or such?
19:19<Chutt>no
19:19<mdz>hmm
19:19<mdz>it'd be easiest to ditch the buffer on a seek
19:19<Chutt>it'll seek to skip data, it'll seek to skip commercials
19:19<Chutt>it'll seek for a couple other reasons, too
19:19<Chutt>bad data in the stream, etc
19:19<mdz>if that only happens when it'll be seeking far, that's ok
19:24-!-Edgan [] has quit ["Client Exiting"]
19:25-!-Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv
19:27<Chutt>heh
19:27<Chutt>i hope people don't mind i've been committing broken code all day
19:28<Chutt>not that any of it should be getting called, but...
19:30-!-Edgan [] has quit ["Client Exiting"]
19:34<mdz>if they mind, they should be reading -commits
19:34<mdz>where I believe you said something like "this is probably all broken"
19:35<Chutt>true
19:35<Chutt>i did =)
19:37<moegreen>that's like expecting someone to read a file called README :)
19:38<Chutt>i'm going to go through and cull out unnecessary includes
19:38<mdz>which reminds me, I shouldn't cvs up before testing this stuff
19:38<Chutt>live-tv and playback of recordings works for me
19:39<Chutt>can i supress those warnings in settings.cpp?
19:40<mdz>yeah, looks like it'll be a while before I get around to actually using those classes
19:40<mdz>those methods anyway
19:40<mdz>they're for the recording editor
19:41<Chutt>right
19:42<moegreen>Chutt: I'll take out the unneeded includes from progfind
19:44<mdz>hmm
19:44<mdz>I'm eyeing this usleep(2000) in nuppelvideoplayer suspiciously
19:44<Chutt>moegreen, i'm going through all of them
19:44<Chutt>no worries
19:44<Chutt>progfind.h is 2 files away
19:44<moegreen>ok
19:45<mdz>when stracing the playback thread, once it gets spooled up, when it goes to sleep to let the buffer drain, it sometimes has to sleep twice
19:45<mdz>two 2ms sleeps in a row
19:46<Chutt>hmm
19:46<mdz>I wonder if a semaphore would be better
19:46<mdz>should be only one context switch I'd think
19:47<mdz>there are too many places it could be getting hung up; I need to figure out how to programmatically detect that this is happening so I can see what's going on
19:47<mdz>or catch it in the act somehow
20:00<mdz>if nothing else, buffered reads in ringbuffer would get rid of those 12-byte reads to get the headers
20:03<mdz>out of 44441 reads during my sample period, 22927 were only 12 bytes
20:03<mdz>that seems like significant system call overhead
20:04<Chutt>could just make all of the larger reads be size + 12
20:04<Chutt>and store that in a buffer
20:05<Chutt>return the 12 bytes if the next read is a frame header
20:05<Chutt>or tack it on to the beginning if it's not
20:05<Chutt>that's kinda how the streaming stuff works
20:08<mdz>what streaming stuff?
20:09<Chutt>the remote frontend stuff
20:09<mdz>joshua bernstein has hosed his system
20:09<Chutt>the minimum blocksize it requests is 128k
20:09<mdz>oh, the remotefile stuff?
20:09<Chutt>so like 3 or 4 frames
20:10<Chutt>qt internally buffers it all
20:11<mdz>does the backend keep sending until the frontend tells it to stop?
20:11<mdz>or does the frontend do explicit reads?
20:11<mdz>I haven't looked at that code at all
20:17<Chutt>it does explicit reads, but in 128k chunks
20:17<mdz>ah
20:17-!-paperclip [~joe@ip68-11-30-173.no.no.cox.net] has joined #mythtv
20:17<Chutt>i should be more aggressive about triggering the next read
20:18<Chutt>but it's only right now when it doesn't have enough data in the buffer
20:18<Chutt>should be when it's less then 128/4 or whatnot
20:19<mdz>hmm, I just discovered setvbuf
20:19<mdz>(3)
20:19<mdz>how handy
20:21<mdz>it does exactly what I want with no extra work
20:21<Chutt>heh
20:21<Chutt>except changing to use file streams
20:21<mdz>I'm glad I found this before I implemented my own buffered i/o setup
20:21<mdz>yeah, already did that
20:21<mdz>only catch is I'm not sure if I have the LFS stuff right
20:21<Chutt>make sure you don't mess up the 64-bit stuff
20:21<Chutt>hah =)
20:21<Chutt>anyway, i'll bbl
20:21<mdz>we are using -D_FILE_OFFSET_BITS=64 now, right?
20:22<mdz>I think that makes fseek() act like fseek64()
20:22<mdz>easy enough to test
20:22-!-Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv
20:44-!-choenig [] has quit [Remote closed the connection]
21:26<Chutt>heh
21:26<Chutt>i fixed that bug with the frontend going away in the middle of watching livetv
21:28<mdz>I doubt that will make him go away
21:29<mdz>next he'll say that the frontend crashes if he kill -9s the backend
21:30<Chutt>which it probably does
21:30<Chutt>but the backend recovers gracefully if you kill -9 the frontend =)
21:30<Chutt>of cousre
21:30<Chutt>course
21:30<Chutt>you lose _all_ those shm segments if you kill the frontend
21:31<Chutt>so it's not too smart to do that
21:33<mdz>I did not realize until now that fseek took a long, and not an off_t
21:33<mdz>so they had to make fseeko and ftello
21:33<mdz>gross
21:34<mdz>I broke seeking somehow
21:34<mdz>even after fixing that
21:34<Chutt>do you ever need to flush those buffers?
21:35<mdz>something tries to read 539609505
21:35<mdz>bytes
21:35<Chutt>yeah, you're getting off the boundaries
21:35<mdz>yep, sounds like it's reading a garbage header
21:35<mdz>I'm calling fseeko64 explicitly though
21:35<Chutt>well, what if it's not flushing those buffers of yours
21:35<Chutt>when you seek
21:36<Chutt>that'd make the first data read after a seek garbage, basically
21:36<mdz>all I'm doing is pointing stdio to a big buffer and telling it to use it instead of its internal buffer
21:36<mdz>so it should handle all that stuff the same way
21:36<Chutt>hmm
21:36<Chutt>i dunno
21:36<mdz>it also does it if I remove the setvbuf stuff
21:36<mdz>looking at strace, it seems to be calling llseek
21:36<mdz>is that the 64-bit one?
21:37<Chutt>believe so
21:37<Chutt>err
21:37<Chutt>no
21:37<Chutt>lseek64 is
21:37<Chutt>but, looks like the llseek syscall is the proper one
21:37<mdz>5444 _llseek(11, 13250548, [13250548], SEEK_SET) = 0
21:37<Chutt>takes two unsigned longs as an offset
21:38<mdz>the fact that both of those values are the same is suspicious
21:38<mdz>13250548 doesn't sound like the offset of the seektable
21:38<mdz>maybe the top 32 bits
21:39<mdz>can you strace something real quick and see if it's the same syscall for you?
21:43<mdz>good news is, playback seems to be smooth while I'm recording
21:43<mdz>I hope it's as easy as this
21:43<mdz>nope
21:43<mdz>still doing it
21:43<Chutt>heh
21:44<mdz>can't hurt to do fewer reads though, assuming I can fix the seeking
21:46<Chutt>ah well
21:46<Chutt>gotta spend time with ye olde wife =)
21:47<mdz>I'm about to go out myself
21:50<mdz>I think a 1M buffer was too big, it would block too long reading
21:50<mdz>but a 100k buffer seems to work nicely
21:53<mdz>better anyway
21:53<mdz>seems to only get hung up every minute or two
21:53<mdz>instead of several times per minute
21:54<mdz>I assume that the reads from the buffer are returning quickly, and then once in a while it has to read new data in and that one is slow
21:54<mdz>there's probably a sweet spot
21:54<mdz>but it's going to relate to the bandwidth of the stream
21:54<mdz>so I think it really needs a reader thread
22:07<rkulagow_>moegreen, are you here?
22:33-!-justin [~justin@ool-18b81c6a.dyn.optonline.net] has joined #mythtv
23:08-!-Edgan [] has quit ["Client Exiting"]
23:10-!-rkulagow [~Robert@12.207.131.29] has joined #mythtv
23:32<-- rkulagow(~Robert@12.207.131.29) has left #mythtv
23:45-!-rkulagow [~Robert@12.207.131.29] has joined #mythtv
23:47-!-Edgan [edgan@24-205-202-237.rno-cres.charterpipeline.net] has joined #mythtv
23:56<Timon>woohoo. . . I now understand pointers!
23:59<bigguy>you go, boy