| 00:20 | <mdz_> | witten: via an output from the sound card? |
| 00:21 | <Chutt> | computer's line out to my receiver |
| 00:21 | <Chutt> | heh |
| 00:21 | <mdz_> | witten: personally, I have my computer connected to my receiver, not the TV |
| 00:21 | <witten> | hmm ok |
| 00:21 | <Chutt> | tv speakers suck |
| 00:21 | <Chutt> | as a general rule |
| 00:21 | <mdz_> | TV speakers generally don't sound so good |
| 00:21 | <witten> | true |
| 00:21 | <witten> | but not everyone has a bitching sound system :) |
| 00:21 | <mdz_> | knock it off, chutt, you keep beating me to the punch |
| 00:21 | <Chutt> | heh |
| 00:22 | <witten> | so how would one go directly from a pc to a tv for audio, if one was so inclined? |
| 00:22 | <mdz_> | witten: even cheap speakers sound better than the speakers built into most TVs |
| 00:22 | <Chutt> | mdz, oh, changing things to do the epg from inside the tv class was harder than i thought, so i went and did it =) |
| 00:22 | <witten> | last I checked most TVs don't have 1/4" audio inputs :) |
| 00:22 | <mdz_> | Chutt: you went ahead and did it because it was harder? |
| 00:22 | <Chutt> | mine does |
| 00:22 | <Chutt> | mdz, yeah, qt threading issues |
| 00:22 | <witten> | Chutt: heh ok |
| 00:22 | <mdz_> | Chutt: 1/4", really? |
| 00:23 | <Chutt> | well, no |
| 00:23 | <Chutt> | it has rca |
| 00:23 | <Chutt> | but, that's just a cable adaptor |
| 00:23 | <mdz_> | witten: why do you want 1/4" inputs? I assume your sound card has 1/8" connectors |
| 00:23 | <witten> | mdz: er, 1/8". that's what I meant |
| 00:23 | <mdz_> | witten: as Chutt says, you can get a cable which goes from 1/8" stereo to dual RCA |
| 00:23 | <mdz_> | witten: at pretty much any computer or stereo store |
| 00:24 | <witten> | okay cool |
| 00:24 | <witten> | just wanted to make sure there was a way |
| 00:24 | <witten> | now the only thing I haven't found is how to do TV out in linux |
| 00:24 | <witten> | video, that is |
| 00:27 | <mdz_> | then you've gotten to the hard part |
| 00:27 | <witten> | heh |
| 00:27 | <witten> | it would just pain me to plunk down $125 on an external scan convert if there's some pci card that can do it in linux |
| 00:28 | <witten> | converter |
| 00:29 | <mdz_> | an external converter will more than likely work out of the box, though |
| 00:30 | <mdz_> | and I can say with some confidence that you will not have an easy time getting TV output on a card to work under Linux |
| 00:30 | <witten> | even with proprietary vendor-supplied drivers? |
| 00:30 | <mdz_> | Chutt: I was thinking about taking a stab at per-recording quality settings this weekend if I have some time |
| 00:30 | <Chutt> | neat |
| 00:30 | <mdz_> | Chutt: unless you want to avoid a database change |
| 00:30 | <Chutt> | that'd be appreciated |
| 00:30 | <Chutt> | naw, go for it |
| 00:31 | <mdz_> | witten: if you find something which works easily, a lot of people would like to know about it |
| 00:31 | <Chutt> | the nvidia binary tv out stuff works easily |
| 00:31 | <witten> | mdz: what chutt said |
| 00:32 | <mdz_> | I hear a lot of complaints from users who have problems getting the drivers to work |
| 00:32 | <mdz_> | which isn't to say it's entirely the drivers' fault, but it doesn't seem trivial for everyone |
| 00:32 | <witten> | it's true |
| 00:32 | <mdz_> | Chutt: you may not represent an entry level Linux user :-) |
| 00:32 | <witten> | the nvidia drivers can be a bitch |
| 00:32 | <witten> | especially with agp |
| 00:32 | <Chutt> | what? |
| 00:32 | <Chutt> | i'm not an entry level user? |
| 00:33 | <Chutt> | damn |
| 00:33 | <mdz_> | I've revoked your membership card |
| 00:38 | <Chutt> | i'm still pondering how to break stuff apart |
| 00:38 | <mdz_> | which stuff? |
| 00:38 | <Chutt> | the multiple boxes support |
| 00:38 | <mdz_> | ah |
| 00:39 | <Chutt> | of course, thinking about code doesn't really happen while i'm playing metroid =) |
| 00:40 | <mdz_> | better make sure that the database config stuff has a 'host' field when it goes in :-) |
| 00:41 | <Chutt> | it's probably going to be easiest to make even the single computer case semi-separated |
| 00:41 | <mdz_> | will it be a requirement that all mythtv boxes sharing a database also share the same RecordFilePrefix? |
| 00:41 | <Chutt> | nope |
| 00:41 | <mdz_> | hmm |
| 00:42 | <Chutt> | i just want a player to say to the master box 'give me this file', and it tells the player where it is, etc |
| 00:42 | <Chutt> | the only time you really need close 2 way communication is while watching live tv |
| 00:44 | <lichen_> | wow, watching live tv over the network.. brilliant! |
| 00:45 | <mdz_> | Chutt: I assume capture still only happens locally, though :-) |
| 00:47 | <witten> | is there such a thing as an svideo to coax converter? and is it just a cheap cable? |
| 00:47 | <mdz_> | are you thinking of separating out the single computer case just from a code structure perspective, or running independent processes? |
| 00:48 | <Chutt> | well |
| 00:48 | <Chutt> | probably independent processes |
| 00:48 | <Chutt> | which'll also have the nice side effect of fixing all the smp issues in libavcodec |
| 00:48 | <mdz_> | witten: I don't know, but my guess would be no |
| 00:48 | <witten> | hmm ok |
| 00:48 | <Chutt> | just have a backend |
| 00:48 | <Chutt> | and a frontend |
| 00:48 | <mdz_> | Chutt: or providing an excuse not to fix the SMP issues in libavcodec |
| 00:48 | <witten> | well then a card with svideo out doesn't do me any good |
| 00:49 | <Chutt> | that too |
| 00:49 | <mdz_> | witten: you don't have composite input even? |
| 00:49 | <Chutt> | i just need to sit down and write up a simple little communications protocol |
| 00:50 | <witten> | http://www.svideotorca.com/svideocoax.html |
| 00:50 | <witten> | mdz: what does composite input look like? |
| 00:50 | <mdz_> | for the single computer case, I'd much rather have the communication of bulk data over the filesystem than some IPC mechanism |
| 00:50 | <mdz_> | witten: an RCA connector |
| 00:50 | <witten> | mdz: oh, yeah, I'm sure the tv has rca inputs |
| 00:51 | <mdz_> | witten: use that, then |
| 00:51 | <Chutt> | mdz, right |
| 00:51 | <witten> | oh, there are cheap s-video to rca cables? |
| 00:51 | <Chutt> | as it is right now, there's very little data that's communicated between the player and the recorder |
| 00:51 | <Chutt> | that i can just do via sockets, and have everything else be files |
| 00:52 | -!- | lichen_ [] has quit ["thats what life is, one big series of down notes"] |
| 00:52 | <Chutt> | it'll complicate the ringbuffer a _little_ bit |
| 00:52 | <mdz_> | so to watch a recording in progress, it would just communicate the path to the file |
| 00:52 | <Chutt> | but not all that much |
| 00:52 | <Chutt> | exactly |
| 00:52 | <Chutt> | it'll make live-tv more like that, really |
| 00:52 | <mdz_> | right |
| 00:52 | <witten> | mdz/chutt: why don't you guys use NFS or something? :) |
| 00:52 | <Chutt> | because i don't want to use nfs |
| 00:52 | <mdz_> | in fact they might even be exactly the same |
| 00:53 | <Chutt> | well, live tv needs to know that it's a ring buffer |
| 00:53 | <mdz_> | on the player side anyway |
| 00:53 | <Chutt> | and when to wrap around |
| 00:53 | <Chutt> | other than that, yup. |
| 00:53 | -!- | witten [] has quit ["ircII EPIC4-1.1.2 -- Are we there yet?"] |
| 00:53 | <mdz_> | why should the player need to know? shouldn't it just be able to read the buffer forever and never come to the end? |
| 00:53 | <Chutt> | if it's a file |
| 00:54 | <mdz_> | I'm getting a hang when some recordings get previewed |
| 00:54 | <mdz_> | I thought it might be one problematic recording, but it just happened with another apparently |
| 00:55 | -!- | lichen_ [lichen@67.8.7.86] has joined #mythtv |
| 00:55 | <mdz_> | seems to be easily reproducible, so I'm going to take a look at it now |
| 00:55 | <Chutt> | cool. |
| 00:55 | <mdz_> | this is with CVS from 2 days ago |
| 00:55 | <Chutt> | actually |
| 00:55 | <mdz_> | didn't seem to happen with 0.7, but I haven't switched back to try it |
| 00:55 | <Chutt> | i can hang it myself |
| 00:56 | <mdz_> | maybe I don't have to rebuild for debugging then :-) |
| 00:56 | <Chutt> | not in gdb, though |
| 00:58 | <mdz_> | I am attached to one that's hung |
| 00:58 | <mdz_> | it's weird though |
| 00:58 | <Chutt> | heh |
| 00:58 | <mdz_> | when I attach, gdb apparently sends itself a SIGTSTP and it gets suspended :-) |
| 00:58 | <mdz_> | Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. |
| 00:58 | <mdz_> | Loaded symbols for /lib/libc.so.6 |
| 00:58 | <mdz_> | [2][2]+ Stopped gdb /usr/bin/mythfrontend 17382 |
| 00:58 | <Chutt> | hey |
| 00:59 | <Chutt> | have you heard of a bug in libc or libpthreads in debian? |
| 00:59 | <mdz_> | one thread is sleeping in #3 0x08054ec0 in QScrollView::mouseReleaseEvent () |
| 00:59 | <Chutt> | static bins segfault in threads in libc functions? |
| 00:59 | <mdz_> | a lot of statically linked binaries break with glibc 2.2->2.3 |
| 00:59 | <Chutt> | newly compiled |
| 00:59 | <mdz_> | all due to NSS issues that I know of, though |
| 00:59 | <mdz_> | no, haven't seen that |
| 01:00 | <mdz_> | why would it sleep on a mouseReleaseEvent? |
| 01:00 | <Chutt> | which thread, though? |
| 01:00 | <mdz_> | can't tell without debugging symbols |
| 01:01 | <mdz_> | thread 4 :-) |
| 01:01 | <Chutt> | heh |
| 01:01 | <Chutt> | i got it, i think. |
| 01:01 | <mdz_> | crap, I didn't build a source package for this CVS snapshot |
| 01:01 | <mdz_> | it happens when scrolling down the list of recorded programs |
| 01:02 | <Chutt> | yeah |
| 01:02 | <Chutt> | i think i've got it |
| 01:02 | <mdz_> | doesn't seem to always happen on the same program, but after a certain amount of frames have been displayed or something |
| 01:02 | <Chutt> | race condition |
| 01:02 | <Chutt> | fixing it now.. |
| 01:02 | <mdz_> | if moving down the list at the same speed every time, it tends to hit at the same time |
| 01:02 | <mdz_> | great |
| 01:02 | <mdz_> | sound like the same bug I see? |
| 01:03 | <Chutt> | yup |
| 01:03 | <mdz_> | back in a bit |
| 01:03 | <Chutt> | i'll have a fix checked in shortly |
| 01:05 | <Chutt> | fixed |
| 01:37 | <blahblechblam> | Everything is configured now. The channels are loaded and the program listings are loaded. Now I get a lime green screen when running mythtv |
| 01:38 | <blahblechblam> | On any channel. |
| 01:41 | <lichen_> | i was just watching tivo |
| 01:41 | <lichen_> | its so smooth and nice :( |
| 02:06 | <blahblechblam> | I get a lot of these errors "VIDIOCMCAPTURE1: Invalid argument" |
| 03:29 | -!- | witten_ [] has quit [Ping timeout: 14400 seconds] |
| 05:36 | -!- | nevertheless [~chris@pD9E09F10.dip.t-dialin.net] has joined #mythtv |
| 07:09 | <-- blahblechblam | (~jason@rdu26-48-218.nc.rr.com) has left #mythtv |
| 09:18 | -!- | Universe [] has quit [Read error: 104 (Connection reset by peer)] |
| 10:32 | -!- | sefudier [] has quit ["Leaving"] |
| 11:31 | -!- | nevertheless [] has quit [Remote closed the connection] |
| 11:55 | -!- | nevertheless [~chris@pD9E09F10.dip.t-dialin.net] has joined #mythtv |
| 12:40 | -!- | nevertheless [] has quit [Remote closed the connection] |
| 12:47 | -!- | nevertheless [~chris@pD9E09F10.dip.t-dialin.net] has joined #mythtv |
| 13:10 | -!- | hadees [~blah@pcp01500931pcs.univde01.de.comcast.net] has joined #mythtv |
| 13:15 | -!- | nevertheless [] has quit [Remote closed the connection] |
| 13:23 | -!- | nevertheless [~chris@pD9E09F10.dip.t-dialin.net] has joined #mythtv |
| 13:34 | <mdz_> | Chutt: around? |
| 13:34 | <Chutt> | yup |
| 13:34 | <mdz_> | I'm trying to work out when it should load the recording parameters from the db |
| 13:35 | <Chutt> | meaning, either in the tv class, or in the frontend? |
| 13:35 | <mdz_> | which method of programinfo, actually |
| 13:35 | <mdz_> | getprogramrecordingstatus? |
| 13:36 | <mdz_> | or applyrecordstatechange? |
| 13:36 | <Chutt> | not there |
| 13:36 | <Chutt> | or there =) |
| 13:36 | <mdz_> | by the way, what does query.exec(foo) do when query is a newly initialized QSqlQuery? |
| 13:36 | <mdz_> | where does it get a database connection from? |
| 13:36 | <mdz_> | magic? |
| 13:36 | <Chutt> | if it doesn't specify a database connection, it uses the default connection |
| 13:37 | <mdz_> | global? |
| 13:37 | <Chutt> | yeah |
| 13:37 | <mdz_> | funky |
| 13:37 | <Chutt> | static variable in the query object |
| 13:37 | <mdz_> | I already have TV loading the parameters based on a profile id |
| 13:37 | <mdz_> | I just need to figure where to load the profile id for a particular recording |
| 13:38 | <Chutt> | hrm |
| 13:38 | <mdz_> | (which I added as a column on each recording table) |
| 13:38 | <Chutt> | so you added a recordingoptions table |
| 13:38 | <Chutt> | to each recording table |
| 13:38 | <hadees> | anyone working on a news/stock/whatever ticker? |
| 13:38 | <Chutt> | hadees, no. |
| 13:38 | <mdz_> | no, I added a recordingprofile column to each recording table |
| 13:38 | <Chutt> | mdz, can you do a quick diff? |
| 13:38 | <mdz_> | which references a recordingprofile table |
| 13:38 | <mdz_> | sure |
| 13:39 | <hadees> | any reason or just cause no one wants too? |
| 13:39 | <Chutt> | hadees, i don't particularly want to |
| 13:39 | <Chutt> | if someone else does, i don't know |
| 13:39 | <mdz_> | sent |
| 13:40 | <hadees> | hehe, just wondering, i think i might give it a crack |
| 13:40 | <mdz_> | hadees: why would you want that to be part of mythtv? |
| 13:40 | <hadees> | why not? |
| 13:40 | <mdz_> | there are already plenty of those sorts of programs which could be run next to mythtv |
| 13:41 | <hadees> | i want it so it looks like it does on like msnbc |
| 13:41 | <hadees> | where its ontop of the image as you watch tv |
| 13:41 | <hadees> | i like to keep up to date with news |
| 13:41 | <mdz_> | so put a KDE kicker or GNOME panel on top of mythtv |
| 13:42 | <Chutt> | mdz, so, hm |
| 13:43 | <hadees> | i guess that would work |
| 13:43 | <hadees> | just thought it would be nice |
| 13:43 | <Chutt> | mdz, what'd i would do is create a 'default' encoding quality |
| 13:44 | <hadees> | from the standpoint of having a machine that only does mythtv so you install just mythtv and nothing else |
| 13:44 | <Chutt> | check if the programinfo has a profile set or not |
| 13:44 | <Chutt> | and fall back to that |
| 13:44 | <mdz_> | I thought we talked about this and agreed that the defaults should just be a profile |
| 13:44 | <Chutt> | in the tv class |
| 13:44 | <Chutt> | right |
| 13:44 | <Chutt> | so it is just a profile |
| 13:45 | <mdz_> | are you saying that the profile in the recording should be able to be null? |
| 13:45 | <mdz_> | and then we load the default profile? |
| 13:45 | <Chutt> | yeah |
| 13:45 | <mdz_> | I was thinking profile would just default to the id of the default profile |
| 13:45 | <mdz_> | and when converting the db, just set them all to that |
| 13:45 | <mdz_> | or make it always id 0 |
| 13:45 | <Chutt> | that works too |
| 13:46 | <Chutt> | as for setting the profile id otherwise |
| 13:46 | <Chutt> | that's your question? |
| 13:47 | <Chutt> | probably just add a helper function to the programinfo class |
| 13:47 | <mdz_> | my question was about loading the actual profile column |
| 13:47 | <Chutt> | ah, hm |
| 13:47 | <Chutt> | well |
| 13:47 | <mdz_> | it seems like it would belong in getprogramrecordingstatus except that is returning a value |
| 13:47 | <Chutt> | in the scheduler |
| 13:48 | <Chutt> | getprogramrecordingstatus is only used in the epg, i believe |
| 13:48 | <mdz_> | which you are apparently using in the epg |
| 13:48 | <Chutt> | the scheduler does all the loading of data into programinfo classes that actually get used for recording |
| 13:49 | <mdz_> | hmm, the scheduler is part of the frontend, yes? |
| 13:49 | <Chutt> | right |
| 13:49 | <mdz_> | this seems like it belongs in the lib |
| 13:49 | <Chutt> | soon to be part of the backend |
| 13:49 | <mdz_> | oh |
| 13:50 | <mdz_> | ah, I see it in scheduler now |
| 13:51 | <Chutt> | sorry for not understanding your question right off =) |
| 13:51 | <Chutt> | bbiab, though |
| 13:51 | <mdz_> | fillercordlists only handles timeslotrecording |
| 13:51 | <mdz_> | oh, no it doesn't.ok |
| 14:11 | -!- | nevertheless [] has quit [Remote closed the connection] |
| 14:18 | -!- | nevertheless [~chris@pD9E09F10.dip.t-dialin.net] has joined #mythtv |
| 16:08 | -!- | witten [~witten@adsl-gte-la-216-86-199-140.mminternet.com] has joined #mythtv |
| 16:38 | -!- | jason_ [~jason@rdu26-48-218.nc.rr.com] has joined #mythtv |
| 16:41 | <Chutt> | nevertheless, are you here? |
| 16:41 | <nevertheless> | jepp |
| 16:41 | <Chutt> | can you change something with that shutdown patch? |
| 16:41 | <nevertheless> | sure |
| 16:41 | <Chutt> | i'd rather have the shutdown logic in the mythfrontend's main.cpp, not themedmenu.cpp |
| 16:42 | <nevertheless> | hmm, ok, ill have a look |
| 16:42 | <Chutt> | just the stuff that does the dialog |
| 16:43 | <Chutt> | should be a fairly simple modification |
| 16:43 | <Chutt> | other than that, looks goo |
| 16:43 | <nevertheless> | ok, how is it about the 3 lines making a new scheduler? is there a way to get rid of em? |
| 16:44 | <Chutt> | ah, not really |
| 16:44 | <nevertheless> | ok, i just thought its silly to make a new one at the end of the program, but it is quite fast though |
| 16:44 | <Chutt> | yeah, it shouldn't be that big of a deal |
| 16:46 | <Chutt> | it _is_ kinda silly, but that's the way it works =) |
| 16:46 | <jason_> | Hi. I'm getting a bright green screen when I start MythTV on Redhat 8.0. Any suggestions? |
| 16:47 | <nevertheless> | its a year ago that i worked with pthreads so I do not remember in detail how the interaction could be between the treads, but I remember this beeing complicated |
| 16:47 | <mdz_> | Chutt: I've got the profile stuff working |
| 16:47 | <mdz_> | Chutt: no way to change it from the UI, though...what are your thoughts on that? |
| 16:47 | <Chutt> | jason, any error messages? |
| 16:47 | <Chutt> | mdz, cool |
| 16:48 | <Chutt> | mdz, not sure, exactly |
| 16:48 | <mdz_> | I wrote a little migration program to take the old settings and stuff them into the database as a default profile |
| 16:48 | <Chutt> | i'm thinking the fix recording conflicts screen could do it |
| 16:48 | <mdz_> | and do the alter tables |
| 16:48 | <Chutt> | neat |
| 16:48 | <Chutt> | have like a radio button on top 'fix conflicts' 'edit record settings' |
| 16:49 | <Chutt> | left/right arrow change that, up/down change programs as currently |
| 16:49 | <mdz_> | what about letting the user select a profile when selecting a program to record? |
| 16:49 | <Chutt> | how would you add that with the current interface? |
| 16:49 | <jason_> | I'm getting errors like: "VIDIOCMCAPTURE1: Invalid argument" |
| 16:50 | <Chutt> | jason, capture card? |
| 16:50 | <jason_> | All-in-Wonder Rage 128 |
| 16:50 | <Chutt> | it's unsupported. |
| 16:50 | <mdz_> | Chutt: dunno, would it require extending DialogBox? |
| 16:50 | <jason_> | damn |
| 16:50 | <jason_> | I should buy a Hauppage WinTV then? |
| 16:51 | <Chutt> | mdz, not thinking of implementation, but just the ui |
| 16:51 | <mdz_> | Chutt: ah |
| 16:51 | <Chutt> | how it'd work |
| 16:51 | <mdz_> | Chutt: I was thinking a radio button for the profile, and then a button (as it is now) for each type of recording |
| 16:51 | <Chutt> | it's not a button now =) |
| 16:51 | <mdz_> | sure looks like a button :-) |
| 16:51 | <Chutt> | that's a select box |
| 16:51 | <Chutt> | list box |
| 16:51 | <Chutt> | whatever |
| 16:52 | <Chutt> | most often, though, people will use the default settings, right? |
| 16:52 | <Chutt> | and you could probably come up with a bunch of different profiles |
| 16:52 | <mdz_> | I guess so |
| 16:52 | <Chutt> | so you'd need to present them in a list |
| 16:52 | <mdz_> | it also occurred to me that this makes it easy to have different settings for live TV vs. scheduled recording |
| 16:53 | <Chutt> | two lists on one page doesn't quite work |
| 16:53 | <mdz_> | trivial even |
| 16:53 | <Chutt> | yup |
| 16:53 | <Chutt> | so if it were on the same page as the select recordings box, you'd need to click through 2 pages to select a recording |
| 16:53 | <mdz_> | is Markie's configuration stuff ready? we'll need a UI for configuring the profiles too |
| 16:53 | <Chutt> | heh |
| 16:53 | <mdz_> | brb |
| 16:53 | <Chutt> | no |
| 16:53 | <Chutt> | i had to rewrite most of what he sent in |
| 16:54 | <Chutt> | the framework's there, though |
| 16:55 | <Chutt> | to add in more config modules |
| 16:55 | <Chutt> | well, not modules, but dialogs |
| 17:13 | <nevertheless> | Chutt: hmmm, ok, i checked it now, but I have no idea how to accomplish your request. how would i move the stuff to the main.cpp? |
| 17:29 | <nevertheless> | well, i have a solution now |
| 17:29 | <nevertheless> | which i don't relly like |
| 18:04 | <witten> | I've got my mythtv HTPC all spec'd out |
| 18:04 | <witten> | but I was curious.. what kinda cpu power is needed for realtime tv watching with mythtv at 352x240? |
| 18:05 | <nevertheless> | my tbird 800 runs at about 30-60 % cpu |
| 18:05 | <nevertheless> | at 384x288 |
| 18:05 | <witten> | wow cool |
| 18:05 | <witten> | IDE harddrive? |
| 18:05 | <nevertheless> | jepp |
| 18:06 | <nevertheless> | ide with UDMA 66 |
| 18:06 | <nevertheless> | hdparm tells 45MByte/sec |
| 18:06 | <witten> | nice |
| 18:07 | <witten> | well I think I've got to tone down these specs a bit then |
| 18:07 | <nevertheless> | ill go for a XP 2000+, so i have a little space left |
| 18:08 | <witten> | those are like $90 |
| 18:09 | <witten> | a 1.1 ghz tbird is $34 |
| 18:09 | <nevertheless> | i don't get tbirds anymor here in germany |
| 18:09 | <witten> | how about durons? |
| 18:10 | <nevertheless> | uah |
| 18:10 | <witten> | uah? |
| 18:10 | <nevertheless> | i don't run a duron on a system which only lives from cpu power |
| 18:11 | <nevertheless> | there you could take the C3 too, this is bad stuff |
| 18:11 | <witten> | hehe true |
| 18:13 | <witten> | anyone willing to sell me a home-brew infrared receiver? |
| 18:18 | <Markie> | witten: heh |
| 18:18 | <Markie> | mdz: yea chutt fixed all my crap.. |
| 18:19 | <Markie> | i bet he cant wait for my next set of changes :^) |
| 18:35 | <mdz_> | Chutt: what do we do about getting the default profile set up on a new installation (not upgrade)? |
| 18:36 | <mdz_> | Chutt: add it in mc.sql? |
| 18:42 | <Chutt> | mdz, sure |
| 18:42 | <Chutt> | if it can be added there |
| 18:45 | <mdz_> | Chutt: mailed you the latest diff, displays the profile name in the conflicts screen |
| 18:49 | <Chutt> | ok |
| 18:57 | <Chutt> | all looks good |
| 19:26 | <mdz_> | I don't really want to check this in until there is a way for the settings to be changed, though |
| 19:27 | <mdz_> | otherwise that functionality is lost |
| 19:28 | <mdz_> | where is the new setup stuff? |
| 19:29 | -!- | hadees [] has quit [Read error: 110 (Connection timed out)] |
| 19:30 | <mdz_> | I see the menu XML, but nothing attached to it |
| 19:43 | -!- | pml [~pml@cdm-66-53-31-laft.cox-internet.com] has joined #mythtv |
| 19:50 | -!- | pml [] has quit [Remote closed the connection] |
| 19:58 | <Chutt> | nothing is yet |
| 19:59 | <Chutt> | except for the theme switching |
| 19:59 | <Chutt> | and that doesn't get saved at all |
| 19:59 | <nevertheless> | asf |
| 19:59 | <nevertheless> | arg |
| 20:02 | <mdz_> | grr, I just got a crash during playback |
| 20:02 | <mdz_> | slice end not reached but screenspace end (6 left EC3BEF) |
| 20:02 | <mdz_> | concealing errors |
| 20:02 | <mdz_> | Bus error |
| 20:03 | <Chutt> | that'd be in libavcodec somewhere |
| 20:03 | <mdz_> | yep |
| 20:03 | <Chutt> | reproducible at all? |
| 20:04 | <mdz_> | trying it now with debug |
| 20:04 | -!- | jason_ [] has quit ["Client Exiting"] |
| 20:05 | <mdz_> | seeking isn't working right for me all the time |
| 20:05 | <mdz_> | if I seek twice in quick succession, it doesn't start playing again |
| 20:06 | <mdz_> | and if I seek while it is in that state, it only advances 1 second |
| 20:06 | <mdz_> | it's especially apparent when it's under gdb and built slow for debugging |
| 20:08 | <Chutt> | ah |
| 20:08 | <Chutt> | well |
| 20:08 | <Chutt> | you can't seek again until it's done now |
| 20:09 | <mdz_> | that wouldn't be a problem except that seeking seems to take a long time |
| 20:09 | <mdz_> | I'll look at that when I've tried to reproduce this crash |
| 20:12 | <mdz_> | hmm, didn't happen for me at the same point in the recording |
| 20:12 | <mdz_> | I did get these, though |
| 20:12 | <mdz_> | 1. marker bit missing in 3. esc |
| 20:12 | <mdz_> | Error at MB: 106 |
| 20:12 | <mdz_> | concealing errors |
| 20:12 | <mdz_> | I don't _think_ the file is corrupted |
| 20:13 | <Chutt> | heh |
| 20:13 | <Chutt> | no idea, unfortunately :( |
| 20:14 | <mdz_> | hmm, it's saying it has an invalid seektable |
| 20:14 | <mdz_> | that would explain the poor seeking behaviour |
| 20:15 | <Chutt> | heh |
| 20:15 | <Chutt> | which error? |
| 20:15 | <Chutt> | maybe something killed the recording before it could be written completely? |
| 20:15 | <Chutt> | i've had a few reports of seektables not getting written |
| 20:15 | <Chutt> | but from noone who was able to debug things at all |
| 20:16 | <mdz_> | the file is pretty close to the right size |
| 20:16 | <mdz_> | haven't watched it all the way through yet |
| 20:17 | <mdz_> | looking at the end of the file, it sure looks like there's a seektable there |
| 20:17 | <mdz_> | bunch of Q frames |
| 20:17 | <Chutt> | maybe the offset's wrong? |
| 20:17 | <Chutt> | bunch? |
| 20:18 | <mdz_> | hmm, there's supposed to be one |
| 20:18 | <Chutt> | right |
| 20:18 | <mdz_> | I can't tell if they're valid frames, of course, just looking at a dump |
| 20:18 | <Chutt> | right |
| 20:19 | <mdz_> | I can't reproduce that error from libavcodec though |
| 20:20 | <mdz_> | playing over the same spot where it happened |
| 20:21 | <mdz_> | position saving doesn't seem to be working...does that only work with a seektable? |
| 20:21 | <Chutt> | right |
| 20:21 | <mdz_> | I don't see why it would... |
| 20:21 | <Chutt> | just faster to seek to the point |
| 20:22 | <mdz_> | so it doesn't even save the position if there is no seektable? |
| 20:22 | <Chutt> | right |
| 20:22 | <mdz_> | ok |
| 20:22 | <Chutt> | if you can figure out why its not seeing the seektable, that'd be great |
| 20:22 | <mdz_> | or if it really has a seektable |
| 20:23 | <Chutt> | right |
| 20:23 | <mdz_> | it looks like it probably doesn't |
| 20:24 | <mdz_> | (gdb) print extradata.seektable_offset |
| 20:24 | <mdz_> | $1 = 2150842253 |
| 20:24 | <Chutt> | does it actually say 'invalid seektable'? |
| 20:24 | <mdz_> | the file is 2150902721 bytes |
| 20:24 | <mdz_> | yes, it does |
| 20:25 | <mdz_> | that offset looks pretty reasonable to me |
| 20:25 | <Chutt> | ok, so that error says there's no Q at that offset |
| 20:25 | <mdz_> | right |
| 20:25 | <mdz_> | I'm going to find out what is there |
| 20:26 | <mdz_> | garbage |
| 20:26 | <Chutt> | is there a Q? |
| 20:26 | <Chutt> | well, anywhere near there |
| 20:26 | <mdz_> | $2 = {frametype = -1 'ÿ', comptype = -5 'û', keyframe = 120 'x', |
| 20:26 | <mdz_> | filters = 100 'd', timecode = -1007546624, packetlength = -385756380} |
| 20:26 | <mdz_> | looking |
| 20:27 | <mdz_> | there's no Q in the entire thing it thinks is the frame header |
| 20:27 | <Chutt> | heh |
| 20:27 | -!- | sefudier [~fabiano@RJ231231.user.veloxzone.com.br] has joined #mythtv |
| 20:28 | <mdz_> | hmm, actually there is a Q as the very next character in the file |
| 20:28 | <mdz_> | but not in the block that was read |
| 20:29 | <Chutt> | the very next character? |
| 20:29 | <Chutt> | after that frameheader? |
| 20:29 | <mdz_> | might be that character |
| 20:29 | <mdz_> | I used tail -c +<num> |
| 20:29 | <mdz_> | I think that counts from 1 |
| 20:30 | <mdz_> | mizar:[~] tail -c +2150842253 /space/video/mythtv/2126_20021117180500_20021117193000.nuv | od -A d -c |head -1 |
| 20:30 | <mdz_> | 0000000 213 Q \0 \0 \0 \0 \0 \0 \0 ( ì \0 \0 224 \t \0 |
| 20:30 | <mdz_> | so I think 213 is at offset ...52 and the Q at ...53 |
| 20:31 | <mdz_> | I think I know what it is |
| 20:31 | <Chutt> | hm |
| 20:31 | <Chutt> | might it not be seeking far enough? |
| 20:31 | <mdz_> | there are no LFS flags on the compiler command line |
| 20:31 | <Chutt> | _GNU_SOURCE defines all those |
| 20:31 | <mdz_> | are you sure? |
| 20:32 | <Chutt> | absolutely |
| 20:32 | <mdz_> | this flie is just over 2GB |
| 20:32 | <Chutt> | unless that's changed in the past few months |
| 20:32 | <mdz_> | and the stuff it's reading does not seem to be the stuff at the right offset, even though it tries to seek there |
| 20:32 | <mdz_> | how big is extradata.seektable_offset? |
| 20:32 | <Chutt> | long long |
| 20:33 | <mdz_> | yep |
| 20:33 | <mdz_> | hmm |
| 20:34 | <mdz_> | wtf |
| 20:36 | <Chutt> | i dunno |
| 20:36 | <Chutt> | maybe it's not redirecting lseek to lseek64 like it should be |
| 20:36 | <Chutt> | try renaming the function call in ringbuffer |
| 20:37 | <mdz_> | (gdb) print ringBuffer->Seek(0, 1) |
| 20:37 | <mdz_> | $9 = 1144 |
| 20:37 | <mdz_> | that's after it's supposed to have seeked to the seek_frameheader |
| 20:37 | <mdz_> | it never went anywhere |
| 20:37 | <mdz_> | does it check the return code on seek? |
| 20:37 | <Chutt> | naw |
| 20:38 | <Chutt> | go into ringbuffer.cpp and change all lseek calls to lseek64 |
| 20:38 | <Chutt> | see if that helps |
| 20:39 | <mdz_> | trying |
| 20:39 | <mdz_> | some thing |
| 20:40 | <mdz_> | same |
| 20:40 | <Chutt> | you changed all lseeks? |
| 20:40 | <Chutt> | sure you ran that binary? =) |
| 20:40 | <mdz_> | `/usr/bin/mythfrontend' has changed; re-reading symbols. |
| 20:40 | <mdz_> | it was different than the one I ran before at least |
| 20:41 | <Chutt> | there's 4 lseeks |
| 20:41 | <Chutt> | the 3rd one is the important one |
| 20:41 | <mdz_> | I changed all 4 |
| 20:41 | <mdz_> | aw, crap |
| 20:41 | <mdz_> | :-) |
| 20:41 | <mdz_> | I had two RingBuffer buffers open |
| 20:42 | <Chutt> | heh |
| 20:43 | <mdz_> | I did install the binary I built though :-P |
| 20:43 | <mdz_> | it just didn't have the change |
| 20:43 | <mdz_> | (gdb) print ringBuffer->Seek(0, 1) |
| 20:43 | <mdz_> | $1 = 2150842253 |
| 20:43 | <mdz_> | works now |
| 20:43 | <Chutt> | it should seek fast now, too |
| 20:44 | <Chutt> | and that explains the couple bug reports i've had |
| 20:44 | <mdz_> | g++ -c -pipe -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wall -W -g `freetype-config --cflags` -D_REENTRANT -D_GNU_SOURCE -DPREFIX=\"/usr\" -DEXTRA_LOCKING -DMMX -DQT_THREAD_SUPPORT -I/usr/include -I/usr/local/include -I.. -I/usr/share/qt/include -I/usr/share/qt/mkspecs/linux-g++ -o RingBuffer.o RingBuffer.cpp |
| 20:44 | <mdz_> | I really don't think that _GNU_SOURCE sets LFS |
| 20:44 | <Chutt> | since i compress down to < 2 GB / hour, and i never record more than an hour |
| 20:44 | <Chutt> | it does |
| 20:44 | <Chutt> | else you wouldn't be able to write files that large |
| 20:45 | <mdz_> | the doc says it does |
| 20:45 | <mdz_> | hmm |
| 20:45 | <yebyen> | Chutt: hey |
| 20:45 | <mdz_> | I dunno what's wrong then |
| 20:45 | <Chutt> | yo |
| 20:45 | <yebyen> | Chutt: you really haven't seen that codec not found error? |
| 20:45 | <Chutt> | it may not be defining whatever it needs to redirect lseek to the lseek64 call |
| 20:45 | <Chutt> | yebyen, right |
| 20:46 | <yebyen> | Chutt: it's not consistent, but some of the times when I let videos play all the way to the end I get it... |
| 20:46 | <Chutt> | never seen it |
| 20:46 | <yebyen> | Chutt: even with the debs now |
| 20:46 | <Chutt> | it's only at the end, though? |
| 20:46 | <Chutt> | that might help a bit.. |
| 20:46 | <mdz_> | that stuff is conditional on __USE_FILE_OFFSET64 |
| 20:46 | <yebyen> | Chutt: yeah, do you hit escape before stuff ends usually? |
| 20:46 | <mdz_> | in unistd.h, which includes features.h before any of that |
| 20:47 | <Chutt> | yebyen, no |
| 20:47 | -!- | nevertheless [] has quit ["Client Exiting"] |
| 20:47 | -!- | nevertheless [~chris@pD9E09F10.dip.t-dialin.net] has joined #mythtv |
| 20:47 | <yebyen> | Chutt: hm |
| 20:48 | <sefudier> | ahh.. finally, mythtv at descent. just installed it on a xp 2.0 box, the hdd is still old though (only 7MB/s).. |
| 20:49 | <yebyen> | xp 2.0 box? |
| 20:49 | <yebyen> | athlon xp? |
| 20:49 | <yebyen> | didn't know there was a 2.0 |
| 20:49 | <yebyen> | of course, i'm still running a Slot A 700mhz Classic Athlon |
| 20:49 | <sefudier> | works very good with the latest rls version at 640x480/mpeg4, using rtjpeg its not good.. whats the average MB/s required for rtjpeg? |
| 20:49 | <sefudier> | yebyen: yeah, there's even 2.8 now |
| 20:50 | <yebyen> | heh |
| 20:50 | <mdz_> | 2800 |
| 20:50 | <sefudier> | of course thats some major $$ |
| 20:50 | <yebyen> | OH |
| 20:50 | <yebyen> | 2.0ghz |
| 20:50 | <sefudier> | no.. 2000+ thing |
| 20:50 | <yebyen> | i thought like a revision 2.0 :) |
| 20:50 | <yebyen> | yeah |
| 20:50 | <sefudier> | their naming stuff |
| 20:50 | <mdz_> | Chutt: seek: Invalid argument |
| 20:50 | <Chutt> | what'd you do? |
| 20:51 | <mdz_> | just switched back to lseek and had it print the error |
| 20:51 | <Chutt> | ah |
| 20:51 | <Chutt> | ok |
| 20:51 | <Chutt> | so |
| 20:51 | <Chutt> | _GNU_SOURCE defines __USE_LARGEFILE64 |
| 20:51 | <Chutt> | but it does not define __USE_FILE_OFFSET64 |
| 20:51 | <Chutt> | meaning, it needs to use lseek64 manually |
| 20:52 | <mdz_> | ah, that makes sense |
| 20:52 | <yebyen> | Chutt: you need a slow-ass box to do testing on :) |
| 20:53 | <yebyen> | Chutt: I tend to think that it's the cause of most of my random little niggling problems |
| 20:53 | <mdz_> | I didn't think _GNU_SOURCE would change the size of off_t because that changes binary compatibility |
| 20:53 | <Chutt> | mdz, exactly |
| 20:53 | <Chutt> | yebyen, naw |
| 20:53 | <Chutt> | that'd be silly =) |
| 20:53 | <mdz_> | so we need -D_FILE_OFFSET_BITS=64 |
| 20:53 | <Chutt> | or |
| 20:53 | <Chutt> | i just use lseek64 =) |
| 20:54 | <yebyen> | Chutt: would it? :) could be bugs that only happen with dropped frames, which you'd almost never experience |
| 20:54 | <mdz_> | bah |
| 20:54 | <mdz_> | are you going to commit that then? |
| 20:54 | <Chutt> | yeah |
| 20:54 | <mdz_> | looks like it's only that file which uses lseek |
| 20:54 | <Chutt> | and jim's patch to fix the delete bug that he made |
| 20:55 | <yebyen> | Chutt: problems like there being a file that plays back strangely (no audio and it plays ultra-fast), or a file that causes mythtv to hang for a minute or so when I go over it in the browser |
| 20:55 | <Chutt> | and erik's patch to add the xawtv adding |
| 20:55 | <mdz_> | actually that's the only change to my RingBuffer right now, I can just commit it |
| 20:55 | <Chutt> | i've already got it in |
| 20:55 | <Chutt> | well, my tree |
| 20:55 | <yebyen> | Chutt: what's your plan on the next mythtv release? any major features going in? :) |
| 20:55 | <Chutt> | and going to commit in a sec |
| 20:55 | <mdz_> | ok |
| 20:56 | <mdz_> | let me know when you have, so I can finish watching my movie :-) |
| 20:56 | <Chutt> | yebyen, ability to have multiple boxes |
| 20:56 | <yebyen> | oh, like one for encoding and one for playing? |
| 20:56 | <yebyen> | elite |
| 20:57 | <Chutt> | as long as the encoding box has a tuner card :p |
| 20:57 | <yebyen> | uh, yeah :_ |
| 20:57 | <yebyen> | :) |
| 20:57 | <yebyen> | well what were you referring to? |
| 20:57 | <Chutt> | big beefy encoder box in my office |
| 20:57 | <yebyen> | HEH |
| 20:57 | <Chutt> | silent wimpy box out in the living room |
| 20:58 | <Chutt> | mdz, it's in there (tm) |
| 20:58 | <Chutt> | was that empty commit message from a few hours ago you adding a directory or something? |
| 20:58 | <yebyen> | Chutt: i'm thinking of upgrading my shit, so I can get it to go at 640x480 |
| 20:58 | <Chutt> | heh |
| 20:58 | <yebyen> | but I just ordered a wireless access point, so that's not happening right now |
| 20:58 | <mdz_> | Chutt: probably, I did add a directory |
| 20:58 | <Chutt> | yeah, that'd do it |
| 20:58 | <mdz_> | and I don't make empty commit messages :-) |
| 20:59 | <Chutt> | i should fix that script one of these days, but i'm lazy, and it's been broken like that for years |
| 20:59 | <mdz_> | I hate that CVS makes you add directories to do a proper diff |
| 20:59 | <Chutt> | oh, it was totally empty, no changed files or anything |
| 21:00 | <mdz_> | yay, no conflicts |
| 21:00 | <yebyen> | speaking of conflicts |
| 21:00 | <yebyen> | "You have time conflicts" |
| 21:01 | <yebyen> | isn't quantum leap on scifi channel anymore |
| 21:07 | <yebyen> | :( |
| 21:08 | <Chutt> | heh |
| 21:08 | <Chutt> | answering email |
| 21:08 | <Chutt> | some guy asks if i'm planning a windows version |
| 21:10 | <_shad> | Chutt: so when you have a box that will encode seperately, the cpu req's will go down a bit? |
| 21:11 | <Chutt> | no |
| 21:12 | <_shad> | how much cpu time does it take to just play back the video? |
| 21:14 | <Chutt> | depends on the video, of course |
| 21:16 | <_shad> | say I have a seperate box for encoding and playing, I can have a slightly slower box because i won't be playing and encoding at the same time, right? |
| 21:16 | <Chutt> | right |
| 21:16 | <_shad> | nice |
| 21:17 | <Chutt> | but, then you need two boxes |
| 21:17 | <_shad> | I have 9 computers here |
| 21:17 | <_shad> | all kinda crappy :) |
| 21:18 | <mdz_> | you'll still need one with a fairly fast CPU to do encoding |
| 21:18 | <_shad> | Ya |
| 21:18 | <mdz_> | depending on the quality you want |
| 21:18 | <_shad> | I'll use the p3-450 for encoding |
| 21:19 | <_shad> | and max out the quality on that |
| 21:19 | <mdz_> | won't take much :-) |
| 21:19 | <_shad> | then I'll use a p2-350 for playback |
| 21:19 | <_shad> | mdz: I know :) |
| 21:19 | <_shad> | but it's better than what it is right now |
| 21:20 | <_shad> | and it also means that I can put many computers around the house to watch tv with one cable line. :) |
| 21:20 | <_shad> | I even have enough puters to put on in the crapper. Hehe |
| 21:20 | <sefudier> | how's the current cvs? usable? any numbers on the performance improvement over the last release? |
| 21:20 | <Chutt> | current cvs is quite useable now |
| 21:20 | <Chutt> | it may not be for long |
| 21:21 | <Chutt> | so if you want to try it out, now's the time |
| 21:21 | <sefudier> | great :) |
| 21:22 | <mdz_> | Chutt: what are you going to break? |
| 21:22 | <Chutt> | well, not 'soon' |
| 21:22 | <Chutt> | but i'm thinking i'll be starting on the splitup next week |
| 21:24 | <mdz_> | illegal 3. esc, esc 2 encoding possible |
| 21:24 | <mdz_> | Error at MB: 295 |
| 21:24 | <mdz_> | concealing errors |
| 21:24 | <Chutt> | heh |
| 21:24 | <Chutt> | you got it back |
| 21:24 | <mdz_> | it seems to have successfully concealed the error this time |
| 21:24 | <mdz_> | (didn't crash) |
| 21:24 | <Chutt> | right |
| 21:25 | <mdz_> | completely different position |
| 21:25 | <mdz_> | and it didn't report an error at the previous position |
| 21:25 | <Chutt> | weird |
| 21:25 | <Chutt> | i wonder what it is |
| 21:25 | <mdz_> | so I don't think it's the stream |
| 21:25 | <Chutt> | right |
| 21:26 | <mdz_> | I wonder if we don't have this dr buffer stuff quite right yet |
| 21:26 | <Chutt> | it may not be =) |
| 21:26 | <mdz_> | I want to find at least one program which actually uses it |
| 21:27 | <mdz_> | I can't find anything besides mplayer though |
| 21:27 | <Chutt> | it was probably written for mplayer's use |
| 21:28 | <mdz_> | then you'd think the mplayer guys would know what to set dr_ip_buffer_count to |
| 21:28 | <Chutt> | heh |
| 21:28 | <Chutt> | riiight |
| 21:31 | <mdz_> | so about configuring the settings in the database...am I to understand that there really is no substantial code yet for the settings dialogs? |
| 21:31 | <Chutt> | right |
| 21:32 | <Chutt> | there's pretty much nothing |
| 21:32 | <mdz_> | well |
| 21:32 | <Chutt> | want to learn qt? |
| 21:32 | <mdz_> | heh |
| 21:32 | <mdz_> | doesn't look hard |
| 21:32 | <mdz_> | I probably already know enough Qt to do it |
| 21:32 | <mdz_> | but I'd rather not write something from scratch just to do the recording settings |
| 21:33 | <mdz_> | presumably we want some reusable stuff for various kinds of settings |
| 21:33 | <Chutt> | well |
| 21:33 | <Chutt> | i think the recording stuff is going to be pretty one-shot stuff, anyway |
| 21:33 | <Chutt> | since it's fairly different from all the other settings |
| 21:33 | <mdz_> | I had thought about defining the valid codec parameters in the db |
| 21:33 | <mdz_> | and using those to build config dialogs |
| 21:33 | <Chutt> | most of those are just on/off type things |
| 21:33 | <mdz_> | but that's a pain to deal with on upgrades |
| 21:34 | <Chutt> | the recording stuff is all values and the like |
| 21:34 | <mdz_> | right, all of the recording parameters are numeric currently |
| 21:34 | <mdz_> | except for the names of the codecs themselves |
| 21:34 | <Chutt> | yeah |
| 21:34 | <Chutt> | and, you'd have to do like 'edit profile' |
| 21:34 | <Chutt> | 'new profile' |
| 21:34 | <mdz_> | but most of them have valid ranges |
| 21:34 | <Chutt> | 'delete profile' |
| 21:35 | <mdz_> | isn't there a GUI design tool for Qt? what's it called? |
| 21:35 | <Chutt> | i've not used it |
| 21:35 | <mdz_> | maybe I'll lay out some stuff and see what it looks like |
| 21:35 | <mdz_> | I've used glade |
| 21:35 | <mdz_> | it's gotta be better than glade |
| 21:35 | <Chutt> | not a fan of design tools |
| 21:36 | <Chutt> | probably |
|
