Broken ttusb-dec DVB support since, well, year(s)

Broken ttusb-dec DVB support since, well, year(s)

[barry bouwsma]

Moin moin!

Sorry I'm posting this here rather than to the more specific
linux-dvb@ mailing list where I'd rather this appear, but my
attempts to surbscibe!@! to that list have been rejected, first
as an invalid e-mail, then an insecure e-mail, and I've been
unable to progress further from this throwaway account.

Feel free to redirect/repost this message there if you're a
qualified developer and feel it's more appropriate.


There is a change that was introduced to the file
drivers/media/dvb/ttusb-dec/ttusbdecfe.c
sometime in the not-too-recent past and which resulted in breaking
the support which early 2.6.1x kernels had for my Hauppauge
DEC-3000s DVB-S device.

The particular code (below) checks the value in a register to
decide the tuning status -- hitherto one had to assume the device
was properly tuned and receiving signal and everything.


     60         switch(result[3]) {
     61                 case 1:  /* not tuned yet */
     62                 case 2:  /* no signal/no lock*/
     63                         break;
     64                 case 3:  /* signal found and locked*/
     65                         *status = FE_HAS_SIGNAL | FE_HAS_VITERBI |
     66                         FE_HAS_SYNC | FE_HAS_CARRIER | FE_HAS_LOCK;
     67                         break;
     68                 case 4:
     69                         *status = FE_TIMEDOUT;
     70                         break;
     71                 default:
     72                         pr_info("%s: returned unknown value: %d\n",
     73                                 __func__, result[3]);
     74                         return -EIO;
     75         }


Unfortunately, while this might work for the other flavours of
card (DVB-T?) supported by this code, in the case of my particular
device for DVB-S, the unknown value returned is 0 and does not
change regardless of tuning status.

I haven't checked whether a different register on my particular
device contains a usable value for the above code.

In any case, with my particular device, in order to use more
recent kernels, I've had to add a ``case 0:'' line to the
``case 3:'' seen above in order to get the previous behaviour
where no check was made.


As I don't know the particular model for which the quoted code
was added, I don't know if my device is unique, or whether the
number of DVB-S users of this code is miniscule, as nobody else
has complained that I've seen.

Apologies for not reporting this long ago when first observed,
but I've not had any meaningful Internet access in a long time
to allow me more than just leeching the latest codes.


thanks,
BOUWSMA Barry


      

Re: Broken ttusb-dec DVB support since, well, year(s)

[Andrew Morton]

On Sun, 22 Jun 2008 23:55:29 -0700 (PDT) barry bouwsma <free_beer_for_all@yahoo.com> wrote:

> Moin moin!
> 
> Sorry I'm posting this here rather than to the more specific
> linux-dvb@ mailing list where I'd rather this appear, but my
> attempts to surbscibe!@! to that list have been rejected, first
> as an invalid e-mail, then an insecure e-mail, and I've been
> unable to progress further from this throwaway account.

These closed lists are a pain.

Lots of subprojects have moved their lists to vger.kernel.org in recent
months.  It gets close to zero spam.  Hint.

> Feel free to redirect/repost this message there if you're a
> qualified developer and feel it's more appropriate.
> 
> 
> There is a change that was introduced to the file
> drivers/media/dvb/ttusb-dec/ttusbdecfe.c
> sometime in the not-too-recent past and which resulted in breaking
> the support which early 2.6.1x kernels had for my Hauppauge
> DEC-3000s DVB-S device.
> 
> The particular code (below) checks the value in a register to
> decide the tuning status -- hitherto one had to assume the device
> was properly tuned and receiving signal and everything.
> 
> 
>      60         switch(result[3]) {
>      61                 case 1:  /* not tuned yet */
>      62                 case 2:  /* no signal/no lock*/
>      63                         break;
>      64                 case 3:  /* signal found and locked*/
>      65                         *status = FE_HAS_SIGNAL | FE_HAS_VITERBI |
>      66                         FE_HAS_SYNC | FE_HAS_CARRIER | FE_HAS_LOCK;
>      67                         break;
>      68                 case 4:
>      69                         *status = FE_TIMEDOUT;
>      70                         break;
>      71                 default:
>      72                         pr_info("%s: returned unknown value: %d\n",
>      73                                 __func__, result[3]);
>      74                         return -EIO;
>      75         }
> 
> 
> Unfortunately, while this might work for the other flavours of
> card (DVB-T?) supported by this code, in the case of my particular
> device for DVB-S, the unknown value returned is 0 and does not
> change regardless of tuning status.
> 
> I haven't checked whether a different register on my particular
> device contains a usable value for the above code.
> 
> In any case, with my particular device, in order to use more
> recent kernels, I've had to add a ``case 0:'' line to the
> ``case 3:'' seen above in order to get the previous behaviour
> where no check was made.
> 
> 
> As I don't know the particular model for which the quoted code
> was added, I don't know if my device is unique, or whether the
> number of DVB-S users of this code is miniscule, as nobody else
> has complained that I've seen.
> 
> Apologies for not reporting this long ago when first observed,
> but I've not had any meaningful Internet access in a long time
> to allow me more than just leeching the latest codes.
> 
> thanks,
> BOUWSMA Barry
> 

