TheGrebs.com:IRC Logs:#mythtv:2007:02:05

---	Log	opened Mon Feb 05 00:00:24 2007
00:00	\|-\|	degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has joined #mythtv
00:49	\|-\|	gnome42 [n=obi@dsl-141-151.aei.ca] has quit [Remote closed the connection]
01:19	\|-\|	czth_ [i=dbrobins@nat/microsoft/x-a17cb1eb56b14013] has joined #mythtv
01:30	\|-\|	LLyricWork [n=chatzill@d58-108-40-187.dsl.vic.optusnet.com.au] has quit ["Chatzilla 0.9.77 [Firefox 2.0.0.1/2006120418]"]
01:34	\|-\|	czth__ [i=dbrobins@nat/microsoft/x-bd141f39b4b094a4] has quit [Read error: 110 (Connection timed out)]
02:29	\|-\|	clever [n=clever@fctnnbsc16w-156034210168.nb.aliant.net] has quit [Remote closed the connection]
02:30	\|-\|	degreseven [n=bryan@c-71-227-220-4.hsd1.or.comcast.net] has quit [Remote closed the connection]
02:34	\|-\|	xris [n=xris@xris.forevermore.net] has quit ["Leaving."]
02:38	\|-\|	aevil [n=aevil@i59F5654E.versanet.de] has joined #mythtv
03:01	\|-\|	stuarta [n=stuart@unaffiliated/stuarta] has joined #mythtv
03:03	\|-\|	PointyPumper [i=Pintlezz@OL221-67.fibertel.com.ar] has quit [Read error: 104 (Connection reset by peer)]
03:30	<gbee>	stuarta: were you seeing a hang in the frontend and/or backend associated with the ffmpeg resync?
03:31	<stuarta>	gbee: that error msg i posted last week was from the frontend
03:31	<gbee>	yep, just wondering if you also experienced the hang, or just the error?
03:32	<stuarta>	hangs, they i change out to kill it and find the error msg
03:32	<stuarta>	s/they/then
03:32	<gbee>	until the ticket was opened yesterday I wasn't convinced the error was connected to the hang, but I'm just recompiling now with the return commented out
03:35	[~]	stuarta hasn't read his email yet
03:36	<gbee>	http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/mpeg12.c?r1=7538&r2=7537&pathrev=7538
03:37	<gbee>	as I pointed out to janne when I first saw the crash, that's the changeset responsible for adding the error
03:37	<stuarta>	the question is, why are we triggering it....
03:38	<gbee>	question is, if a null current_picture_ptr wasn't causing hangs _before_ that changeset, but is doing so afterwards - What is going on?
03:39	<gbee>	s/hangs/segfaults/
03:39	<stuarta>	pure luck
03:39	<stuarta>	its possible to run for ages with subtle memory bugs and not know about it
03:40	<stuarta>	hence why they are such a bitch to track down
03:40	<gbee>	I'm seeing the error appear several times without it hanging - but it seems to always be the last thing in the log before the hang, usually after seeking
03:40	<stuarta>	like the outstanding pes assembler issue. same sort of deal..
03:40	<stuarta>	to be fair, i've only seen it on my mini mac frontend
03:41	<gbee>	the preview thread was triggering it on my backend as well
03:41	<stuarta>	yeah, there are still a few issues with the preview thread
03:42	<gbee>	well in this case it's not really the preview threads fault :)
03:43	<stuarta>	no, not in the slightest :)
03:43	<gbee>	it's just using avcodec to grab a frame of video, and that happens to trip the ffmpeg bug
03:52	\|-\|	beata [i=beata@c-68-83-135-4.hsd1.nj.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
03:52	\|-\|	beata-- [i=beata@c-68-83-135-4.hsd1.nj.comcast.net] has joined #mythtv
---	Log	closed Mon Feb 05 04:45:42 2007
---	Log	opened Mon Feb 05 04:45:46 2007
04:45	\|-\|	mikegrb_ [n=michael@mail.thegrebs.com] has joined #mythtv
04:45	\|-\|	Ekipa kanalu #mythtv: Wszystkich: 72 \|-\| +op [0] \|-\| +voice [0] \|-\| normalnych [72]
04:45	\|-\|	mikegrb [n=michael@mail.thegrebs.com] has quit [Read error: 104 (Connection reset by peer)]
04:45	\|-\|	Kanal #mythtv zsynchronizowany w 9 sekundy
04:46	\|-\|	olds_ [i=olds@antitech.xmission.com] has joined #mythtv
04:46	\|-\|	olds [i=olds@antitech.xmission.com] has quit [Read error: 104 (Connection reset by peer)]
04:46	\|-\|	Beirdo [n=gjhurlbu@unaffiliated/beirdo] has quit [Read error: 104 (Connection reset by peer)]
04:46	\|-\|	Beirdo_ [n=gjhurlbu@unaffiliated/beirdo] has joined #mythtv
04:58	\|-\|	PointyPumper [i=Pintlezz@OL221-67.fibertel.com.ar] has joined #mythtv
05:21	\|-\|	MoRpHeUz [n=morphbr@200.184.118.132] has joined #mythtv
05:37	\|-\|	MonkeyINAbaG [n=WiseMonk@is.da-bom.com] has joined #mythtv
05:52	\|-\|	Puh [i=puh@reppana.ttek.fi] has joined #mythtv
06:22	\|-\|	SaLoMoN [n=SaLo@salooo.org] has joined #mythtv
06:23	\|-\|	SaLoMoN [n=SaLo@salooo.org] has left #mythtv ["Verlassend"]
06:28	\|-\|	PointyPumper [i=Pintlezz@OL221-67.fibertel.com.ar] has quit [Read error: 110 (Connection timed out)]
06:51	\|-\|	aevil^aw [n=aevil@i59F5536E.versanet.de] has joined #mythtv
07:07	\|-\|	aevil [n=aevil@i59F5654E.versanet.de] has quit [Read error: 110 (Connection timed out)]
07:14	\|-\|	lsobral [n=sobral@200.184.118.132] has joined #mythtv
07:25	\|-\|	issues [n=kvirc@ppp89-80.lns2.mel3.internode.on.net] has joined #mythtv
07:33	\|-\|	lucas123 [n=Meijer@lucas.demon.nl] has joined #mythtv
07:53	\|-\|	j-rod [i=jarod@nat/redhat/x-839fc0f6e66575c9] has joined #mythtv
07:59	\|-\|	nelius [n=nelius@pD9E0E680.dip0.t-ipconnect.de] has joined #mythtv
07:59	<nelius>	hi
07:59	<nelius>	i can't find a starting howto for plugin development
07:59	<nelius>	can you point me to some doc's?
08:00	<nelius>	i'd like to code a simple freenx-client wrapper integrated into myth... should be easy, but some "how to start writing a plugin" would be helpfull
08:01	<GreyFoxx>	Go to the wiki and search "plugins"
08:01	<GreyFoxx>	3rd link is some very basic plugin building docs
08:04	<nelius>	ah, thats what i need, tnx
08:07	\|-\|	_BleedAway [i=whocares@saus04.usc.es] has joined #mythtv
08:09	<nelius>	mhh, is there just a <action>external-programm</action> in the menu possible?
08:09	<GreyFoxx>	yes
08:09	<GreyFoxx>	<EXEC> or some such
08:09	<GreyFoxx>	for calling external apps
08:10	<GreyFoxx>	There is a commented out example of it in the base xml files I think
08:10	\|-\|	PointyPumper [i=Pintlezz@OL221-67.fibertel.com.ar] has joined #mythtv
08:11	<nelius>	ah, just like this: <action>EXECTV xawtv -f -device %s -dspdev %s -vbidev %s</action> ?
08:11	<GreyFoxx>	I haven't actually looked at it in years, so without lookin at the xml files tiself I can't confirm the syntax :)
08:12	\|-\|	Merlin83b2 changed nick to Merlin83b
08:19	<nelius>	jepp, it's the EXEC command... Man that was easy :-)
08:20	\|-\|	BleedAway [i=whocares@saus04.usc.es] has quit [Read error: 110 (Connection timed out)]
08:20	\|-\|	_BleedAway changed nick to BleedAway
08:28	\|-\|	Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
08:33	\|-\|	nelius [n=nelius@pD9E0E680.dip0.t-ipconnect.de] has quit [Read error: 145 (Connection timed out)]
08:34	\|-\|	nelius [n=nelius@pD9E0E680.dip0.t-ipconnect.de] has joined #mythtv
08:40	<gbee>	CDev: guy in #mythtv-users asking about uPnp in HEAD, can't see media apparently
08:53	\|-\|	Neeesat25 [n=neosat@87.228.216.119] has joined #mythtv
08:53	\|-\|	issues [n=kvirc@ppp89-80.lns2.mel3.internode.on.net] has quit [Read error: 110 (Connection timed out)]
08:53	<Neeesat25>	Hello to all
08:54	<Neeesat25>	Can I ask for feature request here?
08:55	<GreyFoxx>	No
08:55	<Neeesat25>	Ok
08:56	<stuarta>	you can ask questions on how to write it
08:56	<Neeesat25>	Oh ok
08:56	<Neeesat25>	It's C++ right?
08:56	<stuarta>	yup
08:57	<GreyFoxx>	most all of it is c++ with the libav libaries being C
08:57	<stuarta>	and Qt for base classes & UI
08:59	<stuarta>	oooo, new valgrind....
09:01	\|-\|	jgarvey [n=jgarvey@cpe-075-177-158-190.nc.res.rr.com] has joined #mythtv
09:38	<janneg>	gbee: I'm not sure if removing 'An' for sorting is a good idea. it's a regular german word.
09:38	<gbee>	I wondered about that
09:38	<stuarta>	isn't that supposed to be locale specific
09:38	<stuarta>	or a way of doing it locale specific.
09:39	<gbee>	there is no point in removing The or A unless we also remove An
09:39	<gbee>	stuarta: not at the moment, but it probably should be
09:40	<gbee>	I'll put a locale check in there tonight
09:41	<stuarta>	the devil will be in the details with that one...
09:41	<gbee>	would be better if that sort of thing was handled through settings - so it could work for all languages
09:42	<stuarta>	yeah, my point being, i don't think it's a 1 evening fix...
09:42	<gbee>	right now a simple language check would surfice, in you're using "eng" or "eng_GB" etc
09:43	<gbee>	s/in/if/
09:43	<janneg>	it can't be fixed by locale or a simple setting. I have both german and english programs
09:44	<gbee>	janneg: it can be fixed for the majority
09:44	<stuarta>	can of worms methinks
09:45	<janneg>	gbee: it's a much better workaround but no real fix
09:47	<gbee>	not proposing it as a complete fix or a long term solution
09:47	<gbee>	now if we stored the program language in the program table ...
09:47	<gbee>	only I've no idea if we'd be able to get the data for that
09:48	<janneg>	DVB EIT carries language information, but it would be a big mess to handle removing leading articles for each entry differently
09:50	<stuarta>	you wouldn't remove things as you receive them
09:50	\|-\|	cattelan changed nick to cattelan_away
09:50	<stuarta>	you would use the language of the eit data to modify the sorting algorithm
09:50	<janneg>	gbee: I think language stored into the channel table would be enough. it won't be perfect but storing the language in the program table is insane
09:51	<gbee>	aye
09:52	<janneg>	and it wouldn't help against english original titles in german EIT
09:53	<janneg>	stuarta: has the SDT language information?
09:53	\|-\|	adante [n=adante@203-206-2-201.dyn.iinet.net.au] has quit [Remote closed the connection]
09:53	<stuarta>	ummm.... lemme have a look
09:53	\|-\|	adante [n=adante@203-206-2-201.dyn.iinet.net.au] has joined #mythtv
09:54	<gbee>	it needn't be perfect, remember that it's just to make things a little simpler, because many people tend to forget or ignore the 'A, The, An' when thinking of a programme name
09:55	<stuarta>	no
09:55	<gbee>	it doesn't serve any important purpose
09:55	<stuarta>	it's only really in the PMT
09:55	<janneg>	except it is in a descriptor
09:55	<stuarta>	when the audio streams are listed
09:55	<stuarta>	which changes per program
09:57	<janneg>	gbee: but "An" is an important part of the german title. I wouldn't think of looking for "An jedem verdammten Sonntag" under 'j'
09:58	<gbee>	but would you think to look for "The Bill" under Bill as a native German speaker?
09:59	<gbee>	which is what I mean, if it's based on your configured language then it will work for the majority of cases
10:01	<gbee>	and if necessary, words such as "The" can be applied to multiple languages
10:02	<gbee>	if (lang == eng) { // The, An, A} else if (lang == de) { // The } else if (lang == fr) { // le, la, etc}
10:04	<gbee>	Ultimately I'd prefer the 'articles' for every language weren't hardcoded, they could be part of the translation or made user configurable
10:06	\|-\|	gnome42 [n=obi@dsl-141-151.aei.ca] has joined #mythtv
10:07	<gbee>	btw I keep forgetting where you are, so if you're not a native German speaker I apologise
10:15	<lucas123>	gbee: you might want to not link it to a myth setup, but rather have it be a per channel thing. Lots of people in europe have channels in a lot of different languages. I have at least 5 german and 15 english ones for instance.
10:17	<lucas123>	or better yet a per program thing.. looking at the xmltv spec, the title, subtitle and desc tags have a language property.. (not sure how many implementations actually provide it though)
10:17	<gbee>	yeah, I appreciate that, but I'm just wondering if you benefit from sorting whilst ignoring "The, A, An"
10:18	<gbee>	I may be a bad example, but when thinking of a French or Spanish tv/film name I don't ignore la/le/el/l' etc in the same way I do with The/An/A in english
10:19	<gbee>	that's because I'm not a native French or Spanish speaker btw
10:20	<gbee>	the easiest solution would be to get rid of that sorting altogether
10:21	[~]	gbee thinks he is digging himself a hole here
10:21	[~]	stuarta starts trying to catch the worms
10:31	\|-\|	Neeesat25 [n=neosat@87.228.216.119] has quit []
10:34	\|-\|	Disconnect [n=dis@c-68-48-132-97.hsd1.md.comcast.net] has left #mythtv ["Bailed"]
10:41	<gbee>	http://pastebin.ca/341391
10:41	<stuarta>	erm, isn't the language listed as eng? or does it take on the locale setting?
10:42	<gbee>	ISO639Language is eng, Language is EN_GB
10:43	<gbee>	it's just a concept thing, couldn't decide whether one might be better than the other
10:43	[~]	stuarta senses more worms escaping...
10:44	<gbee>	could do both, just for the heck of it
10:45	<gbee>	wishing I'd ignored #3048
10:49	<gnome42>	hmm, I can't attached a patch to a ticket in trac at the moment - "Rejecting spam: LED" ?
10:51	<gbee>	the patch contains a prohibited string, you'll need to tar it
10:52	<gnome42>	gbee: Oh OK. Thanks gbee
10:52	<gbee>	the spam filter is lousy ;)
10:53	<stuarta>	doesn't even block the dodgy link spams
10:58	<gnome42>	phew! trac finally accepted it. Seems that tar was not enough had to tar and gzip :)
10:59	\|-\|	luckyone_ [n=hidden@CPE-75-87-69-197.kc.res.rr.com] has joined #mythtv
11:00	\|-\|	luckyone_ [n=hidden@CPE-75-87-69-197.kc.res.rr.com] has left #mythtv []
11:00	<janneg>	yes, tar is just a container to hold multiple files. the same string is also in the tar
11:01	<gbee>	sorry, implied but didn't say that
11:01	<janneg>	stuarta: I think it blocks it but sends the notification emails
11:02	<gbee>	didn't want to impose a specific compression - bzip over gzip, or vice-versa
11:02	<gbee>	janneg: it doesn't block it, I'm just very quick at deleting them :)
11:02	<janneg>	everytime I want to delete the spam tickets they are gone
11:03	<gbee>	I'll leave some for you next time ;)
11:03	<janneg>	it was sometimes just seconds after receiving the email
11:05	\|-\|	jmk [n=jmk@vrnawihed51-pool5-a211.vrnawi.tds.net] has quit ["Leaving"]
11:06	\|-\|	_mike3_ [n=mike@dhcp-0-18-39-71-48-17.cpe.mountaincable.net] has joined #mythtv
11:06	<_mike3_>	Hey questions guys. Can somebody tell me a little about the broadcast flag? Are they now building hardware with this?
11:17	<_mike3_>	And what is DRM, isn't this broadcast flag?
11:18	\|-\|	xris [n=xris@xris.forevermore.net] has joined #mythtv
11:27	\|-\|	livingtm [n=livingtm@cpe-74-67-15-162.nycap.res.rr.com] has quit ["Ex-Chat"]
11:29	\|-\|	stuarta [n=stuart@unaffiliated/stuarta] has quit ["leaving"]
12:02	\|-\|	xris [n=xris@xris.forevermore.net] has quit ["Leaving."]
12:39	\|-\|	Puh [i=puh@reppana.ttek.fi] has quit [Nick collision from services.]
12:39	\|-\|	Puh [i=puh@reppana.ttek.fi] has joined #mythtv
12:39	\|-\|	Puh [i=puh@reppana.ttek.fi] has quit [Nick collision from services.]
12:40	\|-\|	noddan_ [n=noddan@noddan-birger.brj.sgsnet.se] has quit [Read error: 104 (Connection reset by peer)]
12:42	\|-\|	noddan [n=noddan@noddan-birger.brj.sgsnet.se] has joined #mythtv
12:47	\|-\|	Puh_ [i=puh@reppana.ttek.fi] has joined #mythtv
12:50	<LLyric>	So, is anyone working on new themes? It looks like Media Center is getting rather pretty - http://www.codinghorror.com/blog/archives/000784.html
12:51	<LLyric>	Is that even within the scope of what a theme can do? It looks way beyond...
12:55	<GreyFoxx>	Most of that would require more than just themeing
12:57	<gbee>	be nice if it was flexible enough to do that, but no-one is offering to write it
12:58	<LLyric>	The themes are all declarative, I guess.
12:58	[~]	LLyric goes to the source - to see how well the Theme Engine concept is abstracted
12:59	<gbee>	well that's the last we'll see of him
12:59	<GreyFoxx>	heh
13:00	\|-\|	rtsai1111 [n=rtsai@208-201-231-158.dsl.dynamic.sonic.net] has joined #mythtv
13:01	<LLyric>	There's no abstraction between a "generic frontend", and our current understanding of what a menu is?
13:02	<GreyFoxx>	abstracted how ?
13:02	<GreyFoxx>	we define elements, the theme defines where they are placed
13:02	<GreyFoxx>	how many are on screen, etc
13:03	\|-\|	rtsai [n=rtsai@208-201-231-158.dsl.dynamic.sonic.net] has quit [Read error: 145 (Connection timed out)]
13:04	\|-\|	nelius [n=nelius@pD9E0E680.dip0.t-ipconnect.de] has quit ["Leaving"]
13:05	\|-\|	jmk [n=jmk@vrnawihed51-pool5-a211.vrnawi.tds.net] has joined #mythtv
13:05	<gbee>	the theme can't define new elements, nor does it allow any level of logic to be placed in the theme
13:06	<gbee>	that may be more flexible but I don't think it's worth going in that direction
13:07	<gbee>	better to make the current elements as flexible as possible and add new elements where necessary
13:07	<GreyFoxx>	and effects/transistions on those elements
13:07	<GreyFoxx>	Even defining a menu item as a jumppoint or key press would be nice
13:08	<LLyric>	Are the elements generated via callbacks, or do they all have to be calculated before the theme renderer is called?
13:09	<GreyFoxx>	don't know off hand
13:10	<gbee>	a lot can be done by just increasing the number of accepted attributes - an example being the buttons, currently only accept two alignment values (left, centre) but one of theme authors just wrote a patch two allow vertical and right alignment
13:10	<GreyFoxx>	Dagmar's patch ?
13:10	<gbee>	LLyric: we parse the theme first, then only enable the elements used
13:11	<LLyric>	The mediacenter view for recordings looks nicer than our two-pane view...
13:11	<gbee>	having said that, it's probably not universally true and some elements are expected in every theme
13:11	<GreyFoxx>	You don't mean that single lineup of images do you ?
13:11	<GreyFoxx>	the screenshot with the daily show stuff ?
13:11	<LLyric>	Sure, though I could see that multiple rows would be nicer.
13:12	<gbee>	GreyFoxx: yeah, it's a small example but if you end that to all the widgets and elements it immediately gives more power
13:12	<gbee>	s/end/add/
13:12	\|-\|	noddan [n=noddan@noddan-birger.brj.sgsnet.se] has quit [Connection reset by peer]
13:12	<GreyFoxx>	LLyric: It quickly be comes unmanagable when you have many recordings
13:12	<LLyric>	Please consider my suggestions in the context of not having written any significant c++ in 5+ years...
13:12	<gbee>	e.g. allowing horizontal, vertical, diagonal scrolling
13:13	<GreyFoxx>	gbee: That I would like
13:13	<GreyFoxx>	especiall if you highlight a name that is longer than the displaysize, after a second start scrolling it
13:13	<GreyFoxx>	In fact, it's on the mythui ticket (#12 I think) :)
13:13	<gbee>	it takes a certain amount of work to implement, but only has to be done once
13:15	<LLyric>	bbl, gotta sleep a bit more
13:18	[~]	j-rod wonders if Ingo's real-time kernel would be a win for a myth box...
13:25	\|-\|	_mike3_ [n=mike@dhcp-0-18-39-71-48-17.cpe.mountaincable.net] has quit ["leaving"]
13:26	\|-\|	siyb [n=siyb@chello212017067085.1.15.vie.surfer.at] has joined #mythtv
13:27	\|-\|	siyb [n=siyb@chello212017067085.1.15.vie.surfer.at] has left #mythtv ["Leaving"]
13:28	\|-\|	eskil [n=eskil@natint3.juniper.net] has joined #mythtv
13:31	\|-\|	beavis [n=beavis@p54A79E39.dip0.t-ipconnect.de] has joined #mythtv
13:31	<GreyFoxx>	san: Myth is designed to stream from the backend to the frontend
13:32	<gbee>	eskil: do you think it would be worth storing album art information in the database? not the art itself, but the paths to the art or an indication that the art is stored in the id3 tag. I thought it might save searching for the art each time a file is played
13:32	<eskil>	gbee, yes and no.
13:33	<eskil>	gbee, there's a ton of good reasons to store it in the db, but once it's in the file, it'll always be present, even when you transfer it to ie. an ipod.
13:34	<eskil>	gbee, I actually think id3v2 also supports having a uri to the art instead of the actualy image data.
13:34	\|-\|	luna6 [n=luna6@ip68-14-110-43.no.no.cox.net] has joined #mythtv
13:34	<eskil>	gbee, for for the sake of using the mp3s on other players/devices, I kinda like having the art in the file itself.
13:34	<gbee>	yeah, I'm not suggesting removing it from the file, just keeping mythmusic as fast as possible by caching that information rather than looking for it each time
13:35	<eskil>	gbee, ah, yes, that would make sense, although I don't know if you'd get any noticeable speed increase.
13:36	<gbee>	you probably saw I committed that patch to prevent re-drawing of the art if it hasn't changed - that particular problem becomes even bigger with your patch because we're no longer just re-drawing the art but searching both the id3 and directory first
13:36	[~]	eskil saw nothing this weekend except his couch & telly.
13:37	<gbee>	it's a minor thing, but any speed increase is worth it imho
13:38	<gbee>	xris and I have discussed adding a music_directory table to store path info, rather than storing the full path for each file in the music_songs dir
13:38	<eskil>	gbee, makes sense, there's a ton of duped strings there.
13:39	\|-\|	stuarta [n=stuarta@unaffiliated/stuarta] has joined #mythtv
13:39	<gbee>	for now it's more about speed, but it offers the possibility to add different ways of browsing music to the existing stuff
13:40	<eskil>	gbee, I've never been too worried about the redraw, it's fast, happens only on track changes.
13:40	<gbee>	I think the same would be true for storing the album art info in the database, I've just seen a media centre screenshot where you can browse the music collection through the album art
13:40	\|-\|	nn [n=joseph@cpe-72-229-104-43.nyc.res.rr.com] has joined #mythtv
13:40	<eskil>	gbee, http://en.wikipedia.org/wiki/CoverFlow
13:41	<eskil>	gbee, I'd also like to see artist art in the db.
13:41	<GreyFoxx>	eskil: That same sort of thing would be neat for flipping through Mythvideo stuff which has Cover Images
13:42	<eskil>	GreyFoxx, yeah, now if someone had the extra time to write a fliptych widget for mythui...
13:42	\|-\|	nn [n=joseph@cpe-72-229-104-43.nyc.res.rr.com] has left #mythtv []
13:43	<gbee>	I'll build on your patch to support storing the info in the db then
13:44	\|-\|	MrGandalf [i=buechlmr@cpe-72-225-32-214.rochester.res.rr.com] has joined #mythtv
13:45	<eskil>	gbee, which patch ? the one if the ticket about id3v2 album art stuff ?
13:46	<gbee>	yep
13:46	<eskil>	gbee, so are you going to load them while scanning all files (and checking timestamps) or just when needed ?
13:48	<gbee>	when performing a scan we'll look for the album art and place the details in the db
13:48	\|-\|	CDevMobile [i=wmirc_us@250.sub-75-192-6.myvzw.com] has joined #mythtv
13:49	<eskil>	yeah, the simplest working solution.
13:50	<eskil>	gbee, I already store station logos in the db for the shoutcast patch - what's the preferred mythtv way to this this ? Blobs or file uris ?
13:50	<gbee>	I should be able to speed up the scanning so that running regular updates won't be a pain in the neck
13:51	<gbee>	eskil: I believe the preferred way for mythtv is as a file, but my personal preference would be as a blob
13:51	<eskil>	gbee, how ?
13:52	<eskil>	(the speedup)
13:52	<eskil>	gbee, yeah, blobs seem better suited, less file separation issues.
13:53	<gbee>	combination of things, some of which have already been done - but improving the queries, indexing, caching etc
13:53	<gbee>	for each when running a scan we look up artist, album and genre information for every single file, rather than caching that information
13:55	<eskil>	ah, that'd be neat.
13:55	<eskil>	now if you could also speed up my nfs....
13:55	<gbee>	must be more tired than I thought, managing to insert random words in my sentences
13:56	<gbee>	"each" was meant to be "example"
13:56	<eskil>	gbee, "for each"... you do like the perl dont you ?
13:56	<gbee>	it was my first love ;)
13:57	<eskil>	I'm sorry.
13:58	<eskil>	I wish I wish I wish I had the time to rewrite mythmusic to be a multi store oriented upnp controller/renderer...
13:58	<stuarta>	a 2nd language of perl... hmmm...
13:59	<gbee>	I've already got the scan (update) running 100x faster on my machines simply by fixing a few simple bugs, which is the stuff I've already committed
13:59	\|-\|	CDevMobile [i=wmirc_us@250.sub-75-192-6.myvzw.com] has quit [Read error: 104 (Connection reset by peer)]
14:00	[~]	gbee eyes stuarta suspiciously
14:00	<eskil>	ohlala, should update then...
14:00	<stuarta>	i've been contemplating a new interface for mythmusic that is more suited to party dj'ing
14:00	<stuarta>	but i've got enough stuff to break already
14:00	\|-\|	CDev [n=CDev@c-71-233-206-26.hsd1.ma.comcast.net] has left #mythtv []
14:00	<eskil>	I'd just like one that didn't lick balls.
14:01	<eskil>	And a codebase that wasn't pretty damn unwieldy.
14:01	[~]	stuarta raises an eyebrow
14:01	<gbee>	just to feed the fire, I'm proficient in php and have a passable understanding of python
14:02	<eskil>	stuarta, just the usual senseless gripe about extra buttons that just take up screen. I know, it's all a matter of taste.
14:02	<stuarta>	no not really
14:02	<gbee>	so now everybody knows the truth, I'm a scripter at heart
14:02	<eskil>	gbee, that's ok, we need them as well.
14:03	<eskil>	stuarta, how so ?
14:03	<stuarta>	having played with a commercial program somewhere i used to work
14:03	<stuarta>	they have some nice stuff in their interface..
14:04	<stuarta>	i'll try to describe it.
14:04	<stuarta>	2 visible areas, 1 with the current playlist,
14:04	<stuarta>	1 with the list of available music
14:05	<gbee>	ohlala? sounds very familiar ...
14:05	<stuarta>	with the ability to easily add a song to the end of the playlist
14:05	<stuarta>	no idea what it was called.
14:05	<stuarta>	can also move songs around on the current playlist
14:05	<stuarta>	all without disturbing the current song
14:05	<gbee>	stuarta: yeah something like that would be nice
14:06	<eskil>	stuarta, was this for TV or computer monitors ?
14:06	[~]	stuarta phone
14:06	<eskil>	oh damn, even less screen area.
14:07	\|-\|	xris [n=xris@dsl081-161-160.sea1.dsl.speakeasy.net] has joined #mythtv
14:09	[~]	stuarta back
14:10	<gbee>	xris: any ideas for this directory table's schema? I've got three columns - id, path and parent id
14:10	<stuarta>	right, it was for a computer monitor, but we could adapt the concept
14:10	<stuarta>	easy to add stuff to running playlists. etc etc
14:10	<stuarta>	easy interface to build playlists (don't we have something like this anyway)
14:11	<xris>	gbee: probably enough for now.
14:11	<eskil>	stuarta, it's just hard to cram multiple view areas into 800x600 and make it readable across the room.
14:11	<stuarta>	sure
14:12	<eskil>	stuarta, but you could always have context sensitive menu, so pressing M offers "Add to playlist" and "Remove from playlist".
14:12	<MrGandalf>	damn, can't remember how to do an svn merge.. does this look right: svn merge --dry-run -r 12730:12730 http://svn.mythtv.org/svn/trunk/mythtv
14:12	<stuarta>	eskil: was more thinking along the lines of highlight show, press ok, adds it to the list.
14:12	<stuarta>	easy to use.
14:12	<stuarta>	s/show/song
14:13	<gbee>	I thought we might scrap the current playlist screen, start again with five top level options (Artist, Album, Genre, Year, Directory)
14:13	<eskil>	stuarta, doesn't it seem more natural that pressing ok makes it play ?
14:14	<eskil>	gbee, yeah, people are already comfortable with that now that we live in the ipod generation.
14:14	<stuarta>	eskil: that is the same as adding the song to an empty current playlist
14:14	<stuarta>	think of the use case.
14:14	<stuarta>	party, wonder up, queue up an hours worth of music
14:14	<stuarta>	s/wonder/wander
14:14	<eskil>	stuarta, I thinking of the case where the playlist isn't empty. Do you replace it or add to the front/back ?
14:15	<stuarta>	i'd add to back.
14:15	<gbee>	stuarta: you can already append stuff to a playlist without interupting playback through the 'search' interface
14:15	<gbee>	it just needs to be extended to normal playlist browsing
14:15	<stuarta>	gbee: it's clunky though.
14:15	<eskil>	stuarta, ah, because you want the jukebox/party style interface. I'm more thinking of the "I'm slacking on my couch"-interface.
14:16	<stuarta>	eskil: essentially yes.
14:16	<janneg>	MrGandalf: no, -c12731 or -r12730:12731 if you want just changeset 12731
14:16	<stuarta>	perhaps it should be known as DJ mode :)
14:16	<eskil>	stuarta, yet another config option !
14:16	<eskil>	stuarta, oh you need a "Add to queue" button on your remote.
14:17	[~]	stuarta needs a remote
14:17	<gbee>	doesn't need to be a config option, just a different screen - could toggle between the normal screen and the DJ screen
14:17	<eskil>	stuarta, a wireless keyboard does not count as a remote.
14:17	<stuarta>	gbee: yes that's the correct way to do it.
14:17	<MrGandalf>	janneg: still nothing.. I'm sitting in mythtv-vid I just downloaded and want to merge with trunk..
14:18	<stuarta>	eskil: hehe :) not that I have one...
14:19	<stuarta>	anyway, that's just my crazy thoughts.
14:19	<stuarta>	maybe once if fix all my outstanding bugs i might work on it.
14:20	<eskil>	stuarta, I agree with them (mostly), and while there's always time to fantasise about fixing mythmusic... well, the coding...
14:21	<stuarta>	:)
14:22	<stuarta>	i'm trying to find a weekend to sort out all the patches in my tree...
14:23	<gbee>	the good news is that there is a lot of work being done on mythmusic at the moment, so gradually it may move in the right direction
14:23	<janneg>	stuarta: stream id is table_id and 0x0 is the table_id for the PAT
14:23	<eskil>	gbee, true.
14:23	<eskil>	gotta get my lunch on...
14:23	\|-\|	eskil changed nick to eskil_afk
14:24	\|-\|	Beirdo_ changed nick to Beirdo
14:24	<gbee>	eskil: think I'll split the album art patch into two or more parts - the banner stuff can go in now, the rest will have to wait for a short while
14:24	<stuarta>	janneg: ah bugger. getting rusty, NIT's on 0x10
14:24	[~]	gbee rusted overnight
14:25	<MrGandalf>	stuarta: yes
14:25	[~]	stuarta runs off to correct himself...
14:25	<gbee>	spent hours reading the DVB specs when I was looking at the scanning problems, couldn't even remember the basic details now
14:25	<MrGandalf>	SDT 0x11, EIT 0x12, PAT 0x00
14:25	<stuarta>	gbee: but i should remember them from all the scanning stuff i've done...
14:26	<janneg>	MrGandalf: svn merge command looks ok
14:26	<MrGandalf>	janneg: odd then, not merging anything..
14:27	\|-\|	noddan [n=noddan@noddan-birger.brj.sgsnet.se] has joined #mythtv
14:28	<janneg>	MrGandalf, stuarta: you're both mixing up table_ids and pids. it's the same for the PAT but the others differ and have multiple table_ids
14:28	<stuarta>	double bugger
14:28	<janneg>	MrGandalf: let me try it myself
14:28	[~]	stuarta trouts himself....
14:29	<MrGandalf>	I was talking PIDs.. NIT current is 0x65 if I remember correctly.. but could be 0x64
14:29	<stuarta>	not on a normal network
14:30	<MrGandalf>	you're right.. mixing up decimal and hex..
14:31	\|-\|	MoRpHeUz [n=morphbr@200.184.118.132] has left #mythtv ["Leaving..."]
14:31	<janneg>	NIT is on pid 0x10 and has table_id 0x40 for actual and 0x41 for other networks
14:31	<MrGandalf>	yes
14:31	<MrGandalf>	64 & 65
14:32	\|-\|	CDev [n=CDev@c-71-233-206-26.hsd1.ma.comcast.net] has joined #mythtv
14:36	<gbee>	reckon 255 chars is enough for a full path, or does it need to be more?
14:37	<stuarta>	not really
14:39	<hads>	The longest path on my box is probably around 120 or so
14:40	<gbee>	ok, TEXT it is
14:40	<janneg>	MrGandalf: svn merge -r12675:12724 http://svn.mythtv.org/svn/trunk/mythtv works here. it has a conflict in configure
14:40	<MrGandalf>	12675? May I ask where you got that revision?
14:40	<stuarta>	gbee: looks for big one and found 103 chars....
14:41	<stuarta>	(just for the directory name)
14:41	<MrGandalf>	the lastest revision is 12730
14:41	<gbee>	heh
14:41	<MrGandalf>	of both trunk and mythtv-vid
14:41	[~]	stuarta blames it on the smashing pumpkins
14:42	<hads>	Oo, there's one that's 160 chars
14:42	<janneg>	MrGandalf: from the mythtv-vid log. changeset 12676
14:42	<gbee>	this will be for the directory path, doesn't include the filename
14:42	<stuarta>	gbee: do you know if we support .m3u playlists atm?
14:43	<hads>	Yeah, that had a pretty long filename in it. If someone has a directory path longer than 255 that'd be a little odd.
14:43	<janneg>	MrGandalf: daniel's last merge merged the changes from up to revision 12675 to mythtv-vid
14:43	<gbee>	stuarta: grep says no
14:44	[~]	stuarta files that one on his wishlist
14:44	[~]	stuarta sighs
14:44	<stuarta>	so many improvements, so little time
14:44	<MrGandalf>	I must of missed that.. maybe I don't need to merge then. I'l was looking for the new signalmonitor addition and didn't see it
14:44	<MrGandalf>	janneg: thanks
14:44	\|-\|	purserj [n=purserj@k-sit.com] has joined #mythtv
14:45	<MrGandalf>	Ah, it's in dtvsignalmonitor, not dvbsignalmonitor..
14:45	[~]	MrGandalf smacks himself..
14:45	<gbee>	I've not decided whether it will actually be a full path or a relative path from the root music directory, the former will ultimately allow us to specify multiple music storage locations but the latter is a lot less expensive in terms of space and is easier to index
14:45	<janneg>	MrGandalf: the fast tuning?
14:45	<MrGandalf>	janneg: the crypt signal monitor
14:46	<stuarta>	gbee: you could easily do relative paths and multiple music storage locations.
14:46	<gbee>	btw, it's been suggested that the signal monitor OSD is made optional - purely because it's not very pretty and is meaningless to most users
14:46	<janneg>	ah, that's already in mythtv-vid
14:46	<gbee>	stuarta: sure, I suppose
14:48	<MrGandalf>	janneg: really appreciate your help though.. should have checked close and saved a lot of time
14:48	<MrGandalf>	s/close/closer/
14:48	<janneg>	gbee: IBTD it's neither especially ugly nor meaningless in the case off errors.
14:49	<gbee>	relative paths have one bonus I've only just thought of, you can move your entire collection on the disk or to a new disk without needing to rescan
14:49	<stuarta>	yup, or to a removable device, that you say carry on the train???
14:50	<gbee>	janneg: how regular are those errors? as a debugging tool it's very useful, but unneeded on a production box and non-technical users don't have a clue what it means
14:50	<stuarta>	must remember music sources are removable...
14:50	<gbee>	as someone said yesterday - his wife doesn't understand it and would rather seem the programme information
14:51	<janneg>	gbee: we could probably trigger it only when tuning wasn't complete after 3 seconds or so
14:51	<gbee>	s/seem/see/
14:51	\|-\|	LLyric [n=simon@d58-108-40-187.dsl.vic.optusnet.com.au] has quit ["Leaving"]
14:54	<janneg>	gbee: I see no need to hide the program information in that screen
15:00	<gbee>	incidently, with the new fast tuning I'm getting under 4 second channel changes on a remote frontend, which is an improvement
15:00	<stuarta>	think it's time i updated again...
15:03	<janneg>	gbee: not overall channel change time but device tune time which should be much lower
15:04	<gbee>	I know that's what you meant by 3 seconds, it just reminded me to mention that my channel change times are down :)
15:06	<gbee>	about 6 months ago, it was taking around 7 seconds I think for a channel change, so 3.5-4 seconds for channels on different multiplexes is pretty damn good
15:10	<gnome42>	janneg: Do you know where the majority of the channel change time is spent? (or wasted :)
15:14	<janneg>	prebuffering the stream
15:14	<stuarta>	that was going to be my guess
15:17	<Chutt>	actually
15:17	<Chutt>	most of the time for digital tv is spent waiting for audio + video timestamps to match up
15:17	<gnome42>	hmm, prebuffering while the signalmonitor looks for SDT/PAT/PMT etc. That prebuffering?
15:18	<Chutt>	at least, that's what the majority of time was when i was looking at hdtv stuff here
15:19	<stuarta>	i've found the hd stuff take longer to startup than the sd content
15:19	<Chutt>	larger stream sizes
15:20	<Chutt>	and there's often a largish offset between audio and corresponding video packets
15:20	<gnome42>	Chutt: ooh, ok.
15:20	<Chutt>	so if we need to throw stuff away, it takes longer..
15:21	<stuarta>	that's what i suspected.
15:23	\|-\|	fightclub [n=fightclu@c-67-177-114-214.hsd1.in.comcast.net] has joined #mythtv
15:23	<janneg>	Chutt: is an extern foo(); in libmythtv for a libavcodec function ok? I don't want to to include the header since it would include other junk.
15:24	<fightclub>	i just installed myth tv onto an ubuntu box... i have 2 120 GB drives i want to use for storage (they are separate from the disk the OS is on)... how should i format these drives (ext3)?
15:24	<Chutt>	janneg, sure
15:24	<janneg>	ok
15:24	<Chutt>	janneg, just be prepared for it to break =)
15:24	<stuarta>	fightclub: you should read the topic
15:25	<fightclub>	oops... sorry gentlemen... got a little ahead of myself
15:25	\|-\|	fightclub [n=fightclu@c-67-177-114-214.hsd1.in.comcast.net] has left #mythtv ["Leaving"]
15:25	<gnome42>	In a previous debugging attempt a long time ago I thought I had discovered that a tvchain update msg was being lost between the backend and frontend. Does that sound at all plausible?
15:26	<janneg>	Chutt: I don't expect that function (mpeg start code detection) to change much in libavcodec
15:28	<MrGandalf>	odd, I find HD streams to startup much faster than SD
15:29	<MrGandalf>	in fact, for me often times as soon as the OSD shows up I see video
15:29	<MrGandalf>	SD content, however, I could be waiting 2-5 seconds
15:30	<MrGandalf>	and I'm not streaming from the backend either
15:30	<gnome42>	MrGandalf: that's for LiveTV?
15:30	<MrGandalf>	yes
15:30	<stuarta>	dishnet just get weirder...
15:30	<MrGandalf>	chutt: is the wait in the recorder end or the player end?
15:30	<gnome42>	MrGandalf: hmm, that is weird. I get subsecond channel changes with bttv/SD ;)
15:31	<MrGandalf>	gnome42: I get faster changes with my pvr card, this was DVB I was talking about
15:32	<MrGandalf>	if the channel is on a new tuner, it's more like 5 seconds, if the same tuner, more like 2
15:32	<gnome42>	MrGandalf: Oh, OK.
15:33	<MrGandalf>	changing to a pvr tuner is more like 3 seconds, change tuner is ~1 second
15:33	<MrGandalf>	er, change channel ~1 second
15:37	<eskil_afk>	stuarta, m3u, the shoutcast patch uses .pls files
15:37	\|-\|	eskil_afk changed nick to eskil
15:37	<stuarta>	eskil: okay cool.
16:08	\|-\|	wildwrk [n=jawildma@65.43.29.90] has joined #mythtv
16:08	\|-\|	wildwrk [n=jawildma@65.43.29.90] has left #mythtv []
16:10	\|-\|	purserj [n=purserj@k-sit.com] has quit [Remote closed the connection]
16:10	\|-\|	purserj [n=purserj@k-sit.com] has joined #mythtv
16:21	<janneg>	MrGandalf: re #3051 is that a merged build? I had also problems to build the merged stuff. a clean co of mythtv-vid worked fine though
16:23	<MrGandalf>	Nope, no merged.. lemme look at something
16:23	<MrGandalf>	Nope, that's unmodified (well, mostly) mythtv-vid
16:24	<MrGandalf>	wait.. was in added in 12731 or 12732
16:24	<MrGandalf>	closing ticket
16:26	<MrGandalf>	is there no way to close tickets anymore?
16:27	<janneg>	only for people with account
16:28	<MrGandalf>	can you close it for me if you're there?
16:28	<janneg>	already done
16:28	<MrGandalf>	thanks
16:30	\|-\|	purserj [n=purserj@k-sit.com] has quit [Remote closed the connection]
16:36	\|-\|	purserj [n=purserj@k-sit.com] has joined #mythtv
17:05	\|-\|	jgarvey [n=jgarvey@cpe-075-177-158-190.nc.res.rr.com] has quit ["Leaving"]
17:09	\|-\|	AlienX [n=theanswr@unaffiliated/alienx] has joined #mythtv
17:11	<MrGandalf>	damn, switching tuners defaults to the save channel and not the requested channel
17:11	\|-\|	beavis [n=beavis@p54A79E39.dip0.t-ipconnect.de] has quit ["Verlassend"]
17:12	\|-\|	lsobral [n=sobral@200.184.118.132] has quit ["Leaving"]
17:15	<stuarta>	MrGandalf: it's a fallback in case the new channel doesn't work
17:15	<MrGandalf>	the new channel works
17:16	<stuarta>	something in those latest set of updates made the seeking behaviour a lot better
17:16	<MrGandalf>	there's no indication that I selected the new channel nor that something is wrong with it
17:17	<MrGandalf>	I'll have to track that down tomorrow.. I remember this happening once before.
17:17	<MrGandalf>	in the mythtv-eit branch
17:18	<stuarta>	well that's been merged for ages...
17:19	<gbee>	stuarta: more recent than the variable network stuff?
17:19	<gbee>	that really improved seeking for me
17:20	<stuarta>	first update for about a week or so...
17:20	<gbee>	if "variable network stuff" sounds vague, it's only because I can't remember what the change was exactly ;)
17:20	<gbee>	but it's older than a week
17:21	<stuarta>	it's possible, my previous version was older than a week :-/
17:26	<stuarta>	gbee: it looks harder to make the frontend lockup than it did before...
17:28	<gbee>	I'm running with that null pointer check commented out and it hasn't locked up once, but I'm not sure if that's done to other fixes which have gone in since the resync
17:28	<gbee>	s/done/down/
17:28	<stuarta>	yeah...
17:29	<stuarta>	ah, worked out a way to see which version i'm on.
17:29	<gbee>	?
17:30	<stuarta>	looking at my graphs of the backend memory size.
17:30	<gbee>	I need to experiment, but I've not had the time
17:30	<stuarta>	sadly i now remember i was playing with amd64 last wed, so it's not then
17:30	<stuarta>	probably the wed before that...
17:32	<gbee>	hmm, my memory is pretty bad - the network stuff I mentioned was Bruce's adaptive blocksize code and it was committed back in November
17:33	<stuarta>	oh that stuff.
17:33	<stuarta>	no wasn't that, i need to tune that
17:33	<gbee>	I could have sworn it was more recent
17:33	<stuarta>	things go funny when your cpu is borderline for the content you are viewing
17:34	<gbee>	applies more when using a remote frontend - made a real difference here
17:34	<gbee>	but clearly too old ;)
17:34	<stuarta>	i only just rebuilt the frontend, backend is exactly the same
17:35	<stuarta>	hopefully the DB update wasn't too bad, since the frontend did it. ooops.
17:35	<gbee>	I've not noticed any improvements in seeking, unless you count the lockup problem
17:36	<gbee>	db update was mostly xris' indexes, completely harmless
17:37	<stuarta>	ah, well that would help things
17:39	<gbee>	depending how old your last version was, a new column was added to the cardinput table for the fast tuning stuff
17:39	<stuarta>	could also be that, but i'm watching recordings, so i doubt it
17:39	<gbee>	but that's also safe as it's backend only
17:45	\|-\|	eskil [n=eskil@natint3.juniper.net] has quit [Read error: 110 (Connection timed out)]
17:48	\|-\|	eskil [n=eskil@nat-service4.juniper.net] has joined #mythtv
17:48	[~]	xris really needs to finish his slow query log analyzer
17:48	<xris>	gbee: question.. what would you think is the best way to identify channels that don't have an xmltvid?
17:49	<xris>	country+channum?
17:49	<gbee>	channum won't work, satellite, terrestrial and cable will overlap
17:50	<xris>	in the US, callsign is fairly unique, but I hear that elsewhere in the world they're not actually used
17:50	<janneg>	for dvb networkid,transportid,serviceid
17:51	<gbee>	callsign is in the db over here, although it's just the channel name - the important thing is that many people edit the callsign because it's often too long to fit in most places mythtv uses it
17:51	<xris>	where are those in the db?
17:52	<xris>	I see serviceid in the chanel table
17:52	<janneg>	xris: networkid,transportid in dtv_multiplex and serviceid in channel
17:52	<xris>	this is going to be FUN to code. blech.
17:52	<gbee>	dtv_multiplex and channel
17:53	<xris>	janneg: and those won't overlap between countries, etc?
17:53	<gbee>	dtv_multiplex and channel are linked by mplexid
17:53	\|-\|	Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
17:54	<xris>	think that would apply to dvb-s, too?
17:54	<gbee>	iirc networkid is supposed to be unique - but janne or stuarta can confirm that
17:54	<gbee>	so a combination of those three, should uniquely identify a channel
17:54	<stuarta>	there's even a list somewhere of what network id belongs to what company
17:55	<gbee>	BUT the same channel shown on two different networks would have different ids
17:55	<xris>	gbee: that's not really a big deal.
17:55	<xris>	false negative can be added. false positive is a problem
17:55	<stuarta>	just to confuse you, there's original network id, and network id
17:56	<gbee>	stuarta: think that might over complicate things ;)
17:56	<xris>	I basically need to completely redesign my channel icon db so that it can link all of these things together better.
17:56	<xris>	separate tables for callsign, xmltvid and apparently dvb_id
17:57	<xris>	linker tables between each of them.. or at least between xmltvid and the others
17:58	<stuarta>	oh great, now they've started putting <movie name> (cont) in the guide data.
17:58	<stuarta>	muppets
17:58	<gbee>	don't envy you the job, but it'll be a great asset when it's done
17:59	<gbee>	they are supposed to get better, not worse :(
18:01	<janneg>	mythtv doesn't care about the network id
18:01	<xris>	janneg: does it store it, though?
18:01	<xris>	or does it matter?
18:02	<janneg>	no, the networkid column is really the original network id
18:04	<janneg>	I will change that eventually
18:04	<stuarta>	not exactly high priority tho
18:05	<xris>	so since I have no idea what any of this is, what should I use to identify a unique channel?
18:06	<gbee>	networkid, transportid and serviceid
18:06	<janneg>	SELECT networkid,transportid,serviceid FROM channel,dtv_multiplex WHERE channel.mplexid = dtv_multiplex.mplexid;
18:06	<xris>	good enough.
18:07	[~]	xris grumbles about vague column names in mythtv queries..
18:07	<gbee>	the original network id just means that if channel A is originally broadcast on network 1 and then rebroadcast on network 2, it's new network id is 2 but it's original network id would be 1
18:08	<stuarta>	good on paper. we are let down by application of the standards
18:08	<gbee>	both original networkid and the networkid are broadcast in the stream
18:08	<gbee>	it's good enough for this purpose
18:09	<xris>	gotcha
18:09	<stuarta>	yeah, but the broadcasters often break stuff by not bumping the netid to the onetid
18:09	<stuarta>	true, good enough for this
18:09	<xris>	so that will get dvb, and US/Canada zap2it stuff, and anyone who uses xmltv...
18:09	<xris>	wonder if there's anything else.
18:09	<stuarta>	no worth worrying about methings
18:09	<stuarta>	thinks
18:09	<xris>	heh
18:10	<stuarta>	anyway sleep required....
18:10	<janneg>	xris: you could ask daniel for ATSC
18:11	<stuarta>	it's similar from memory
18:11