Daniel Kristjansson wrote:
> I asked in commits if someone using these could test the patch on #730 a
> few days ago. But no one seems to have responded.
>
> Does anyone actually use passthru?
>
> If not, removing the passthru feature could simplify the code a bit...
I definitely use AC3 passthru.
Robert LeBlanc wrote:
> Here is the status. I put in to Debian to pick up the requested package
> mythtv. I have yet to hear a response. I may have not done It right
> either, but I followed what instructions I could find on their web site.
> I tried to set-up a project on alioth.debian.org, but th
Adam Egger wrote:
> So does anyone have a working debian folder? Debs created with my
> debian folder still show lots of error messages in lintian/linda but
> they could be a good starting point if you guys don't have a better
> one.
I have a "working" debian directory that's minimally hacked from
> The filters seem simple enough, but I've yet to understand why bobdeint
> (which i'm using as a template)
> works at twice the framerate while the other filters do not.
The code that actually doubles the framerate is in the VideoOutput and
VideoOutputXv classes, and their interaction with Nuppel
Taylor Ralph wrote:
> The
> reason I disabled using video as timebase was due to
> an issue using it and AC3 passthrough together. Using
> both of these options caused only a few bleeps of
> sound every second or so to be processed on my
> receiver yet the video played back smoothly. This
> happene
Daniel Kristjansson wrote:
> 1/ make sure timestretch only works when it is 'safe',
> i.e. the audio is not being decoded extranally.
I have a patch (from John Poet) that does this. It works for me; fails
for him (no audio). I also can't do any Myth work until Debian
completes its gcc4 tran
Mark Spieth wrote:
> mpeg2 seek support in libavformat is not as good as it should be as it has
> no knowledge about keyframes. hence my fudge of seeking mpeg1/2 at least 15
> frames before the frame desired so that it hits a keyframe on its way to
> getting the actual frame being sought. This is n
I'd just like to mention that I recorded a mono AC3 program from my
local PBS station this past week (ATSC). Without this patch (or
something like it), mythfrontend hangs CPU-bound trying to play, or
mythbackend hangs trying to make a preview pixmap. With this patch it
plays fine.
Original patch
Robert Tsai wrote:
> Look in -commits; this has been patched around in dvbconfparser.cpp
Thanks. For the record:
http://www.gossamer-threads.com/lists/mythtv/dev/136034
-Doug
signature.asc
Description: OpenPGP digital signature
___
mythtv-dev mailing
Is anyone else seeing this? I have a fresh checkout of mythtv, and have
done 'apt-get build-dep mythtv'. I've been building MythTV for a couple
years w/o hassle, but now I get:
g++-3.4 -c -pipe -mcpu=i686 -mtune=pentium4 -Wall -W -O3 -Wall
-Wno-switch -fomit-frame-pointer `freetype-config --cfla
Isaac Richards wrote:
>>Probably makes sense to wait for 2.6.12 to be at least released, if not
>>shipped by at least one major distro. This is the kernel that has the
>>DVB drivers for both HD-2000 and HD-3000 cards in it.
>
>
> Are the v4l drivers for it in the kernel?
Nope. Though they ship
Isaac Richards wrote:
> Speaking of which, when are we deprecating the hdtvrecorder stuff? Doesn't
> make sense to support two different drivers for the same hardware to me,
> especially when one (ie, DVB) is much more of a standard.
Probably makes sense to wait for 2.6.12 to be at least releas
John P Poet wrote:
> What happens when BOB is used with 480p for 480i material? Is each
> field scaled from 240 to 480, and then "bobbed" out to the TV? I
> assumed that any scaling would happen after the video was
> deinterlaced.
That's right. It's deinterlaced first, then each field is scaled
John P Poet wrote:
> Is anyone using the BOB deinterlacer with SD material? If so, what
> modeline are you using?
I went through a similar process to what you described (and I snipped),
but ended up watching 480i material scaled to 540p since (a) the OSD
looks so much better, and the video is not
Christian Hoehle wrote:
> My OSD flickers heavily if I use bob-deinterlacing. Flickering only occurs
> on playing back with speed 1.00x. If I change speed to 1.05x or 0.95x (or
> any other value except 1.00x), OSD is displayed flawlessly.
>
> Any ideas?
This is a known limitation of the way bob cu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Kristjansson wrote:
> I think Doug had a test stream where the PMT changed every few seconds.
To be fair, I went to extremes to capture it, but...
http://jekyl.no-ip.org/doug/change.mpg (22 MB) -- please be gentle to my
cable modem.
- -Doug
-
Taylor Jacob wrote:
> I guess the subject is wrong then..
Yeah, subject line's about a week old... sorry :-)
-Doug
signature.asc
Description: OpenPGP digital signature
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman
Taylor Jacob wrote:
> There is no cached VCT for myth to use when its scaning.. There is nothing I
> can
> really do about doing a scan when the VCT isn't present other than make some
> educated guesses at what channels are present in the stream.. I need to code
> this up for doing a scan of cable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kyle Rose wrote:
>>I thought Taylor said DVB should fall back to the cached TVCT in the
>>case where it doesn't see a new one? Or are you using V4L (hdtvrecorder)?
>
>
> I'm still using V4L. I guess this means I should switch, which means a
> few h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kyle Rose wrote:
>>Your carrier is not sending PSIP at all.. There is supposed to be data on the
>>1FFB PID, and that is why the scan is hanging..
>
>
> This happened again tonight on WFXT (Boston area FOX affiliate). There
> needs to be a workaroun
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Kristjansson wrote:
> Yes, but I fixed it by not getting the X11 lock for
> glXWaitVideoSyncSGI().
>
> I can't google anything that says this is safe though.
IIRC the OpenGL context includes the thread that created it, and it's
only safe to us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Kristjansson wrote:
> I just wanted to add that I expect there to be a few problems as this
> gets wider testing.
>
> Bring it on.
Hi Daniel,
This looks good for Xv. No problems so far in my testing.
Things are not so good for XvMC for me.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Terry Barnaby wrote:
> Doug Larrick wrote:
>> A couple weeks ago Isaac indicated that some (most? many?) video
>> cards/drivers can't scale video into such a small overlay.
>
> I think this would be a worth while feature. O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Boleslaw Ciesielski wrote:
> Doug Larrick wrote:
>
>> I have a crappy not-quite-right PSIP parser that I wrote as an exercise.
>> If you'd like it, get the source from
>> http://jekyl.no-ip.org/doug/psipguide.C
>&g
Kyle Rose wrote:
>>Well either you did, and it worked, or they noticed it themselves (or
>>read this list!). WFXT PSIP (complete with 3 days' guide data) looks to
>>be back on line.
>
>
> What tool are you using to get this?
I have a crappy not-quite-right PSIP parser that I wrote as an exercise.
Kyle Rose wrote:
>>The TVCT caching with the dvb code SHOULD allow this to continue to work even
>>when the PSIP is not present as long as the MpegTS Program Number has not
>>changed since the TVCT stopped being sent.
>>
>>This is the third station I have heard about that has stopped sending PSIP f
Kyle Rose wrote:
> Recently, WFXT (the local FOX affiliate) won't record in MythTV: I end
> up with zero-byte files, and the backend complains of not getting data
> from the capture card. However, if I change the channel with dtvstream
> and then dd directly from the device, I get data.
I'm also
Thomas Börkel wrote:
> HI!
>
> Ivor Hewitt wrote:
>
>> Yay. Thanks for the tip Doug, forcing the driver to use a real
>> modeline and we have smooth video. Magic.
>
>
> Is this also possible with NVidia cards?
>
> I always get:
>
> DRMVideoSync: Could not open device /dev/dri/card0
nVidi
Ivor Hewitt wrote:
> Would it be more accurate for mythtv to actually time the drm sync
> interval to establish the refresh rate rather than use the refresh rate
> reported by X? or does it just use that value as a guide?
Probably not. Reading what's specified to the hardware should be more
preci
Ivor Hewitt wrote:
> # xvidtune -show
> "1280x1024" 0.00 1280000 1024000
>
> Hmmm, could that be the problem? The driver is using a synthetic
> modeline which isn't fully populated?
That's definitely weird. At 0 MHz pixel clock, it should take an
infinite amount o
Ivor Hewitt wrote:
> I have a drm vsync question
>
> I'm currently getting myth working on a VIA CN400 unichrome-pro board...
> the current problem I've got is that the mythplayer is running away with
> itself and seems to have problems with the drm timing calculation.
>
> A log from a cn400 (@
Taylor Jacob wrote:
> Quoting Doug Larrick <[EMAIL PROTECTED]>:
>
>>Well a lot of the code (especially Daniel's new code) was a nice
>>framework to parse and get useful information out of the TS stream. Had
>>the DVB folks (not Myth, the driver author
Daniel Kristjansson wrote:
> On Thu, 2005-03-24 at 00:15 -0500, Andy Poling wrote:
>>It also has a small change to OpenGLVideoSync::WaitForFrame in vsync.cpp that
>>prevents what I think is an aggravation of an already late situation. Instead
>>of forcing us to wait an entire frame if we're late,
The attached patch has 3 pieces of code:
* code to locally check the CRC of ATSC EIT and ETT packets. This is
#ifdef'd out, but I included it as a potential debug aid, and to show
how little code it actually is :-)
* Minimal support for MSS (multiple segment strings) with more than one
segment. S
[EMAIL PROTECTED] wrote:
Changes committed by taylor on Tue Mar 22 23:56:32 2005
Modified Files:
in mythtv/libs/libmythtv:
siparser.cpp
Log Message:
Stop discarding channels in VCTs that have a minor number of 0
Taylor Jacob wrote:
Can you try the attached patch, and let me know if
you get other tables slipping through that are bad? I need to validate the DVB
docs before I use this as a blanket solution hence no commit on this one yet..
Looks like a winner... no bad CRCs all day.
-Doug
signature.asc
Des
Daniel Thor Kristjansson wrote:
> On Tue, 22 Mar 2005, Taylor Jacob wrote:
> ]Quoting Doug Larrick <[EMAIL PROTECTED]>:
> ]It seems more reasonable to just drop the table to me.. Having CRC code in
> ]multiple places seems like a bad idea.. With the frequency of any section
Taylor Jacob wrote:
It appears that the drivers ONLY check tables that have the
section_syntax_indicator set.. This is the correct thing to do, but if that 1
bit is screwed up you will be in trouble.. I got a number of tables that were
dropped because of this.. Can you try the attached patch, and l
Taylor Jacob wrote:
If you look at the dvb driver API and the code in question, you will see that
the demux driver does section reassembly in software and or hardware (depending
on if your transport ic can do it in hardware or not). It is ONLY for section
data the dvb driver does CRC validation..
Taylor Jacob wrote:
Quoting Doug Larrick <[EMAIL PROTECTED]>:
So my question... I note that the code is sending a flag to the driver
to check CRC for the EIT and ETT PIDs. Is Myth supposed to check some
flag on the packet and drop bad ones, or is the driver supposed to
filter out packet
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 f
It appears the DVB drivers for *both* pcHDTV cards, including QAM
support for HD-3000, have been accepted into the DVB CVS repository.
I also saw a note on the pchdtv forum that it's possible to use the
normal v4l analog capture driver alongside the DVB digital driver
(though obviously not at the
Brad Templeton wrote:
> Again, am I missing something? When does the player play DVDs? Or is
> this something planned for the future, switching from mplayer for that
> function?
1. I think you can specify to use the internal player for MythVideo. I
don't use MythVideo at all, so I don't know.
2
John Pullan wrote:
> We put in a preferredLanguages setting in the db (comma separated list
> of language codes). We use it for the choosing which epg language to
> grab from the dvb stream, and I *think* also for choosing which audio
> stream to record.
hdtvrecorder records all the audio streams
Brad Templeton wrote:
[Whoops, somehow I sent this to users instead of dev]
This is a patch that seems to work for the problem I described in
a recent message to mythtv-users entitled:
"Picking the wrong audio stream from multi-stream AC3 causing no sound?"
This patch makes the code do what the
[EMAIL PROTECTED] wrote:
> Discard 'early' audio packets (timestamped too much before video) for
> less slow video at the start of playback/seeks/channel changes.
> Quicker exiting on recorded shows (> 30 minutes unmodified). Fix some
> infinite loops if attempting to pause at the wrong time.
>
> P
Daniel Thor Kristjansson wrote:
]So Daniel (or anyone), are you working on moving over to the new DVB
]stuff, or would you like some help?
Help would be good ;)
My current priorities are:
1/ support analog on pcHDTV cards
2/ signal monitoring, user feedback for tuning
3/ subtitles for ATSC
4/ c
Todd Freeman wrote:
I am not sure how many people I am speaking for... I know at least
myself... but until there is a way to do analog recording from the
pchdtv with either a seperate driver or with the DVB drivers I am not
too hot on development moving over to them.
I'm not talking about the DVB d
John Patrick Poet wrote:
Doug disable the patch to tune ATSC channels by looking at both the
major and minor portions of the channel number. This was the correct
thing to do, since it was broken. As he pointed out, that code was
looking at the Frequency ID instead of the Channel number to determi
Chris Pinkham wrote:
Just committed [a bunch of fixes here] to CVS.
Thanks, Chris! Wow, that was a real tempest in a teapot.
-Doug
signature.asc
Description: OpenPGP digital signature
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/
Ivor Hewitt wrote:
In that case I don't understand the bob logic for the PutImage calls. The
adjustments to the y position affect the destination position not the source.
The logic appears to only make sense where dest resolution is the same as the
source resolution, I can't see how it could/would
Doug Larrick wrote:
When I delete a program from Watch Recordings, it doesn't get removed
from the list. The file is gone, and exiting and re-entering Watch
Recordings shows the program as gone. This bug is new over the past few
days.
Nope. Never mind. It's just taking 10-30
When I delete a program from Watch Recordings, it doesn't get removed
from the list. The file is gone, and exiting and re-entering Watch
Recordings shows the program as gone. This bug is new over the past few
days.
-Doug
signature.asc
Description: OpenPGP digital signature
_
Bruce Markey wrote:
However, attached is a quick patch for testing.
Nope :-)
-Doug
signature.asc
Description: OpenPGP digital signature
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Jay Merrifield wrote:
I've been having this problem for a while now, I'm running the latest
CVS version on a P4 2.8Ghz Fedora Core 2 system with a hd3000 card. I
can view 720p HDTV signals just fine, they usually take up about
60-70% of my cpu power, but when I try and to watch a 1080i source, I
ge
Daniel Thor Kristjansson wrote:
I've attached a patch that makes the fix and also ads two super verbose
VB_PLAYBACK macros that should help me debug the problems people
encounter.
FYI, I see some weirdness (seems like one field scaled more than the
other) on my main Myth box when in any of the zoom
Daniel Thor Kristjansson wrote:
A yagi is the same thing except the rods are evenly spaced and each is
as long as the other. This is a high gain, narrow band antenna. The more
segments (rods) a yagi has the more directional and higher gain it is.
Both types of antenna's usually have a reflector at
Taylor Jacob wrote:
Can anyone else take a look at what their ATSC broadcasters are sending? The
FCC PSIP mandate has now kicked in, and in my market ALL the stations are
sending valid guide data over the air along with proper STT times, etc..
Here are the Boston-area stations I receive. Some are
Taylor Jacob wrote:
Quoting "Tom E. Craddock, Jr." <[EMAIL PROTECTED]>:
How do you scan for that info with say..the pchdtv3k card?
I think there is an app for the pchdtv you can use to look at the guide..
You can try my crappy 'psipguide' proof-of-concept test program...
source here: http://jekyl.n
I was hoping John Poet would chime in himself on this, but this is a big
bug for HDTV users (may cause them to record the wrong subchannel) and
so I think it's important for it to go in.
It's my belief this functionality can't work the way it's coded. The
required major channel number is not relia
Wendy Seltzer wrote:
From today's cvs, I can't tune subchannels other than 1 in US HDTV.
I think I see the problem. The recently-applied patch (21-Jan) "ATSC
major_minor channel selection patch from John Poet" is incorrect. It is
confusing the major channel number with the FCC (broadcast) freque
Jeremiah Morris wrote:
Just a quick announcement about a recently added feature:
The latest CVS now includes a version of libmpeg2
(http://libmpeg2.sourceforge.net) as an alternative to the FFMpeg-based
video decoding. FFMpeg still handles the demuxing, but the video can be
handed to libmpeg2 inste
Jeremiah Morris wrote:
Just a quick announcement about a recently added feature:
The latest CVS now includes a version of libmpeg2
(http://libmpeg2.sourceforge.net) as an alternative to the FFMpeg-based
video decoding. FFMpeg still handles the demuxing, but the video can be
handed to libmpeg2 inste
thor wrote:
Attached is a short patch that will add a command line option
(--no_channel_name_updates) to mythfilldatabase. This will prevent the
updating logic from rewriting the channel's name with whatever it is called
by the source of the listing data. Ie. You can edit your channel names in the
On Wed, Jan 19, 2005 at 08:31:21PM -0600, Chris Mumford wrote:
I still have to add up the columns 56.1% + 38.2% + 4.1% + 2.1% = 100.5%
which makes sense since the best synthetic hyperthreading improvement was
7%.
The improvement with HyperThreading is not a fixed amount. It depends
on how much eac
Eric Anderson wrote:
So yesterday I wrote a small program to scan through the saved
transport stream to try to figure out *how* the data was corrupted.
What I found is sets of duplicate packets. Thus, I am starting to
think that this is a driver issue.
Just out of curiosity... do the duplicate pack
John Patrick Poet wrote:
This patch fixes the ATSC program tuning code to look for the major
channel number in addition to the minor channel number.
Interesting. You've got stations broadcasting more than one major
channel number? Not that there's anything wrong with that, but I would
not expe
Neil Whelchel wrote:
Hello,
I was just wondering if anyone was working on or planning to work on a
patch to use timestretch to keep live tv playback in sync. IE If playing
live tv and the current playback position is within 30 seconds of real
time, use timestretch to keep it there. If not, I would
Taylor Jacob wrote:
Any of the PCHDTV guys please feel free to look this over especially the
Database structure used for tuning as it will not change..
Not having a DVB card handy, I find it tough to scan the database
structure from the patch. Would somebody be willing to do a dump of
their capt
Stephen Hocking wrote:
All,
After being away from home for some time, returning recently and rebuilding
myth, I see that mythfilldatabase mangles the HDTV channel frequencies to be the
same as the channel number. Is there a fix in the works for this? Or do I have
to correct the channel frequencies
The attached patch fixes a couple problems in dealing with ATSC's
virtual channel tables:
1. It seems some channel names are NULL-padded rather than space-padded
out to 7 characters like they should be.
2. If we don't see the requested subchannel, fall back to the first one
in the table, and com
Angel Li wrote:
I didn't know about the "+" key, where is that mentioned?
I had thought it was in keys.txt, but I don't see it there.
-Doug
signature.asc
Description: OpenPGP digital signature
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://myt
Taylor Jacob wrote:
DVB guide data can't replace xmltv in Australia either. Last I checked,
our networks were only transmitting information about the next two
programs. We can get xmltv data for up to a week via the internet.
Yes its situations like this that require both XMLTV and OTA guide to be
David Shay wrote:
- Original Message -
From: "Ivor Hewitt" <[EMAIL PROTECTED]>
To:
Sent: Monday, January 03, 2005 3:00 PM
Subject: Re: [mythtv] Experimental epia/xvmc colour osd HACK
Just wanted to report that I, too, have applied this to Jan. 1 CVS and
it
works great. Stuttering stops an
Angel Li wrote:
Hello,
I'm having a problem with some HD channels, e.g. Fox NFL on Sundays,
which display video but there is no sound. Attached is the mythtv output
when trying to play back a file recorded yesterday. If you want to
download the clip you can get it at
Does the sound come back if
Ashley Clark wrote:
On Jan 1, 2005, at 5:04 PM, Doug Larrick wrote:
The attached simple patch uses the HDTV-style channum for HDTV
channels (_, rather than just the channel number, when
updating an existing channel from DataDirect.
I have a problem with this new patch. The guide information is
Taylor Jacob wrote:
Let me just state up front that I think merging more of DVB and pcHDTV
support is a good goal. I think we're suffering from a lack of
communication and information, not any desire to undermine these plans.
The concept behind my dvb patchset is to create a database heiarachy
The attached simple patch uses the HDTV-style channum for HDTV channels
(_, rather than just the channel number, when updating an
existing channel from DataDirect.
-Doug
Index: programs/mythfilldatabase/filldata.cpp
===
RCS file: /v
Eric Anderson wrote:
Okay, so I don't claim to know much about PSIP, but from the comments,
0xCC is ETT (extended text table). And from looking at the code, we're not
doing anything with ETT anyway (ie, DECODE_ETT = 0). So what to do?
Perhaps the CRC computation for ETT packets is different?
CRC co
Kyle Rose wrote:
On a tangentially-related topic, can someone review for me what I need
to do with respect to ATSC minor channel numbers and freqid?
This changed recently, for the better. Previously, you had to manually
enter the real channel and program number into freqid, but now we get
the re
Daniel Thor Kristjansson wrote:
Most of audio information with ATSC is not in the stream that ffmpeg
sees. Even the limited audio descriptor sometimes present in the PMT is
jettisoned with the PMT rewriting. I don't think ffmpeg even tries to
look at this information, but we don't save it in the
Well, what it really requires is for someone to look up the rule used
for audio streams in MPEG2 files. There must be some sort of rule,
otherwise stand alone DVD players and HDTVs would get it wrong. In
my (limited) testing, DVDs appear to follow a pattern of the highest
numbered track that meet
J. Donavan Stanley wrote:
Doug Larrick wrote:
The attached patch modifies AvFormatDecoder::autoSelectAudioTrack() to
prefer an audio stream that is mentioned earlier in the tables
(lower-numbered). My PBS stations often have two audio tracks -- the
normal one, and DVS (Descriptive Video
The attached patch modifies AvFormatDecoder::autoSelectAudioTrack() to
prefer an audio stream that is mentioned earlier in the tables
(lower-numbered). My PBS stations often have two audio tracks -- the
normal one, and DVS (Descriptive Video Service, for the
vision-impaired). The current code
Whenever I attach a patch and send it to the list, my message has a PGP
signature verification failure. I think this is because my mailer
(Mozilla Thunderbird w/ Enigmail) is signing the entire MIME message
(including the patch), and the list processing software adds its own
footer as a MIME a
Doug Larrick wrote:
The attached patch fixes a longstanding difficulty in setting up an HDTV
Myth box, namely that you needed to go in and manually set the freqid
field in your database as appropriate for each of your stations.
Look back in this thread for the rest of the details.
This version
John Patrick Poet wrote:
Do you know how to detect the amount of physical RAM in the system?
Well, you could popen out to vmstat on a UNIX-like machine... I don't
know of a fully portable way.
I just got an early Christmas present in the form of a Seagate 400GB
drive. I have been wanting to com
John Patrick Poet wrote:
I have written a version of the hdtvrecorder ringbuffer code which
creates a variable number of ringbuffers, per recording.
Each ringbuffer is 20mb in size. If a ringbuffer fills up, another
ringbuffer is created and all new data is written to it. When the
filewriter
[EMAIL PROTECTED] wrote:
The current MythTV in CVS does not compile.
The problem is a missing INCLUDE file
tspacket.h
used in
hdtvrecorder.h
and indirectly in
hdtvrecorder.cpp
Anyone know where it is?
cvs update -d
-Doug
signature.asc
Description: OpenPGP digital signature
Ed Wildgoose wrote:
The "juddering" may be the same as I am seeing. See my post "Problem
with severe video jitter in current MythTv".
This started occuring after upgrading to the CVS release after 0.16.
I am tracking this down by rebuilding MythTv on various CVS dates.
So far the problem seems t
Joe Barnhart wrote:
I really like this idea. Watching high-def shows in
1080i, I noticed that the mythfrontend sometimes
reports 1088 vertical resolution instead of 1080. I
think this causes Xv to scale the result, which lowers
the quality. Note, this the VERTICAL dimension rather
than the horizo
John Patrick Poet wrote:
Here is my version of a ringbuffer thread for hdtvrecorder. I had not
actually planned on posting this quite yet, but since this is now a hot
topic, here you go.
Just wanted to say that the combination of this patch and Daniel's
cleanup patch (hdtv-recorder-v38) fixed a
[EMAIL PROTECTED] wrote:
And it must not break the database/setup for those of us who cannot run
mythfilldatabase as there is no feed/info available (eg perth)
These changes only affect the built-in zap2it DataDirect grabber.
Though if you're manually setting up freqid's for HDTV in the database,
Joshua M. Thompson wrote:
What seems logical to me is to default to the first subchannel and
provide a function mappable to a remote button to flip between the
subchannels.
Actually, this doesn't make sense at all, at least in my area. The
subchannels are not really related.
I have 3 channels wi
Daniel Thor Kristjansson wrote:
Should those be HDTV channel 2-1 and NTSC channel 21? That way if there
is a HDTV channel 2-10 and 21-0 there is no ambiguity. (Channel 21-0
would be NTSC channel 21 in the HDTV naming system.)
But the infrastructure in Myth to allow non-numeric channel numbers
(i
Taylor Jacob wrote:
With DVB only the PAT and PMTs are read real time the SDT (Same as your TVCT)
and other tables are all run from cached versions and when an updated version
shows up in the stream the Database is updated to reflect this (much like a
real set top box would do).
Good to know. Yes,
Kyle Rose wrote:
Doug, what will this patch do to my existing channel setup? Should I
blow away the rows in the channel and program tables associated with
the HDTV input before I run mythfilldatabase?
No need. For existing channels mythfilldatabase will simply rewrite the
freqid field. If you d
bill peck wrote:
Am I missing something on the channel part? What if I
have the following channels:
hdtv channel 2 subchannel 1
ntsc channel 21
Won't both of these channels be channel 21?
Yes, they will, assuming you have both an ATSC and an NTSC tuner in the
same system. If 21 is standard-def
The attached patch fixes a longstanding difficulty in setting up an HDTV
Myth box, namely that you needed to go in and manually set the freqid
field in your database as appropriate for each of your stations. This
information is provided by datadirect, and thanks to Daniel's recent
work in the
1 - 100 of 104 matches
Mail list logo
