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

00:00<justin_>the docs have practially nothing for debian because debian comes with everything you need in the first place
00:01<rkulagow>axel thimm has rpm's for mythtv as well, which should work for mandrake too. i'll be checking them out on a test box.
00:02<justin_>its not that hard to compile in debian, just slow from being c++
00:02<justin_>the first time I did it I just had bad luck, zap2it had changed that same day
00:02<justin_>so it completely broke:)
00:03<rkulagow>do mdz's debs have all the other modules, like mythweather, etc, or just the core app?
00:03<rkulagow>well, 0.7 actually didn't have other modules, did it?
00:03<justin_>he has mythtv and mythgame or something
00:03<Chutt>it had music, web, game, gallery
00:03<Chutt>i believe he made debs of music
00:03<rkulagow>there was mythgallery in 0.7, but i know weather is totally new.
00:04<justin_>I use mythweb mythvideo and mythweather
00:04<justin_>but mythweb i think has changed a lot since I'm away
00:04<Chutt>he's got web, tv, and music
00:05<rkulagow>:) huh, figures that debian is riding on the compile from source coattails of the mandrake and redhat docs for stuff that's not deb'ified. (is that a word?)
00:06<rkulagow>(that's a joke - no distro wars please)
00:07<justin_>i had looked at the docs, most of the stuff for redhat was how to install mysql, or xmltv or qt
00:07<justin_>for debian you just install 5 things or so, then build mythtv
00:07<Chutt>gallery, game, and video are all simple no-depends compiles, though
00:07<justin_>and mythweb isnt even a compile:)
00:07<Chutt>well, it has additional dependencies
00:09<rkulagow>chutt, i'll start working on 0.8 docs and send them to you once i get my own 0.8 stuff working. i'm thinking that the big things to cover are: master backendserver, non-master backends and frontends. commercial skip doesn't need too much explaining, and i'm thinking of some of the big different features between 0.7 and 0.8. what am i forgetting?
00:10<rkulagow>i'm trying to think of what people are most likely to messup. wrong IP addresses, fucking with the port configs, etc.
00:11<justin_>does the backendsettings still default to 192.168.....
00:11<Chutt>mainly, setting up the mysql access
00:11<Chutt>justin, nope
00:11<Chutt>that's all setup in the first page of the setup program now
00:11<Chutt>yeah, i think i made it default to localhost
00:11<Chutt>which is a broken default, but..
00:11<justin_>evertime I used to update cvs I'd have to fix that
00:12<Chutt>i'd rather have it default to empty, and force people to insert the correct setting
00:12<justin_>ah, that too
00:12<Chutt>because it only works for a single frontend
00:12<rkulagow>anything interesting to note on the mini-webserver on port 6544?
00:12<justin_>yeah, but localhost would work for someone, while a random 192.168 address probably wouldnt work for anyone
00:12<Chutt>rather, a single frontend on the same machine on the backend
00:12<justin_>but having it ask is best:)
00:12<Chutt>it's all in the gui
00:12<Chutt>anyway, so it should be fine
00:13<Chutt>rkulagow, not yet, no
00:13<Chutt>i'll flesh that out eventually
00:13<Chutt>more status info, like when mythfilldatabase was last run, etc
00:13<rkulagow>mebbe for 0.9 you can use that apple rendesvous stuff someone had mentioned...
00:13<Chutt>i'm fairly happy with the current setup
00:13<rkulagow>(i didn't say it was a _good_ idea)
00:14<Chutt>i just wanted a lightweight simple comm protocol
00:14<justin_>is setup now built into mythfrontend?
00:14-!-meth [] has quit [Read error: 54 (Connection reset by peer)]
00:14<Chutt>so that's what i wrote
00:14<Chutt>justin, partially
00:14<Chutt>there's the frontend settings
00:14<Chutt>and the backend setup
00:14<Chutt>the backend is still a separate app
00:14<rkulagow>chutt: other stuff that would be nice is last XMLTV run (or guide data to DATE)
00:14<justin_>makes sense
00:14<justin_>I cant wait to get back to school so I can play:)
00:15<Chutt>rkulagow, and stuff like what the different tuners/frontends are doing
00:15<rkulagow>duh, last xmltv run == mythfilldatabase was last run.
00:15<Chutt>just some simple status info
00:15<Chutt>right now it just has if remote backends are connected or not =)
00:16<Chutt>so it's fairly useless
00:16<rkulagow>yep, sounds good. are you jazzed about the release, and ready for the onslaught once /. picks it up?
00:16<Chutt>can't really be much worse than it's been before
00:16<Chutt>a couple hundred more people on the lists won't affect things much, really
00:16<Chutt>seein as there's >700 there now
00:17<rkulagow>chutt: ever get your epia 10000 from via?
00:17<Chutt>i need to reply to him
00:17<rkulagow>make sure to say "dude" a lot. :)
00:17<Chutt>left him hanging since thursday
00:18<Chutt>i dunno
00:18<Chutt>for free hardware, i'd be willing to make sure it ran
00:18<Chutt>nothing else
00:18<Chutt>he was talking about possibly optimizing things for their stuff
00:19<rkulagow>well, now that there's non-XV support from Chris, that gets at least one potential hurdle out of the way.
00:19<rkulagow>audio might be a bitch though.
00:19<Chutt>yeah, but that's not really all that useful
00:19<Chutt>since it doesn't really do scaling
00:20<Chutt>710 people on the -dev list, almost 487 on the -users list, 194 on the -commits list
00:20<Chutt>that's insane
00:20<rkulagow>insane in the membrain.
00:20<rkulagow>going to bed. have a good night.
00:20<Chutt>yeah, same here
00:20<Chutt>'night =)
00:21<rkulagow>(now watch as all the freaks come out. you ever look at scrollback and see what goes on at 0300? scary!)
00:23* justin_wonders why someone is running a radeon with fbdev
00:44<mdz>rkulagow: all of the dependencies for mythtv are available as Debian packages
00:53-!-nziarek [] has quit [Read error: 60 (Operation timed out)]
01:48-!-Captain_Murdoch [] has joined #mythtv
02:32<-- Captain_Murdochhas quit ()
08:50-!-nziarek [] has joined #MythTV
09:53<rkulagow>moegreen: are you here?
10:12-!-nziarek [] has quit [Read error: 110 (Connection timed out)]
10:48-!-justin_ [] has quit [Read error: 110 (Connection timed out)]
10:58-!-rickter [] has joined #mythtv
11:08<rkulagow>chutt: are you here?
11:35<rkulagow>chutt: are you here?
11:45<-- rkulagow(~mythtv@ has left #mythtv
11:47-!-rkulagow [~mythtv@] has joined #mythtv
12:17-!-Soopaman [namapoos@] has joined #mythtv
13:01-!-justin_ [] has joined #mythtv
13:17<Chutt>rkulagow, not really =)
15:19<rkulagow>chutt: are you back now?
15:21<rkulagow>turns out that i've got that same QPainter null issue that someone else reported. got it in gdb, but doesn't give anything interesting in the bt
15:21<Chutt>ah, sure
15:22<rkulagow>This GDB was configured as "i586-mandrake-linux-gnu"...
15:22<Chutt>can you update to current cvs and see if it prints out anything interesting?
15:22<rkulagow>(gdb) run
15:22<rkulagow>Starting program: /usr/local/bin/mythfrontend
15:22<rkulagow>[New Thread 16384 (LWP 1541)]
15:22<rkulagow>connecting to backend server:
15:22<rkulagow>QPainter::begin: Cannot paint null pixmap
15:22<rkulagow>Program received signal SIGSEGV, Segmentation fault.
15:22<rkulagow>[Switching to Thread 16384 (LWP 1541)]
15:22<rkulagow>0x4083ddb2 in XSetTile () from /usr/X11R6/lib/
15:22<rkulagow>Current language: auto; currently c
15:22<rkulagow>(gdb) bt
15:22<rkulagow>#0 0x4083ddb2 in XSetTile () from /usr/X11R6/lib/
15:22<rkulagow>(gdb) bt full
15:22<rkulagow>#0 0x4083ddb2 in XSetTile () from /usr/X11R6/lib/
15:22<rkulagow>No symbol table info available.
15:22<rkulagow>ok, will do. (this is on a non-master backend running Qt 3.1
15:22<Chutt>and make sure that there's no older version of libmyth anywhere
15:22<Chutt>and that you're running the right bin as well
15:23<rkulagow>ok, cvs -z3 co doesn'
15:24<rkulagow>t show any new files, so i believe i'm already running the latest. let me check that there aren't any old libs lying around.
15:24<rkulagow>nope, only libs are in /usr/local/lib
15:25<Chutt>can you go in to libs/libmyth/mythcontext.cpp
15:25<Chutt>around line 165
15:25<Chutt>see the if (height < 160 bit?
15:25<Chutt>comment out the line with the if on it
15:26<Chutt>and the bits that say 'height = 640;' and 'height = 480;'
15:26<Chutt>i have that backwords in tere
15:27<rkulagow>height and width should be reversed
15:28<rkulagow>height=480, etc, correct?
15:28<Chutt>i just fixed that
15:28<Chutt>but, i'm wanting you to just comment out those two lines
15:29<Chutt>i'm interested in the debug output
15:29<rkulagow>ok, standby
15:29<rkulagow>so, the if and the height, width are commented out
15:30<Chutt>shouldn't have to do a make clean or anything
15:33-!-thor_ [] has quit ["using sirc version 2.211+KSIRC/1.2.1"]
15:33<rkulagow>almost there - feeding daughter...
15:38<rkulagow>here we go:
15:39<rkulagow>(gdb) run
15:39<rkulagow>Starting program: /usr/local/bin/mythfrontend
15:39<rkulagow>[New Thread 16384 (LWP 2400)]
15:39<rkulagow>connecting to backend server:
15:39<rkulagow>Somehow, your screen size settings are bad.
15:39<rkulagow>GuiHeight: 0
15:39<rkulagow>GuiWidth: 0
15:39<rkulagow>m_height: 600
15:39<rkulagow>m_width: 800
15:39<rkulagow>Falling back to 640x480
15:39<rkulagow>Somehow, your screen size settings are bad.
15:39<rkulagow>GuiHeight: 0
15:39<rkulagow>GuiWidth: 0
15:39<rkulagow>m_height: 600
15:39<rkulagow>m_width: 800
15:39<rkulagow>Falling back to 640x480
15:39<rkulagow>QPainter::begin: Cannot paint null pixmap
15:39<rkulagow>Program received signal SIGSEGV, Segmentation fault.
15:39<rkulagow>[Switching to Thread 16384 (LWP 2400)]
15:40<Chutt>still doesn't say where it's crashing, i assume?
15:40<rkulagow>Program received signal SIGSEGV, Segmentation fault.
15:40<rkulagow>[Switching to Thread 16384 (LWP 2400)]
15:40<rkulagow>0x4083edb2 in XSetTile () from /usr/X11R6/lib/
15:40<rkulagow>Current language: auto; currently c
15:40<rkulagow>(sory - bad cut and paste)
15:41<Chutt>ok, at the end of the same function you just modified
15:41<Chutt>cout << wmult << " " << hmult << endl;
15:42<Chutt>which theme are you using, btw?
15:42<rkulagow>before the floating point div, correct?
15:42<Chutt>at the very end
15:43<Chutt>one more change
15:43<Chutt>line 424
15:44<Chutt>after the QPixmap background(GetNumSetting("GuiWidth"
15:44<Chutt>see it?
15:45<Chutt>cout << "background is: " << background.width() << " " << background.height() << endl;
15:45<rkulagow>before QPainter?
15:47<rkulagow>here we go:
15:47<rkulagow>(gdb) run
15:47<rkulagow>Starting program: /usr/local/bin/mythfrontend
15:47<rkulagow>[New Thread 16384 (LWP 3006)]
15:47<rkulagow>connecting to backend server:
15:47<rkulagow>Somehow, your screen size settings are bad.
15:47<rkulagow>GuiHeight: 0
15:47<rkulagow>GuiWidth: 0
15:47<rkulagow>m_height: 600
15:47<rkulagow>m_width: 800
15:47<rkulagow>Falling back to 640x480
15:47<rkulagow>1 1
15:47<rkulagow>Somehow, your screen size settings are bad.
15:47<rkulagow>GuiHeight: 0
15:47<rkulagow>GuiWidth: 0
15:47<rkulagow>m_height: 600
15:48<rkulagow>m_width: 800
15:48<rkulagow>Falling back to 640x480
15:48<rkulagow>1 1
15:48<rkulagow>background is: 0 0
15:48<rkulagow>QPainter::begin: Cannot paint null pixmap
15:48<rkulagow>Program received signal SIGSEGV, Segmentation fault.
15:48<rkulagow>[Switching to Thread 16384 (LWP 3006)]
15:48<rkulagow>0x4083edb2 in XSetTile () from /usr/X11R6/lib/
15:48<rkulagow>Current language: auto; currently c
15:48<Chutt>ok, sec
15:50<Chutt>ok, delete your mythcontext.cpp
15:50<Chutt>update to current cvs
15:51<rickter>hello all, was wondering if I could pose a hypothetical question to you all concerning multiple frontend/backend setups?
15:51<Chutt>so you should have a new copy of mythcontext.cpp
15:51<Chutt>and let me know if it works
15:51<Chutt>don't need to make clean or anything
15:51<rkulagow>right; making
15:54<rkulagow>looks good - watching "home movies". cool.
15:54<Chutt>so that fixed it ok?
15:55<rkulagow>burp time. bbl. thanks.
15:55<rickter>so may I ask you all a few questions about multiple backend/frontend setups?
15:55<Chutt>don't fucking ask if you can ask a question
15:55<Chutt>that's so stupid.
15:56<Chutt>you just asked one, why not just go ahead and ask what you wanted to in the first place?
15:56<rickter>christ, since you guys belittle people like that, seemed reasonable
15:57<Chutt>i'm sorry, i don't like people who needlessly waste my time
15:57<rickter>well, my question being
15:58<rickter>will multiple systems connecting to each other alter the stop points, delete episodes, etc on the other backend or just read only access?
15:58<Chutt>it's full access
15:58<Chutt>anything a local frontend can do, a remote one can do
15:58<rickter>is there any way to disable that? I have an upstairs neighbor who wants to use myth, but i don't want them to be able to delete stuff
15:58<Chutt>editing is limited to one frontend at a time, though
15:59<Chutt>not with the way things work now, no
15:59<Chutt>it'd be fairly easy to add in access controls, but...
15:59* justin_should probably make sure the myth port is firewalled when I get back:)
16:00<Chutt>really, someone with a need for that will have to write the code
16:00<justin_>yeah, doesn't really matter right now
16:00<rickter>ok, i thought it might be something like limited mysql access would take care of it, but I only have a rudimentary understanding of the code
16:00<justin_>and adding authentication and stuff would be mostly straightforward
16:01<Chutt>well, the backend is what actually deletes stuff
16:01<Chutt>and provides the list of shows, etc
16:01<Chutt>so the backend would have to know who's connected and what they are/aren't allowed to do
16:02<Chutt>of course, you _would_ have to couple that with mysql access controls, i suppose
16:02<rickter>well, stop points are the major issue, my gf doesn't want them to be able to change the stop points on episodes she is watching, which i think is valid
16:03<rickter>is that data stored in the mysql db?
16:04<rickter>hmmm, if i setup a seperate user for their frontend to connect with, that would stop them from changing stop points, correct?
16:04<Chutt>not certain, really
16:14<rkulagow>chutt: do non-master backends need to run mythfilldatabase?
16:36<Chutt>they can
16:36<Chutt>but it should only need to be run once
16:41<bigguy>they all share the same db right?
16:41-!-meth [] has joined #mythtv
16:42<bigguy>of course maybe one of them would be recording from sat, 2 from cable and so on. You'd need different info
16:42<Chutt>all in the db
16:43<Chutt>and filldatabase will collect as much data as it needs to, with as many different grabbers as it needs to
16:43<Chutt>so one run _somewhere_ should take care of it =)
16:48<rkulagow>ok; i was just asking because setup still says "run mythfilldatabase" and i wanted to make sure that it was still appropriate.
16:48<rkulagow>(wanted to get the docs accurate on this point...)
16:56* poptixponders pasting
16:56<bigguy>how any lines?
16:56-!-rickter [] has quit [Read error: 54 (Connection reset by peer)]
16:56<bigguy>many even
16:57<poptix>DB Error (program insert): / Query was:
16:57<poptix>INSERT INTO program (chanid,starttime,endtime,title,subtitle,description,category) VALUES(1078, "20030316223000", "20030317000000", "No Man's Land:
16:57<poptix>European Edition 5", "", "Foreign women experience passion sans men.", "Adult");
16:57<poptix>Driver error was: / QMYSQL3: Unable to execute query / Database error was: / Duplicate entry '1078-20030316223000' for key 1
16:58<bigguy>woot pr0n
16:58<Chutt>well, was there a preexisting entry with that chanid and starttime?
16:59<poptix>i would assume there was
17:00<poptix>that's from mythfilldatabase
17:00-!-inman [] has joined #mythtv
17:01<Chutt>you wouldn't happen to have two channels in xmltv that have the same channel number, would you?
17:02<poptix>[root@tranq .xmltv]# cat tv_grab_na |sort |uniq -d
17:02<Chutt>it'd be in ~/.mythtv/, though
17:02<Chutt>you'd need to only use the first column, not the whole line
17:03<Chutt>well, the 2nd column
17:03<inman>you may find the data from the db more easily:
17:03<inman>select distinct a.callsign,b.channum,a.channum from channel a, channel b where a.chanid != b.chanid and a.callsign = b.callsign group by callsign order by b.channum;
17:03<Chutt>i've got a number of dupe channel numbers in my data feed, actually
17:03<poptix>[root@tranq .mythtv]# cat TV.xmltv |sort |uniq -d
17:04<Chutt>cat TV.xml | cut -d ' ' -f 2 | sort | uniq -d
17:05<Chutt>if it's formatted the same as mine is, at least
17:05<poptix>channel: 78 HOTNET
17:05<poptix>channel: 78 SPICE
17:05<Chutt>lookithat ;p
17:06<poptix>damned tv listings
17:06<inman>any reason we can't handle this gracefully in filldata()?
17:06<inman>i had this problem myself with many channels when i first started with myth...
17:06<Chutt>it is handled gracefully
17:06<Chutt>it attempts to prune out any dupes by comparing the amount of data that's there
17:07<Chutt>conflicts, etc
17:07<inman>well, it crashed due to db errors when i installed from cvs a couple weeks ago.
17:07* inmanshrugs.
17:07<Chutt>it certainly doesn't crash due to dupe channels like that
17:08<Chutt>since i just let it run through
17:08<inman>someone else had the problem and i posted the comment-em-out solution to them in the dev list.
17:08<Chutt>it does complain about things, though
17:08<inman>s/crash/bitches with db errors/
17:08<inman>are you sure a db failure doesn't put us into a "suboptimal" execution path?
17:09<inman>eg. breaking out of a loop or something...
17:09<Chutt>it just continues on
17:15<mdz>they did that with my listings, and tv_grab_na didn't change anything, only spit out warnings
17:15<mdz>it said that the old channel was unavailable, and there was a new channel available with the new name
17:16<inman>i had exactly what poptix has, day one. multiple callsigns, single channums.
17:16<Chutt>mdz, see andrew bishop's patch to your mplayer patch?
17:17<Chutt>looks like he took care of the rtjpeg stuff
17:17<mdz>just finished going through that mailbox too
17:17<Chutt>oh, wait, he only sent it to users
17:17<mdz>maybe I haven't gotten it yet
17:17<Chutt>shall i forward it to you?
17:18<bigguy>Chutt: he sent 2 patches right?
17:18<Chutt>the other just changes the cutlist into a format that mplayer can grok
17:18<mdz>yeah, do
17:18<mdz>I don't have any rtjpeg stuff to test it on, but if it doesn't break things for me, I'll happily merge it into the patch on my site
17:20<mdz>I put together a reader thread for the ringbuffer
17:20<mdz>haven't tested whether it smooths out my suspected latency problem or not
17:20<Chutt>help any?
17:20<mdz>but it's a little sluggish on seeking
17:20<mdz>which I kind of expected
17:20<Chutt>i'd rather if you didn't commit that to cvs at the moment, btw =0
17:20<Chutt>err, =)
17:20<mdz>it takes a fraction of a second to get going again
17:20<mdz>nah, course not
17:20<mdz>just experimenting
17:21<mdz>it'd be nice if the kernel would do this for me, actually
17:21<bigguy>mdz: nfs stuff?
17:21<inman>changing the chanPerPage and timePerPage for the alternate EPG crashes the guide on my box.
17:21<mdz>I believe it does read-ahead, but maybe there's a way to tune it to do more
17:21<mdz>bigguy: yep
17:21<inman>mdz: i'm having the same issues with ringbuffer/seeking/nfs.
17:22<bigguy>mdz: linux nfs server stuff is teh suck as some would say
17:22<mdz>inman: oh? that works fine for me with the current code
17:22<bigguy>linux client is good tho
17:22<inman>i'm using a commercial linux-nfs implementation...
17:22<mdz>my only problem is a very small skip every 30-60 seconds if I'm both recording and playing back at the same time
17:22<inman>mdz: it's better, but livetv is still slow/jerky.
17:22<mdz>with just playback, it sometimes happens once every few minutes
17:22<mdz>inman: yeah, live tv doesn't work too well in such a setup
17:22<inman>mdz: which encoder are you using? i'm using rtjpeg.
17:23<mdz>inman: mpeg-4
17:23<inman>mpeg-4 always skips every few seconds for me, i can't understand it.
17:23<inman>rtjpeg offers awesome quality and doesn't seem to dent my cpu much, i don't get it.
17:23<Chutt>it doesn't compress very much
17:23<mdz>rtjpeg produces huge files, so you'll be doing a lot of I/O, especially with nfs
17:24<Viddy>mdz: rsize=8192,wsize=8192 <-- these are probably the things you need to fester with for nfs
17:24<inman>but i can't make mpeg-4 work at minimum quality levels.
17:24<inman>viddy: that disables the automagic packet-size scaling though.
17:24<mdz>Viddy: not on ethernet
17:24* Viddyblinks
17:25<mdz>reading and writing 8k blocks in ~1500-byte Ethernet frames adds up to more overhead than 1k blocks
17:25<inman>i think the chanPerPage and timePerPage settings should be disabled in the setup gui.
17:26-!-justin_ [] has quit [Read error: 60 (Operation timed out)]
17:26<inman>unless... do those settings only get smaller?
17:26<Chutt>how are you changing the settings?
17:27<inman>via the gui, i couldn't increase them.
17:27<inman>via the db, i crashed the guide. :-D
17:27<Chutt>you can't increase them
17:27<inman>okay, that answers that question.
17:27<Chutt>the gui only lets you select things that work
17:27<inman>i'm trying to make the guide run at a decent speed.
17:28<Chutt>turn off the 'decorate qt widgets according to theme' setting in appearance
17:28<inman>btw, i need to submit a patch for web/movies so that it will do the right thing with multiple tuners.
17:29<inman>(prior to 0.8)
17:29<Chutt>you've got less than a week :p
17:29* inmanwill have it done in a few minutes.
17:33<mdz>I need a switch
17:33<mdz>this hub is not helping things
17:34<inman>i thought you were using wireless?
17:34<mdz>why would you think that?
17:34<mdz>I'm not crazy
17:34* inmanshrugs.
17:35<inman>i thought you were. :-P
17:35<mdz>I could probably get away with larger nfs block sizes if I had a switch
17:36<inman>i don't understand why you think the overhead is greater at higher packet sizes.
17:36<inman>you are using nfs/tcp, right?
17:36<mdz>packet != block
17:36<mdz>and no, I'm not using tcp, though I've thought about trying it
17:36<inman>is it not the default now?
17:36<mdz>hell no
17:36* inmanisn't using "normal" linux nfs.
17:37<mdz>I think you may even need a patch just to get it
17:37<mdz>though it may be in 2.4.20
17:37<mdz>yeah, it's in .20 (marked experimental), not .19
17:37* inmannods.
17:38<mdz>now to find a cheap switch that doesn't suck too much
17:38<inman>mine is tcp and it's fast, but that may not be why.
17:39<mdz>how are you classifying "fast"?
17:39<inman>my tcp network only flows at about 2.6meg/sec and the nfs is almost the same.
17:39<mdz>I get over 3 megabytes/sec throughput without even trying, which is more than enough for video
17:40<inman>my client is a slow box on 10bt, but... it's plenty quick for me.
17:40* inmanis more concerned about wireless.
17:40<mdz>my network utilization tops out at less than 4 mega_bits_
17:40<mdz>I don't have a throughput problem
17:41-!-rickter [] has joined #mythtv
17:41<inman>what do you think the bottleneck is?
17:41<inman>you don't have any foundry eq on your net, by any chance?
17:41* inmanhad some bad experiences with foundryOS and linux/nfs.
17:43<mdz>probably from collisions
17:43<mdz>but general network latency is probably enough to explain what I'm seeing
17:43<inman>how many clients on the hub?
17:43<inman>have you tried testing with `ttcp`?
17:44<mdz>only two clients on the hub that actually do anything, one being the NFS client, and one being the server
17:44<mdz>but that's enough to get 0.1% or so collisions
17:45<inman>just from the acks/request from the client?
17:45* inmanfrowns.
17:46<mdz>1 second of video would be about 6 frames if there were no other overhead
17:46<mdz>so the packet rate is pretty high
17:46<mdz>about 400pps
17:46<mdz>in each direction
17:47<mdz>IP overhead + UDP overhead + NFS overhead, etc.
17:47<inman>still, that's not too high throughput.
17:47<Chutt>throughput isn't the problem
17:47<mdz>yes, I think I've mentioned that :-)
17:47<inman>with udp you shouldn't have a latency issue.
17:47<Chutt>occasional latency is
17:47<mdz>I get 10 times the throughput with a simple benchmark than the video streams require
17:48<mdz>UDP packets take the same amount of time to make a round trip as anything else
17:48<inman>do you have anything with which to test the nfs?
17:48<mdz>worse when they need to be retransmitted
17:48<mdz>what do you mean?
17:48<inman>yes but there's less sequencing issues.
17:49<inman>well, you've ruled out the underlying network and the throughput issues.
17:49<poptix>i was pushing 40mbit/s for 3 hours lastnight with samba
17:49<inman>so what does that leave you with? nfs itself?
17:49<mdz>inman: do you know what problem I'm trying to solve?
17:49<inman>latency, but where?
17:49<poptix>that was with a linksys 8 port switch
17:50<mdz>poptix: that sounds reasonable
17:50<poptix>i think the limitation was the PII-300 that the data was being pushed to
17:50<mdz>inman: latency in read() :-)
17:50<poptix>the load was at 4.5, and samba was at 90% cpu =p
17:50* inmansighs.
17:50<mdz>poptix: want to send me your switch in the mail?
17:50<poptix>mdz: heh =)
17:51<Chutt>switches are cheap nowadays
17:51<poptix>mdz: are you thinking of upgrading, or are you having problems with an existing 10/100 network?
17:51<mdz>poptix: I have a hub
17:51<inman>cheap switches are cheap, good switches are still only cheaper. ;-)
17:51<mdz>Chutt: yeah, I should just pick one up at the store
17:51<poptix> Switch 8PORT 10/100 Mbps
17:52<mdz>but there has been a flood of shitty networking equipment into the market it seems
17:52<poptix>DESKTOP (4 + 4Port) Dual Speed 8Port Ethernet LAN
17:52<poptix>oh, n/m
17:52<poptix>that's $16, but has a minimum order of 5
17:52<Chutt>$40 or so probably at a b&m for a linksys
17:52<inman>people now sell hubs as switches, it's ridiculous.
17:52<Chutt>'course, that's all crappy, but hey =)
17:53<poptix>you can get a compaq 5 port 10/100 for $17 + $1.99 shipping
17:53<mdz>inman: yeah, I'd like to get something I know will be OK
17:53<mdz>maybe I should pick up a Catalyst from ebay
17:53<inman>mdz: any netgear with and internal power supply.
17:53<mdz>plenty of tech companies going out of business and selling good stuff
17:53* inmanswears by netgear.
17:53<mdz>inman: yeah? they're all over the place, I could pick one up
17:54<poptix>mdz: you could always pick up a D-Link DI-614+ 11/22/44mbit wireless AP (802.11b+) that comes with a 4 port switch
17:54<inman>i have an fs308 (i think)
17:54<poptix>i got one for $69
17:54<Chutt>i've got a cheapo linksys 5 port switch, and an smc wireless router/switch/ap thingie
17:55<Chutt>the smc broke, and their tech support was alive at 3 am for a phone call
17:55<Chutt>which was rather amazing, i thought =)
17:55<mdz>Chutt: we have an SMC router/switch/AP thing at work
17:55<inman>so you called them and they told you it was broken?
17:55* inmangrins.
17:55<mdz>the thing hangs about once a week and needs to be power cycled
17:55<Chutt>pretty much
17:55<inman>good thing you found out at 3am!
17:55* inmanchuckles.
17:55<Chutt>mdz, mine's been on for about a year now
17:56<Chutt>inman, heh, they tried to get it to reset itself, it was picking random ips to live on =)
17:56* inmanuses the fr318 netgear router/switch.
17:56<mdz>Chutt: is the linksys ok?
17:56<Chutt>it's slow
17:56<Chutt>but, it's rather old
17:56<Chutt>haven't had any problems with it
17:57<inman>mdz: make sure you don't buy anything with SNMP on it. :-P
17:57<Chutt>i don't like linksys, though
17:57<Chutt>i've got two dead wireless pcmcia nics from them that they refused to replace
17:57<inman>i heard the linksys WAP stuff sucks, but i don't know if that extends to their router/WAP products.
17:57* inmannods.
17:57<inman>they must just have bad WiFi gear, period.
17:58<mdz>micro center carries d-link, linksys, siemens, USR and "xsense" whoever that is
17:58<bigguy>I like d-link
17:59* Viddylikes nortel
17:59<bigguy>we used a bunch of them at the schools
17:59<bigguy>managed and not
18:00<inman>once you get into managed switches, it's a whole new ballgame.
18:00<inman>cisco 3300s, 3900s, etc.
18:00<mdz>the cheapest is a USR 5-port switch for $39
18:00<bigguy>well we used both
18:00<mdz>wait a describes itself as a "switching hub"
18:00<bigguy>but the reason we didn't use cisco was because of the budget
18:00<mdz>wtf is that
18:00<inman>it's not a switch, that's for sure.
18:01<mdz>probably means autosensing
18:01* inmansnickers.
18:01<inman>told ya they're selling hubs as switches.
18:01<mdz>I had to look twice to notice
18:01<inman>i think we paid like 3-4k per cisco 3900 (nice backplanes)
18:01<inman>the 3300s were slower, but only like 800-1200/each or something.
18:02<inman>3300s are good for gig/copper, too, which the 3900 has no module for.
18:05<inman>mdz: try ttcp?
18:06<Viddy>switching hub == switch
18:06<inman>are you really comparing retail badging to a real glossary?
18:06<Viddy>yeah :)
18:07* inmanpats Viddy on the head.
18:07<mdz>inman: if I'm not mistaken, that is a tool for measuring TCP throughput
18:07<inman> Ttcp times the transmission and reception of data between two systems
18:07<inman> using the UDP or TCP protocols.
18:08* inmanshrugs.
18:08<inman>i think it may help you isolate where the latency is actually occuring.
18:12<mdz>inman: the way mythtv currently works, it has a loop that looks a bit like this: while (...) { read a frame; decode the frame into a buffer for display }
18:12<mdz>the uncompressed frames are large and stored in the X server, so there aren't very many of them
18:13<mdz>if that read() takes too long, bad things happen
18:13<inman>is there any reason we can't read and decode in separate threads?
18:13<mdz>hey good idea! I didn't think of that when I implementad that this morning
18:13* inmangiggles.
18:14<mdz>that's how this discussion began
18:14* inmannods.
18:14<mdz>it's a bit tricky to get it right though
18:14<inman>so even with the data already on the client, in memory (albeit compressed), there is still latency in the decode->display loop...?
18:14<mdz>so that it doesn't have to wait too long for the reader to spool up after a seek
18:14* inmannods.
18:14<mdz>the decode and the read happen in one thread
18:14<mdz>display happens in another thread
18:15<inman>i think i knew that from prior investigation.
18:15<inman>do you through the entire read buffer away when seeking?
18:15* inmannods.
18:16<mdz>even if it tried to be smart, most of the time it would have to anyway, at least with my 30-second fastforward amount
18:16<inman>how big is the buffer in compressed frames?
18:16<mdz>there is no buffer of compressed frames
18:16<mdz>that's what I was experimenting with
18:16<inman>that's what i mean.
18:16<mdz>they are read and decoded (decompressed) and then buffered
18:16* inmangrins.
18:16<mdz>about 2M right now
18:16<mdz>reading 200k chunks
18:17<inman>2m decompressed or 2m read?
18:17<mdz>2M of data from the file
18:17<mdz>so compressed
18:17<inman>the way mpeg works, you need incremental frames and deltas, right?
18:18<inman>so you need to buffer enough to seek, which is not just a few deltas...?
18:18<mdz>unless you enable exact seeking, mythtv only seeks to the nearest keyframe
18:18* inmannods.
18:18<mdz>which is a complete frame
18:19<inman>each read blocks on 200k?
18:20<mdz>I've experimented with a lot of different chunk sizes
18:20<bigguy>wow an internationalization patch
18:21<inman>the 'Locale' should be renamed to distinguish it from 'locale' (for mythweather)
18:21<inman>or vice-versa, more likely.
18:27<mdz>well that's isn't seeking
18:27<mdz>that would explain the delay
18:28<mdz>must not have read the seektable for some reason
18:29-!-vidar [] has quit [Read error: 113 (No route to host)]
18:36-!-vidar [] has joined #mythtv
18:44-!-nziarek [] has joined #MythTV
18:54-!-justin_ [] has joined #mythtv
19:21-!-Soopaman [] has quit [Read error: 60 (Operation timed out)]
19:22<inman>can anyone explain how alternate inputs for a given capture device are used by TVRec?
19:23<inman>it looks like it defaults to the defaultinput and there doesn't seem to be any way to point it at another input within the object.
19:29-!-nziarek [] has quit [Read error: 60 (Operation timed out)]
19:36-!-TheAsp [] has joined #mythtv
19:37<TheAsp>whats this programrating table?
19:38<TheAsp>oh, havent updated myth
19:50-!-PeteCool [] has joined #mythtv
19:50<PeteCool>Chutt: remember about people saying the mouse pointer appeared in mythmusic vis, and never disappeared? It's bumpscope that does that
19:51<PeteCool>the others don't do it
19:51-!-meth [] has quit [" | Urban Terror Freestyle!"]
20:09<PeteCool>Is it possible to have the prev/rew/play/pause/stop/ff/next widgets in mythmusic behave like the other ones (eg, the "Next" in the setup screens)?
20:12<PeteCool>I mean that both enter and space could activate them
20:13<inman>should be pretty trivial.
20:18<PeteCool>that's what I thought, but after a talk with my friend, it seems java (even though it looks very similar) is missing "some" things I need to know to code this
20:19<PeteCool>so I'm reading up on it :)
20:19<inman>what does java have to do with it?
20:20<PeteCool>some people say it's similar, and I know some of it
20:20<inman>it's irrelevant to this exercise. :-)
20:39<TheAsp>is mythmusic more friendly with large collections now?
20:40<inman>what do you mean by "friendly"?
20:44<inman>strange, music isn't working for me at all
20:44<inman>pete: are you using the cvs version?
20:45<TheAsp>it used to want to rescan my files all the time
20:45<TheAsp>startup times were horrible
20:46<inman>no, that's still a problem.
20:46<inman>i don't know why people don't complain about it.
20:47<TheAsp>i'd complain if i could actually use it :)
20:47<inman>how many files do you have? are you storing them over nfs?
20:48<inman>mythmusic is unable to recognize my FLAC files; the ones it encoded for me just a couple weeks ago.
20:48<inman>wtf is going on here
20:48<PeteCool>inman: yes, I'm using CVS
20:48<TheAsp>no, 5400rpm drive...
20:48<inman>pete: when i get my playlist playing, i'll take a look at your button request.
20:49<inman>asp: it's the number of files that matters, not the size.
20:49* inmannods.
20:50<inman>well, for starters, we could scan them only when the playlist editor is requested.
20:50<inman>then normal playback would not be affected (if that's all you ever do).
20:50<TheAsp>grr, my cat just killed an ide cable
20:51<inman>that's why i keep the litterbox /outside/ of my PC...
20:51<TheAsp>hhaha, he dug it out of a box
20:51<TheAsp>well, it doesn't take long to scan the mtimes and only rescan the mtimes of files not in the db
20:52<TheAsp>only rescan the ones with an mtime not in the db
20:52<inman>you can scan the directories only, but that's still a decent number of nodes.
20:52<inman>i would rather just have a button that people can hit which updates the db.
20:53<inman>hit it only when invisibly moving files into MusicLocation.
20:53<inman>otherwise, mythmusic should be able to handle the "Import" updates normally.
20:54<inman>mythmusic: unsupported fileformat
20:55<inman>the playlist editor is also confused about which branches are selected.
20:55<inman>pete: can you see if you can rip and then play a FLAC ("Perfect") track?
20:57<TheAsp>mtime isnt even stored in the db...
20:58<inman>of course, that's why it's slower. well, one reason.
20:58<inman>here's a quote from isaac:
20:58<inman>The slowdown is in generating the entire GUI tree of music data, and in doing
20:58<inman>a CD lookup if needed, not in loading/saving the playlist (since that doesn't
20:58<inman>even happen at the same time). In my experience, hitting the CD takes much
20:58<inman>longer than the rest of the data lookups.
21:00<TheAsp>thats about cd's
21:00<inman>well, he goes on...
21:00<inman>Things could be preloaded somewhat, but every track needs to be checked
21:00<inman>against the default playlist in order to properly mark upper level tree items
21:00<inman>as selected or not (ie, If every track in an album is in the playlist, then
21:00<inman>the album should be selected. If every album by an artist is selected, the
21:00<inman>artist should be selected).
21:00<TheAsp>i'm not talking about the gui
21:00<TheAsp>im talking about updating the metadata in the db
21:01<TheAsp>the mp3 metadat
21:01<inman>when does that happen?
21:01<TheAsp>when you start
21:01<inman>i think the information is shared and built by both functions.
21:02<TheAsp>wjem ot says stuff like this:
21:02<TheAsp>Checking: /data/Music/Dead Voices on Air - Piss Frond/03 - Dead Voices on Air - Sulphur.mp3
21:02<inman>i don't know why it checks every time you start. as i said, i think it should be triggered manually by the user.
21:02<TheAsp>i dont
21:03<TheAsp>i think it should see what files were modified or not in the db and only update the ones that wern't
21:03<inman>that's output from tracks you added via `import` earlier, is it not?
21:03<TheAsp>how big is your mp3 library?
21:03<inman>the db doesn't match the filesystem, though.
21:03<TheAsp>and i mean big, not count
21:03<inman>how can the db know if you've modified the fs?
21:03<TheAsp>since it involves reading them all
21:03<inman>i don't use MP3, I use flac.
21:03<TheAsp>inman: by checking and storing the mtimes of the files
21:04<inman>asp: are you using any other program to manipulate your library?
21:04<TheAsp>you mean the metadata in the db?
21:04<TheAsp>or the files on the disk?
21:04<inman>are you using ANY other program, other than mythmusic, to create or arrange files in your filesystem.
21:04<inman>the fs
21:04<TheAsp>i'm adding albums all the time
21:05<inman>asp: are you using ANY other program, other than mythmusic
21:05<TheAsp>of course
21:05<TheAsp>why would i use mythmusic at all?
21:05<TheAsp>it scans my files every time i start it
21:05<inman>then how do you expect myth to recognize that stuff has changed?
21:05<TheAsp>by checking the mtimes on the files?
21:05<inman>...which involves scanning the entire fs.
21:05<TheAsp>mtime's are the times the fs records for when a file is modified
21:05<TheAsp>it involves checking the dir tree, not reading in the id3 tags from the files
21:06<inman>that's a fs-metadata scan.
21:06<inman>oh, i see what your complaint is! :-)
21:06* inmansmacks himself.
21:06<inman>yeah, it could do that. yeah, it'd be faster.
21:06<inman>how many directories do you have?
21:06<TheAsp>or so
21:06<TheAsp>it reads in 27gb
21:06<inman>find -type d /data/Music | wc -l
21:07<TheAsp>committee:/data/Music$ ls -1 | wc -l
21:07<TheAsp> 386
21:07<inman>you have a single directory per each album, that's all?
21:07<TheAsp>thats it
21:07* inmannods.
21:07<Chutt>it doesn't check anything other than the filename when it does that
21:08<Chutt>unless the track's not in the db
21:08<TheAsp>then whats it doing to my hd?
21:08<Chutt>grabbing the mtime wouldn't be any faster
21:08<inman>it doesn't examine the id3 tag?
21:08<Chutt>not on startup
21:08<PeteCool>inman: can't do a rip right now, it's recording... I don't have enough free cpu time to do that
21:08<Chutt>unless the track is not in the database, then it reads in the id3 tag
21:08* inmannods.
21:08<inman>sounds fine to me.
21:09<TheAsp>Chutt: last time i tried it it kept doing it, which inman implied earlier
21:09<TheAsp>everytime i started
21:09<inman>it has to scan all nodes in the tree in order to find any nodes that have changes.
21:09<TheAsp>but i'm happy with it just checking the filenames
21:09<Chutt>if it prints out 'Checking
21:09<Chutt>then it's not in the db
21:09<Chutt>and it's reading the id3 info in
21:10<Chutt>if, for some reason it _couldn't_ write to the db, then it'll say that every time it starts up
21:10<TheAsp>yeah, i knew it all wasnt in the db this time
21:10<inman>does FLAC work for anyone using CVS/music?
21:10<Chutt>i believe so
21:10<Chutt>i don't remember what i have in flac or in ogg anymore
21:10<inman>mythmusic broke in several ways since i updated today.
21:10<Chutt>update the db?
21:11<inman>yeah; i had to blow away all my old patches. :-D
21:11<TheAsp>does mythfilldb get all the data for the next 2 weeks every run?
21:11<TheAsp>is there a way to force it?
21:11<Chutt>inman, flac works fine
21:12<Chutt>theasp, nope
21:12<Chutt>noone's written a --force option yet =)
21:15<inman>my bad, it was a db tweak of mine.
21:15<TheAsp>i wanna see what movies are on this week :)~
21:16<Chutt>use mythweb, then
21:17<TheAsp>thats why i want to force it
21:17<Chutt>not getting it...
21:17<TheAsp>because i only have 1 day of data in the programrating table
21:17<TheAsp>which it uses to find movies
21:17<Chutt>oh, just wipe your program table
21:18<Chutt>and the programrating table
21:18<TheAsp>i suppose that would work
21:18<inman>chutt: TVRec is instantiated with a cardnum argument and defaults to the defaultinput for the card.
21:19<inman>chutt: where does it change inputs?
21:19<PeteCool>mythfilldatabase only fetched tomorrow's data, but I have many channels unknown for the whole day of tomorrow and the day after, too
21:19<Chutt>inman, for recordings, or through mythtv?
21:19<inman>chutt: uhh. there's a difference?
21:19<Chutt>'through mythtv' meaning 'when watching tv'
21:19<Chutt>yup, there is
21:20<inman>chutt: is there a second constructor that uses a source?
21:20<inman>er, sourceid argument?
21:20<Chutt>will do it for recordings
21:20* inmanboggles.
21:20<Chutt>when watching tv, it's ToggleInputs()
21:20<Chutt>since that's a manual action
21:20<mdz>Chutt: so how do you feel about iostreams?
21:21<Chutt>mdz, i don't use em for anything but output
21:21<Chutt>why, got better buffering using them?
21:21<mdz>it makes it quite a bit cleaner
21:21<Chutt>inman, what, don't like the name? :p
21:21<mdz>I implemented a streambuf with a read-ahead thread
21:22<mdz>so you can wrap it around any istream
21:22<inman>i see toggleinputs, but i don't understand what that has to do with my question. :-P
21:22<mdz>and then when you read from it, you get the read-ahead functionality
21:22<Chutt>that's what changes inputs
21:22<Chutt>when you hit c when watching tv
21:22<inman>chutt: let's say i have multiple cardinputs in the db bound to a single capturecard.
21:23<inman>it seems to me that the TVRec() needs to find the input before it launches and starts blindly changing channels.
21:23<inman>but i don't see where it does that.
21:23<Chutt>what do you mean?
21:23* inmanturns off mythmusic. :-)
21:24<inman>TVRec() is constructed with cardid.
21:24<Chutt>if it's a scheduled recording, it changes to the proper input for that recording in SetChannel
21:24<inman>SetChannel SetsInputs()?
21:24<Chutt>SetChannel takes a programinfo (for the recording)
21:24<inman>i'm looking at this stuff right now and i just don't see that.
21:25<Chutt>looks up the proper input and channel to switch to from the db
21:25<Chutt>and changes to both
21:25<inman>SetChannel from which object?
21:25<Chutt>there's two of them, you realize
21:25<Chutt>line 548
21:25<inman>oh shit
21:25* inmangrins.
21:26<inman>bingo, thanks
21:26<Chutt>that's only for recordings, though
21:26* inmannods.
21:26<Chutt>manual changing of inputs happens in toggleinputs, which you saw already
21:27<Chutt>chuck rocks
21:28<poptix>how much wood could a wood chuck chuck if a wood chuck could chuck wood
21:28<poptix>that's harder to type out than it is to say
21:28<inman>pete: let me know when you want that patch for mythmusic, and how.
21:30<Chutt>bumpscope.cpp is missing a call to SDL_ShowCursor(0);
21:31<inman>anyone know pete's email addy?
21:37<Chutt>not i
21:38<TheAsp>mythweb is triggering some rendering bug in mozilla
21:39<TheAsp>heh, odd
21:39<inman>which part of mythweb?
21:40<TheAsp>if you have program type turned on, and stars turned on (and possibly other things) and go into the movie list, the program type is sometimes garbled or invisible
21:40<TheAsp>the html is fine
21:41<inman>i'm using galeon, which is based on gecko, too.
21:41<inman>works for me with program type. which version of mozilla?
21:42<TheAsp>0.0.20030305.09.trunk-1 and 1.2.1-9
21:42<TheAsp>could be xft's fault too
21:42<Chutt>gtk has bugs rendering aa text?
21:42<Chutt>how's that possible!
21:42* inmansmirks.
21:42<TheAsp>it doesnt use gtk to render fontd
21:43<TheAsp>it uses xft directly
21:43<TheAsp>or freetype if you arnt using the xft build
21:43<inman>goddamn mozilla is slow
21:44<TheAsp>and don't knock gtk :P atleast you can compile it in a day :)
21:44<PeteCool>inman: I don't that kind of patch really fast, I can live with it for a while... anything that Chutt accepts is fine for me :)
21:45<Chutt>petecool, that cursor thing should be fixed now
21:45<PeteCool>TheAsp: mozilla doesn't take more that 6 hours to compile on my slow celeron 500... that's 1/4 of a day, not more than a day :)
21:45<TheAsp>i didn't say mozilla :)
21:46<TheAsp>i think qt took ~3 hours on my 1ghz amd...
21:46<inman>asp: is the bug perhaps due to the "stars character"?
21:47<TheAsp>it could be
21:47<TheAsp>i haven't tried turning them off
21:47<TheAsp>i'm not all that concerned
21:47<TheAsp>(though it shouldnt show the movie description in both cells if showing program descriptions is turned on)
21:47<PeteCool>Chutt: great, I'll take a look at it later tonigh (recording in progress) =)
21:47<TheAsp>(which i already fixed)
21:48<inman>huh, i didn't even notice that feature. :-)
21:48<TheAsp>inman: its in the settings file
21:49<inman>the query for finding the program description for use by the OSD is scanning the entire program table.
21:49<inman>rewriting the query causes it to only scan a few hundred records. is this worth submitting a patch for?
21:51<PeteCool>will the mythmusic settings ever be put in the database? Having my settings overwritten everytime I make install is annoying
21:52<TheAsp>PeteCool: you could edit the settings in the cvs...
21:52<inman>if you manually insert the settings into the db, you can get rid of the file.
21:52<Chutt>petecool, eventually, post 0.8
21:52<Chutt>inman, long as it's not overcomplicated, sure
21:52<inman>you know me :-)
21:57<Chutt>think i fixed the scheduler
21:58<PeteCool>Chutt: it was broken?
21:58<Chutt>for >= 3 cards
21:58<PeteCool>I wish I had >= 3 cards :)
21:58<Chutt>the multi-card conflict resolution was slightly off
21:59<Chutt>if you had 3 programs to record in the same timeslot
21:59<Chutt>it'd go through and move two of them to the 2nd card, thus fixing the first program
21:59<TheAsp>you have 3 cards?
21:59<Chutt>then it'd move one of them back to the first card, because it didn't check to see if that first one was free or not
22:00<Chutt>so you'd end up with programs 1 and 3 on card 1, program 2 on card 2, and nothing on #3
22:00<Chutt>now it checks, so it works
22:00<Chutt>i think =)
22:00<Chutt>theasp, on two machines, yes
22:00<PeteCool>So now it's unlimited (to the limits of the variable type used, obviously) ?
22:00<Chutt>mostly just for testing
22:00<Chutt>petecool, i think so, at least
22:04<PeteCool>would there be any advantage to using a 8mb-buffer HD over a 2-mb?
22:04<PeteCool>I really don't know how myth writes its data to disk
22:04<Chutt>there shouldn't be, no
22:06<TheAsp>might he good with rtjpeg, if only because it uses a bit of disk i/o
22:06<TheAsp>though im sure the kernel does a good job of taking care of that
22:07<TheAsp>does the o(1) scheduler affect myth badly?
22:07<PeteCool>Why would it be bad?
22:07<justin_>just renice it to -16 or so
22:07<TheAsp>would what be bad? O(1)?
22:07<TheAsp>yeah, i spose that would fix it :)
22:08<PeteCool>justin_: did you read the discussion on kerneltrap? renice is not the solution, says linus, ingo and other scheduling gurus :)
22:08<TheAsp>since im doing it now anyway
22:08<justin_>PeteCool: its not the solution but it works
22:08<TheAsp>PeteCool: it's not the solution ot be forced on people was what he was saying
22:09<justin_>like the idiots that whine that they cant compile stuff and watch movies at the same time
22:09<PeteCool>I didn't finish reading the page though, was there a final conclusion/inclusion of code?
22:09<justin_>a perfect sched would be nice, but renicing stuff has worked for 30 years
22:09<PeteCool>justin_: actually I can watch mythtv and compile mythtv at the same time without problems ;)
22:09<TheAsp>PeteCool: it wouldnt have been much of a story if it wasn't :)
22:09<PeteCool>justin_: I mean livetv
22:10<justin_>i do everything at the same time, cause its reniced
22:10<justin_>it never has problems
22:11<PeteCool>justin_: the only time I ever needed to nice something was mpg123 on a pentium 100
22:11<PeteCool>and only to prevent skips when mysql was accessed
22:11<justin_>mpg123 on my p100 uses the same ammount of cpu that myth does on my athlon xp 1600+
22:13<Chutt>inman, just checking that query..
22:13<PeteCool>eh, that's the evolution of multimedia
22:14<inman>chutt: so many of them, are there. :-(
22:14<Chutt>existing query time: 0.00 to 0.01 seconds
22:14<Chutt>modified query time: 0.00 to 0.01 seconds
22:14<Chutt>what's the difference? :p
22:15<inman>chutt: do you want me to mount a real argument?
22:15<Chutt>you just substituted one join type for another
22:15<Chutt>and doesn't a left join take longer than an equi join?
22:15<inman>uh, no.
22:15<Chutt>since it potentially returns more..
22:15<inman>i'm not really sure what you're talking about, but the answer is no. :-)
22:16<inman>put an "explain" before each query in your mysql monitor `mysql` and see what pops out.
22:16<inman>that will explain which tables are accessed and how many records need to be scanned, as well as which indexes may be used.
22:17<inman>if the table isn't in memory, it has to load a decent amount of data.
22:17<Chutt>the rows are identical
22:17<inman>paste the queries you're running into IRC, please?
22:18<Chutt>it's on another machine
22:18* inmanloads the source.
22:18<Chutt>all i did was fill in some values for that query
22:18<inman>i really want to improve the db backend of myth. :-/
22:19<Chutt>the original query seems like it can use more indexes than the modified one
22:19<inman>this is the analysis of the query i sent you:
22:19<inman>| table | type | possible_keys | key | key_len | ref | rows | Extra |
22:19<inman>| capturecard | system | NULL | NULL | NULL | NULL | 1 | |
22:19<inman>| cardinput | ALL | NULL | NULL | NULL | NULL | 2 | where used |
22:19<inman>| channel | ALL | NULL | NULL | NULL | NULL | 265 | where used |
22:19<inman>| program | ref | PRIMARY,chanid | PRIMARY | 4 | channel.chanid | 542 | where used |
22:19<Chutt>right, that's similar to what i got
22:19<TheAsp>pg's is much nicer
22:19<inman>so what's the problem?
22:20<Chutt>what's the analysis for the original query?
22:20<Chutt>it's basically identical for me
22:20* inmantries to dig it up.
22:20<Chutt>except the possible_keys and key are more populated
22:20<Chutt>the row counts are the same
22:20<Chutt>but the ordering is different
22:20<inman>| table | type | possible_keys | key | key_len | ref | rows | Extra |
22:20<inman>| capturecard | system | PRIMARY | NULL | NULL | NULL | 1 | |
22:20<inman>| cardinput | ALL | NULL | NULL | NULL | NULL | 2 | where used |
22:20<inman>| program | ALL | PRIMARY,endtime,chanid | NULL | NULL | NULL | 54207 | where used |
22:20<inman>| channel | eq_ref | PRIMARY | PRIMARY | 4 | program.chanid | 1 | where used |
22:20<Chutt>see, that's not what i get.
22:20<inman>what is your original query?
22:21<Chutt>the same one that's in the source
22:21<inman>i'm pulling out the query directly from the database server log.
22:21<Chutt>i typed it in manually
22:21<inman>here, i'll paste it to IRC.
22:21<inman>SELECT starttime,endtime,title,subtitle,description,category,callsign,icon FROM program,channel,capturecard,cardinput WHERE channel.channum = "3" AND starttime < 20030308193405 AND endtime > 20030308193405 AND program.chanid = channel.chanid AND channel.sourceid = cardinput.sourceid AND cardinput.inputname = "Television" AND cardinput.cardid = capturecard.cardid AND capturecard.videodevice = "/dev/video0";
22:22<inman>obviously, 54207 represents the number of records in my program table.
22:22<Chutt>well, i obviously don't have 142 records in the program table
22:22* inmangiggles.
22:22<Chutt>and that's what 'explain' says is the rows value for the original query
22:22<inman>which version of mysql are you running?
22:23<inman>maybe it's performing the optimization automagically.
22:23<TheAsp>whats the alternative to the above query?
22:23<Chutt>theasp, replacing the program.chanid = channel.chanid with left join's
22:24<inman>SELECT starttime,endtime,title,subtitle,description,category,callsign,icon FROM capturecard left join cardinput using (cardid) left join channel using (sourceid) left join program using (chanid) WHERE channel.channum = "3" AND starttime < 20030308193405 AND endtime > 20030308193405 AND cardinput.inputname = "Television" AND capturecard.videodevice = "/dev/video0";
22:24-!-Soopaman [] has joined #mythtv
22:24<Chutt>basically, replacing one type of join with another
22:24<inman>the left joins represent a perfect match between what we're trying to accomplish and how the data is structured.
22:24<Chutt>which, as should be obvious, doesn't have any affect on the speed
22:24<Chutt>at least here
22:25<TheAsp>inman: just because explain says its faster doesnt mean its actually faster either
22:25<inman>i'm running 3.23.54a.
22:25<Chutt>here, i'll load up irc on that machine and paste things
22:25<inman>asp: i know, but this isn't a complicated join.
22:26-!-Chutt2 [] has joined #mythtv
22:26<Chutt2>original query:
22:26<Chutt2>mysql> explain select starttime,endtime,title,subtitle,description,category,callsign,icon from program,channel,capturecard,cardinput where channel.channum = "3" and starttime < 20030308201500 and endtime > 20030308201500 and program.chanid = channel.chanid and channel.sourceid = cardinput.sourceid and cardinput.inputname = "Television" and cardinput.cardid = capturecard.cardid and capturecard.videodevice = "/dev/video0";
22:26<Chutt2>| table | type | possible_keys | key | key_len | ref | rows | Extra |
22:26<Chutt2>| channel | ALL | PRIMARY | NULL | NULL | NULL | 59 | where used |
22:26<Chutt2>| program | ref | PRIMARY,endtime | PRIMARY | 4 | channel.chanid | 142 | where used |
22:26<Chutt2>| cardinput | ALL | NULL | NULL | NULL | NULL | 3 | where used |
22:26<Chutt2>| capturecard | eq_ref | PRIMARY | PRIMARY | 4 | cardinput.cardid | 1 | where used |
22:26<Chutt2>4 rows in set (0.00 sec)
22:26<Chutt2>modified query:
22:26<Chutt2>mysql> explain select starttime,endtime,title,subtitle,description,category,callsign,icon from capturecard left join cardinput using (cardid) left join channel using (sourceid) left join program using (chanid) where channel.channum = "3" and starttime < 20030308201500 and endtime > 20030308201500 and cardinput.inputname = "Television" and capturecard.videodevice = "/dev/video0";
22:26<Chutt2>| table | type | possible_keys | key | key_len | ref | rows | Extra |
22:26<Chutt2>| capturecard | ALL | NULL | NULL | NULL | NULL | 3 | where used |
22:26<Chutt2>| cardinput | ALL | NULL | NULL | NULL | NULL | 3 | where used |
22:26<Chutt2>| channel | ALL | NULL | NULL | NULL | NULL | 59 | where used |
22:26<Chutt2>| program | ref | PRIMARY | PRIMARY | 4 | channel.chanid | 142 | where used |
22:27<Chutt2>4 rows in set (0.00 sec)
22:27<inman>well, it should still be clear that the first one is more efficient.
22:27<inman>how many entries in your program table?
22:27<Chutt>15k or so
22:28<inman>i usually have like 60k. how many channels do you have?
22:28<Chutt>i've culled it down to 59
22:28<inman>er, the second one is more efficient.
22:29<Chutt>how so?
22:29<Chutt>they look identical
22:29<inman>think about what's happening here.
22:29<Chutt>the first even looks to be more efficient
22:29<Chutt>since it's using more indexes
22:29<inman>we know we only want the records associated with the capturecard with videodevice=/dev/video0
22:29<inman>so right off the bat, we've found our matching record in the first step
22:30<inman>we never need to backtrack, so to speak, in any future query.
22:30<Chutt>i've got two video devices with the name of /dev/video0
22:30<PeteCool>is that about the fix conflicts section?
22:30<inman>chutt: sounds like a bug to me. :-)
22:30<Chutt>two machines
22:30<inman>it's the same thing i just fixed in the movies/mythweb thing.
22:31<inman>we should be also querying for the hostname, then.
22:31<Chutt>there's really no need
22:31<Chutt>since we're hitting up the sourceid
22:31<Chutt>and the input name
22:31<inman>we calculate the sourceid /from/ the videodevice
22:31<PeteCool>oh, Chutt, since Fix Conflicts started working again for me, getting in there is much slower (3x) while I have ~1.5x more recordings then at that time
22:32<PeteCool>any ideas why?
22:32<PeteCool>this isn't really linear
22:32<Chutt>slow conflict resolution
22:32<Chutt>mdz's new stuff where it marks the pruned out programs, perhaps
22:32-!-Chutt2 [] has quit ["Client Exiting"]
22:33<Chutt>i suppose it should use the hostname as well
22:33<Chutt>but that's besides the point
22:33<inman>should i engineer an example that will show the time differences?
22:33<Chutt>i just engineered an example, and there was no time difference
22:34<inman>there's no time difference in your test with limited records in each of the tables.
22:34<inman>i'm not saying the numbers are going to change dramatically, but this query is executed every time i change channels.
22:34<Chutt>so's a usleep(300000)
22:34<inman>to catch the tuner?
22:36<inman>could you put my query in so that /my/ channel changes are faster?
22:37<TheAsp>inman, how long does it take for both queries to run for you?
22:37<inman>mysql> SELECT starttime,endtime,title,subtitle,description,category,callsign,icon FROM program,channel,capturecard,cardinput WHERE channel.channum = "3" AND starttime < 20030308193405 AND endtime > 20030308193405 AND program.chanid = channel.chanid AND channel.sourceid = cardinput.sourceid AND cardinput.inputname = "Television" AND cardinput.cardid = capturecard.cardid AND capturecard.videodevice = "/dev/video0";
22:37<inman>| starttime | endtime | title | subtitle | description | category | callsign | icon |
22:37<inman>| 20030308193000 | 20030308230000 | Hockey | | | | ATT3W | |
22:37<inman>1 row in set (5.64 sec)
22:37<inman>that's without the data in memory.
22:37<inman>with it in memory, it's
22:37<inman>1 row in set (0.17 sec)
22:38<inman>my query (in memory)
22:38<inman>1 row in set (0.00 sec)
22:39<TheAsp>what about not in memory?
22:39<inman>i'll restart mysql...
22:39<PeteCool>inman: is your computer much slower than chutt's ?
22:40<inman>1 row in set (0.13 sec)
22:40<Chutt>he's got a broken mysql server, that's for sure :p
22:40<inman>i'm on a athlon 2000.
22:40<Chutt>and a faster machine?
22:40* inmanshrugs.
22:40<inman>this is stock redhat, so it's i386 arch.
22:41<Chutt>this is stock debian
22:41<PeteCool>it depends on the chipset too
22:41<PeteCool>and their memory controllers
22:41<inman>i think i'm going to give up on this disk virtualization stuff and switch to a fully source-built distro.
22:42<inman>this is a dual-athlon, the tiger board.
22:42<TheAsp>source-built distros are for weenies
22:42<inman>oh, and the db is on a 10krpm scsi disk with an average seek of <4ms.
22:43<TheAsp>i cant imagine putting up with all that compiling
22:43<Chutt>mine's on a crappy maxtor that was also in the process of recording :p
22:43<inman>maybe 3.23.55 is a real improvement.
22:43<TheAsp>maybe redhat just sucks? :)
22:44<TheAsp>what kind of tables are you using, inman?
22:44<inman>could be, but i'm stuck with it as long as i'm using this disk virtualizer.
22:44<inman>normal myaism
22:46<inman>that wasn't a good test, btw, since mysql was able to slurp data from os disk buffers.
22:46<inman>let's put another 45k records into chutt's program table and see if he starts to slow down.
22:46<TheAsp>i dont want livetv, so i dont care :)
22:47<Chutt>how would that make the fact that the number of rows used in each of the two queries was the same?
22:47<Chutt>any different?
22:47<inman>got me. i think your mysql is just optimizing away the stupid sql. :-)
22:48<Chutt>and why's channel listed last in your 'bad' explain?
22:48<Chutt>shouldn't it be first?
22:48<Chutt>since that's what's first in the where clause..
22:48<inman>the order of the where clause is completely irrelevant.
22:48<inman>you know, there is documentation on how mysql optimizes queries...
22:49<Chutt>you mean, on
22:49<Chutt>really? :p
22:49<inman>hey, i'd be /happy/ if this stuff worked quickly.
22:55<PeteCool>inman: try it with 3.23.55, you'll know if it's your db contents, or the dbms
22:55<PeteCool>remove one variable of the problem to find what the other is ;)
22:55<inman>yeah, i know.
22:55<inman>what about everyone else using mysql under stock redhat?
22:55<inman>screw 'em?
22:57<TheAsp>8.1 comes out soon
22:57<PeteCool>just compile the latest 4.0, it should be faster
22:57* inmannods.
22:57<inman>i know pete, but the point is that the developers aren't the only ones trying to use the software. :-)
22:57<TheAsp>chutt's is easier on the eyes
22:58<Chutt>i think it's easier to read
22:58<Chutt>and as i see no difference..
22:58<inman>you think it's harder to read a left join?
22:59<Chutt>i think the existing query is clearer in what it's doing, yes
22:59<TheAsp>well left join i left join do
22:59<inman>it has 3 less WHERE clauses and clearly indicates in the join itself which column is serving as a key.
22:59* inmanshrugs.
22:59<Chutt>if i saw any difference here, i'd apply your patch
22:59<Chutt>but i don't
22:59<inman>i've shown you a difference on my machine.
23:00<inman>chutt: why don't you make mysql-3.23.55 a requirement for 0.8?
23:00<Chutt>how do you know that it's that?
23:01<inman>i don't see how your version would generate a different EXPLAIN output.
23:01<Chutt>i don't see how yours could generate something that poor, either
23:01<inman>what indexes do you have on program?
23:01<Chutt>i have what's in the mc.sql stuff
23:01<inman>chutt: there is no implicit optimizations in the query.
23:02<inman>the documentation on optimization is for mysql 4.x, btw.
23:15<PeteCool>Chutt: did you add a check that if the viz fails, it should switch to another?
23:16<Chutt>i don't think i did
23:16<PeteCool>I put goom in my viz list, sometimes I see a white screen for a part of a second, but it never comes up
23:17<Chutt>thor may have
23:17<PeteCool>and IIRC goom starts up with a white screen
23:17<PeteCool>and doesn't work on my backand
23:18<Chutt>i think the white screen is just the vis taking a bit to startup
23:18<Chutt>i see the same, occasionally
23:19<PeteCool>wtf, at 640x480 bumpscope is faster than Spectrum
23:19<PeteCool>makes no sense
23:19<Chutt>ffts do take a little bit of time
23:54<Chutt>mysql 5.23.53 auto-optimizes the query differently
23:54<Chutt>but, still ok
23:54<Chutt>i have .53 on hand
23:54<Chutt>so it was easy to test
23:54* inmannods.
23:55<Chutt>and the auto-optimizer was still more efficient
23:55<inman>do you doubt my output?
23:55<Chutt>if i could reproduce it
23:56<inman>well, you've seen that 2 minors make a difference, do you not believe that 1 minor makes a difference?
23:56<Chutt>not such a major difference
23:56<Chutt>since that's totally broken
23:56<inman>it sounds like it makes a bigger difference if it's broken, as you suggest.
23:56<Chutt>it's not using _any_ of the indexes for the program table
23:56<inman>why leave it up to the broken db when all you have to do is write it differently.
23:57<Chutt>because writing it different is less efficient
23:57<Chutt>3x more compares on .55
23:57<inman>writing it my way is less efficient?
23:57<inman>did i read that correctly?
23:57<Chutt>11x more compares on .53
23:58<inman>writing it my way is different on .53 than .55?
23:58<inman>how could that be? is it scanning all of program?
23:58<Chutt>.53 optimized the query better
23:58<Chutt>it's scanning all of channel
23:58<inman>well, channel is stored in memory anyway.
23:59<Chutt>on .53, it doesn't scan all of channel for some reason
23:59<inman>i'm so confused.
23:59<inman>when you average the performance across both versions, which query is better?