Hamish,
i know you're in Melbourne - i'm also in Melbourne also.
i wonder how much of this may be related to a less-than-ideal aerial?
i had previously dabbled with Hauppage WinTVs - analog capture cards -
which worked relatively well.
the only channel which wasn't great was Channel 31.
with a
On Sun, Mar 20, 2005 at 08:04:12PM +1100, Lincoln Dale wrote:
i know you're in Melbourne - i'm also in Melbourne also.
i wonder how much of this may be related to a less-than-ideal aerial?
I don't think so. A few points in support of my argument:
1. Errors are detected and logged as
I've been having problems for ages now with certain dvb-s channels from
Astra 28.8E.
I finally figured it out today. The serviceid column in channel
has a max size of 32768, but a lot of channels have serviceid of 52515,
52505 etc...
As soon as i perfomed:
alter table channel modify column
Dan Christensen wrote:
...
As an example, the patch below puts an x in the left-hand column for
conflicts, a - for programs not recorded because too many have
already been recorded, and a . for other things marked deactivated.
Skipping the last two might be better, since it's usually conflicts
I'm
Bruce Markey [EMAIL PROTECTED] writes:
The RecStatusChar is established and well known (C for conflict,
P for previously shown, card numbers for will record) and would
probably be more useful and familiar.
Yes, this is much better. But I would like to show nothing in the
case of something
Well, either downgrade to qt-3.3 ( a problem if you want to use
kde-3.4) or use the mouse.
This is a lttle tricky since the cursor doesn't show ;-)
But if you move the mouse around you can gray out the button you
want to execute, e.g. Finish. Then just left click. It works.
Odd,tedious, but it
Yes, this is much better. But I would like to show nothing in the
case of something that will record or that will record at another
time, so only the problem cases are indicated.
Why not just change the css so the color is easier to see? As long as
it looks decent enough (would prefer changing
Hi,
It is not possible to watch recordings (or LiveTV) on debian64. This
problem is already described in [mythtv-users] MytvTV Frontend
Freezes (seemingly no errors)
(http://www.gossamer-threads.com/lists/mythtv/users/114125 ). There
are also some debian64 users describing the same problem in the
On Sun, Mar 20, 2005 at 12:14:27PM -0500, Dan Christensen wrote:
Bruce Markey [EMAIL PROTECTED] writes:
The RecStatusChar is established and well known (C for conflict,
P for previously shown, card numbers for will record) and would
probably be more useful and familiar.
Yes, this is
I noticed some strange differences between the embedded vbi data while doing
video capture in MythTV (using mpegrecorder) and plain recordings from the
prompt.
Both capture the MPEG PS from /dev/video. MythTV just reads a block of data
and dumps this into a ringbuffer file, so nothing fancy.
Update of some files to support the following
- standard teletext graphics
- (black) background color(s) enabled by default
- use 'W' key to toggle between transparent and black background
As I am not sync-ed to the latest CVS, just overwrite the existing files with
the ones in the tar.gz (as
Chris Petersen [EMAIL PROTECTED] writes:
Yes, this is much better. But I would like to show nothing in the
case of something that will record or that will record at another
time, so only the problem cases are indicated.
Why not just change the css so the color is easier to see? As long as
Hi guys,
Just wondering if this would be a valid proposition:
Use the commercial-detection code to run on live tv to mute the
commericals.
Does anyone know the minimum system specs required to run the
commercial-detection code in real-time (or faster-than RT)?
anyone interested in helping me start
On Sat, Mar 19, 2005 at 09:35:51PM -0500, J. Donavan Stanley wrote:
Don't take all of the above to mean it's all been sweetness and sunshine
here in Stanley manner. I've had my share of headaches, but my
headaches have come from experimentation and me doing boneheaded things
to one or more of
On Sat, Mar 19, 2005 at 09:02:13PM -0800, Thomas M. Pluth wrote:
Also, HDTV cards, because of the data rate involved, are very selective
about the PCI chipset of the motherboard. They seem to work best on Intel
based boards (845, 865, 875 chipsets). They are very sensitive to PCI bus
Think latency. The HD-2000 has a small FIFO and overruns occur quite
easily.
-Original Message-
From: Brad Templeton [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 20, 2005 3:53 PM
To: [EMAIL PROTECTED]; Development of mythtv
Subject: Re: [mythtv] Re: Whats wrong with myth
On Sat, Mar
It is a pity there is no international open source Beer-o-gram
service.
Good idea, William. BeerBank? BeerTrade? BeerPal?
(www.beerpal.com actually exists,
but alas there is no bank component yet)
--
Nigel Pearson, [EMAIL PROTECTED] | People say I'm strange, does it
Telstra BID, Sydney,
Dan Christensen wrote:
(The problem is probably worse for me because
I have a 14 1600x1200 screen, so the border lines are very thin.)
Completely off topic but
DAMN you must have some good eyes!
___
mythtv-dev mailing list
I am doing some testing of my HD-2000 using DVB with an eye toward
pitching in to fix any issues I encounter. I've got it populating guide
data into the database from the one channel I can receive on the crappy
antenna attached to my dev box, but there are a lot of transmission
errors due to the
Daniel Thor Kristjansson wrote:
On Thu, 10 Mar 2005, Nigel Pearson wrote:
] I think the Xv and XVMC videoout stuff is identical
]in the geometry respect (being a derivative work), and I
]did made the same change to both, so both should be good?
I've attached a patch that makes the XVideo and
John Patrick Poet wrote:
Daniel Thor Kristjansson wrote:
On Thu, 10 Mar 2005, Nigel Pearson wrote:
]I think the Xv and XVMC videoout stuff is identical
]in the geometry respect (being a derivative work), and I
]did made the same change to both, so both should be good?
I've attached a patch
On Sun, 20 Mar 2005 12:14:27 -0500, Dan Christensen [EMAIL PROTECTED] wrote:
Bruce Markey [EMAIL PROTECTED] writes:
The RecStatusChar is established and well known (C for conflict,
P for previously shown, card numbers for will record) and would
probably be more useful and familiar.
22 matches
Mail list logo