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 like to give it a
sho
On Mon, Jan 10, 2005 at 10:13:29PM -0500, Jeremiah Morris wrote:
> On 10 Jan 2005, at 9:52 PM, David Engel wrote:
> >Does that
> >mean I'll have to replicate the calculation in all three places?
>
> AFAIK, yes. User functions are only in the MySQL 5.x development. With
> MySQL 4.1, you could use
This patch adds AAC support to mythmusic. It is a fairly simple port of
the aacdecoder from mfd. You must enable it when you configure mythmusic
using either the --enable-aac or --enable-all options.
It relies on FAAD2 from http://www.audiocoding.com. From the mfd/README:
__NB__: As of Ma
On 10 Jan 2005, at 9:52 PM, David Engel wrote:
Does that
mean I'll have to replicate the calculation in all three places?
AFAIK, yes. User functions are only in the MySQL 5.x development. With
MySQL 4.1, you could use a sub-select to create a virtual table with
the calculation done once. With 3.x
On Mon, Jan 10, 2005 at 09:25:53PM -0500, [EMAIL PROTECTED] wrote:
> Use the calculation instead of the column alias in your JOIN clause:
Thanks to you and Jeremiah Morris for the quick response.
Unfortunately, the real calculation spans several lines, and needs to
used in two JOINs besides being
On 10 Jan 2005, at 9:12 PM, David Engel wrote:
SELECT record.title, program.starttime,
TO_DAYS(program.starttime) AS progdays
FROM record
LEFT JOIN program ON record.title = program.title
AND progdays = record.type
ORDER BY program.title, program.starttime;
It results in the followi
Use the calculation instead of the column alias in your JOIN clause:
SELECT record.title, program.starttime,
TO_DAYS(program.starttime) AS progdays
FROM record
LEFT JOIN program ON record.title = program.title
AND TO_DAYS(program.starttime) = record.type
ORDER BY program.title,
I'm working on a new Myth feature and have run into a problem
(probably operator error) with mysql. The following query is a
greatly simplified example of whay I'm trying to do.
SELECT record.title, program.starttime,
TO_DAYS(program.starttime) AS progdays
FROM record
LEFT JOIN progr
That might make sense... It worked fine for me at first then stopped,
thinking back that may be due to adding the extra directory for holding
episodes in a series. I'll try moving one of the directories later and
see if it doesn't crash too.
Thanks for the insight.
Simon
Ian Forde wrote:
On Sun
On Mon, 10 Jan 2005, Kyle Rose wrote:
> > 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.
My backend:
DFI PRO875B motherboard
3.0 GHz
> 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.
On Mon, Jan 10, 2005 at 10:57:09AM -0500, Taylor Jacob wrote:
> > Then I deleted all the channels from one transport in the myth setup
> > program, and ran the full scan of existing transports again. The removed
> > channels did not come back..
>
> The SDT (DVB) / TVCT (ATSC) version number is sto
On Mon, Jan 10, 2005 at 11:01:49AM -0500, Taylor Jacob wrote:
> > After I did the scan, each of the channels on a particular mux had the
> > same channel number - and it was the service ID of one of the programs.
> > eg all my ABC channels (HDTV, Melbourne, 1, 2, 3, 4) all have the
> > channel numb
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
Hi All,
This is an improved version of my patch to fix problems with rounding
errors caused by the X-Servers rounding of the DisplaySize configuration
parameter.
I have tidied us some more of the Aspect setting code so that:
1. Fill mode works the same from the Global settings and the "W" key.
On Mon, 10 Jan 2005, Kyle Rose wrote:
> 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
> Broadcasters are only encouraged to not change the TVCT too often,
> they not required to. A 4 bit number will roll over too quickly to
> depend on it. You can achieve the goal of not hitting the database too
> often by storing the PSIP CRC instead, at the cost of storing a 4 byte
> number instea
I don't think I was clear enough last time as to why the ServiceVersion is kept
in dtv_multiplex.
The VersionNumber is only supposed to change when the payload changes. Like I
said before these tend to change slowly not hourly. I have seen most of them
remain the same in my market since I got my
On Mon, 10 Jan 2005, Taylor Jacob wrote:
]Quoting Daniel Thor Kristjansson <[EMAIL PROTECTED]>:
]> This is a bug for ATSC. The version number is a 4 bit number you should
]> not expect it to be accurate after you close and reopen the stream.
]
]Why are the verison numbers not valid for you? The o
Quoting Daniel Thor Kristjansson <[EMAIL PROTECTED]>:
> This is a bug for ATSC. The version number is a 4 bit number you should
> not expect it to be accurate after you close and reopen the stream. It
> should not be in the database. Plus the TVCT is broadcast every 400 ms
> so this doesn't speed u
On Mon, 10 Jan 2005, Taylor Jacob wrote:
]Have you actually seen these version numbers change that quickly?
No, but I have seen the TVCT change, while the version number remains 0.
]If the VersionChanges so does the CRC, unless you mean do a CRC on the
]payload only..
Yes, if the version chang
Has anyone looked at any other PVR projects specifically for modules that
could be ported to MythTV?
As an example, there's a *gorgeous* "Daily Comics" plugin for GB-PVR, and
there's no license specifications in the source code. It's written in C#,
which can't be all that hard to use... (IANAP
I need to parse the select music tree to obtain all
file names that are checked and can't understend how
to do that.
I want to put the parsing method in
DatabaseBox::keyPressEvent
Can somebody help me?
Thanks, Pablo.
_
On Mon, 10 Jan 2005, Taylor Jacob wrote:
]> Then I deleted all the channels from one transport in the myth setup
]> program, and ran the full scan of existing transports again. The removed
]> channels did not come back..
]The SDT (DVB) / TVCT (ATSC) version number is stored in dtv_multiplex.
]Th
Isaac Richards wrote:
Transcoding's pretty much unsupported. Guy that wrote it doesn't
really contribute that often anymore, and none of the other devs use
it (as far as I know). It breaks fairly often, especially for
non-mpeg4 -> mpeg4.
Upon further testing it appears to be a matter of playba
> After I did the scan, each of the channels on a particular mux had the
> same channel number - and it was the service ID of one of the programs.
> eg all my ABC channels (HDTV, Melbourne, 1, 2, 3, 4) all have the
> channel number 564.
Thats the way it should be by default with no Channel numbers
> I noticed that NorDig uses the same tag (0x83) for logical channel
> descriptor. See section 12.2.5 in
> http://www.nordig.org/pdf/NorDig-Basic_ver_1.0.1.pdf .
Well if you can validate this let me know the NetworkID and i'll make sure it
gets turned on for them as well..
Taylor
> Then I deleted all the channels from one transport in the myth setup
> program, and ran the full scan of existing transports again. The removed
> channels did not come back..
The SDT (DVB) / TVCT (ATSC) version number is stored in dtv_multiplex. This way
the channel updates can be sped up consi
One question about selection of audio pids for recording: quite a few of
the channels I can receive provide multiple audio streams; not only
different formats (ac3, stereo, doly surround..) but also different
lannguages (synchronized german or original english soundtrack).
is there any way to rec
Isaac Richards wrote:
Transcoding's pretty much unsupported. Guy that wrote it doesn't really
contribute that often anymore, and none of the other devs use it (as far as I
know). It breaks fairly often, especially for non-mpeg4 -> mpeg4.
Good thing it's documented as being unsupported when you
Christian Hack wrote:
I wasn't aware it was unsupported but for the record my DVB (i.e. MPEG2) to
MPEG4 transcoding always works great and saves about 50% of disk space. In
fact transcoding to MPEG4 was how I was able to watch a few things when
ffmpeg went a bit bad recently.
I personally don't thi
G'day world.
> I'm an Australian living over in the US, and we see the same things with
AC3
> sound as you do - a lot of the programs are AC3 encoded, but with only two
> channels, setting off the ProLogic decoder. The AC3 standard allows for 1
to
> 5.1 channels (plus whatever DD-EX attempts to
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
On Sun, 9 Jan 2005 10:58:02 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> On Sun, Jan 09, 2005 at 01:22:20AM -0500, Chris Pinkham wrote:
> >
> > I'll ask what I ask everyone at work when they bring a problem to
> > me, "what do the logs say?" It sounds like it might not be able
> > to run
Mark,
I'm an Australian living over in the US, and we see the same things with AC3
sound as you do - a lot of the programs are AC3 encoded, but with only two
channels, setting off the ProLogic decoder. The AC3 standard allows for 1 to
5.1 channels (plus whatever DD-EX attempts to do with rear c
]recording from one of my ivtv cards, I get intermittent blockiness on
]the HDTV stream.
]Thing is, I get no bttv: buffer overrun errors, except during the
]times I expect them (e.g., another recording starting). This suggests
]the driver is getting the data correctly, but it is being ditched or
On Sun, 09 Jan 2005 19:42:24 +, John Pullan <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-01-09 at 23:23 +0800, Tim Davies wrote:
> > John,
> > It only falls down if the 0x83 descriptor is used for something else
> > somewhere.
> >
> That's my point really. I was quite amused/worried when I saw you
I'm testing DVB 3.5 here and noticed something odd.
I populated dtv_multiplex by hand (by importing 'scan' input data) since it's
tedious here. Then I ran a full scan of existing transports and got all
the correct channels.
Then I deleted all the channels from one transport in the myth setup
pro
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.
After I did the scan, each of the channels on a particular mux had the
same
> "Tj" == Tj <[EMAIL PROTECTED]> writes:
Tj> Marcus Metzler wrote:
>> You could also try and see what the following test program,
>> which uses
>>
>> transform.c, will give you as output.
>>
>>
>>
Tj> How should I run it?
Tj> I run it like ./transf
Marcus Metzler wrote:
You could also try and see what the following test program, which uses
transform.c, will give you as output.
How should I run it?
I run it like ./transform filename vpid apid, and the original file is
reduced from 340Mb into 319MB..
Tried playing it with mplayer, got vide
I've just done a very nasty hack to mpegts.c to get AC3 working in Oz. I
changed the card(s) to record the TS and now I have all channels running
smoothly with AC3, or MPEG for that matter.
CPU sits at around 70% for an Athlon 3200+ playing Nine HD. Very nice!
Now I just have to clean up the ha
Mark Anderson wrote:
On Mon, 10 Jan 2005 06:16 pm, you wrote:
Right, I've had a go with the AC3 patch against DVB Patch V3.5.
I modified it slightly (not stomping on anyone's toes here):
if you can help get the transport.c stuff sorted out then you are forgiven :-)
- I removed the transf
> "Mark" == Mark Anderson <[EMAIL PROTECTED]> writes:
Mark> Marcus, I tried to use your test program and got a binary
Mark> output, what should I be looking for?
Mark> BTW: I have been saying PCM when I mean MPEG, my decoder
Mark> reports PCM and that's what I have been thinki
Marcus,
I tried to use your test program and got a binary output, what should I be
looking for?
BTW: I have been saying PCM when I mean MPEG, my decoder reports PCM and
that's what I have been thinking, sorry for any confusion.
Here is what I did:
[EMAIL PROTECTED] test]# dvbsnoop -s pidscan
On Mon, Jan 10, 2005 at 05:13:53PM +0800, Tim Davies wrote:
> I have two TS streams for you, but they are huge! One is 56Mb and the other
> is 180Mb, for supposedly one minute of HDTV (might be a bit over).
>
> How much do you want? Being a TS, I should be able to chop the ends off
> right? Bea
Marcus,
I have two TS streams for you, but they are huge! One is 56Mb and the other
is 180Mb, for supposedly one minute of HDTV (might be a bit over).
How much do you want? Being a TS, I should be able to chop the ends off
right? Bear in mind my uplink speed is 256kbps.
And no, I think we onl
On Mon, 10 Jan 2005 07:15 pm, Tim Davies wrote:
> I may be able to help with transform.c, I'm grabbing your patch now...
>
> I'm fairly convinced the blockiness is caused at the pes filtering stage,
> and not the frontend. I've got an Athlon XP 3200+ and it plays Nine HD
> perfectly under Windows
> "Mark" == Mark Anderson <[EMAIL PROTECTED]> writes:
Mark> On Mon, 10 Jan 2005 06:16 pm, you wrote:
>> Right, I've had a go with the AC3 patch against DVB Patch V3.5.
>>
>> I modified it slightly (not stomping on anyone's toes here):
>>
Mark> if you can help get the
I may be able to help with transform.c, I'm grabbing your patch now...
I'm fairly convinced the blockiness is caused at the pes filtering stage,
and not the frontend. I've got an Athlon XP 3200+ and it plays Nine HD
perfectly under Windows (at absolute max 60% CPU).
Could be wrong though ;-)
W
On Mon, 10 Jan 2005 06:56 pm, you wrote:
> Mark Anderson wrote:
> > Yes, I have been assuming my processor can't keep up (p3 2.6) tried
> > XvMC but
> >
> >that asserted all the time.
>
> I'm not at home and I forgot everything, but could the blockyness be
> caused by the ugly mpeg.c??
>
I don't th
On Mon, Jan 10, 2005 at 06:48:20PM +1100, Hamish Moffatt wrote:
> On Mon, Jan 10, 2005 at 12:23:01AM -0500, Taylor Jacob wrote:
> > I've been working on adding this in tonight. Is there any chance there is a
> > document you can get from the Aussie equilivilant to the US FCC that would
> > have
>
Mark Anderson wrote:
Yes, I have been assuming my processor can't keep up (p3 2.6) tried
XvMC but
that asserted all the time.
I'm not at home and I forgot everything, but could the blockyness be
caused by the ugly mpeg.c??
Are you working on getting transform.c to work with original mpeg.c?
54 matches
Mail list logo
