| 00:08 | -!- | gtaylor [~gtaylor@picante.ne.client2.attbi.com] has joined #mythtv |
| 00:09 | -!- | gtaylor [] has quit [Client Quit] |
| 00:10 | <Chutt> | heh |
| 00:10 | <Chutt> | people join, people quit |
| 00:27 | -!- | gtaylor [~gtaylor@picante.ne.client2.attbi.com] has joined #mythtv |
| 00:27 | <gtaylor> | Isaac, still here? |
| 00:27 | <Chutt> | yeah |
| 00:27 | <Chutt> | hi |
| 00:28 | <gtaylor> | Chutt, obviously ;) |
| 00:28 | <Chutt> | yup |
| 00:28 | <gtaylor> | So I poked at the code, and got myself confuse dbetween chanid and channum etc; but then I guess it's working for you, so I dunno what gives... |
| 00:28 | <Chutt> | well |
| 00:28 | <Chutt> | what type of recording? |
| 00:28 | <gtaylor> | allrecord. |
| 00:29 | <Chutt> | yeah, do a cvs update |
| 00:29 | <Chutt> | that was broken until about a half hour ago |
| 00:29 | <gtaylor> | since two hours ago? |
| 00:29 | <gtaylor> | ah, ok, that's easy ;) |
| 00:29 | <Chutt> | it was trying to change channels to the category name |
| 00:29 | <Chutt> | didn't _quite_ work =) |
| 00:30 | <gtaylor> | ah-ha. might be good to check returns on some fo these, or easier in c++, throw stuff up ;) |
| 00:30 | <Chutt> | well |
| 00:30 | <Chutt> | it would've worked if i had finished the code, too |
| 00:30 | <gtaylor> | hehe ;) |
| 00:30 | <Chutt> | it's just like 90% done |
| 00:31 | <gtaylor> | OK, so that's cool;. I still wish I could figure out why my system seems so marginal performance-wise. VIA PCI can't be *that* much slower or they'd have had a recall. |
| 00:31 | <Chutt> | did you ever try increasing the pci latency of the tuner card? |
| 00:32 | <gtaylor> | No, I mainly fiddeld with the PCI bus itself. I recall the buffer thing you suggested, was that in a mail, too? |
| 00:32 | <Chutt> | yeah |
| 00:32 | <Chutt> | but if it's really jittering on the record side, that buffer change won't affect it |
| 00:33 | <Chutt> | i do use the 'latency=248' option to the bttv module when i modprobe it on startup |
| 00:34 | <Chutt> | had some problems earlier with the card not getting enough time on the bus, so frames were incomplete on capture |
| 00:34 | <gtaylor> | ok, I'll try that out. oddly, I can't find your original message about it, but whatever. |
| 00:35 | <Chutt> | it was just to increase the 'usepre' variable in the nuppelvideoplayer.cpp file from 2 to 8 or something like that |
| 00:35 | <gtaylor> | Yes, that message I've got. 'pick' just doesn't find anything else from you with the word latency. Must've deleted it by mistake or something. |
| 00:35 | <Chutt> | heh |
| 00:36 | <Chutt> | might've sent that to someone else off list or whatnot |
| 00:36 | <Chutt> | too many emails to keep track of |
| 00:36 | <gtaylor> | quite! so I'll set for 640x480@rtjpeg and see if I can't get smooth recording and playing with that. |
| 00:37 | <Chutt> | using mpeg4 might be smoother, too |
| 00:37 | <Chutt> | since the amount of compressed data is smaller |
| 00:37 | <Chutt> | so it's a bit lighter on transfers and stuff |
| 00:38 | <Chutt> | lemme know if allrecord is fixed or not, too =) |
| 00:38 | <Chutt> | i think it is, but i haven't actually recorded anything since i fixed it |
| 00:38 | <gtaylor> | mpeg4? always seems like that's a bit marginal on the cpu. what quality/rate settings do you use for it? |
| 00:38 | <gtaylor> | bttv reports no such parameter "latency" |
| 00:39 | <Chutt> | currently, 640x480, bitrate of 2800, max quality 2, min quality 15 |
| 00:39 | <Chutt> | what driver version? |
| 00:39 | <Chutt> | err, bitrate of 3300, rather |
| 00:39 | <Chutt> | 1.5GB/hour at that resolution |
| 00:41 | <gtaylor> | unclear, you'd think there would be a rcs string or something. it's stock from 2.4.18, i think, although somewhere i may have updated it in the confusion way back when. |
| 00:42 | <Chutt> | weird. |
| 00:42 | <gtaylor> | hmm. doe slarger bitrate and quality range make for more or less codec work? |
| 00:42 | <Chutt> | cpu's about the same as the default bitrate |
| 00:42 | <Chutt> | i'm not sure if the quality range changes much |
| 00:43 | <Chutt> | uses about 35-40% cpu to record only |
| 00:43 | <Chutt> | on my 1800+ |
| 00:43 | <gtaylor> | yearh, my bttv is stock 2.4.18. there's a "lat" variable in teh code, but this reads the pci latency out of the bttv config space. |
| 00:47 | <gtaylor> | there'sa "gbuffers" option for bttv, but nothing else that seems like it would have a performance implication |
| 00:48 | <gtaylor> | ...and mine is using "2" as opposed to 64 or however many it can do. I assume mythtv uses the mmapped mode? Maybe this would help. |
| 00:49 | <Chutt> | mythtv'll only use 2 buffers |
| 00:50 | <Chutt> | might help to make it do more, though |
| 00:51 | <gtaylor> | if it's a descriptor ring sort of affair, yes. we'll see. |
| 00:51 | <gtaylor> | what bttv version is yours wiht the latency argument? |
| 00:52 | <Chutt> | 0.7.96 |
| 00:53 | <gtaylor> | ah-ha, I have 0.7.97 sitting around but not being used. It looks much newer, perhaps there are other improvements, as well. |
| 01:01 | <gtaylor> | hmm. with all thoses settings, it's a smidge jittery just watching tv. and the sound cuts out from time to time. |
| 01:02 | <Chutt> | doh |
| 01:02 | <gtaylor> | 640x480 3300 picture sure is sharp, though, makes me wish it worked ;) |
| 01:03 | <gtaylor> | do you run a kernel with the low latency patches or anything like that/ |
| 01:03 | <Chutt> | nope |
| 01:03 | <Chutt> | i've been meaning to try em and all that, but just haven't gotten around to it |
| 01:04 | <gtaylor> | I guess I'll give that a whirl. If that fails, I'll toss my motherboard for something else. |
| 01:06 | <gtaylor> | oh, I was goign to try rotating cards around to diferent slots, too. |
| 01:06 | <Chutt> | is anything sharing irqs? |
| 01:07 | <gtaylor> | hmm. everything is on irq 11. |
| 01:08 | <Chutt> | i don't have anything sharing on my box |
| 01:09 | <Chutt> | oh, i should respond to your last email to the list and say that bug should be fixed =) |
| 01:09 | <gtaylor> | well, it's something to try. it's all going through screwy apic code anyway, but maybe. |
| 01:16 | <gtaylor> | so just plain recording with those settings is giving a load of 0.65ish. |
| 01:16 | <Chutt> | heh |
| 01:17 | <Chutt> | my system load when doing tv watching is 0.51 or so with those settings |
| 01:18 | <gtaylor> | curious. you said you'd run your memory fast or something? was it just CAS timing of 2 or command rate or what? |
| 01:19 | <Chutt> | cas 2, aggressive timing |
| 01:20 | <gtaylor> | hmm. I wonder if that's it; seems like lots of the codec and dma stuff would benefit from faster memory. |
| 01:20 | <Chutt> | that's about the only things i can modify, memory-wise, in the bios |
| 01:20 | <Chutt> | sharing irqs might be part of it as well |
| 01:20 | <Chutt> | since it has to figure out which device is belonging to each interrupt |
| 01:21 | <gtaylor> | yes, but that should be one reg read in teh irq controller. |
| 01:21 | <gtaylor> | i'll fiddle that and the mem timings and reboot and see what we see. |
| 01:36 | <gtaylor> | ok, i'm back |
| 01:36 | <gtaylor> | so I set cpu clock to 138 from 133 |
| 01:36 | <gtaylor> | tried but failed to set all the irq's by hand |
| 01:36 | <Chutt> | heh |
| 01:36 | <gtaylor> | and set the memory to cas 2 command rate 1t. |
| 01:37 | <Chutt> | same stuff? |
| 01:37 | <gtaylor> | and loaded the new bttv without latency arg |
| 01:37 | <gtaylor> | live tv 640x480@3300 is pretty smooth, no audio glitches. |
| 01:37 | <gtaylor> | so that's promising. |
| 01:37 | <Chutt> | cool |
| 01:37 | <gtaylor> | historically, watching one thing while recording another is "harder" |
| 01:37 | <Chutt> | really? |
| 01:37 | <gtaylor> | so we'll have to see after it records something |
| 01:38 | <Chutt> | it seems to be better on my box |
| 01:38 | <gtaylor> | yes, livetv tends to have stuff still buffered, whereas reading one thing and writing antoher tends not to |
| 01:38 | <gtaylor> | anyway, this is where my oversize heatsink+fan and the other four case fans had better pay off. |
| 01:39 | <gtaylor> | no way this memory is rated for cas 2/1t. |
| 01:39 | <Chutt> | hehe |
| 01:39 | <gtaylor> | I don't know if modern chipsets fire nmi or something else for ecc corrections; it would be nice to know. |
| 01:40 | <gtaylor> | (stupid ten-cent PC hardware. wouldn't have all these issues on a proper machine) |
| 01:40 | <Chutt> | heh |
| 01:41 | <Chutt> | and it's linux, too =) |
| 01:41 | <gtaylor> | yes, there's another grab-bag of poorly integrated flaming wild innocation ;) |
| 01:41 | <gtaylor> | innovation. |
| 01:42 | <gtaylor> | all right, I'm going to go and actually *watch* this thing for a while. |
| 01:42 | <gtaylor> | thanks for all your tips etc... |
| 01:42 | <Chutt> | heh |
| 01:42 | <Chutt> | sure thing |
| 01:42 | -!- | gtaylor [] has quit ["Leaving"] |
| 01:43 | -!- | gtaylor [~gtaylor@picante.ne.client2.attbi.com] has joined #mythtv |
| 01:44 | <Chutt> | heh |
| 01:44 | <gtaylor> | so what's the expected ratio of thread cpus? I've got 79% in one and 5-18% in a few others. |
| 01:45 | <Chutt> | 'bout right |
| 01:45 | <gtaylor> | seems like lvie tv would have one huge, one less huge, and a smattering. |
| 01:45 | <Chutt> | the biggy's the encoder |
| 01:45 | <Chutt> | next largest would be the decoding work |
| 01:45 | <gtaylor> | hmm. 75% cpu for just encoding? |
| 01:45 | <Chutt> | using top? |
| 01:45 | <gtaylor> | yes, top |
| 01:46 | <Chutt> | heh |
| 01:46 | <gtaylor> | is there much synchronization between threads, as in pthread-posix semaphores/mutexes/etc? |
| 01:46 | <Chutt> | mostly pthread read/write locks |
| 01:46 | <Chutt> | a few pthread mutexes |
| 01:46 | <gtaylor> | do they hit much? |
| 01:46 | <Chutt> | shouldn't |
| 01:46 | <Chutt> | i kept locking down to a minimum |
| 01:47 | <Chutt> | there _is_ a big lock if you're doing 2 encodes of mpeg4 at a time, though |
| 01:47 | <gtaylor> | good. linux threads are godawful hack. the locks use *signals* |
| 01:47 | <Chutt> | the encoder isn't quite threadsafe =) |
| 01:47 | <gtaylor> | ...to the *process group* no less... |
| 01:47 | <Chutt> | heh |
| 01:47 | <Chutt> | that should improve soon =) |
| 01:47 | <Chutt> | new pthreads lib in the pipeline |
| 01:48 | <gtaylor> | definetely avoid the "flock fo worker threads" pattern - we did something that way once at work and it was a disaster. |
| 01:48 | <gtaylor> | yes, there are a few competeing kernel-free semaphore implementations out there. |
| 01:48 | <Chutt> | no |
| 01:49 | <Chutt> | this one's by the glibc guys, so it's acutally going to replace the linuxthreads stuff |
| 01:49 | <Chutt> | actually |
| 01:49 | <Chutt> | heh |
| 01:49 | <gtaylor> | well, good luck to them. I'll just stay away from threads, thank you ;) |
| 01:49 | <Chutt> | it was part of the 'start a few hundred thousand threads in 2 seconds' update |
| 01:50 | <Chutt> | iirc |
| 01:50 | <gtaylor> | ah, yes, saw that mentioned somewhere. lots of effort in a bad direction. |
| 01:50 | <gtaylor> | a computer is a state machine. best to write code that way. |
| 01:51 | <Chutt> | ah, one of those anti-threads people =) |
| 01:51 | <gtaylor> | most of us in the networking industry are. |
| 01:52 | <gtaylor> | my box at work runs 500k ppp sessions at once. threads would jsut be laughable. |
| 01:52 | <Chutt> | heh |
| 01:53 | <gtaylor> | so 95% cpu use for live tv seems pretty marginal. I may try to overclock a bit more. |
| 01:53 | <Chutt> | how fast's the cpu at now? |
| 01:53 | <gtaylor> | 138MHz for a 1587MHz internal core; uses the normal 1800+XP multiplier and volts. |
| 01:54 | <Chutt> | right |
| 01:54 | <Chutt> | wonder why you're using so much more cpu than i am |
| 01:54 | <gtaylor> | dunno. this is the mystery. |
| 01:54 | <Chutt> | it tops out at 70% or so with those options |
| 01:55 | <gtaylor> | I'm using the nvidia -provided drivers, for agp and X, to an agp 4x slot. |
| 01:55 | <Chutt> | same |
| 01:56 | <gtaylor> | 95% user 4% system ... wonder how accurate "system" is. on mips it doesn't include bottom half (ie interrupt handlers, most driver stuff, etc) |
| 01:56 | <gtaylor> | does oprofile work on althons/ |
| 01:56 | <Chutt> | top's fairly inaccurate |
| 01:57 | <Chutt> | in general |
| 01:57 | <Chutt> | no idea on oprofile |
| 01:58 | <gtaylor> | this is something of a mystery. |
| 01:59 | <gtaylor> | you aren't running your cpu at 166 or something? |
| 01:59 | <Chutt> | nope |
| 01:59 | <Chutt> | have enough of a heat problem as it is =) |
| 01:59 | <gtaylor> | you have two different bttv cards, which do you normally use? |
| 01:59 | <Chutt> | the hauppauge card is the main one |
| 02:00 | <Chutt> | since it supports stereo |
| 02:00 | <gtaylor> | bt878, modern? |
| 02:00 | <Chutt> | yup |
| 02:00 | <Chutt> | wintv-radio |
| 02:00 | <Chutt> | hm |
| 02:00 | <Chutt> | you don't, by chance, have it compiled for debugging, do you? |
| 02:00 | <Chutt> | i turn that on sometimes and forget about it |
| 02:01 | <gtaylor> | only if that's on by default, where's the -g? |
| 02:01 | <Chutt> | in the settings.pro |
| 02:01 | <Chutt> | top level of the source |
| 02:01 | <gtaylor> | config += release, the debug one is #'d out. |
| 02:02 | <Chutt> | heh |
| 02:02 | <Chutt> | ok, one hypothesis shot down |
| 02:02 | <gtaylor> | ah, gcc 2.95 or 3.x? |
| 02:02 | <Chutt> | 2.95 |
| 02:02 | <Chutt> | debian hasn't switched to 3.2 yet |
| 02:03 | <Chutt> | if you're using 3.x, might try switching the -mpentiumpro to -mathlon-xp and adding some more of the newer optimization flags to that line in settings.pro |
| 02:03 | <gtaylor> | I've got 2.95. |
| 02:06 | <gtaylor> | would mtrr settings apply to the bttv? I have done nothing with those except note that the nv ones were magicalyl OK. |
| 02:07 | <Chutt> | i haven't touched mine at all |
| 02:12 | <gtaylor> | still looks smooth, at least in livetv mode. |
| 02:13 | <gtaylor> | audio 44100 quality 7? |
| 02:13 | <gtaylor> | and you did say 3300 bitrate for mpeg4? |
| 02:14 | <Chutt> | yeah |
| 02:14 | <Chutt> | but i'm recording at 32000 |
| 02:14 | <Chutt> | since i'm using the btaudio stuff |
| 02:14 | <gtaylor> | ah, i wonder if that's way more efficient? |
| 02:14 | <Chutt> | shouldn't be appreciably different |
| 02:15 | <gtaylor> | is it just a sound device on the bt card? |
| 02:15 | <Chutt> | yup |
| 02:15 | <Chutt> | transfers the audio over the pci bus |
| 02:15 | <gtaylor> | hmm. I guess the same as a pci audio card. |
| 02:15 | <Chutt> | no cable to the sound card |
| 02:15 | <gtaylor> | I thought the btaudio device didn't do stereo? |
| 02:15 | <Chutt> | so it's how i'm using two cards at once |
| 02:16 | <Chutt> | the digital dsp does stereo 32000, the analog one does mono 44100 |
| 02:16 | <Chutt> | iirc |
| 02:16 | <Chutt> | at least, i'm getting stereo passed through, my receiver thinks its prologic encoded |
| 02:17 | <gtaylor> | hmm. well, it's something to try. I'm using an ensoniq 1371 card, since the onboard via audio is noisy. always been a fine card, so I wouldn't have thought to suspect it. |
| 02:17 | <Chutt> | the 1371? yeah, good little card |
| 02:18 | <Chutt> | i have a box at work with 5 of em in it =) |
| 02:18 | <gtaylor> | but you don't have five ears |
| 02:19 | <Chutt> | was a real cheap way to get 10 channels of recording capability |
| 02:20 | <gtaylor> | hmm. should your mythfrontend binary be any different from mine? I could just run your binary and see fi that churns a lot |
| 02:20 | <Chutt> | it'll be different |
| 02:20 | <Chutt> | all those shared libs and stuff |
| 02:20 | <Chutt> | and the fact that i don't have a working binary at the moment =) |
| 02:21 | <Chutt> | i'm in the middle of adding a 4th recording option |
| 02:21 | <Chutt> | record all on a certain channel |
| 02:21 | <gtaylor> | 4th option? |
| 02:21 | <gtaylor> | oh, that would be handy. |
| 02:22 | <gtaylor> | what would also be nice would be "record this title once at some point" for cable movies. |
| 02:22 | <Chutt> | hrm |
| 02:22 | <Chutt> | i think something like that'll come along once i start doing more of the automated recording type stuff |
| 02:23 | <gtaylor> | did you ever have any further thoughts on the ffw/rew hanging bug of mine? has anyone else reported it? |
| 02:23 | <Chutt> | no one else has reported it, i can't reproduce it at all |
| 02:23 | <Chutt> | and i really don't know what else it might be |
| 02:23 | <Chutt> | oh, and i do mean to fix the ff off the end of an in-progress recording one of these days =) |
| 02:23 | <gtaylor> | weird, again. it was still present in recent cvs using lower bitrate mpeg4 and rtjpeg, but I haven't seen ti just now iht livetv at 3300. |
| 02:24 | <gtaylor> | i wonder if it's related to the rest of my mystery somehow? |
| 02:25 | <Chutt> | probably a race condition |
| 02:28 | <gtaylor> | is there much library code from my system (ie not avcodec) that executes in the coder path? |
| 02:28 | <Chutt> | not especially |
| 02:29 | <gtaylor> | are exceptions and rtti turned off or the c compilter used for the codec stuff? |
| 02:30 | <Chutt> | the c compiler's used for libavcodec |
| 02:30 | <Chutt> | exceptions and rtti are on for everything else |
| 02:30 | <Chutt> | i'm not sure what turning them off will do to qt |
| 02:32 | <gtaylor> | hmm. well, a few per frame in your nuppel code shouldn't hurt.. |
| 02:37 | <gtaylor> | does NuppleVideo::Initialize run as an early thing in the recording thread? I'd like to start profiling that thread there. |
| 02:37 | <Chutt> | lemme check |
| 02:38 | <Chutt> | actually |
| 02:39 | <gtaylor> | NuppleVideoRecorder::Initialize, I mean. |
| 02:39 | <Chutt> | it gets called before the encoder thread gets spawned |
| 02:39 | <Chutt> | so that might not be the best place to start =) |
| 02:39 | <gtaylor> | ah, where can I put something then? |
| 02:39 | <Chutt> | StartRecording would be where the main encoder thread starts |
| 02:39 | <Chutt> | but all the work is done in another child thread |
| 02:40 | <Chutt> | the main thread just grabs the buffers from the v4l device and copies em to an internal buffer |
| 02:40 | <Chutt> | heh |
| 02:40 | <gtaylor> | ther's an audio thread and a write thread started there, but doest the parent go on to encode? |
| 02:41 | <Chutt> | so compiling with -fno-rtti and -fno-exceptions drops the binary size by over 200KB |
| 02:41 | <Chutt> | the write thread does the actual encoding |
| 02:41 | <gtaylor> | ah. |
| 02:41 | <Chutt> | for both audio and video |
| 02:42 | <gtaylor> | no doubt. rtti won't kill you unless you use it, and exceptions have a per-c++ function overhead, so most of the codec stuff should be immune. |
| 02:42 | <Chutt> | right |
| 02:42 | <Chutt> | everything seems to run ok, so i'll just leave those options in |
| 02:42 | <Chutt> | i was just worried qt might not like it if i did that =) |
| 02:43 | <gtaylor> | does it make it any faster or slower? |
| 02:43 | <Chutt> | doesn't look like it |
| 02:53 | <Chutt> | allright |
| 02:53 | <Chutt> | that's done |
| 02:53 | <Chutt> | new recording option is now in cvs |
| 02:53 | <Chutt> | so, i'm off to bed =) |
| 03:02 | <gtaylor> | ok, bye. profile results in morning, with any luck at all. |
| 03:02 | -!- | gtaylor [] has quit ["Leaving"] |
| 05:50 | -!- | LinuxBTAudio [~LinuxBTAu@0x50c46ceb.arcnxx10.adsl-dhcp.tele.dk] has joined #MythTV |
| 05:51 | -!- | LinuxBTAudio is now known as JensLH |
| 05:51 | <JensLH> | Anyone alive? |
| 09:11 | <-- JensLH | (~LinuxBTAu@0x50c46ceb.arcnxx10.adsl-dhcp.tele.dk) has left #MythTV |
| 09:16 | <davehunn> | h odd thing |
| 09:16 | <davehunn> | the scheduler is not picking up the channel nuber and records everything on the sae channel not good :( |
| 09:17 | <davehunn> | cvs version as off first october |
| 11:19 | -!- | mdz [] has quit [Read error: 110 (Connection timed out)] |
| 11:59 | <Chutt> | davehunn, read the mailing list, perhaps? |
| 14:37 | -!- | davehunn [] has quit [Read error: 104 (Connection reset by peer)] |
| 14:39 | -!- | davehunn [~david@pc1-mars1-4-cust156.mid.cable.ntl.com] has joined #mythtv |
| 14:42 | <davehunn> | arg now i have done a cvs update it segfaults all the time (mythtv) the other bits are ok |
| 14:43 | <davehunn> | [New Thread 1026 (LWP 22975)][New Thread 1026 (LWP 22975)] |
| 14:43 | <davehunn> | Changing from None to WatchingLiveTV |
| 14:43 | <davehunn> | Program received signal SIGSEGV, Segmentation fault. |
| 14:43 | <davehunn> | [Switching to Thread 1026 (LWP 22975)][Switching to Thread 1026 (LWP 22975)] |
| 14:43 | <davehunn> | 0x4055eb72 in QString::deref () from /usr/lib/libqt-mt.so.3 |
| 14:44 | <Chutt> | make clean/edit settings.pro to enable debugging/rebuild |
| 14:44 | <Chutt> | will get you something useful |
| 14:48 | <Chutt> | but, i'm leavin for a bit =) |
| 14:54 | <davehunn> | ahh bolox it runs with debuggin enabled |
| 14:56 | <davehunn> | so to recap with no debbugging mythtv segfaults with debugging it runs fine |
| 14:57 | <davehunn> | g++ --version |
| 14:57 | <davehunn> | 2.95.4 |
| 14:57 | <davehunn> | 2x1.2 duron + 512 ddr ram haupage win tv nicam |
| 15:59 | <Chutt> | it probably was a dependency issue |
| 15:59 | <Chutt> | not compiling everything it needed to with the update |
| 15:59 | <Chutt> | blowing away things to recompile for debugging fixed it |
| 16:18 | <davehunn> | ah could be |
| 16:18 | <davehunn> | yes |
| 16:19 | <Chutt> | probably libmyth that did it |
| 16:19 | <davehunn> | ill try a make after a clean and see if it still works in a bit |
| 16:19 | <Chutt> | it's not very library-like yet, doesn't handle ABI changes at _all_ |
| 16:20 | <davehunn> | ok |
| 17:38 | <davehunn> | which file do i incude for int setGeometry ? |
| 17:40 | <Chutt> | qwidget.h? |
| 17:41 | <davehunn> | i a trying to nock together a little view so i can view a file as its being recorded |
| 17:42 | <davehunn> | but i get mythplay.cpp:69: implicit declaration of function `int setGeometry(...) |
| 17:44 | <davehunn> | and the same for setFixedSize and showFullScreen but i dont understand why as i have |
| 17:44 | <davehunn> | #include <qlayout.h> which has these functions in and i should be running with the same ake options as mythfrontend |
| 17:46 | <Chutt> | heh |
| 17:47 | <Chutt> | you do know if you go to 'watch tv' while a recording is going on, it'll ask if you want to watch the recording, right? |
| 17:47 | <davehunn> | no |
| 17:47 | <davehunn> | thats ok then i did not want to break the recording |
| 17:47 | <davehunn> | can i pause etc ? |
| 17:47 | <Chutt> | yup |
| 17:48 | <Chutt> | only thing is you can ff off the end of the recording |
| 17:48 | <Chutt> | and it'll just exit playback |
| 17:48 | <davehunn> | hmm |
| 17:48 | <davehunn> | no can ff of the end |
| 17:48 | <davehunn> | but it didnt start at the beging of the file |
| 17:48 | <Chutt> | as for the undefined things, you're probably not calling it from a child of qwidget or whatnot |
| 17:49 | <davehunn> | oh ok |
| 17:49 | <davehunn> | ill have a look at that in a bit |
| 17:50 | <davehunn> | i was going to use the player as a starting to to write a conversion uil to convert to saller avi ~ 50 eg/half hour |
| 17:54 | <Chutt> | there's half written re-encoding stuff in the nuppelvideoplayer class |
| 17:54 | <Chutt> | but |
| 17:54 | <Chutt> | it still uses the internal format |
| 17:54 | <Chutt> | could be a starting point, though |
