Brandon Beattie wrote:
On Fri, Jul 01, 2005 at 05:58:30AM +0100, Terry Barnaby wrote:
One useful feature of separate non raided/LVM'ed disks that I
use is to power down the disks that are not in use. This
saves power and increases disk life.
I did have a 10 minute power safe enabled on my
Thomas M. Pluth wrote:
Comments?
How about something like this ;
1) Define a single location for recordings. This should be a high speed
disk right on your master backend and have enough available space to handle
your typical daily recording load.
2) Define a group of long term storage
Randall J. Parr wrote:
Brandon Beattie wrote:
Well it happened, one of 5 disks in my LVM setup went bad and the claims
of every LVM user I know didn't come true (That if you lose one disk,
you can still get to the data of the rest).
From this I had an idea and wanted to see if it's a good
Daniel Kristjansson wrote:
On Sun, 2005-06-26 at 21:06 +0200, Steven wrote:
Hi,
It been a while since I updated my EPIA-M frontend to CVS but today I did.
I compiled using ./configure --cpu=pentium-mmx --enable-xvmc
and all seems well but there are strange hickups in blackback.
This is in the
Ivor Hewitt wrote:
On Tuesday 07 Jun 2005 03:09, Isaac Richards wrote:
On Monday 06 June 2005 10:07 pm, Kevin Ruland wrote:
Hi all
I am interested in implementing Picture-in-Picture for XvMC-vld
accellerated systems. I noticed in the XvMC header support for
subpictures. Has anyone looked
Jarod Wilson wrote:
In an effort to get a 0.18.1 release out the door, we need more folks to test
it for stability/proper functionality, etc. You can check the code out from
cvs like so:
$ cvs -d :pserver:[EMAIL PROTECTED]:/var/lib/mythcvs login
Logging in to :pserver:[EMAIL
Steven wrote:
Terry Barnaby schreef:
The current MythTV CVS with XvMC VLD decoding crashes when changing
a channel.
This is due to to the test to see if a valid XvMC port is available
in the static function VideoOutputXv::GetBestSupportedCodec() on lines
820-838. This fails on a channel change
Terry Barnaby wrote:
Hi Daniel,
XvMC VLD in a Via M10K box is now working better, but still not right.
The main problem now is that sometimes channel changes work and
sometimes they don't.
I have tracked this down to an issue with the OSD.
When the channel change fails the code is stuck
Your OSD fix in CVS has certainly fixed the problem with changing
channels due to the OSD locks. Thanks. Things are much better now.
However I have still had a channel change fail after quite a few
changes. Here is an example where two channel changes worked Ok
and the third failed. On the third
Daniel Kristjansson wrote:
On Fri, 2005-05-06 at 07:30 +0100, Terry Barnaby wrote:
Your OSD fix in CVS has certainly fixed the problem with changing
channels due to the OSD locks. Thanks. Things are much better now.
However I have still had a channel change fail after quite a few
changes. Here
Hi Daniel,
XvMC VLD in a Via M10K box is now working better, but still not right.
The main problem now is that sometimes channel changes work and
sometimes they don't.
I have tracked this down to an issue with the OSD.
When the channel change fails the code is stuck in
Isaac Richards wrote:
On Tuesday 03 May 2005 04:49 pm, Terry Barnaby wrote:
Ok, It appears to default to off and the settings indicate that it
should not normally be used. So should this be changed ?
I did not need to use this option prior to the XvMC/Xv merge ...
I just want to make sure
Hi,
Included is a patch that fixes the error messages when XvMC VLD is
used with the latest XvMC/VLD merge.
Terry
Index: libs/libavcodec/xvmcvldvideo.c
===
RCS file: /var/lib/mythcvs/mythtv/libs/libavcodec/xvmcvldvideo.c,v
retrieving
be there with XvMC VLD decoding ...
Terry
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [EMAIL PROTECTED] Web: www.beam.ltd.uk
BEAM for: Visually
Neale Swinnerton wrote:
Hi Terry,
your xvmc_vld_4.patch fixes the crash, but I still 'hang' when I change
channel. I get this in the log, any clues? I'm running
CVS from 00:00GMT 2005-05-04
+ xtraview.v2.patch
+ xvmc_vld_3.patch
+ xvmc_vld_4.patch
Neale.
I'm not sure, the build you have used
Neale Swinnerton wrote:
Terry Barnaby wrote:
I'm not sure, the build you have used sounds like the one I am using
except for the xtraview.v2.patch. You could try removing that ?
You could try a complete re-build and ldconfig ?
Did a rebuild, still got the problem. The interesting thing
Terry Barnaby wrote:
Daniel Kristjansson wrote:
On Mon, 2005-05-02 at 20:31 +0100, Terry Barnaby wrote:
Daniel Kristjansson wrote:
Thanks for adding the patch.
I agree there should not be an exit there, but there does not seem
to be a way of returning an error from this. I must admit, with my
Terry Barnaby wrote:
Terry Barnaby wrote:
Daniel Kristjansson wrote:
On Mon, 2005-05-02 at 20:31 +0100, Terry Barnaby wrote:
Daniel Kristjansson wrote:
Thanks for adding the patch.
I agree there should not be an exit there, but there does not seem
to be a way of returning an error from this. I
Gareth Powell wrote:
I'm trying to get MythTV up and running, and after a number of
problems, I think I'm nearly there.
I'm using MythTV 0.18+ out of CVS from about a week ago (although I'm
happy to upgrade if it will help) on an i386 with basically FC2, but
I've added all the prerequisite RPMs
It looks like the problem is with AVSync (again !).
If I set disableaudio in NupplePlayer.cpp video display is fine.
If I set avsync_avg = frame_interval at the top of
NuppelVideoPlayer::WarpFactor() all is Ok (bar audio delayed/infront).
What is supposed to happen in NuppelVideoPlayer::AVSync()
Isaac Richards wrote:
On Tuesday 03 May 2005 04:17 pm, Terry Barnaby wrote:
It looks like the problem is with AVSync (again !).
If I set disableaudio in NupplePlayer.cpp video display is fine.
If I set avsync_avg = frame_interval at the top of
NuppelVideoPlayer::WarpFactor() all is Ok (bar audio
There is a missing #include errno.h in mythcontext.cpp, at
least for Fedora 3.
Terry
Index: libs/libmyth/mythcontext.cpp
===
RCS file: /var/lib/mythcvs/mythtv/libs/libmyth/mythcontext.cpp,v
retrieving revision 1.172
diff -u -r1.172
Terry Barnaby wrote:
There is a missing #include errno.h in mythcontext.cpp, at
least for Fedora 3.
Terry
Index: libs/libmyth/mythcontext.cpp
===
RCS file: /var
Updated info on Current state of MythTv using Via XvMC VLD
Hardware MPEG decoding.
Just a short note to update people with the status of MythTv
when using Via XvMC VLD hardware MPEG decoding.
This is based on my setup using an Via M10K box as a TV Client
directly driving a 4:3 PAL TV Via S-Video.
Daniel Kristjansson wrote:
9. My MythTv config line is:
./configure --prefix=/usr --enable-xvmc-vld --cpu=i686\
--enable-dvb-eit --enable-dvb\
--dvb-path=/data/src/MythTv/include; qmake mythtv.pro
Note: --cpu=i686 is needed to get MMX working.
This seems to be the
Daniel Kristjansson wrote:
On Mon, 2005-05-02 at 20:31 +0100, Terry Barnaby wrote:
Daniel Kristjansson wrote:
Thanks for adding the patch.
I agree there should not be an exit there, but there does not seem
to be a way of returning an error from this. I must admit, with my
searching through
Daniel Kristjansson wrote:
On Mon, 2005-05-02 at 20:31 +0100, Terry Barnaby wrote:
Daniel Kristjansson wrote:
Thanks for adding the patch.
I agree there should not be an exit there, but there does not seem
to be a way of returning an error from this. I must admit, with my
searching through
Just a short note to update people with the status of MythTv
when using Via XvMC VLD hardware MPEG decoding.
This is based on my setup using an Via M10K box as a TV Client
directly driving a 4:3 PAL TV Via S-Video. DVB-T cards are used
in a separate server.
Works well with MythTv CVS 2005-04-23
CVS 2005-04-25.
I note that in the current CVS 2005-04-29 it does work, but the Video/Audio
AvSync has major issues with huge stutters. I presume this is due
to videoout_xv.c changes
Terry
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business
Hi,
My investigations into this are leading to the fact that there is a bug
in the MPEG TS handling in libavformat or libavcodecs. At least when
XvMC VLD is involved but possibly in all cases although other decoding
methods my cope with the bug better.
What appears to happen is that when the PMT
Terry Barnaby wrote:
Hi,
The current MythTv CVS version (2004-04-25) of the Xv/XvMC merge appears
to be broken on a Via M10K box using XvMC VLD acceleration.
Problems are:
1. If DVB-T cards are set to TS mode the system will show TV
on startup, but will fail on channel change.
Before
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 06:52 +0100, Terry Barnaby wrote:
Hi,
The current MythTv CVS version (2004-04-25) of the Xv/XvMC merge appears
to be broken on a Via M10K box using XvMC VLD acceleration.
Problems are:
1. If DVB-T cards are set to TS mode the system will show TV
Here is a little more feedback on this problem.
It appears that the Xv/XvMC/avcodec system has not recondigured itself
properly after a channel change.
I have put debug messages in the libviaXvMC library to see what is called.
You should see a sequence like:
XvMCLoadQMatrix:
XvMCBeginSurface:
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 21:41 +0100, Terry Barnaby wrote:
My enclosed attachments show some part of the sequence before changing
the channel (working1) and the first bit after (bug1).
The Via XvMC system gets a XvMCLoadQMatrix(),XvMCBeginSurface()
sequence then a lot
Terry Barnaby wrote:
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 21:41 +0100, Terry Barnaby wrote:
My enclosed attachments show some part of the sequence before changing
the channel (working1) and the first bit after (bug1).
The Via XvMC system gets a XvMCLoadQMatrix(),XvMCBeginSurface
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 23:00 +0100, Terry Barnaby wrote:
I don't think there is an issue with closing and re-opening the
context in XvMC VLD. So I am note sure your channel change
system will affect the problem.
There appears to be a more fundemental problem in avcodec
Hi,
The current MythTv CVS version (2004-04-25) of the Xv/XvMC merge appears
to be broken on a Via M10K box using XvMC VLD acceleration.
Problems are:
1. If DVB-T cards are set to TS mode the system will show TV
on startup, but will fail on channel change.
Before changing channel
Doug Larrick wrote:
Terry Barnaby wrote:
Is there any real reason why MythTv uses this alternate software scheme ?
Any idea as to why it does just not use the normal video output system with
a small overlay window in the right place ???
A couple weeks ago Isaac indicated that some (most? many
Daniel Kristjansson wrote:
On Wed, 2005-04-20 at 21:43 +0100, Terry Barnaby wrote:
Actually, going back to MythTv CVS 2005.04.14, it also uses quite a lot
of CPU while displaying the small video in Watch Recordings, not
quite the same level as with the patch (about 90% versis 98%).
The picture
Daniel Kristjansson wrote:
On Tue, 2005-04-19 at 22:46 -0400, Daniel Kristjansson wrote:
This is an update on the Xv/XvMC patch.
The patch is here:
http://www.mrl.nyu.edu/~danielk/mythtv/xv-xvmc-merge-v13.patch.bz2
However, there is still a problem with Jumping backward and forward
in HDTV. My
Daniel Kristjansson wrote:
On Wed, 2005-04-20 at 20:19 +0100, Terry Barnaby wrote:
I have just tried compiling MythTv from CVS 2005-04-19 with this
patch for a Via M10K system with XVMC VLD.
I get the compiler error:
videooutbase.cpp: In member function `int
VideoOutput::DisplayOSD(VideoFrame
Daniel Kristjansson wrote:
On Wed, 2005-04-20 at 20:19 +0100, Terry Barnaby wrote:
I have just tried compiling MythTv from CVS 2005-04-19 with this
patch for a Via M10K system with XVMC VLD.
I get the compiler error:
videooutbase.cpp: In member function `int
VideoOutput::DisplayOSD(VideoFrame
Terry Barnaby wrote:
Daniel Kristjansson wrote:
On Wed, 2005-04-20 at 20:19 +0100, Terry Barnaby wrote:
I have just tried compiling MythTv from CVS 2005-04-19 with this
patch for a Via M10K system with XVMC VLD.
I get the compiler error:
videooutbase.cpp: In member function `int
VideoOutput
Roger James wrote:
John,
Thank you, setting Use Hardware MPEG decoder fixed the problem.
I guess that either hardware decoding was being used by default on my
previous build, or a problem has been introduced into software decoding in
recent CVS commits.
I would not like to hazard a guess as to
Greg Grotsky wrote:
I've been trying to narrow down the issue with audio jitter and
slow-mo video. I've determined that it was broken in CVS sometime
between 3/27/2005 and 3/29/2005. I checked out CVS MythTV from
3/27/2005 and it works for all channels, when I check it out from
3/29/2005
Ivor Hewitt wrote:
On Monday 11 Apr 2005 22:23, Daniel Kristjansson wrote:
I've updated the xv/xvmc merge patch with the help of some VLD
debugging by Ivor Hewitt. Hopefully this version functions with
XvMC-VLD..
The patch is at:
http://www.mrl.nyu.edu/~danielk/mythtv/xv-xvmc-merge-v7.tbz
I've
Terry Barnaby wrote:
Hi,
The current MythTv CVS version of MythTV has a stange problem with
display on my Via M10K box which uses Via VLD XVMC hardware MPEG decode.
The Via M10K box is a simple client with a separate server containg DVB
cards.
Myth CVS after 2005.03.30 has this problem.
MythTV
Terry Barnaby wrote:
Terry Barnaby wrote:
Hi,
The current MythTv CVS version of MythTV has a stange problem with
display on my Via M10K box which uses Via VLD XVMC hardware MPEG decode.
The Via M10K box is a simple client with a separate server containg
DVB cards.
Myth CVS after 2005.03.30 has
Ed W wrote:
I've attached the frontend log output in case it helps - the only
thing in there that I noticed that is new is the use of OpenGL vsync
support. Previous ATrpms builds have not had that and so RTC timing
has been used.
There's a reason that that defaults to off.
FYI: I get lots
Jesper Sörensen wrote:
Terry Barnaby wrote:
Could some change to the DVB code have resulted in an MPEG stream that
the Via MPEG hardware cannot decode correctly ?
The only thing I can think of is if your hw decoder has problems with
multiple parallell streams? In that case the decoder
Jesper Sörensen wrote:
Terry Barnaby wrote:
Could some change to the DVB code have resulted in an MPEG stream that
the Via MPEG hardware cannot decode correctly ?
The only thing I can think of is if your hw decoder has problems with
multiple parallell streams? In that case the decoder
Jesper Sörensen wrote:
Terry Barnaby wrote:
Jesper Sörensen wrote:
Terry Barnaby wrote:
Could some change to the DVB code have resulted in an MPEG stream
that the Via MPEG hardware cannot decode correctly ?
The only thing I can think of is if your hw decoder has problems with
multiple parallell
Ivor Hewitt wrote:
On Thursday 07 Apr 2005 21:06, Terry Barnaby wrote:
Hi,
The current MythTv CVS version of MythTV has a stange problem with
display on my Via M10K box which uses Via VLD XVMC hardware MPEG decode.
The Via M10K box is a simple client with a separate server containg DVB
cards.
Myth
Hi,
The current MythTv CVS version of MythTV has a stange problem with
display on my Via M10K box which uses Via VLD XVMC hardware MPEG decode.
The Via M10K box is a simple client with a separate server containg DVB
cards.
Myth CVS after 2005.03.30 has this problem.
MythTV CVS before 2005.02.20
Jarod Wilson wrote:
On Wednesday 30 March 2005 00:39, Juha Kuikka wrote:
running CVS from a few days ago, and I've noticed for awhile now that
many buttons (next, No, leave my card settings alone, etc) won't
click with enter/space. Well, they change color as if they're
depressed, but they don't
Per Åge Sørvik wrote:
Something seems to be wrong with the scaling code. I've got 5:4,16:10
and 16:9 display devices, and the DisplaySize set to reflect the
correct ratio in the X* config files on the different machines. All
content scaless correctly on the 16:9 16:10 devices, but on the 5:4
Ivor Hewitt wrote:
On Wednesday 23 Feb 2005 09:25, Terry Barnaby wrote:
I have just updated to Mythtv 0.17 from 0.16.
I have cleared my channel settings and have tried to use the new DVB
auto scan system to set up my channels.
In general this seems to work fine, except that it appears to have
Jeroen Brosens wrote:
People,
Please read the following: http://www.100fps.com/why_bobbing.htm
I am seriously doubting the correct implementation of the 'Field Bob'
filter (as this website calls it) in MythTV's bobdeint, because this
occurs in every single show I watch up till now, be it a
Hi All,
Any other feedback on the last mythtv-aspect3.patch I submitted
a while ago ?
It is working well here.
Can it be put into the CVS tree ?
Terry
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454
Thomas Börkel wrote:
HI!
VDR lets you have multiple directories for recordings with ascending
number, like /video0, /video1, etc. In this case, you just configure
the name /video.
Maybe this is something for MythTV, too?
A first step could be, that MythTV just looks into all directories for
Paul Greidanus wrote:
Mark Edwards wrote:
I was thinking along these lines before Christmas when I wanted to
temporarily add an extra disk for Christmas films to my server.
I added a bit of code to Myth to allow me to do this, a bit of a hack.
This added the Global preference: VideoDirs beneath
Terry
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [EMAIL PROTECTED] Web: www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals
Robert Clark wrote:
Hi Terry,
On Tue, 2005-01-04 at 16:21, Terry Barnaby wrote:
This patch fixes problems with rounding errors caused by the X-Servers
rounding of the DisplaySize configuration parameter.
I think there's some overlap between your patch and the one I posted
last month
Gavin Hurlbut wrote:
Terry Barnaby [EMAIL PROTECTED] wrote:
SNIP
See how easy that was? PLEASE cut out stuff that you aren't specifically
replying to.
The only time I'm noticing jittery video or something similar is when something
tries to use the CPU (like compiling, or starting a recording
Ed Wildgoose wrote:
I am using an M10K box with Fedora 2 and have set the DisplaySize
option to 400 225 which seems to work fine for me, apart
from the OSD which I know has been fixed. My MythTv is
from CVS on 21/11/04.
Nice to know. What is your screen res with these settings? 720x576 as
aspect ratio.
Terry
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [EMAIL PROTECTED] Web: www.beam.ltd.uk
BEAM for: Visually
66 matches
Mail list logo
