En/na P. van Gaans ha escrit:
Luca Olivetti wrote:
En/na P. van Gaans ha escrit:
Sorry, that doesn't seem to help, I don't see any difference at all.
It doesn't seem to hurt either.
Not that I was really expecting it to help (after all it cannot report
an mpeg sync without a tps lock, or can it?), but it was the only
thing I could think of driver side.
Bye
Sorry Luca, but my e-mail client automatically starts at the top of the
message (Thunderbird)
oh, they must have changed the default recently (though I just created a
test account and it defaulted to "repky at bottom").
, in any e-mail conversation with companies I
companies don't get the internet and don't get email (otherwise they
won't be using any microsoft software connecting to the internet at
large). Anyway it has nothing to do with dvb.
receive top-posted replies (and they expect me to top-post back or else
I risk not getting a response) and trust me it's really hard to remember
to do a different posting style just for one person. I'm trying but it's
so easy to forget. If bottom-posting were the "standard" I would use it
by default but it simply isn't, at least not in e-mail. It's not
intentional, I don't mean to annoy you but how can I remember?
Simple, read the message you're composing from top to bottom and see if
it makes sense. If you're top-posting it surely won't. Companies don't
usually make sense either, that's because they don't mind top posting,
or actually require it ;-)
I gave "scan" a go and scan is a lot faster than Kaffeine. And good
thing, more frequencies allow to be scanned, but still not all.
with or without the suggested modification?
On the
ones that don't work I get "(tuning failed)". But if the driver wouldn't
be the problem I couldn't explain why the MSI scans (also in Kaffeine)
without problems. So "scan" works better.. I'm not far enough into the
technical stuff to explain this.
As I said earlier (and if I didn't I'm telling it now ;-)) I'm not a dvb
expert, but the driver is trying to report what the stick is telling, so
if the stick is reporting a lock when there isn't one I cannot do much.
Of course I could have misinterpreted the data sheet or didn't match
exactly what it's reporting to the linux dvb infrastructure.
The af9005 provides 3 bits:
- "agc lock" that I mapped to FE_HAS_SIGNAL
- "tps lock" that I mapped to FE_HAS_CARRIER
- "mpeg 2 lock signal" that I mapped to FE_HAS_LOCK, FE_HAS_SYNC,
FE_HAS_VITERBI
"scan" only looks at FE_HAS_LOCK, and that correspond to "mpeg 2 lock
signal". With the modification I suggested I made it dependent also on
"tps lock". I think the driver cannot do much more (besides filtering
the signal, waiting for it to be stable for, e.g. 200ms, but I'm not
sure that's the correct thing to do)
There are also various bits that I ignored: "fractional frequency offset
estimator lock", "integer frequency offset estimator lock" and "sampling
clock offset lock".
What I'm asking now is if I got the mapping right, if not what should be
the correct one.
Bye
--
Luca
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
