> "Mark" == Mark Anderson <[EMAIL PROTECTED]> writes:
Mark> On Thu, 13 Jan 2005 02:01 am, Jesper Sörensen wrote:
>> Tim Davies skrev: >>If you are talking about the
>> STREAM_TYPE_PRIVATE_DATA => >>STREAM_TYPE_AUDIO_AC3 fix in
>> DVBRecorder::CreatePMT then you are >>completely
MythMusic segfaults the frontend when I load without any playlists or
ActivePlayQueue. If I go into select music, and choose one song to
be added to the active play queue, it works fine. I started looking
for a NULL pointer in databasebox or playlist.cpp, but haven't found
it yet. Heading to be
Hi.
I don't know if this is just me or if it is the general case right now
but apparently the 'originalairdate' for shows is not being stored in
the 'recorded' table even though there is a field for it. I have this
belief as all my recorded shows have '-00-00' as their value in the
'recorded'
Well, I was appropriately chastised on the user's list for not
contributing code, so I put together a small but useful mythweb
patch which is included. I had not coded in PHP before but it's
pretty similar to many other languages.
This patch modifies the mythweb search to allow you to see all
mo
After some distraction setting up a second backend to debug on, I've
tracked down the problem I was having with live recording playback
ending prematurely. The problem is that the timeout in
RingBuffer:safe_read is 0.9 seconds, which is shorter than the 1 second
write period in RingBuffer:Disk
Here's the results of my testing of transform.c/h.
This is using the avformatdecoder.cpp patches from Mark and the one line AC3
change in dvbrecorder.cpp. No patches to mpeg.c and using software AC3.
Yep, a bit of a mouthful!
Recording the TS: (I took out the incCurrentAudio bit for this)
- No
All,
I'm having problems getting my new pcHDTV card to work with Myth.
I can dtvsignal (96%) and watch via mplayer just fine. But when
changing to the same channel using myth I get a large black border on
three sides + a large pink border on the fourth. Also, the sound is
muddled and any chann
I am currently working with the MythBurn creator to get the mythtv
part finished. He has this as a separate module.
I think that it's possibly better to put this code (and future cd burn
support) in the respective modules: mythdvd, mythmusic. With each
module in charge of burning files.I'
>
> > I don't see a pattern there. Maybe there is just something wrong with
> the
> > code that gets the video timings wrong in a transport stream. I haven't
> > tried to understand that (yet!).
>
> Have you checked to see if the PCR is making it into the TS?
Yes it is. The problem seems to c
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
As of late In program listings I am missing channel 77 SPEED (I just
downloaded from CVS the other day).
Thanks to the prompt help of Tom at zap2it.com it looks like
mythfilldatabase may be in error when pulling down a lineup that has two
different channels "77" and "408".
zap2it.com shows that I
Jesper Sörensen wrote:
Please try the attached patch (against patch 3.5). Unfortunately the
paths in the patch are wrong but it should work if you specify the
file names manually when applying the patch. Let me know if you
can't get it to apply and I'll try and make a new one for you.
I manage
On Wed, 12 Jan 2005 09:15 am, Mark Anderson wrote:
I fixed the audio in trandsport.c, unfortunatley I screwed up the video.
Attached is the diff as it stands, anyone see anything obvious causing the
video screw up?
The diff is applied againts the original transport.c and no mpeg.c hack is
need
On Thu, 13 Jan 2005 02:01 am, Jesper Sörensen wrote:
> Tim Davies skrev:
> >>If you are talking about the STREAM_TYPE_PRIVATE_DATA =>
> >>STREAM_TYPE_AUDIO_AC3 fix in DVBRecorder::CreatePMT then you are
> >>completely correct. This will be in the next DVB patch. If there are
> >>other changes neede
David Engel wrote:
On Tue, Jan 11, 2005 at 04:06:40PM -0800, Bruce Markey wrote:
David, while I don't mean to discourage any optimization =), as
ugly as this is, I don't think it has a real appreciable impact
on run time. Because if the CASE, only one or the other of these
I'm really more concerne
tv_grab_uk_rt used to be able to be run with the --days parameter. This
is no longer required or honored by the grabber.
The result of this was the XML file (which contains 14 days of
information anyway) was downloaded by mythfilldatabase 14 times for each
channel.
The first run was reasonably
Please try the attached patch (against patch 3.5). Unfortunately the
paths in the patch are wrong but it should work if you specify the
file names manually when applying the patch. Let me know if you can't
get it to apply and I'll try and make a new one for you.
I managed to apply the patch bu
Jesper Sörensen wrote:
What I can tell from the logs is that the CA_PMT that is sent
fromMythTV is 8 bytes shorted than the CA_PMT that is sent from VDR
and that I got 'Malformed PAT' errors in the MythTV.
OK, I see a couple of differences. There is some "private data" in
the CA descriptor tha
What I can tell from the logs is that the CA_PMT that is sent
fromMythTV is 8 bytes shorted than the CA_PMT that is sent from VDR
and that I got 'Malformed PAT' errors in the MythTV.
OK, I see a couple of differences. There is some "private data" in the
CA descriptor that is stripped by Myth wh
> Worked out why. When UpdateServicesInDb is called, the NIT object has no
> information unless you are doing a full scan. All three QValueList
> members in the NIT object are empty. Hence no LCNs. It works OK if you
> do a full scan. Not sure why the NIT object would be empty yet.
I have some cod
> I don't see a pattern there. Maybe there is just something wrong with the
> code that gets the video timings wrong in a transport stream. I haven't
> tried to understand that (yet!).
Have you checked to see if the PCR is making it into the TS?
> I was thinking that the Aussie AC3 "hack" is pr
On Tue, Jan 11, 2005 at 04:06:40PM -0800, Bruce Markey wrote:
> David, while I don't mean to discourage any optimization =), as
> ugly as this is, I don't think it has a real appreciable impact
> on run time. Because if the CASE, only one or the other of these
I'm really more concerned about clari
Tim Davies skrev:
If you are talking about the STREAM_TYPE_PRIVATE_DATA =>
STREAM_TYPE_AUDIO_AC3 fix in DVBRecorder::CreatePMT then you are
completely correct. This will be in the next DVB patch. If there are
other changes needed as well, please let us know.
Yep, that's the one.
Great!
The
>
> If you are talking about the STREAM_TYPE_PRIVATE_DATA =>
> STREAM_TYPE_AUDIO_AC3 fix in DVBRecorder::CreatePMT then you are
> completely correct. This will be in the next DVB patch. If there are
> other changes needed as well, please let us know.
>
Yep, that's the one.
The only other stuff
> "Mark" == Mark Anderson <[EMAIL PROTECTED]> writes:
Mark> Folks, After a number of hours starting at hex dumps and
Mark> trying to learn a bit about mpeg/dvb protocols I have
Mark> finally found the problem with transport.c, unfortunately I
Mark> haven't been able to craft so
No its nothing to do with this. This patch just
affects the performance of the OSD when watching live
tv or a recording.
It sounds like you are still using X to display the
tv. The 350 support needs to be enabled in the
setup/.../playback section and mythtv needs to be able
to succesfully open play
I was thinking that the Aussie AC3 "hack" is probably better in
dvbrecorder.cpp as the recorded stream is then in a format that can be
transcoded easily. And mpegts.c is untouched. And it is simpler. Any
opinions against doing it that way?
If you are talking about the STREAM_TYPE_PRIVATE_DAT
I have X working on the PVR-350 output with the latest ivtvdev driver
(v0.8) but I'm really confused with mythtv : I can't watch MPEG-2
recordings or live tv except sometimes at really poor framrate but xvid
transcoded files are working, besides that the GUI of the frontend is
displayed without
Well, it seems my assumption with AC3 and the messed up timing on the
recordings isn't right. I did some tests (only once each):
ChanVideoAudio Time OK
---
1 576iMP2&AC3no
2 576iMP2&AC3no
3 576iMP2yes
7
On Wednesday 12 January 2005 05:24, Kyle Schlansker wrote:
> leave it to me to attach the wrong patchfile...this one should be right...
talking of Goom
are there plans to upgrade to a recent version of Goom? it seems to have soom
cool stuff in it (an interpreter to conrol the visualisation)
regar
Anders Hanson skrev:
More info!
I turned on DumpTPDUDataTransfer in both MythTV and VDR and compared
the logs.
I did the test a couple of times with the same outcome. I had both VDR
and MythTV use the same start channel.
Great, that seems like a good approach.
Everytime I started VDR it successf
On Tue, Jan 11, 2005 at 12:10:38AM +1100, Hamish Moffatt wrote:
> On Sun, Jan 09, 2005 at 07:44:11AM +0800, Tim Davies wrote:
> > Here is a patch to read the logical channel numbers in the channel scan. It
> > works in Australia at least.
>
> I'm in Australia and I didn't have that much luck.
Wo
32 matches
Mail list logo
