Christopher N. Deckard [EMAIL PROTECTED] writes:
I'm getting this linker error when trying to build MythTV CVS (current
as of 11:20am EST November 30th). I've tried for a week to get this
resolved and haven't figured anything out. Any ideas?
...
/usr/bin/ld: postprocess.o: relocation
How is it unwieldy? People whine and moan about it, but I've not seen one
description of either a) how it's bad, or b) how to make it better that would
actually work with a remote control.
I have about 1300 albums ripped, so I have the same problem.
Personally, I'd like to see segregation
Personally, I'd like to see segregation by first letter happen
automatically once the number of entries at a particular level
(artist, album, etc.) rises above 4 or 5 screenfuls, so I don't have
to hit PgDn 70 times before getting to S.
You do know about 'splitartist', right?
Guess not. :)
Daniel Thor Kristjansson [EMAIL PROTECTED] writes:
I think this may be highly dependent on the number of cards and the
hard drive characteristics. Any chance you could detect buffer
overruns and use that as a signal to grow the buffer? Also what
about locking these pages in memory so that
I presume without doing any more in-depth research that these are
different symptoms of the same MMX problems that also plague the
ffmpeg/libavcodec code. It's likely that much of the assembly code
will need to be tweaked or rewritten for AMD64.
Cheers,
Kyle
Paul Barrette [EMAIL PROTECTED]
As Isaac suggested, this patch moves the fdatasync(fd) call to it's own
thread. The means that the ThreadedFileWriter does not have to wait for
that call to return before processing data.
What is the need to force a sync anyway?
In my experience, the default Linux I/O scheduler will
Simon Kenyon [EMAIL PROTECTED] writes:
i definitely remember linus saying that running without swap was a bad idea
(for linux that is). this of course might no longer be true; but it was at
one stage
I think it all depends on the amount of physical RAM one has in
relation to the amount of
Since the patches Isaac committed yesterday, my HDTV playback isn't
smooth. The recordings themselves are fine, but playback alternates
between slow (say 10-15 fps) and fast (say 30-35 fps) about once a
second or so. I have guests over, so for now I just sync'ed back to
24 Dec 00:00. I'll look
Thomas M. Pluth [EMAIL PROTECTED] writes:
Probably something with the ffmpeg resync and/or Daniels V39 patch?
I suspect it's the ffmpeg resync, though there are other changes in
that checkin (note to maintainer: logically separate out checkins to
make locating problems easier): when I resync
Doug Larrick [EMAIL PROTECTED] writes:
Your big issue here is that WGBHDT3 and WGBHDT4 don't really exist.
Unsubscribe from them at zap2it, and remove them. WHDHDT2 is another
phantom. The others look all right to me (I'm in the Boston area), but
you have duplicate channel numbers which
This patch should be self-explanatory.
Cheers,
Kyle
Index: libs/libmythtv/channelbase.cpp
===
RCS file: /var/lib/mythcvs/mythtv/libs/libmythtv/channelbase.cpp,v
retrieving revision 1.10
diff -u -r1.10 channelbase.cpp
---
Something I'm struggling with is the difference in vibrance between
ATSC and NTSC recordings, and between monitors (DLP vs. LCD vs. CRT,
in my case). NTSC recordings at the default PVR input levels look
very washed-out compared to ATSC recordings of the same material, but
I can modify the Xv
Mark Edwards [EMAIL PROTECTED] writes:
Presumably you are aware that brightness contrast etc can be set on a per
channel basis allready.
But I believe those columns from the channel table are used at
recording time, not playback time, no? Not sure if they're used on
the PVR's; they may only
Mark Spieth [EMAIL PROTECTED] writes:
doesnt help if you want to use timestretch.
will always be different.
works ok if desired rate = monitor refreshrate/2 when using xv at least.
So, my screens are at 60Hz, and my input is all 29.95 Hz, and I still
get this problem. However, I see the
So, my screens are at 60Hz, and my input is all 29.95 Hz, and I
still get this problem. However, I see the problem only with the
new ffmpeg; if I sync libavcodec (and nothing else) back to 24 Dec,
there's no issue. I'm puzzled as to what the ffmpeg guys could
have changed to cause this
Would it be possible to change the name to GANT or G-A-N-T or
whatever.
It would be better all around to get the Eclipse guys to fix their
busted code.
Cheers,
Kyle
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
This indeed fixes the problem I've been seeing. I didn't see any
traffic about this on mythtv-dev; what was the root of the problem?
Cheers,
Kyle
---BeginMessage---
Changes committed by ijr on Sat Jan 8 00:11:29 2005
Misdetection of streams with b-frames, essentially. Since libavformat now
generates good dts numbers (it didn't when the original code was written), I
just switched to using those instead of futzing with the pts numbers.
Can you translate to English? :) Sorry, I'm not all that familiar
Short version: I ditched the single frontend/backend dealie and
replaced it with a separate 3.2 P4 HT frontend and Athlon 1800 333 FSB
backend. Now, when recording HDTV (HD-2000) concurrently with a
recording from one of my ivtv cards, I get intermittent blockiness on
the HDTV stream.
Thing is,
Daniel Thor Kristjansson [EMAIL PROTECTED] writes:
This doesn't really jibe with my experience, unless you are running out
of CPU, which shouldn't be the case for a P4 3.2Ghz machine.
Well, the problem is evident in the recording itself, so it may be
that the 1.533 athlon isn't enough. But
So I think I had it backwards: the pcHDTV driver seems to report
buffer overrun when the device read buffer fills up because the
application isn't reading fast enough. This is probably therefore not
the issue.
I did a test today outside of myth with dtvstream and dd. I set up
dd's from
DFI PRO875B motherboard
3.0 GHz HT P4 cpu
1GB RAM
Three HD-3000 cards
Fedora Core 2 with stock 2.6.7 kernel (custom configured)
Myth CVS as of Jan 8th.
I can record three shows simultaneously, while watching a fourth, with
absolutely no data loss or coruption.
Well, at least I know
FWIW, the blockiness problem I've encountered appears limited to the
HD-2000: I get no such FIFO overrun issues with the 3000, so if you're
using only 3000's, you should be okay.
I am currently trying to grok the FIFO stuff in the bt878, because I
think the btatsc driver handles FIFO overrun
For the past few months, I have been seriously considering getting
ahold of one of those 169time.com-modified DirecTV HD receivers (they
add a firewire port) and adding support for it to MythTV to allow
recording of high-definition programming from DirecTV. I do not claim
to understand any of the
But when you're receiving data from some other system... or you're
trying to debug a piece of hardware, calling assert() when you see
some unexpected data doesn't necessarily help the debug process all
that much.
Agreed completely. An assert resulting from unexpected data input is
generally
Your response seems more than fair. The pricing structure of their
product will limit it to a very, very small market. Sad to say,
it's probably a non-starter so you are correct to not waste time on
it unless they show some committment to the MythTv community.
Yeah, I think I agree, much to
This:
I have become convinced that the motherboard is a critical factor
in how well the pcHDTV cards work.
is really unfortunate. I'm becoming more and more convinced that a
simple serial transport protocol a la firewire or USB but with better
access to memory is the right way to go for
If you have more than one tuner, and all are being used for recording (or
live
tv elsewhere), how does it pick which recording to automatically take you to?
It arbitrarily chooses the first tuner today; it could choose the
first tuner's recording under this system.
If all available
Jason Weinstein [EMAIL PROTECTED] writes:
Cool...now only if HDTV decoding could be handled by a Mac Mini...
Don't laugh: my Pentium M 1300 is oh-so-close with libmpeg2. Not
quite there, but it threatens to work when the on-screen content
doesn't change too quickly. My dream is viewing HDTV
Here's a last-minute patch I'd like to sneak in. It rotates the log
(i.e., reopens the logfile and dup2's it onto fd 1 and 2) when SIGHUP
is sent to mythbackend. Note that there are restrictions on what you
can do within a signal handler (specifically with regard to pthreads),
which is why there
Isaac Richards [EMAIL PROTECTED] writes:
I use myth on my primary desktop system and usually like watching programs
in a 800x600 window, however, occasionally I like to watch stuff full
screen. Mythfrontend as it stands now doesn't provide any non-tedious way
to accomplish that.
Why don't
In the end I concluded that the BT878 was inadequate for this purpose;
it isn't designed for it and so the FIFO is too small. It's provisioned
for audio data at up to a megabit, not ATSC/DVB data at 20 Mbit or
above.
I second this analysis. The megablocks patch I wrote for the HD-2000
driver
Ok, I've found an old patch from Kyle Rose to replace all
pthread_rwlock_* calls with a mix of pthread_mutex_* and
pthread_cond_*:
http://www.gossamer-threads.com/lists/mythtv/users/107232?search_string=pthread_rwlock;#107232
Isaac, is it a bad solution to replace them permanently
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.
Furthermore, WGBH (the local PBS
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 for
some time.. I
If you are not intending on contributing things back to myth, then you have
no
reason to be on this list. Please stop wasting other people's time with
off-topic junk.
Dan, don't mind Isaac; evidently he misplaced his bottle of Prozac this
morning.
Non-abrasively: mythtv-dev is for the
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?
Kyle
___
mythtv-dev mailing list
Daniel Kristjansson wrote:
Just do it, it won't be committed unless it's clean. Make sure it still
works with gcc 2.95.3, as this is still needed for some platforms.
I believe this basically means you can't use all the fancy C++ style
casts,
Not true. All the fancy (ISO) casts work great:
I believe either static_cast or const_cast doesn't exist in 2.95.
Nope. They both exist and work, as well as reinterpret_cast.
FWIW, having done lots of 2.95-3.3 porting, the main things you'll run
into are primarily syntax:
Everything's fine in myth with gcc 3.x. 4.x is a different
Are you seeing the problem I had where the lower part of the image is mpeg
blocks from another frame?
FWIW, I am seeing this now as well.
Kyle
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
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 workaround for this: I'm perfectly willing to deal with
the extra space taken up by
FWIW, I've (incorrectly) had non-zero overscan and scan displacement on
my desktop frontend for a long time; since the videoout_xv.cpp changes,
the top X lines of each frame have appeared at the bottom of the display
window, and everything else has been moved up by X lines. This effect
disappears
I have a question related to this commit:
Changes committed by danielk on Tue May 3 18:58:58 2005
...
This removes the next to last exit() call in the myth libraries.
It removes the exit() call in ThreadedFileWriter when an output
file can not be opened (due to permissions problems,
What woud happen to the file if the backend was unable to write some data
and then later succeeds in writing?
Maybe mpeg2 files can handle this, but what about nupplevideo type nuv
files? Woudn't that result in a corrupt file after the point where it failed
to write for a while?
I put this
This is on a
bartoon athlon
In association with Ay Carumba Entertainment? :)
Sorry, couldn't resist.
Cheers,
Kyle
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Kyle Rose wrote:
Attached is a patch to add AudioScrobbler support to MythMusic. It is
not quite final: once I receive a plugin ID from the AS guys, that will
need to replace the testing id tst in the MythScrobbler constructor.
The patch I attached doesn't quite work as I intended. Try
This makes Xinerama displays the same aspect as the videos.
My first included patch fixes screen aspect ratio detection with Xinerama.
Also adding a log message for when no physical display size found.
My second patch allows changes to setup-appearance to have effect without
restarting
MythTV wrote:
#33: SIGHUP log rotation
+---
Id: 33 | Status: new
Component: mythtv |Modified: Fri Jul 1 21:53:19 2005
Severity: low | Milestone: 0.19
48 matches
Mail list logo
