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
> 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
> res
Here's a slightly better patch: it adds a toggle for the AudioScrobbler
support, so you can shut it off without erasing the username/password.
Otherwise, functionality hasn't changed. I still haven't received a
permanent AS plugin ID, so the patch isn't yet final. If you use
AudioScrobbler, pleas
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
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.
This support was designed to require as few changes to the stock
libscrobbler (provi
> 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
> 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 th
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,
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
>>What is a good combination of pcHDTV DVB and ivtv drivers?
>
>
> I'm using dvb cvs code from around the beginning of March with a v4l snap of
> roughly the same vintage and tracking the very latest ivtv dev releases (all
> of which have pretty must just worked since roughly 0.3.2e-ish for me
> 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 hours of trial-and-error. :)
What is a good combination of pcHDTV DVB and
> 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 b
> 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
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 di
> 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
mythtv-dev@mythtv
> No, it'd be offtopic on the users list, too.
As I indicated. But a lower signal-to-noise ratio seems to be accepted
there than here.
Cheers,
Kyle
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 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
> 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..
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 a
> 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 repl
> 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
dri
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.
>
>
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
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
> We're discussing what happens when all tuners are in use. See the subject
> line of the email?
Point taken.
Kyle
___
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>> > 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.
>
> Myth
> 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
Joe Barnhart <[EMAIL PROTECTED]> writes:
> Well... How about Opteron's little brother? I'm building a backend
> with two PCHD-3000s on a dual Athlon MP board (Tyan Tiger MPX). It
> has two Athlon MP 2000 processors, but I've considered using my old
> clunky 1200 processors if they can keep up wi
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 the
> 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
> 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
genera
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
I wanted to try a longer buffer in the bttv driver, so I grabbed the
data sheet from Conexant's site and had a look. Unfortunately, they
don't make it easy: it appears that 256K is as long a buffer as one
can determinstically support with the given microcode, because there
are only 4 bits for the s
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 situa
> 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 leas
> I saw this with an early version of the HD3000 driver. Have not
> seen it since v1.3, however.
On HD-3000 or 2000? I haven't tried the 3000 card yet: it may react
better. That's something to try.
> Does it happen with ALL of your stations?
Well, it happens at least with ABC, FOX and PBS-HD.
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 /dev/vide
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. Bu
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, I
> 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
w
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
--- Begin Message ---
Changes committed by ijr on Sat Jan 8 00:11:29 200
> This should also let us treat the bttv inputs as extra inputs on the
> pcHDTV when scheduling recordings, so we don't try to record from
> both at the same time (they share a tuner).
BFO: this will be very useful for implementing something like a
"MythRadio" that uses the radio tuner from a PVR
> 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
http://mythtv.org/cgi-bin/mailman/
>> 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
"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 t
I was wrong about setting Bob correctly getting rid of the jittery
playback: it was the lack of a control that led me to believe it was
gone.
The difference appears to be that the jitter happens only in the
presence of both Xv output and the new ffmpeg code. I don't know how
the two can possibly
"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 o
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 pictu
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
--- libs/libmyth
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 w
Apparently, this problem:
> I have had a problem in the very recent past (last week or two) in
> which my freqid column in the channel table for the local DirecTV
> channels (yeah, weird) has been getting set to NULL, so my channel
> changing script has no argument passed to it.
is to be solved b
"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 resyn
"Thomas M. Pluth" <[EMAIL PROTECTED]> writes:
> I've noticed jumpy playback when I'm watching Live TV, but watching
> recordings seems to be perfect.
Not here: I get this on recordings. Don't know if it happens with
live TV or not.
> I've got Daniels V38 patch and John PP's ringbuffer patch ins
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
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
> IMHO, and not having tried it, the new system sounds like a winner.
> The only big problem I see is if the system goes into swap, it would
> spiral out of control needing more and more buffers as it struggles
> to keep up. Perhaps detecting the amount of physical RAM in the
> system and limiting
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]> wri
Daniel, I just started using this along with John's ringbuffer patch,
and everything works incredibly well: no buffer underruns so far, for
instance. Great work!
Cheers,
Kyle
Daniel Thor Kristjansson <[EMAIL PROTECTED]> writes:
> This patch fixes three problems with the hdtv reccorder. It's bee
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 tha
Rutger Hendriks <[EMAIL PROTECTED]> writes:
> Hi list,
>
> the problem described below still applies on CVS for a few seconds ago
> I have now -fPIC -DPIC -fPIC in the following variables:
> CFLAGS, CXXFLAGS, LFLAGS, LIBS
> in the Makefile in mythtv/libs/libavcodec
>
> Any input is appreciated. I
>> 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 wi
>> 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?
Gue
> 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 segregatio
Doug Larrick <[EMAIL PROTECTED]> writes:
> 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 datad
Bruce Markey <[EMAIL PROTECTED]> writes:
> Works for me and Doug didn't object so I've committed this.
Excellent.
I'd love to hear some confirmation from other users that this patch
fixes the "jitter" problems despite having had OpenGL support compiled
in.
This was one of the two remaining big
"Flo Kohlert" <[EMAIL PROTECTED]> writes:
>> FWIW, OpenGL vsync wasn't working for me because vsync.cpp does some
>> of the GLX initialization in a non-portable way. I didn't bother
>> trying to figure out which of the following modifications fix the
>> problem, but one of them does.
>>
>> Is th
"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: relocati
> Umm... because that's how the calls were made in the examples cited in
> the code? I'm glad to see somebody who knows more about OpenGL look it
> over.
Oh, I don't want to make it sound like I know ass about OpenGL: I
haven't done any GL programming since 1997. I stole all of my changes
from
FWIW, OpenGL vsync wasn't working for me because vsync.cpp does some
of the GLX initialization in a non-portable way. I didn't bother
trying to figure out which of the following modifications fix the
problem, but one of them does.
Is there a specific reason the following calls were made the way t
> Not sure. Try an earlier version of the driver (I have 6111) and see if
> this makes a difference?
Nah, same deal with 6111.
I'll look into it more when I get more time. I'm pretty hosed at the
moment...
Kyle
___
mythtv-dev mailing list
[EMAIL PRO
71 matches
Mail list logo