Thanks.  Cc's added.

Re: Broken ttusb-dec DVB support since, well, year(s)

[Peter Beutner]

[-- Attachment #1: Type: text/plain, Size: 3669 bytes --]

Andrew Morton schrieb:
> On Sun, 22 Jun 2008 23:55:29 -0700 (PDT) barry bouwsma <free_beer_for_all@yahoo.com> wrote:
> 
>> Moin moin!
>>
>> Sorry I'm posting this here rather than to the more specific
>> linux-dvb@ mailing list where I'd rather this appear, but my
>> attempts to surbscibe!@! to that list have been rejected, first
>> as an invalid e-mail, then an insecure e-mail, and I've been
>> unable to progress further from this throwaway account.
> 
> These closed lists are a pain.
> 
> Lots of subprojects have moved their lists to vger.kernel.org in recent
> months.  It gets close to zero spam.  Hint.
> 
>> Feel free to redirect/repost this message there if you're a
>> qualified developer and feel it's more appropriate.
>>
>>
>> There is a change that was introduced to the file
>> drivers/media/dvb/ttusb-dec/ttusbdecfe.c
>> sometime in the not-too-recent past and which resulted in breaking
>> the support which early 2.6.1x kernels had for my Hauppauge
>> DEC-3000s DVB-S device.

So only dvb-s support is broken. The DEC-2000t (hopefully) still works.
If there is still somebody around using that thing ;)
Honestly, I wasn't aware that the DEC-3000s has ever really worked.

>>
>> The particular code (below) checks the value in a register to
>> decide the tuning status -- hitherto one had to assume the device
>> was properly tuned and receiving signal and everything.
>>
>>
>>      60         switch(result[3]) {
>>      61                 case 1:  /* not tuned yet */
>>      62                 case 2:  /* no signal/no lock*/
>>      63                         break;
>>      64                 case 3:  /* signal found and locked*/
>>      65                         *status = FE_HAS_SIGNAL | FE_HAS_VITERBI |
>>      66                         FE_HAS_SYNC | FE_HAS_CARRIER | FE_HAS_LOCK;
>>      67                         break;
>>      68                 case 4:
>>      69                         *status = FE_TIMEDOUT;
>>      70                         break;
>>      71                 default:
>>      72                         pr_info("%s: returned unknown value: %d\n",
>>      73                                 __func__, result[3]);
>>      74                         return -EIO;
>>      75         }
>>
>>
>> Unfortunately, while this might work for the other flavours of
>> card (DVB-T?) supported by this code, in the case of my particular
>> device for DVB-S, the unknown value returned is 0 and does not
>> change regardless of tuning status.
>>
>> I haven't checked whether a different register on my particular
>> device contains a usable value for the above code.
>>
>> In any case, with my particular device, in order to use more
>> recent kernels, I've had to add a ``case 0:'' line to the
>> ``case 3:'' seen above in order to get the previous behaviour
>> where no check was made.
>>

Indeed I added the above code only for the dec2000-t model. Since I have no
idea how that stuff works on the dec3000, probably the best thing to do is to
revert to the old behaviour for dec3000s models, i.e. just pretend we always have
a signal. Something like the attached patch. Does that help?


>>
>> As I don't know the particular model for which the quoted code
>> was added, I don't know if my device is unique, or whether the
>> number of DVB-S users of this code is miniscule, as nobody else
>> has complained that I've seen.
>>

well, i remember at least one report on the linux-dvb ml a long time ago
and iirc I have posted the same patch there, but it didn't help.
We never figured out how to make that particular dec3000s work.
And without hw documentation this is more like a puzzle game.
Which is rather demotivating.

[-- Attachment #2: dont-try-to-readout-signal-status-for-dec3000s.patch --]
[-- Type: text/x-patch, Size: 1538 bytes --]

As reported by BOUWSMA Barry the readout of the signal status doesn't work
on dec3000-s models. Since we don't know how to do it better, revert back
to the old behaviour and always report a signal lock.

Signed-off-by: Peter Beutner <p.beutner@gmx.net>
--- linux/drivers/media/dvb/ttusb-dec/ttusbdecfe.c.orig	2008-06-23 09:50:00.000000000 +0200
+++ linux/drivers/media/dvb/ttusb-dec/ttusbdecfe.c	2008-06-23 09:53:27.000000000 +0200
@@ -38,7 +38,15 @@ struct ttusbdecfe_state {
 };
 
 
-static int ttusbdecfe_read_status(struct dvb_frontend* fe, fe_status_t* status)
+static int ttusbdecfe_dvbs_read_status(struct dvb_frontend* fe, fe_status_t* status)
+{
+	*status = FE_HAS_SIGNAL | FE_HAS_VITERBI |
+		FE_HAS_SYNC | FE_HAS_CARRIER | FE_HAS_LOCK;
+	return 0;
+}
+
+
+static int ttusbdecfe_dvbt_read_status(struct dvb_frontend* fe, fe_status_t* status)
 {
 	struct ttusbdecfe_state* state = fe->demodulator_priv;
 	u8 b[] = { 0x00, 0x00, 0x00, 0x00,
@@ -251,7 +259,7 @@ static struct dvb_frontend_ops ttusbdecf
 
 	.get_tune_settings = ttusbdecfe_dvbt_get_tune_settings,
 
-	.read_status = ttusbdecfe_read_status,
+	.read_status = ttusbdecfe_dvbt_read_status,
 };
 
 static struct dvb_frontend_ops ttusbdecfe_dvbs_ops = {
@@ -273,7 +281,7 @@ static struct dvb_frontend_ops ttusbdecf
 
 	.set_frontend = ttusbdecfe_dvbs_set_frontend,
 
-	.read_status = ttusbdecfe_read_status,
+	.read_status = ttusbdecfe_dvbs_read_status,
 
 	.diseqc_send_master_cmd = ttusbdecfe_dvbs_diseqc_send_master_cmd,
 	.set_voltage = ttusbdecfe_dvbs_set_voltage,

Re: [linux-dvb] Broken ttusb-dec DVB support since, well, year(s)

[barry bouwsma]

Sorry to take so long to reply.  kernel@ dropped and replaced
by dvb@.  Patch worked for me.

--- On Mon, 6/23/08, Peter Beutner <p.beutner@gmx.net> wrote:

> >> sometime in the not-too-recent past and which resulted in breaking
> >> the support which early 2.6.1x kernels had for my Hauppauge
> >> DEC-3000s DVB-S device.

> So only dvb-s support is broken. The DEC-2000t (hopefully) still works.
> If there is still somebody around using that thing ;)
> Honestly, I wasn't aware that the DEC-3000s has ever really worked.

Well, it has, shall we say, ``issues'' or Wiki-material.

Lessee:  (specifics are based on european reception)
USB1 -- acceptable for radio, or VIC Screenpeaks video; had
worked for high-quality ARD video from NDR+ and MDR+, which
seemed to be clamped to no more than 7 or 8Mbit/sec peaks,
whatever fit well into USB1, but those particular channels
are/will be history.  Unsuitable for video now from the
remaining ARD transponders, except the new BR-alpha and SR
(rarely exceed 4Mbit/sec, due to most of the bandwidth on
that transponder being CBR audio).  Probably suitable for
commercial or other bandwidth-pinched broadcasters in other
lands where visible blocking artifacts don't matter, and
well over five/six stations per transponder is the norm.
But that's a general USB1/2 issue, not specific to this.

Repackages the TS for delivery via USB which is then repacked.
The timestamps get, um, manipulated (cycle at about half the
time of normal TS timestamps) which causes problems during
certain seeks in mplayer, or somehow seeks get messed up.

This repackaging also appears to have the effect of slightly
smoothing bitrate bursts on the TS, so that it is possible
to get uncorrupted video from this device where other USB1
devices with the same signal fail, but not for an extended
sequence of running water and such continuous high bandwidth
video.

For some reason, corrupts certain radio streams every ten or
20 seconds or so; only heard on the ORF Oe2 160kbit/sec Joint
stereo stations, never heard on FM4 from the same transponder,
or from BBC7, another 160kbit/sec Joint Stereo station.  The
corruption is audible and cannot be detected by mpg123 or the
like, as the 480-byte frames remain as such, while within the
payload of the mp2 gets somehow repeated or something (analyzed
once, but can't remember definitively) -- the CRC may show a
problem but is mostly ignored.

Limited normally to a single SD MPEG video PID and accompanying
mp2 audio stream with the same PCR.  Can't snarf PMT, 2nd audio,
H.264, 1080i MPEG, AC3, teletext, etc etc etc.

Under Linux, does not appear capable of delivering the 22kHz
band-switching signal to allow tuning to 11,7-12,75GHz channels
from ten or so simple LNBs, unless passed through another receiver
tuned to a high-band channel of the appropriate polarization.
However successfully switches a DiSEqC multischalter to receive
all bands and such with no hackery.  No o'scope here so I haven't
investigated.

Does not power up by itself.  Consumes a significant amount of
power after manually powered on and used.  Luckily this has not
been a real problem since the last europe-wide power outage,
apart from my power bill.

Occasionally seems to get stuck tuned to the previous channel
viewed and then the timing data for the video gets broken or
alternatively totally hosed; less often will deliver hopelessly
completely corrupted video in the PVA data, with audio mostly
or partly intact, from which only a power cycle will recover.

Cannot coexist and simultaneously operate with, in my case, a
Hauppauge WinTV Nova-S USB (1.x) older device on the same USB
controller, without going boom on 2.6.14 (haven't tried the
latest kernels), which would be either foolish (except I limit
my use of those two to low-bandwidth audio/video) or not a
problem as I use a separate EHCI-able card as well as the built-
in UHCI and therefore don't need to panic.

Therefore, after acquiring adequate other devices that perform
more reliably, I've limited my use of it to recording audio TS
data that will be stripped to only the mp2 payload Real Soon Now.
I'd retire it if I would backport recently-added code to work for
a different USB receiver, but haven't really missed having that.


However does allow one to connect via RGB SCART a TV, so I did
not need to worry about upgrading my (then 160MHz CPU, now 200MHz)
hardware to view something.  And it can support a CAM, not that
I've had interest in that.  And has an (unusable?) s/pdif coax
output.  Never tried under another OS.


There's probably something in there that would lead one to believe
that it never really worked, about as much as I'll never be able to
really run a marathon again after you send your bunch of goons
around to smash my kneecaps into a pulp...

The fact that I'm able to use it may be unrelated to how I'm working
to build my upper-body strength before you track down my IP address.



> >> In any case, with my particular device, in order to use more
> >> recent kernels, I've had to add a ``case 0:'' line to the
> >> ``case 3:'' seen above in order to get the previous behaviour
> >> where no check was made.

> Indeed I added the above code only for the dec2000-t model. Since I have no
> idea how that stuff works on the dec3000, probably the best thing to do is to
> revert to the old behaviour for dec3000s models, i.e. just pretend we always have
> a signal. Something like the attached patch. Does that help?

Oh, you want me to try it, or just to say that it can't be
any worse than the hack I'm using now (though yours is better)

I'll have to wait until my DEC is not busy making radio recordings
to try it for positive verification...

(days pass, twiddles thumbs)

Works for me.  Patch applied to a week-ish-old 2.6.26-rc8, delivered
stream with no errors reported..


> >> was added, I don't know if my device is unique, or whether the
> >> number of DVB-S users of this code is miniscule, as nobody else
> >> has complained that I've seen.

> well, i remember at least one report on the linux-dvb ml a long time ago
> and iirc I have posted the same patch there, but it didn't help.
> We never figured out how to make that particular dec3000s work.

I recall seeing something, back when I had no regular 'net access
and had to make an overnight trip two or three times a year to a
large town and try to update as much of my source repositories as
possible in a few hours while reading for the newest info, but
then not being able to contribute in an up-to-date fashion.  At
that time I had my hack workarounds to get it working, so...

Sorry that I haven't been able to contribute in any meaningful sense
until, well, I would say now, but I can't see that I've contributed
anything meaningful, so I'll have to take a gamble and say, sometime
before the turn of the century...


thanks,
barry bouwsma


      


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb