openpvr-devel Mailing List for OpenPVR (Page 2)
Brought to you by:
brian_j_murrell,
jfunk
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(2) |
Feb
|
Mar
(28) |
Apr
(22) |
May
|
Jun
(19) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
(7) |
Dec
|
2003 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
2004 |
Jan
(4) |
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alan M. <si...@ya...> - 2003-03-30 23:36:29
|
Hello, Well, I have "schedule" working now, though I am using my own "record" script (which uses 'at' to schedule the recordings) because I use mencoder, which records the show into DivX already. Actually, I am looking into using 'mp1e' as well, but am running to some build errors that hopefully their mailing list can help me with. :-) I have to admit I like the idea of a (decent) one hour recording only taking up ~600MB of space though :-) In the meantime, I do have a querstion regarding the output "schedule" gives, specifically with reggards to the "seenput" commands. A sample output from my run of "schedule" looks like this: at 22:00 05.04.03 <<EOF /usr/local/openpvr/record --device 0 --end "epoch 1049612399" --channel "11 CHAN" 'Andromeda: Angel Dark, Demon Bright'; /usr/local/openpvr/seenput 'Andromeda' 'Angel Dark, Demon Bright'; EOF /usr/local/openpvr/seenput 'Andromeda' 'Angel Dark, Demon Bright' 1049608800 3600 '11 CHAN' 0 I know it give the command to cut-and-paste, and I understand that the /usr/local/openpvr/seenput 'Andromeda' 'Angel Dark, Demon Bright' puts the entry into the 'seen.db' file so that it isn;t scheduled on a subsequent run of 'schedule' (looks like this is done at the same time the 'at' recording command is done??) However, I am a little puzzled by the /usr/local/openpvr/seenput 'Andromeda' 'Angel Dark, Demon Bright' 1049608800 3600 '11 CHAN' 0 Is this putting the entry into the 'seen.db' file again? If so, is there a reason for this, since it was already put in there by the first 'seenput' command? TIA for your help. Alan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
From: Alan M. <si...@ya...> - 2003-03-25 23:01:22
|
--- "Brian J. Murrell" <a5d...@in...> wrote: > There is a fix in CVS to correct this problem. Okay, I will try grabbing the latest and greatest from CVS, and report back if the problem still persists. Thank you. Alan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
From: Brian J. M. <a5d...@in...> - 2003-03-25 15:49:26
|
On Tue, Mar 25, 2003 at 10:24:21AM -0500, Alan Murrell wrote: > Hello, Hi. > I downloaded 7 days' worth of TV data using XMLTV, > then ran the 'tv_sort' (from XMLTV) utility on the > data to add the "Stop" times. Good. > However, when I run the 'schedule' program, I get the > following error: >=20 > Segmentation fault (core dumped) This is because schedule depends on stop times being present, even though the XMLTV DTD does not specify them as being required. It is difficult to schedule recordings without knowing the stop time/duration of a program. > I did run it again using strace, and the output is > available here: >=20 > <http://members.zoolink.com/alan/schedule.strace.txt> Strace output is usually quite useless when trying to diagnose a segfault. There is a fix in CVS to correct this problem. It still requires that you run the xmltv output through tv_sort to fix up stop times of all but the last programs on a given channel. Those last programs (one per channel) will be dropped by schedule. This should not really be a problem as it is one program that is dropped, the one at the end of your 7 day schedule. b. --=20 Brian J. Murrell |
From: Alan M. <si...@ya...> - 2003-03-25 15:24:28
|
Hello, I downloaded 7 days' worth of TV data using XMLTV, then ran the 'tv_sort' (from XMLTV) utility on the data to add the "Stop" times. However, when I run the 'schedule' program, I get the following error: Segmentation fault (core dumped) I did run it again using strace, and the output is available here: <http://members.zoolink.com/alan/schedule.strace.txt> I did have a look at the output, but was unable to make too much sense of it, other than it appeared to be doing what it was supposed to (reading 'wanted_programs.xml.gz', etc.) TIA, Alan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
From: Brian J. M. <5b6...@in...> - 2003-02-20 06:28:24
|
To answer the subject line -- nope. Not yet. On Wed, Feb 19, 2003 at 10:06:24PM -0800, Robert Kulagowski wrote: > Looks liks last commit was 3 months ago, and last message was Nov-2002. >=20 > Did someone turn out the lights, ~looking around~ Lights are still on here. The lack of commits just means stability and happiness. :-) Seriously though, I have been using the code that in CVS (the scheduler) and my hacked up GTK GUI (just a simple pick list-> mplayer launcher) for over a year now. It does everything I want it to (or mostly -- as time for new features is limited). I probably have some outstanding code I need to commit, but it's nothing major. I have been looking at the Freevo project, and do have it functioning on DirectFB with the G400 CRTC2 support. I kinda like Freevo, but it has some usability issues for me currently. The main problem is the poll based event loop rather than an interrupt driven one. This causes the IR and UI to be too sluggish for my likes. There are also some missing UI features that I need before I can start using it like password protected folders and a menu supporting the display and viewing of recorded televsion programs properly. The "Movies" menu item is just not suitable. The sort is wrong, it does not display dates, and does not query about file deletion after playing. If I were a Python hacker (I am learning currently) and had a little more time to fully understand the Freevo code I would solve these problems myself, but I don't have the skills (yet) or the time currently. Once I do get proficient in Python, I will probably try porting the schduler and recording tools over to Python and see how well they perform (the scheduler can be quite compute intensive in the case of lots of conflicts) so Freevo can have a good conflict resolving scheduler and recording tools. But until then... > or has everyone moved to MythTV or Freevo? That could happen and the openpvr tools could get folded into Freevo (or maybe MythTV -- I have not looked at it in some time) but not yet. b. --=20 Brian J. Murrell |
From: Robert K. <rku...@ro...> - 2003-02-20 06:06:24
|
Looks liks last commit was 3 months ago, and last message was Nov-2002. Did someone turn out the lights, or has everyone moved to MythTV or Freevo? __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Alan M. <si...@ya...> - 2002-11-07 16:51:11
|
--- Jerry Veldhuis <je...@ma...> wrote: > nice board...what no mpeg4 encoder ? :) Not yet. I think the 1GhZ version has an MPEG-2 *decoder* though. Give it time. :-) Actually, I was looking at some benchmarks, and as far as MP3 and DivX encoding, it doesn't seem compare very well (time-wise) with "lesser" CPUs. In all honesty, the CPU *is8 rated lower than thier AMD/Intel counterparts (i.e., a 1GHz AMD or Intel CPU is faster than the 1GHz 'C3' CPU these mobo use); but that's apparently because they are built for quietness :-) I'm reading a PC Labs review of the 800MHz mobo they put together for using as a "multimedia box". > putting <> around the url and they'll deal with the > line-wrap problem :) Well, the reason I wasn't sure about the line-wrap was because I use Yahoo! for my mailing list mail, and the URL wrapped in the little box where I compose the mail, so I wasn't sure if it would retain the line wrapping or not; I just wanted to make sure I made the reader aware :-) ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
From: Alan M. <si...@ya...> - 2002-11-07 16:24:14
|
Hello there! Saw this link on another mailing list I am on, and thought I'd share. Looks pretty darn good! (But then, I'm easily impressed <grin>): ----- http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ----- (Sorry if the above wraps; it may be necessary to cut-and-paste the URL together <grin>) ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
From: Brian J. M. <447...@in...> - 2002-11-03 11:10:13
|
On Sun, Nov 03, 2002 at 02:39:02AM -0500, Alan Murrell wrote: > Hello, Again. Hi. > 1. Are the data files that 'schedule' is looking for > still 'tv_data.xml.gz' and 'wanted_programs.xml.gz'?=20 Yes. From the source of schedule.c: doc =3D xmlParseFile("/tmp/tv_data.xml.gz"); if (doc =3D=3D NULL) exit(1); and doc =3D xmlParseFile("/tmp/wanted_programs.xml.gz"); if (doc =3D=3D NULL) exit(1); > 2. Am I correct in assuming that these files > (whatever they are to be called), as well as the "seen > database" should *all* reside in the SEENDB_PATH? Nope. Still /tmp. This is all due to a lack of build-time configuration like autoconf. I really should get around to putting that sucker in. > Again, TIA. I just wanted to see how much things have > changed since the posting on April 17 of this year > regarding how these programs all work now. Well, there have been changes, that is for sure, but should not be anything too drastic. b. --=20 Brian J. Murrell |
From: Alan M. <si...@ya...> - 2002-11-03 07:39:07
|
Hello, Again. Okay, I got the schedule and seendb stuff created. I put my SEENDB_PATH in 'Makefile.local' as '/var/cache/openpvr'. Now, previously, one had to have the XML file containing the data from XMLTV in '/tmp/tv_data.xml.gz', and the programs you wanted to record in '/tmp/wanted_programs.xml.gz'. When 'schedule' was run, it parsed through the 'wanted_programs.xml.gz' file, listed when they were on (and gave the commands for scheduling them), and that was that. There was some definite output on the screen regarding conflicts, etc. I created my 'wanted_programs.xml.gz', and got my XMLTV data into the 'tv_data.xml.gz' file. I tried them both in the "old" location of /tmp, and in the SEENDB_PATH, but each time, when I run 'schedule', it does not seem to do anything and just returns to the command line. I guess my questions are these: 1. Are the data files that 'schedule' is looking for still 'tv_data.xml.gz' and 'wanted_programs.xml.gz'? If not, what should they be? 2. Am I correct in assuming that these files (whatever they are to be called), as well as the "seen database" should *all* reside in the SEENDB_PATH? Again, TIA. I just wanted to see how much things have changed since the posting on April 17 of this year regarding how these programs all work now. ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
From: Alan M. <si...@ya...> - 2002-11-03 02:21:18
|
--- "Brian J. Murrell" > > ----- > > #DEFS = -DSEENDB_PATH=\"/var/cache/openpvr\" > > ----- > > First of all, remove the pound/hash sign from the > beginning of the line. Okay, that makes sense :-) > if you want your seen_db in /tmp, change the > "/var/cache/openpvr" to > "/tmp". Actually, that was a bit of a slip. I originally wanted to put it into /tmp, but upon thinking about it, I figured /var/cache/openpvr would be a better location, and be more 'LSB' compliant :-) > Done. It has the SEENDB_PATH set to > /var/cache/openpvr. Excellent. I will give this a try, and let you know if I have any further problems :-) Thanx! :-) ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
From: Brian J. M. <cf8...@in...> - 2002-11-03 00:47:04
|
On Sat, Nov 02, 2002 at 06:11:06PM -0500, Alan Murrell wrote: > Hello, Hey. > I am attempting to build the Perl/C OpenPVR programs, > and am running into a bit of trouble with the > 'Makefile.local' file. I wish to keep my 'seen_db' in > the /tmp directory, so this is what my > 'Makefile.local' file consists of: >=20 > ----- > #DEFS =3D -DSEENDB_PATH=3D\"/var/cache/openpvr\" > ----- First of all, remove the pound/hash sign from the beginning of the line. Pound/hash signs signify comments in Makefiles. Second of all, if you want your seen_db in /tmp, change the "/var/cache/openpvr" to "/tmp". > Or perhaps > a sample 'Makefile.local' file could be provided in > the CVS for download, Done. It has the SEENDB_PATH set to /var/cache/openpvr. b. --=20 Brian J. Murrell |
From: Alan M. <si...@ya...> - 2002-11-02 23:11:12
|
Hello, I am attempting to build the Perl/C OpenPVR programs, and am running into a bit of trouble with the 'Makefile.local' file. I wish to keep my 'seen_db' in the /tmp directory, so this is what my 'Makefile.local' file consists of: ----- #DEFS = -DSEENDB_PATH=\"/var/cache/openpvr\" ----- But when I run 'make all', I get the following error: ----- cc -g -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/gnome-xml -Wall -g -lxml -lz -lglib -ldb-3.3 schedule.c -o schedule schedule.c:1098:2: #error "You must define SEENDB_PATH in Makefile.local" schedule.c: In function `main': schedule.c:1100: `SEENDB_PATH' undeclared (first use in this function) schedule.c:1100: (Each undeclared identifier is reported only once schedule.c:1100: for each function it appears in.) make: *** [schedule] Error 1 ----- I have obviously mis-defined SEENDB_PATH, so I was wondering if an example could be provided? Or perhaps a sample 'Makefile.local' file could be provided in the CVS for download, and then one culd just substitute the path inthe sample file (if they wish) with the path they want their DB files to reside. TIA, ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
From: NextResearchSurvey <nex...@ev...> - 2002-08-10 22:56:53
|
You have been invited to participate in an important research study regarding consumer home electronics. This survey, sponsored by NextResearch, Inc. ( <http://www.nextresearch.com/> http://www.nextresearch.com), will take approximately 8 minutes to complete. We will be awarding 25 winners a new Personal Video Recorder upon completion of the research. The entire survey must be completed to be eligible for the prizes. Entertainment companies will use the information in an effort to provide better services to you in the future. This market research survey is being conducted within the Market Research Society's Code of Conduct and as such we will not be selling you anything, nor will we pass on any details to anyone. All answers are completely confidential, your name and personal information will not be collected in this survey; we only request your e-mail address and phone number for prize verification and notification. If you have any questions, feel free to contact the project manager, Jennifer Choate at 901.491.4995. Click on the link below to participate and we thank you for your time. <http://websurveyor.net/wsb.dll/9645/survey.htm> http://websurveyor.net/wsb.dll/9645/survey.htm Regards, NextResearch Team |
From: Brian J. M. <e9e...@in...> - 2002-07-14 05:33:50
|
On Mon, Jul 08, 2002 at 01:39:59AM -0400, Alan Murrell wrote: > Hello, Hi, > I am playing with mp1e using the Perl "record" script > (running it manually for now; will play with doing > scheduled recordings when I'm happy with the output), Cool. > and when I specify a --end time, it doesn't stop when > that time rolls around around; I have to kill the > process to stop it. I have tried specifying the --end > option in both 24hr time format (yes, my system time > is correct) and in seconds. >=20 > Here is the mp1e command it is running after I put > 'record --channel 45 --end <time/sec> test_file': Please! When you give a command line and it's output and complain that "it's not working", _do_not_ edit the command line. In your above command, you removed the _most_ useful (and only important) part of the command with your "<time/sec>" instead of putting in the value you really used. The time you ran the command would also have been useful. Please provide the command line and _all_ of it's output (up until mp1e starts writing status lines anyway) of some samples of: $ date; record --channel 45 --end <time/sec> test_file > --- output --- > v4lctl setchannel "45"; v4lctl bright 40000; v4lctl > contrast 30000; v4lctl hue 32768; v4lctl color 37500; > mp1e -vv -n 36503 Did you read the mp1e manpage when trying to debug this? -n <value> is the number of seconds to record. As you can see, whatever you put into "<time/sec>" was calculated to be 10.139722 (36503 / 60 / 60) hours long. Knowing the time you ran the command and the value of "<time/sec>" would help in debugging. > When I look at the coding, there doesn't seem to be > anything in the options for mp1e which specifies an > end time. -n <seconds> > Is it because I'm running it manually > (i.e., if I were to do cut and paste the output from > the schedule program into my console to put a schedule > into 'at', would it start and stop properly? Nope. > One other thing: at first, everytime I tried running > the 'record' script manually with mp1e, it would > immediately exit (bringing me back to the command > line). It *looked* like it was trying to find mp1e in > /tmp (i.e., /tmp/mp1e), so I commented the '/tmp' part > out, and seems to have worked quite nicely > (presumably, anyway; I still have to wait to see what > the test output files look like). Yeah, more "local" hard coding. I really do need to put some "autoconf" smarts into the openpvr code in general. b. --=20 Brian J. Murrell |
From: Alan M. <si...@ya...> - 2002-07-08 05:40:05
|
Hello, I am playing with mp1e using the Perl "record" script (running it manually for now; will play with doing scheduled recordings when I'm happy with the output), and when I specify a --end time, it doesn't stop when that time rolls around around; I have to kill the process to stop it. I have tried specifying the --end option in both 24hr time format (yes, my system time is correct) and in seconds. Here is the mp1e command it is running after I put 'record --channel 45 --end <time/sec> test_file': --- output --- v4lctl setchannel "45"; v4lctl bright 40000; v4lctl contrast 30000; v4lctl hue 32768; v4lctl color 37500; mp1e -vv -n 36503 -s 640x480 -b 5000 -f 29.97 -a 0 -B 128 -p /dev/dsp -S 32 -x /dont/set/mixer> "/pvr/Video/recorded/test_file.mpeg" 2>"/pvr/Video/recorded/test_file.output" --- output --- When I look at the coding, there doesn't seem to be anything in the options for mp1e which specifies an end time. Is it because I'm running it manually (i.e., if I were to do cut and paste the output from the schedule program into my console to put a schedule into 'at', would it start and stop properly? One other thing: at first, everytime I tried running the 'record' script manually with mp1e, it would immediately exit (bringing me back to the command line). It *looked* like it was trying to find mp1e in /tmp (i.e., /tmp/mp1e), so I commented the '/tmp' part out, and seems to have worked quite nicely (presumably, anyway; I still have to wait to see what the test output files look like). TIA, ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your ad for free now! http://personals.yahoo.ca |
From: Brian J. M. <108...@in...> - 2002-06-27 18:24:51
|
On Wed, Jun 26, 2002 at 11:05:33PM -0500, Monty Walls wrote: > Is anyone else having problems with your recording > going nuts (losing sync droping frames) > in the last minute or so of 59 minute plus recordings? Not here, but I am using CVS versions of mp1e. b. --=20 Brian J. Murrell |
From: Monty W. <mw...@ca...> - 2002-06-27 04:11:41
|
Is anyone else having problems with your recording going nuts (losing sync droping frames) in the last minute or so of 59 minute plus recordings? -- -Monty Walls (mw...@ca...) - MIS, Oklahoma Tax Commission - - My opinions are my own, my employer knows nothing about it. |
From: Brian J. M. <100...@in...> - 2002-06-23 20:09:22
|
On Fri, Jun 21, 2002 at 07:55:11PM -0400, Alan Murrell wrote: > Hello. Hi there. > I ran "make" (using gcc-3.0.4) in the OpenPVR > directory (downaloded latest CVS just this morning), > and I get the following error: [ error snipped ] I should set up autoconfigure to build all of this so I can put build-time requirements into it all. > I have the db1-* packages from Mandrake 8.2 > installed (v1.85-7). In case you're wondering, I had > to change the "#include (db.h)" line in schedule.c to > "#include (db1/db.h)", to reflect it's location on my > system. Wrong fix. schedule actually uses version 3 of the Berkeley Database. On Mandrake, you need to install libdb3.3-devel and it's dependencies -- urpmi will figure them out for you if you do a: # urpmi libdb3.3-devel > Thanx, in advance. NP. Glad to see you are finally using schedule. :-) b. --=20 Brian J. Murrell |
From: Alan M. <si...@ya...> - 2002-06-21 23:55:12
|
Hello. This is most likely not a problem with schedule.c itself, but I thought I'd post it here just in case. I ran "make" (using gcc-3.0.4) in the OpenPVR directory (downaloded latest CVS just this morning), and I get the following error: ----- ERROR ----- gcc-3.0.4 -g -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/gnome-xml -Wall -g -lxml -lz -lglib -ldb-3.3 schedule.c -o schedule In file included from schedule.c:28: /usr/include/db1/db.h:121: parse error before "u_int" /usr/include/db1/db.h:122: parse error before "u_int" /usr/include/db1/db.h:123: parse error before "u_int" /usr/include/db1/db.h:124: parse error before "u_int" /usr/include/db1/db.h:125: parse error before "u_int" /usr/include/db1/db.h:137: parse error before "u_int" /usr/include/db1/db.h:140: parse error before "psize" /usr/include/db1/db.h:146: parse error before '}' token /usr/include/db1/db.h:153: parse error before "u_int" /usr/include/db1/db.h:155: parse error before "nelem" /usr/include/db1/db.h:156: parse error before "cachesize" /usr/include/db1/db.h:160: parse error before '}' token /usr/include/db1/db.h:168: parse error before "u_int" /usr/include/db1/db.h:172: parse error before "bval" /usr/include/db1/db.h:174: parse error before '}' token /usr/include/db1/db.h:153: parse error before "u_int" /usr/include/db1/db.h:155: parse error before "nelem" /usr/include/db1/db.h:156: parse error before "cachesize" /usr/include/db1/db.h:160: parse error before '}' token /usr/include/db1/db.h:168: parse error before "u_int" /usr/include/db1/db.h:172: parse error before "bval" /usr/include/db1/db.h:174: parse error before '}' token schedule.c: In function `wasSeen': schedule.c:467: `DB_NOTFOUND' undeclared (first use in this function) schedule.c:467: (Each undeclared identifier is reported only once schedule.c:467: for each function it appears in.) schedule.c:470: structure has no member named `err' schedule.c:471: too many arguments to function schedule.c:472: structure has no member named `err' schedule.c: In function `prevScheduled': schedule.c:508: `DB_NOTFOUND' undeclared (first use in this function) schedule.c:511: structure has no member named `err' schedule.c:512: too many arguments to function schedule.c:513: structure has no member named `err' schedule.c: In function `main': schedule.c:905: warning: implicit declaration of function `db_create' schedule.c:906: warning: implicit declaration of function `db_strerror' schedule.c:906: warning: format argument is not a pointer (arg 3) schedule.c:910: structure has no member named `open' schedule.c:911: `DB_CREATE' undeclared (first use in this function) schedule.c:912: structure has no member named `err' schedule.c:913: too many arguments to function schedule.c:914: structure has no member named `err' schedule.c:1394: too many arguments to function schedule.c:1395: structure has no member named `err' make: *** [schedule] Error 1 ----- ERROR ----- I have the db1-* packages from Mandrake 8.2 installed (v1.85-7). In case you're wondering, I had to change the "#include (db.h)" line in schedule.c to "#include (db1/db.h)", to reflect it's location on my system. I did take a look at the apparently-offending lines in db.h, but unfortunately I was unable to determine whether or not they are structured properly or not. Is this really a problem with db.h, or is it maybe an error on schedule.c's partparsing it? (well, I guess that would be make's problem, wouldn;t it?) Thanx, in advance. ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Find, Connect, Date! http://personals.yahoo.ca |
From: Monty W. <mw...@ca...> - 2002-06-17 16:27:27
|
On Wed, 5 Jun 2002 23:09:21 -0400 "Brian J. Murrell" <5cb...@in...> wrote: > On Wed, Jun 05, 2002 at 08:47:04PM -0500, Monty Walls wrote: > > > > lazyness. Looks like I'm going to have add the v4l2 patch set to my running > > kernel. With mp1e configured about the same as your's my K7-1200mhz drops > > about 20% of the frames. > Thanks everyone. I added v4l2 to my systems and my drop problems went away. I can now capture at 640x480 without drop problems on both my K7-800 & K7-1200. Did have sound capture/playback problems after upgrading so I upgraded alsa from .50 to .90 and those went away. So my current kernel is RH 2.4.18-4 (with all the RH patches) with merged Low-latency+Preemption patches + v4l2 + alsa-.90-rc1. Talk about a collection of bailing wire & bubble gum.... Now I just have to beat up on my cable provider to clean up their damn noisy signal :) Buy the way mp1e complains that my fields are out of order for fun filters, sound familiar anyone??? -- -Monty Walls (mw...@ca...) - MIS, Oklahoma Tax Commission - - My opinions are my own, my employer knows nothing about it. |
From: mark <ml...@in...> - 2002-06-11 13:25:42
|
I have been trying to figure out why I was have been having problems recording sound and it turned out to be my stereo setup. In the process I upgraded my sound to alsa which should be better than OSS but I can't seem to get mp1e-1.9.1 or 1.9,2 to compile with alsa support and if I record with alsa support for oss (/dev/dsp) the recording level is really low unless in mono. Can anyone tell me why mp1e isn't seeing alsa or at least how to make it see alsa? Mark |
From: Monty W. <mw...@ca...> - 2002-06-06 03:20:06
|
On Wed, 5 Jun 2002 23:09:21 -0400 "Brian J. Murrell" <5cb...@in...> wrote: > On Wed, Jun 05, 2002 at 08:47:04PM -0500, Monty Walls wrote: > > > > lazyness. Looks like I'm going to have add the v4l2 patch set to my running > > kernel. With mp1e configured about the same as your's my K7-1200mhz drops > > about 20% of the frames. > > Wow! I get a few drops per hour (more depending on what else the box > is doing) but nothing near 20%. How recent is your mp1e? I am using > the mp1e from the rte project. My last cvs update was May 13 11:54 > (which means I should update again to see what's new :-) > mp1e from zapping(aka rte) 1.9.2 released version (non-cvs). Looks like I should get the cvs version then :) Sounds like v4l2 is a big difference. If I get industrious after I get back in town (gone Thurs-Sunday), I'll see I can't build myself a set of kernel rpms with v4l2 in them (2 boxes to update so rpms make things a lot easier for me). rt.c was a quick hack between emails :) But I'll probably get some use out of it on a couple of other programs... -- -Monty Walls (mw...@ca...) - MIS, Oklahoma Tax Commission - - My opinions are my own, my employer knows nothing about it. |
From: Brian J. M. <5cb...@in...> - 2002-06-06 03:09:44
|
On Wed, Jun 05, 2002 at 08:47:04PM -0500, Monty Walls wrote: > =20 > lazyness. Looks like I'm going to have add the v4l2 patch set to my runn= ing > kernel. With mp1e configured about the same as your's my K7-1200mhz drops > about 20% of the frames. Wow! I get a few drops per hour (more depending on what else the box is doing) but nothing near 20%. How recent is your mp1e? I am using the mp1e from the rte project. My last cvs update was May 13 11:54 (which means I should update again to see what's new :-) > CPU load is only about 40%, so it's not that... Seems a little high for a K7-1200Mhz when my Athlon TB 800 only goes that high. > If I drop to 640x240, I get essentially no drops using v4l, but have > to run mp1e as real-time to do it (cheating). I cheat. :-) > My realtime toy is attached I do it right in mp1e: Index: main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/zapping/rte/mp1e/main.c,v retrieving revision 1.33 diff -u -r1.33 main.c --- main.c 13 May 2002 05:38:00 -0000 1.33 +++ main.c 6 Jun 2002 03:04:59 -0000 @@ -40,6 +40,7 @@ #include <sys/mman.h> #include <sys/time.h> #include <sys/stat.h> +#include <sys/resource.h> #include <asm/types.h> =20 #include "common/videodev2.h" @@ -353,8 +354,13 @@ program_invocation_name =3D argv[0]; #endif =20 + errno =3D 0; + if (setpriority(PRIO_PROCESS, getpid(), -10) =3D=3D -1 && errno != =3D 0) + perror("mp1e: setpriority"); + options(ac, av); =20 #if 0 if (mux_syn !=3D 4) { --=20 Brian J. Murrell |
From: Monty W. <mw...@ca...> - 2002-06-06 01:52:35
|
On Wed, 5 Jun 2002 21:12:20 -0400 "Brian J. Murrell" <55d...@in...> wrote: > On Wed, Jun 05, 2002 at 06:42:45PM -0500, Monty Walls wrote: > > > > Been playing with mp1e, first had to patch the v4l code (patch is turned in). > > How come? You want to use v4l2 anyway. Much better a/v syncing > results. > lazyness. Looks like I'm going to have add the v4l2 patch set to my running kernel. With mp1e configured about the same as your's my K7-1200mhz drops about 20% of the frames. CPU load is only about 40%, so it's not that... If I drop to 640x240, I get essentially no drops using v4l, but have to run mp1e as real-time to do it (cheating). My realtime toy is attached -- -Monty Walls (mw...@ca...) - MIS, Oklahoma Tax Commission - - My opinions are my own, my employer knows nothing about it. |