From: Andy Furniss <adf.lists@gmail.com>
To: "Russel Winder" <russel@winder.org.uk>,
"Peter Fässberg" <pf@leissner.se>,
DVB_Linux_Media <linux-media@vger.kernel.org>
Subject: Re: SV: PCTV 292e support
Date: Mon, 25 Jan 2016 18:23:38 +0000 [thread overview]
Message-ID: <56A6682A.3090007@gmail.com> (raw)
In-Reply-To: <1453743221.15408.86.camel@winder.org.uk>
Russel Winder wrote:
> On Mon, 2016-01-25 at 00:48 +0000, Andy Furniss wrote:
>> Russel Winder wrote:
>>> On Sun, 2016-01-24 at 10:07 +0000, Andy Furniss wrote:
>>
>>> It finds all the physical channels, quite happily describes all
>>> the virtual channels in the T1 channels, fails to find anything
>>> in one of the T2 channels and finds unnamed channels in the
>>> other T2 channel. The device itself is fine, as it gets all T1
>>> and T2 channels on Windows. This implies something awry with it
>>> in a Linux context.
>>
>> OK, I can't reproduce this on Tacoleneston which has three T2
>> muxes.
>
> I have managed to get some proper T2 tuning. :-)
>
> Someone emailed me privately to tell me about:
>
> https://github.com/OpenELEC/dvb-firmware
>
> The 292e demod firmware in their is 8 bug fix release further on that
> the one I had. It looks like there was a crucial bug fix in there.
Ahh, that's good. I ought to get that myself, I am still using 4.0.4!
>> I am using some old git version (Jun 10), I'll try current as time
>> allows.
FWIW I did build current git and it does work.
> I am finding locking behaviour to be very strange. Sometimes I get an
> immediate lock on a -50.0 signal, sometimes -35.0 signal fails to
> lock. I am not sure if this is just a timing/sampling thing or
> whether there is a quality of signal thing I am missing.
I've only really tested with a "real" aerial, but it did seem like
sometimes it took longer than others to lock.
> As I am focused on lightweight, I am working with non-fixed aerials
> so low signal strengths. Though for testing I have an aerial with
> powered high gain.
Random thoughts on player -
You'll need to handle AAC in LATM that switches between 2 and 5
channels. VLC falls down in this respect. Avoid FAAD as the release at
least had a bug that will cause volume issues with some content if it
has dynamic range control metadata. ffmpeg aacdec handles channel
switching and ignores DRC meta - so you get full range.
On V4l
As I leave mine plugged in a headless box I don't hit this, but I think
there's a chance that if you repeatedly plug and have fragmented memory
that it will eventually fail to allocate some buffers.
prev parent reply other threads:[~2016-01-25 18:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-24 5:28 PCTV 292e support Russel Winder
[not found] ` <ijvkgaod4jhqyaoroevcea7f.1453613737402@email.android.com>
2016-01-24 5:57 ` SV: " Russel Winder
2016-01-24 6:56 ` Russel Winder
2016-01-24 8:46 ` Russel Winder
2016-01-24 10:07 ` Andy Furniss
2016-01-24 12:50 ` Russel Winder
2016-01-25 0:48 ` Andy Furniss
2016-01-25 17:33 ` Russel Winder
2016-01-25 18:23 ` Andy Furniss [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A6682A.3090007@gmail.com \
--to=adf.lists@gmail.com \
--cc=linux-media@vger.kernel.org \
--cc=pf@leissner.se \
--cc=russel@winder.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox