TheGrebs.com:IRC Logs:#mythtv: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:06	<justin_>	hmm?
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:10	<Chutt>	well
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	<justin_>	oh, 127.0.0.1?
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	<justin_>	yay:)
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:11	<justin_>	howso?
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>	eh
00:13	<Chutt>	i'm fairly happy with the current setup
00:13	<rkulagow>	(i didn't say it was a _good_ idea)
00:13	<Chutt>	heh
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>	heh
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 [~cpinkham@ip68-107-147-203.hr.hr.cox.net] has joined #mythtv
02:32	<-- Captain_Murdoch	has quit ()
08:50	-!-	nziarek [~nathanzia@mke-24-167-222-150.wi.rr.com] 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 [~rickter@12-220-224-236.client.insightBB.com] has joined #mythtv
11:08	<rkulagow>	chutt: are you here?
11:35	<rkulagow>	chutt: are you here?
11:45	<-- rkulagow	(~mythtv@12.207.131.29) has left #mythtv
11:47	-!-	rkulagow [~mythtv@12.207.131.29] has joined #mythtv
12:17	-!-	Soopaman [namapoos@24.82.199.52] has joined #mythtv
13:01	-!-	justin_ [~justin@ool-18b81c6a.dyn.optonline.net] has joined #mythtv
13:17	<Chutt>	rkulagow, not really =)
15:19	<rkulagow>	chutt: are you back now?
15:20	<Chutt>	yup
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)][New Thread 16384 (LWP 1541)]
15:22	<rkulagow>	connecting to backend server: 192.168.10.102:6543
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)][Switching to Thread 16384 (LWP 1541)]
15:22	<rkulagow>	0x4083ddb2 in XSetTile () from /usr/X11R6/lib/libX11.so.6
15:22	<rkulagow>	Current language: auto; currently c
15:22	<rkulagow>	(gdb) bt
15:22	<rkulagow>	#0 0x4083ddb2 in XSetTile () from /usr/X11R6/lib/libX11.so.6
15:22	<rkulagow>	(gdb) bt full
15:22	<rkulagow>	#0 0x4083ddb2 in XSetTile () from /usr/X11R6/lib/libX11.so.6
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:24	<Chutt>	allright
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	<rkulagow>	yes
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>	heh
15:26	<Chutt>	i have that backwords in tere
15:26	<Chutt>	there
15:27	<rkulagow>	height and width should be reversed
15:28	<rkulagow>	height=480, etc, correct?
15:28	<Chutt>	right
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:29	<Chutt>	right
15:30	<rkulagow>	recompiling
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:34	<Chutt>	heh
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)][New Thread 16384 (LWP 2400)]
15:39	<rkulagow>	connecting to backend server: 192.168.10.102:6543
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)][Switching to Thread 16384 (LWP 2400)]
15:39	<Chutt>	hmmmmm
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)][Switching to Thread 16384 (LWP 2400)]
15:40	<rkulagow>	0x4083edb2 in XSetTile () from /usr/X11R6/lib/libX11.so.6
15:40	<rkulagow>	Current language: auto; currently c
15:40	<rkulagow>	(sory - bad cut and paste)
15:40	<Chutt>	heh
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>	after
15:42	<Chutt>	at the very end
15:42	<rkulagow>	liquid
15:42	<rkulagow>	ok
15:43	<Chutt>	one more change
15:43	<rkulagow>	ok
15:43	<Chutt>	line 424
15:44	<Chutt>	after the QPixmap background(GetNumSetting("GuiWidth"
15:44	<Chutt>	see it?
15:44	<rkulagow>	yes
15:45	<Chutt>	cout << "background is: " << background.width() << " " << background.height() << endl;
15:45	<rkulagow>	before QPainter?
15:45	<Chutt>	yup
15:46	<rkulagow>	making
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)][New Thread 16384 (LWP 3006)]
15:47	<rkulagow>	connecting to backend server: 192.168.10.102:6543
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)][Switching to Thread 16384 (LWP 3006)]
15:48	<rkulagow>	0x4083edb2 in XSetTile () from /usr/X11R6/lib/libX11.so.6
15:48	<rkulagow>	Current language: auto; currently c
15:48	<Chutt>	hmm
15:48	<Chutt>	ok, sec
15:50	<Chutt>	ok, delete your mythcontext.cpp
15:50	<rkulagow>	ok
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:54	<Chutt>	great.
15:54	<rkulagow>	yep
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	<rickter>	k
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:)
15:59	<Chutt>	heh
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:03	<Chutt>	yup
16:04	<Chutt>	bbl.
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:34	<Chutt>	nope
16:36	<Chutt>	well
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	<Chutt>	yup
16:41	-!-	meth [~meth@12-222-69-138.client.insightBB.com] 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:43	<bigguy>	k
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:55	<poptix>	hrm
16:56	* poptix	ponders 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	<bigguy>	heh
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 [~dert@h00022d45b977.ne.client2.attbi.com] 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:01	<poptix>	nope.
17:02	<poptix>	[root@tranq .xmltv][root@tranq .xmltv]# cat tv_grab_na \|sort \|uniq -d
17:02	<poptix>	#
17:02	<Chutt>	it'd be in ~/.mythtv/, though
17:02	<Chutt>	and
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][root@tranq .mythtv]# cat TV.xmltv \|sort \|uniq -d
17:04	<poptix>	#
17:04	<Chutt>	cat TV.xml \| cut -d ' ' -f 2 \| sort \| uniq -d
17:04	<poptix>	hmm
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	<poptix>	hrm
17:05	<Chutt>	lookithat ;p
17:06	<poptix>	=)
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	* inman	shrugs.
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>	yup
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	<mdz>	nope
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	<mdz>	ah
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:19	<Chutt>	sent
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	<Chutt>	heh
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:23	<Chutt>	yup
17:24	<inman>	clearly
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	<Viddy>	hmmm
17:24	<mdz>	Viddy: not on ethernet
17:24	* Viddy	blinks
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:25	<Viddy>	ahh
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	* inman	will 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	* inman	shrugs.
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	* inman	isn'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	* inman	nods.
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	* inman	is 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 [~rickter@12-220-224-236.client.insightBB.com] 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	* inman	had some bad experiences with foundryOS and linux/nfs.
17:42	<mdz>	latency
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	* inman	frowns.
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:48	<poptix>	erm
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	* inman	sighs.
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	* inman	swears 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	* inman	grins.
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	* inman	chuckles.
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	* inman	uses 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	* inman	nods.
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	<mdz>	switches
17:58	<bigguy>	I like d-link
17:59	* Viddy	likes 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 minute...it 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	* inman	snickers.
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:05	<Viddy>	http://www.webopedia.com/TERM/H/hub.html
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	* inman	pats Viddy on the head.
18:07	<mdz>	inman: if I'm not mistaken, that is a tool for measuring TCP throughput
18:07	<inman>	DESCRIPTION
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	* inman	shrugs.
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	* inman	giggles.
18:14	<mdz>	that's how this discussion began
18:14	* inman	nods.
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	* inman	nods.
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	<mdz>	yep
18:15	<inman>	s/through/throw/
18:15	* inman	nods.
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	<mdz>	oh
18:16	<inman>	oh
18:16	* inman	grins.
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	* inman	nods.
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 interesting...it 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 [~vidar@janus.prosalg.no] has joined #mythtv
18:44	-!-	nziarek [~nathanzia@mke-24-167-222-150.wi.rr.com] has joined #MythTV
18:46	<inman>	:483
18:46	<inman>	oops.
18:54	-!-	justin_ [~justin@ool-18b81c6a.dyn.optonline.net] 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 [asp@CDR13-117.accesscable.net] has joined #mythtv
19:37	<TheAsp>	whats this programrating table?
19:38	<TheAsp>	oh, havent updated myth
19:50	-!-	PeteCool [~PeteCool@modemcable110.15-201-24.timi.mc.videotron.ca] 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 ["http://urbanservers.com \| http://urbanservers.com/ursradion 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:45	<TheAsp>	etc...
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	<TheAsp>	25gb
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:48	<TheAsp>	27gb...
20:49	<inman>	asp: it's the number of files that matters, not the size.
20:49	<TheAsp>	~5000
20:49	* inman	nods.
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>	err
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 i