Re: PATCH: Query DVB frontend capabilities

2011-11-11 Thread BOUWSMA Barry
Hash: SHA1

On Do (Donnerstag) 10.Nov (November) 2011, 22:20,  Mauro Carvalho Chehab wrote:

 We should also think on a way to enumerate the supported values for each DVB $
 the enum fe_caps is not enough anymore to store everything. It currently has $
 filled (of a total of 32 bits), and we currently have:
   12 code rates (including AUTO/NONE);

I'm probably not looking at the correct source, but the numbers
seem to match, so I'll just note that in what I'm looking at,
there are missing the values  1/3  and  2/5 .

But I have to apologise in that I've also not been paying
attention to this conversation, and haven't even been trying
to follow recent developments.

   13 modulation types;

Here I see missing  QAM1024  and  QAM4096 .

   7 transmission modes;
   7 bandwidths;

Apparently DVB-C2 allows us any bandwidth from 8MHz to 450MHz,
rather than the discrete values used by the other systems.
If this is also applicable to other countries with 6MHz rasters,
would it be necessary in addition to specify carrier spacing,
either 2,232kHz or 1,674kHz as opposed to getting this from the
channel bandwidth?

   8 guard intervals (including AUTO);

Here I observe the absence of  1/64 .

   5 hierarchy names;
   4 rolloff's (probably, we'll need to add 2 more, to distinguish between$

Of course, I'm just pointing out what I find, as I really don't
know anything about the transport systems, and someone who 
actually does might be able to say more, and correct my errors.

So just ignore me -- I'd rather see these values added sooner
than later if needed.  Apparently the broadcasts from Borups
Allé scheduled to start sometime around now will be switching
over to use those mentioned to test their increased robustness.

barry bouwsma

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Key found at
Comment: Anständige Signaturen und Verschlüsselung gibt es nur mit GNUpg
Comment: und nicht mit De-Mail.

To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [PATCH] drivers: support new Siano tuner devices.

2011-08-02 Thread BOUWSMA Barry
On k (kedd) 19.júl (július) 2011, 14:21,  Doron Cohen wrote:

 This is the first time I ever post changes to linux kernel, so excuse me
 if I have errors in the process.
 As Siano team member, I would like to update the drivers for Siano
 devices with the latest and greatest fixes. Unfortunately there is a hug
 gap between the current code in the kernel and the code Siano has which
 is more advanced and supports newer devices. I will try to break down
 the changes into small pieces so each of the changes will be clear and
 Here is the first change which is my test balloon and includes simple
 changes which includes support in new devices pulished after the kernel
 source maintenance has stopped.

Thanks for your contribution, and I hope it sees usage.

I have found that for many kernel revisions, I have had to have
some variant of the following added code, for my Siano-based
device to function automatically in DVB-T modus:

--- 3.0.0-rc1-hacks/sms-cards.c.orig2011-04-06 04:04:12.0 +0200
+++ 3.0.0-rc1-hacks/sms-cards.c 2011-07-09 10:17:30.0 +0200
@@ -301,6 +301,11 @@
+/* XXX HACK */
+   request_module(smsdvb);
+   break;
/* do nothing */

Apologies if this problem has been addressed by your patchset.
If there was a reason for removing this functionality, I have
not been able to follow it over time.

Another thing, as my device is capable of receiving DAB radio
broadcasts and Siano has provided a library to make this possible
under Linux, are there plans to update this library for the DAB+
standard that is now being used, with the Reed-Solomon error
protection and up to HE-AACv2 audio encoding?  (I am aware of the 
960-sample-window incompatibility with many AAC software players.)

barry bouwsma
mails will be delayed due to infrequent internet access
now on the road in croatia
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [PATCH] Fix av7110 driver name

2010-06-13 Thread BOUWSMA Barry
On Sat (Saturday) 12.Jun (June) 2010, 05:10,  VDR User wrote:

 This patch simply changes the name of the av7110 driver to AV7110
 instead of the generic dvb it's set to currently.  Although it's
 somewhat trivial, it still seems appropriate to fix the name to be
 descriptive of the driver.

Thanks Derek; I'll just note that as submitted, the trivial patch
is a ``reversed'' patch, but I'd hope that any tools written for
auto-patch-handing should be able to detect this and correct this

The other patch is in ``proper'' order, so no worries.

 --- v4l-dvb/linux/drivers/media/dvb/ttpci/av7110.c  2010-06-11
 13:24:29.0 -0700
 +++ v4l-dvb.orig/linux/drivers/media/dvb/ttpci/av7110.c 2010-06-11
 12:49:50.0 -0700

 -   .name   = AV7110,
 +   .name   = dvb,

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Is anybody working on TechniSat CableStar Combo HD CI USB device?

2010-06-10 Thread BOUWSMA Barry
On Tue (Tuesday) 08.Jun (June) 2010, 12:14,  Bjørn Mork wrote:

 Markus Rechberger writes:
  Trident is also still improving the quality of their driver and
  firmware, it very much makes
  sense that they handle their driver especially since those DRX drivers
  are very complex
  (basically too complex for being handled by the community, the drivers
  would just
  end up somewhere unmaintained).
 Ouch.  That makes me wonder about the state of the Windows drivers for
 those devices...  Better stay away from them, I guess.

Just to throw this out there, the 'doze support for one such
Micronas-based device I have -- the Linux kernel support for which
either does not exist or cannot be publicly distributed -- is less
than optimal in my experience, which may have nothing to do with

While I was able to make a flawless test recording for a few
minutes of one medium-bitrate lower-resolution high-definition
programme to mislead me into thinking that I'd have success with
a full-length programme, for some reason it turned out that my use
of the device under 'doze for an extended time on a borrowed 'doze
box suffered fairly frequent problems manifested each as a short
dropout of the recording.

This could also be pilot error, as I remain willfully ignorant of
'doze and its details, but if a machine with CPU horsepower over
eight times that (neglecting other acceleration) of my workhorse
that routinely makes four simultaneous flawless recordings
including some at higher resolution/bitrate, is unable to keep up
with the bitstream, then something has got to be seriously wrong,
in my opinion.

A later recording of a higher bitrate (excellent quality standard-
definition video source) stream again exhibited the same problem.
Perhaps 'doze can't keep up writing to its own native filesystem
as it approaches being full, or if I can't keep my hands away from
configuring it to be user-hostile as I prefer.

And of course there's the factor of intermediate hardware to be
considered -- my device is connected via a USB interface which has
caused major filesystem corruption over time with the particular
Linux kernel I was using, despite of working flawlessly with a
different video card.  And 'doze...  *shiver*

Anyway, I'd be happy to learn that others have had success with
the same device, although for me it's no longer a priority to have
it working, to say nothing of working perfectly.  My testing of
the device has been relatively minimal, using it where other tuner
cards lack support.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

2010-02-06 Thread BOUWSMA Barry
I'm not even trying to follow this discussion at all, but I
feel I have to chime in to be off-topic...

On Sat, 6 Feb 2010, hermann pitton wrote:

Bye bye Teletext. Nothing for future kernels, huh?
   Yes, you say it. It definitely will go away and we do have not any
   influence on that! Did you not notice the very slow update rate these
  a. NOTHING will go away. This is empty rant, nothing else it is!
  In US teletext is dead, yes. In Europe analogue television is close to
  dead. Yes.
  But I have found no information source that teletext will disappear in
  general. At least not in Europe or Germany.
  So if you keep that up then prove the assertion please.
 In the UK too. And after world war II we always followed BBC.
 Not that bad ...

The BBC has switched over to ``Digital Text'' via the Red Button
service on Freeview.  This is based on MHEG, and has the advantage
that pretty much all receivers are built around a particular 
platform which specifies inclusion of the Red Button services,
a particular EPG, LCNs, and so on.  Be that platform Freeview, or
Sky, or Freesat.

This is not the case in your country -- the public broadcasters
have adopted MHP which has gone over about as well as a lead 
balloon.  There is also not a specified platform, but rather any
manufacturer can offer a receiver based on the DVB specifications.
Usually teletext support will be built-in to the decoder; also, 
most boxes pass the DVB Teletext information to the television
regenerated as the analogue VBI interval which pretty much every
set supports.

As far as I know, the proposed Eutelsat Viseo platform being 
pushed does not specify a MHP- or MHEG-based replacement for
teletext, nor am I aware of any alternative platforms to take
over and mandate a replacement of the current level teletext.

Can you even find a MHP-capable settop box in the shops today?
Also, as far as I know, the national MHP service was dropped from
terrestrial broadcasting some years ago, and at best there may
be still a regional and minimal service offered by Bayerischer
Rundfunk, but nothing like one finds on Freeview.

Conditions have diverged too much between the two countries these
days.  In the UK, Sky has a lion's share of the market, while I've
barely seen anything but a few sports bars with a Premiere 
subscription.  Also while the commercial public service 
broadcasters in the UK have relied on terrestrial service through
the country, this has not been true of the comparable private
commercial broadcasters in germany, who are not even participating
in terrestrial broadcasting outside of a handful of strategic
centres.  Also, teletext in germany is a service of the individual
broadcasters or contracted out in the commercial case, while the
Teletext and Teletext Holidays and such closing in the UK is its 
own service.

Without support already in place for a transition away from VBI-
based teletext over the coming years, I can't see it happening.
I know that Austria made a big deal of their MHP-based ORF text
service, but I don't know how great a penetration it has.  I've
read tht it requires significant bandwidth of the terrestrial
multiplexes, while conventional teletext requires around that of
an audio channel -- back when ZDFvision was sending MHP data plus
AC3 streams terrestrially, I clocked four MHP streams each with a
data rate comparable to a lower-quality audio stream, together
some twice the data rate of each of the three separate teletext

  What slow update rate please?
  What the hell are you talking about, man?
 Previously information available there was updated within minutes, now
 in best case every six hours it seems to me.

I don't know what services you are viewing; those which I use
are updated within seconds of updated data, and happen to be the
first place I turn to for current information.  The amount and
quality of information I get from conventional teletext is far
more impressive than what I see on the BBC's Red Button service.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [ANNOUNCE] git tree repositories

2010-01-20 Thread BOUWSMA Barry
Moin Andy,

On Tue, 19 Jan 2010, Andy Walls wrote:

 On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
  BTW: I just made a clone of the git-tree - 365MB *ouff*.
 Assuming 53.333 kbps download speed, 0% overhead, no compression:
 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr =
 15.95 hours

Wow, that's about twice as fast as my first clone of the 
various SCM trees, mostly with CVSup, many years ago, after
leaving the world of high-speedLand.  Actually, when I made
my first git kernel clone, I think it was less than 100MB
yet still elicited the same astoundment I see now.

And basically I did dial in and let all the checkouts run
overnight from whichever provider was affordable, back when
the per-minute costs were ten to 100 times what I see today.

Although many other BSD full trees were updates of changes
that had then occurred in five years, and CVSup/rsync and
the like can do the work in bits and pieces.

 Can git resume aborted clones?  It could be many weeks before I have a
 20 hour window where I don't have to use my land line phone for voice...

Unfortunately, my experience has been no, both in initial
checkouts, and in large updates -- if I go for a month without
pulling Linus' latest changes, with the poor connectivity I
have, sometimes it will take three or four attempts until I
can get all those handful of megabytes of chunks intact at

Worse is if your ISP has you on a configuration that doesn't
preserve your IP for the duration of your download, changing
it every few minutes, or hours, as is a common practice to
keep customers from running servers or doing anything useful.
The net was made for surfing, not downloading, dammit.

I am writing from the point of view of a beginner who knows
nothing about the advantages of `git' or `hg' or `svn' and
friends and who only wants to clone the entire development
tree locally for off-line work with access to any point of
development, and as such I don't know of any possible expert
flags like ``--partial'' or something to instruct `git' not
to discard any complete or partial chunks.  In fact, I don't 
remember if I downloaded the original kernel in any special way, 
such as a .tbz file to be used as a base and then updated from 
there.  So don't take my word as gospel.

barry bouwsma
in the middle of an aborted-after-four-hours update of FreeBSD 
during the bandwidth-hungry ``fixup'' process that thanks to 
their accursed move to `svn' seems to take much longer than just
pulling the deltas alone, but luckily which I can resume once I
get ``better'' connectivity and not lose much of anything.
grumble mumble old fart grumble
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [ANNOUNCE] git tree repositories

2010-01-20 Thread BOUWSMA Barry
On Wed, 20 Jan 2010, Mauro Carvalho Chehab wrote:

 Andy Walls wrote:
  On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
  BTW: I just made a clone of the git-tree - 365MB *ouff*.
  Assuming 53.333 kbps download speed, 0% overhead, no compression:
  365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr =
  15.95 hours
 It is an one time download, since, once you got it, the updates are cheap.

Getting a bit off-topic here, but hey

Yes, but it is that first step of getting the download that is
the problem.

Until the tree ends up with a conflicted merge (has happened to
me a few times), and then a beginner such as myself has no idea
what to do and pushes the tree out of the way and starts anew
(or decides to give up on the tree that's no longer so much of
interest), but that's when I've had better connectivity than
Sir Walls here.

A big problem I see and which will affect the majority of people
on less-than-ideal connections is that the initial clone is that
the `git clone' for such a large tree is not something you can
pick up if interrupted in the middle.  I'd hate to be in Andy's
house as he's drenched with sweat clenching the arms of his
chair watching the progress bar go from 98% to 99% to
^%{3f{NO CARRIER as someone on his party line down the road
picks up the phone to chat with their sister in the next room.
Actually, that's not true, I'd love to hear it as I'm sure there
are a good variety of swear words I haven't learned from the time
I had me mouth washed out with Irish Spring, carried on to this
day by gargling every evening with Fairy Liquid.

 Btw, it is a way small than a single CD needed for you to install Linux.

But `wget' has an option to resume the download, even if it takes
a week to get the entire CD as it did me.  Or better, as I used,
`jigdo' which splits the download even further, automagically
uses `wget' in shortened `retry' mode, and allows me to get the
missing parts elsewhere -- before, like `git' or other SCM
frontends, getting incremental updates.

That is what seems to be missing from `git', in spite of its
other advantages over `rsync' or `CVSup', for an initial download.

 If you want to get it and you're not willing to pay to a decent Internet
 connection, just ask someone to get it for you and save on a CD.

This is not a good attitude to have -- I have been in places with
no practical internet connection and places where it was not worth
it to pay for a ``decent'' connection.  Still, I tried to get on-
line when possible.

You are also working with volunteers who are putting out their own
money to get connectivity.  I'm sure that I am not the only one on
the list who is unable to get a satisfactory decent-paying job at
present, but who is willing to donate time and some resources to
advance Linux and other free software.  To do so I rely on more
fortunate friends who can afford a decent connection, when most of
my usage wouldn't even be noticed on a dial-up connection.

Sorry, I'm just ranting.  Ignore me.  Or I'll blow you all 
sky-high after a week.

barry bouwsma
no-fly zone, until spring
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Siano SMS1140 problem

2009-12-31 Thread BOUWSMA Barry
Sorry for the delay in replying...  A spiffy new year everyone for
whom calendars and clocks and daylight and seasons have meaning,
and also to the rest of you living in your mum's basement.

On Tue, 29 Dec 2009, wrote:

 I've already worked with different adapters (Pinnacle 320E with  em28xx, 
 Intel CE9500B1, Hauppauge Nova-T Stick and SAA7134), and all have worked 
 without big problem reading the howto I've found online; but now I've a new 
 dvb-adapter, and it's a Siano SMS1140.

I have a related, but different adapter, which until now I've just
been using for DAB+ and DAB service reception, but I decided I'd
check if there might be a regression in later kernels.  Problem is
I'm using a deliberately crippled machine, so that I don't trust
all that I see.  (Browser `lynx' tossing up kernel malloc failures
I'd never seen before, for example)  That aside,

 - dmesg output:
 usb 1-7: new high speed USB device using ehci_hcd and address 7
 usb 1-7: New USB device found, idVendor=187f, idProduct=0201
 usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-7: Product: MDTV Receiver
 usb 1-7: Manufacturer: MDTV Receiver
 usb 1-7: configuration #1 chosen from 1 choice
 usb 1-7: firmware: requesting dvb_nova_12mhz_b0.inp
 smscore_set_device_mode: firmware download success: dvb_nova_12mhz_b0.inp
 usbcore: registered new interface driver smsusb

What I see in my first failed attempt is
[422523.242709] usb 3-2.2.1: firmware: requesting dvbt_bda_stellar_usb.inp
[422523.329911] smsusb: probe of 3-2.2.1:1.1 failed with error -71
[422523.331556] usbcore: registered new interface driver smsusb

Unfortunately, that prevents me from identifying at what point in
the following sorta-successful attempt you would see the 
registration of the smsusb...  And I am too lazy to unload those
modules and try again :-)

Here is what I see after a successful load of the firmware, that
the device disconnects, reconnects with a different ID, and then
runs into further problems:

[422545.201374] usb 3-2.2.3: firmware: requesting dvbt_bda_stellar_usb.inp
[422545.468215] usb 3-2.2.3: USB disconnect, address 26
[422547.750697] usb 3-2.2.3: new full speed USB device using uhci_hcd and 
address 27
[422547.883683] usb 3-2.2.3: New USB device found, idVendor=187f, 
idProduct=0100[422547.883826] usb 3-2.2.3: New USB device strings: Mfr=1, 
Product=2, SerialNumber=0
[422547.883978] usb 3-2.2.3: Product: SMS DVBT-BDA Receiver
[422547.884095] usb 3-2.2.3: Manufacturer: Siano Mobile Silicon
[422547.886690] usb 3-2.2.3: configuration #1 chosen from 1 choice
[422548.012889] smsusb_onresponse: line: 116: error, urb status -84, 0 bytes

I am not sure if you should see the same thing (disconnect, 
reconnect with different ID from the firmware) with your 
particular device after firmware load.

In any case, the kernel version I had used for DAB+ reception is
several versions back, and the last time I attempted to use this
device for DVB-T is even older than that (no problems then, but on
different hardware, with a lot fewer USB hubs in the path to 
cause problems).

I'd offer to see what I could do with the particular kernel source
which gives me the above, except that I've already overwritten 
that source with newer.

Anyway, I will see what I can do with my device with either the
newest kernel, or the older stable one which I've patched into
usefulness, sometime in the coming days or weeks, and report any
successes or failures (plus differences to the Siano library that
supports the Eureka-147 DAB decoding, should that also fail).

 Someone can explain to me how to get it to work or where I miss something 
 ori, if it's due to some regression, how to debug it and support a programmer 
 for this?

This isn't much, but in the absence of any other replies, it's the
best I can offer.

barry bouwmsa
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Bad image/sound quality with Medion MD 95700

2009-12-25 Thread BOUWSMA Barry
On Fri, 25 Dec 2009, TAXI wrote:

 I tried a Medion MD 95700 with kernel 2.6.32 (for tests: and
 have a very bad image and sound quality.

I have two of these boxes, and they work great -- but I've had to 
patch the kernel in different ways to have success.

One way for my production machine happily running 2.6.14 with 
patches, due to the fact that this kernel has a problem with
isochronous data being passed through an external hub -- the
95700 has a built-in hub to allow its built-in USB port to co-
exist with the datastream and the remote control.

The other way works for newer kernels, sort of, and looks for the
data on a different alternate interface where it can be found (but
it requires a kick in the pants to get it started), although it
is possible to successfully use either the isochronous or the bulk
datastream which the device delivers with these later modern 

The other thing to note is that this device delivers a full
unfiltered Transport Stream, which with the 13,27Mbit/sec typical
bandwidth per channel used in your country (apart from some local
exceptions of greater values), will require a USB2 interface.

I mention this because the last multi-gigahertz-CPU machine I got
my grubby fingers on still had only a built-in USB1 chipset, 
although when you write:

 under windows XP the image and sound is perfect.

That leads me to believe you have a USB2 interface and can ignore
this -- although if you're somehow failing to load the EHCI driver
and falling back to the companion UHCI or EHCI USB1, it will be a
problem.  You may want to verify that -- I am thwarted by 
unco-operative hardware that prevents me from using numbered
kernel revisions as you mention as opposed to my custom kernels
direct from the `git' repository tuned to my hardware and usually
with more patches and hacks than are reasonable.

 [mpeg2video @ 0xc62be0]ac-tex damaged at 23 4
 [mpeg2video @ 0xc62be0]ac-tex damaged at 14 9
 [mpeg2video @ 0xc62be0]skipped MB in I frame at 40 10
 [mpeg2video @ 0xc62be0]invalid mb type in I Frame at 29 15
 [mpeg2video @ 0xc62be0]skipped MB in I frame at 32 19

This and the following errors can be caused by any number of 
reasons for a corrupt data stream -- inadequate bandwidth (use
of USB1 where USB2 is required for a complete Transport Stream),
improper antenna orientation, or, with certain kernel revisions,
attempting to read an isochronous data stream as bulk or vice

Ooops, I just rebooted after a crash before plugging in a more-
than-one-button-mouse on this machine I never intended to make
serious use of, so I can't paste the diffs, but...

around line 620 in my reference code, there is a line that sets
the alternate interface to 6.  This is expected to be bulk, but
on my boxes is isoc.

You can change this to interface 0, on which my boxes delivers
bulk data flawlessly.

I've attempted to add a test of what sort of data is present on
this interface, and if it's not bulk, decides to read isoc data
from this interface (6) instead.  That also works, but somehow
needs an extra kick such that the first time it fails, yet is
fine after that.  (I get occasional failures from other tuner
cards that work fine immediately after, so I've worked around
this in the scripts I use.)

Anyway, I've been meaning to clean up this patch, or the 
alternative patches, and submit them to be ignored, but when
I have my machine operating fully again (yeahright), I can send
you some of these alternative patches to try -- running 
successfully on 2.6.14 and 2.6.27-rc4.

Hope this is helpful in spite of its vagueness...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Bad image/sound quality with Medion MD 95700

2009-12-25 Thread BOUWSMA Barry
Moin moin, TAXI...

On Fri, 25 Dec 2009, TAXI wrote:

 BOUWSMA Barry schrieb:
  The other thing to note is that this device delivers a full
  unfiltered Transport Stream, which with the 13,27Mbit/sec typical
  bandwidth per channel used in your country (apart from some local
  exceptions of greater values), will require a USB2 interface.

 it is a USB2 interface:
 [3.965425] usb 1-3.1: new high speed USB device using ehci_hcd and
 address 6 (it's the USB hub in the box)

Na gut -- so habe ich erwartet.  Aber sicher ist sicher, vertrauen 
ist gut, usw.

Or in english, I expected that, but it is always good to be sure, 
as it is one of the problems or bottlenecks which I regularly

  around line 620 in my reference code, there is a line that sets
  the alternate interface to 6.  This is expected to be bulk, but
  on my boxes is isoc.
  You can change this to interface 0, on which my boxes delivers
  bulk data flawlessly.

 I think isoc would be okay on 2.6.32, so no need to change that, right?

Das Problem ist, der Treiber erwartet BULK Datei, nicht ISOC, aber
das Kistchen liefert ISOC (isochronous) Datei.  Deswegen kommt es
zu Probleme.

Or, the thing is, Linux is expecting to be seeing bulk data on 
this particular alternate interface (6).  If the receiver is not
delivering this, but is instead delivering isochronous data, it's
not in the same format and isn't properly handled by the driver.

Changing it so that the driver reads from alternate interface 0
results in all my hacked versions being able to read the data
properly.  Even before reading isoc data through hubs was fixed
sometime around or before 2.6.18-ish.

  but when
  I have my machine operating fully again (yeahright), I can send
  you some of these alternative patches to try -- running 
  successfully on 2.6.14 and 2.6.27-rc4.

 That would be nice.
 P.S. my english is not the best so I don't understand all you wrote but
 why don't you put the patches upstream?

Mein deutsch ist noch schlimmer, wie Du siehst  :-)  Verzeihung 
wegen meine Muttersprache -- gerne schreibe ich, falls moeglich,
einfacher und verstaendlich.

Es gibt zwei moegliche Loesungen, entweder einen anderen Dateityp
aus'm `Endpunkt' zu lesen, oder aus ein anderem `Endpunkt' lesen.
Mein Kode ist leider nicht sauber.  Es laeuft bei mir, aber 
koennte Probleme bei anderen verursachen.  Ich kann keine 
Unterschiede zwischen `bulk' und `isoc' Datei auch mit 'nem 
200MHz Server feststellen, und kann deswegen keine gute Wahl 
zwischen die beiden entscheiden.  Ich bin auch mit meiner Loesung 
nicht ganz zufrieden.

Or, I hope you see from my dreadful sentences above that you need
not be ashamed of your english, but I will be happy to re-phrase
and try to clarify anything I have written.

My work-in-progress patches try to use the two possible solutions,
without affecting anyone whose receivers work, but I have not 
found a clear reason to favour one solution over the other.  The
solution which I think stomps less on the existing code is not
perfect (first tuning fails), and after getting my receivers to
work with both possibilities, I have not tried to clean up the
two solutions for submissions as possible patches.

Hast Du die 2.6.32 Quellkode?  Kannst Du aus `patches' etwas 
schaffen, und dabei die beide Moeglichkeiten testen?

(Are you able to build a new kernel to test my patches to see
if they solve your problem?)

barry bouwsma
('tschuldigung, wegen moi' Tastatur, Grammatik, Woerterschatz,
und allgemein Bloedheit)
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Bad image/sound quality with Medion MD 95700

2009-12-25 Thread BOUWSMA Barry
On Fri, 25 Dec 2009, TAXI wrote:

  I have my machine operating fully again (yeahright), I can send
  you some of these alternative patches to try -- running 
  successfully on 2.6.14 and 2.6.27-rc4.

 That would be nice.

Hintergrund (aber nicht so wightig)...

I have not had the chance to update my `git' kernel source since 
more than a month, and even then, it is on a disk which I cannot
plug in at present.  The latest source I have at hand which I've
patched is 2.6.27-rc4.  There may be some differences from the
present code, so I am not sending a normal patch.

(Ich verwende aeltere Quellcode, deswegen musst Du per Hand
etwas aendern)

verify that you are seeing the same problem I have had.

As I do not have a simple patch, I will give you the simple
changes to be made by hand.  Either way should give you a working
receiver, and both, but not together, should work.

Make a copy of the source file...
$  cd (your linux source)
$  cd drivers/media/dvb/dvb-usb
$  cp -pvi  cxusb.c  cxusb.c-DIST

Edit cxusb.c

find the function
it should have the line
if (usb_set_interface(adap-dev-udev, 0, 6)  0)
or something very similar -- change this 6 to 0.

This will cause the driver to look at alternate interface 0 for
bulk data.

Now rebuild the kernel or the dvb_usb_cxusb module, reboot or load
the new module, and try it and see if it is better.

I will send a second alternative patch, to read isoc data from
interface 6, in a separate message.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Bad image/sound quality with Medion MD 95700

2009-12-25 Thread BOUWSMA Barry
On Fri, 25 Dec 2009, TAXI wrote:

 BOUWSMA Barry schrieb:
  Now rebuild the kernel or the dvb_usb_cxusb module, reboot or load
  the new module, and try it and see if it is better.

 Great job, it works!
 Thank you so much :)
 Should we try the isoc transfer now?


I wish I could find a clean patch that I used in the past -- but
it is hidden on a disk...  somewhere...  somewhere...

I may have to send an untested patch.  Boy, I wish I could copy
and paste with my mouse  :-)

Here is some source code which I have from 2005, with the ISOC
parameters that used to be used...

.generic_bulk_ctrl_endpoint = 0x01,
/* parameter for the MPEG2-data transfer */
.urb = {
.type = DVB_USB_ISOC,
.count = 5,
.endpoint = 0x02,
.u = {
.isoc = {
.framesperurb = 32,
.framesize = 940,
.interval = 5,

.num_device_descs = 1,
.devices = {
{   Medion MD95700 (MDUSBTV-HYBRID),

The idea is to fit this into the cxusb_medion_properties that
is probably near line 900 of your present source, plus or minus
however many changes there have been in the past five kernel
releases since my 2.6.27-rc4.

These are the lines which now look much like  .type = USB_BULK,
and so on.


Of course, you will first want to
$  mv -iv cxusb.c  cxusb.c-bulk-hack
$  cp -pvi  cxusb.c-DIST  cxusb.c
then make your changes to the unchanged original cxusb.c

In a later patch which I have intended to be compatible for all
users, I have this set somewhere else, with lines similar to

+/* XXX try to switch to using ISOC instead of BULK */
+/* XXX debug */err(attempting to use isoc transfers on alt6 
+   props-adapter-stream.type = USB_ISOC;
+   props-adapter-stream.u.isoc.framesperurb = 32;
+   props-adapter-stream.u.isoc.framesize = 940;
+   props-adapter-stream.u.isoc.interval = 5;
+#endif /* XXX HACK */

But this patch is very messy, and I must clean it up before I
can even think of posting it to the list...

I hope this can get you started, as I continue to search for a
simple patch which does the above, but correctly.

batty bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: scan/scan-s2 doesn't tune, but dvbtune does?

2009-12-21 Thread BOUWSMA Barry
On Fri, 18 Dec 2009, Michael Akey wrote:

I can't get the scan/scan-s2 utilities to lock any transponders (DVB-S).
 My test satellite is AMC1 103W, the Pentagon Channel tp. This is
some simple user error on my part, but I can't figure it out.  I have a
Corotor II with polarity changed via serial command to an external IRD.
 C/Ku is switched by 22KHz tone, voltage is always 18V.  Ku is with tone
off, C with tone on.  Speaking of which, is there a way to manually set
tone from the arguments on the scan utilities?

   I think
 it's a tone issue, but then again, why does attempting to scan something on
 both bands C and Ku (tone on, and tone off respectively) not work?  I figured
 if it's a tone issue that only one band would work.
 I tried setting the FEC and even the delivery system (S1 rather than S) and it
 makes no difference.  I could try the DVB-S2 NBC mux on that satellite too..
 but I'm not sure why that would make a difference.
 If you folks have any other ideas, let me know.  Thanks for your responses so

Hi Mike,

I overlooked your description of your Corotor and IRD earlier, and
now, with poor connectivity, I can't really look up the details 
and match them with my experiences.

I have a switch that is activated by the 22kHz signal and which
used to be used for old analogue setups to select between two
positions.  I'm not sure if there is a discrete component like
this in your setup, but if there is, is it possible for you to
bypass it and get directly to the C- or Ku-band LNB?  Or am I
failing to do research to show me this is not possible...

In any case, I'd do what I can to get directly to the LNB.  Also,
your mention of polarity switching is, well, alien to me.  I
suspect the card is expecting to use 13V or 18V to get vertical
or horizontal polarisation; for circular polarisation I wouldn't
know what handedness corresponds to what switching.

Anyway, the 18V you say is constant, would be supplied by the
horizontal polarisation.  If you're able to get that 22kHz switch
out of the way, and scan the Ku-band LNB directly, you ought to be
able to see the same results with giving the directly-used 
frequency values, or subtracting 1 000 000kHz to convert your
10750MHz to the 9750MHz expected by the low-band Universal LNB
local oscillator frequency -- the latter normally not generating
the 22kHz signal.

I don't know if this will help at all, or if it's possible, and I
apologise for my ignorance about your specific dish(es?).

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?

2009-12-18 Thread BOUWSMA Barry
On Fri, 18 Dec 2009, Robert Longfield wrote:

 Ok so I ran a live CD on my windows box and there were no sync
 problems. I installed the latest Ubuntu CD and dual booted my windows
 machine and there was no sync problems but there was other issues,
 many tiny black lines on edges during fast movement when I did a $ cat
 /dev/video0  foo.mpg.

This sounds like an interlacing issue -- I suspect you are using
some player that delivers 25 full frames per second to your 
display instead of somehow getting 50 partial fields from them
or interpolating the fields into 50 frames per second.

This is fairly normal when not dealing with progressive material 
(720p HD video, or 1080i HD or even SD video taken from source 
material such as film shot at 24 fps).  Most players have options 
to enable one of any number of deinterlacers, some of which work 
better than others for selected movement.  (There are many 
different commandline options for `mplayer', one of which will 
present the fields of a 576i video as 288-line images which helps 
decipher fast-scrolling text, for example.)

If you are reproducing your video at your display's native 
resolution without zooming it to fullscreen, you can see each
of the jagged lines matching one pixel vertical resolution.

barrry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: scan/scan-s2 doesn't tune, but dvbtune does?

2009-12-15 Thread BOUWSMA Barry
On Mon, 14 Dec 2009, Michael Akey wrote:

 I can't get the scan/scan-s2 utilities to lock any transponders (DVB-S).  My
 test satellite is AMC1 103W, the Pentagon Channel tp. This is probably some
 simple user error on my part, but I can't figure it out.  I have a Corotor II
 with polarity changed via serial command to an external IRD.  C/Ku is switched
 by 22KHz tone, voltage is always 18V.  Ku is with tone off, C with tone on.

I'm afraid that I have a european background into which your use
does not fit my expectations.  What I expect is that the voltage
will be determined by what sort of polarisation you are trying to
receive (your fixed 18V would correspond to horizontally polarised
transponders) whilst the 22kHz tone would be used to select within
the Ku band between the low and high band (switchover between a
universal LNB's 9750 and 10 600 MHz IF at actual frequency near
11 700 MHz).

Variants thereupon may depend on older installations, and while
C band does exist, I've never personally bothered to use it or
play with LNBs and such to learn those details.  With this
background, I'll attempt to interpret what I see below.

 $ ./scan-s2 -a 0 -v -o zap -l 10750 INIT

 initial transponder DVB-S  1210 H 2000 AUTO AUTO AUTO
 initial transponder DVB-S2 1210 H 2000 AUTO AUTO AUTO
 -- Using DVB-S
  tune to: 12100:h:0:2
 DVB-S IF freq is 135

This frequency would normally be tuned with 22kHz tone on, with
a traditional Universal LNB.  I can't be arsed to look up the
particular bird on which your transponder lies to get its
particulars (frequency 12100h, SR 2 I will take from your
parameters), but if this utility is selecting the 22kHz
switching signal based on the frequency, it may assume
that 12100 needs this tone, in spite of your specifying the
LO intermediate frequency, which apparently you use to select
between Ku band and when active, C band.

 If I use dvbtune, it works though..
 $ dvbtune -f 135 -p H -s 2 -c 0 -tone 0 -m

 tuning DVB-S to L-Band:0, Pol:H Srate=2000, 22kHz=off

Here you're tuning directly to the IF frequency which the
above utility determines from your specified LO value and
desired tuning frequency.

I'd look at the source code for the above utilities which
fail to see if it's deciding 22kHz tone based on the tuned
frequencies.  If so, and there aren't options to work around
this as you can with directly specifying the IF to `dvbtune'
as above, then it may work to massage the input values you
feed to `scan' not to be the actual frequencies.

 The tuning file 'INIT' contains only the following line:
 S 1210 H 2000 AUTO

If this corresponds to 1 350 000 kHz IF, and you faked that
your LNB had an IF of 9750 MHz, the corresponding ``tuning
frequency'' would be 11 100 MHz, or 1110 H in the above
line.  Horizontal polarisation corresponds to your 18V
nicely.  Otherwise it's a particular configuration which would
be alien to me with my limited hands-on experience.

Note that what you get back from parsing the NIT tables when
tuning the above transponder at the hacked value would need
to be again adjusted similarly.  But I don't know what the
frequencies and bands are that are used by this bird, nor do
I know what sort of consumer equipment is used outside the
part of the world where I learned my knowledge of the trade.

Anyway, that's how I interpret your results.  I'd be happy if
someone with more intimate knowledge of those utilities, their
options, and other setups, could give you a one-line cure for
your woes -- otherwise I hope I've provided a bit of background
to help you better understand what may be going on.
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: no locking on dvb-s2 22000 2/3 8PSK transponder on Astra 19.2E with tt s2-3200

2009-12-09 Thread BOUWSMA Barry
On Wed, 9 Dec 2009, Newsy Paper wrote:

 no matter if I use Igors or Manus driver, there's no lock on 11303 h 22000 
 2/3 8psk. Other users at vdr-portal report same problem.
 The strange thing is that all other transponders that use 22000 2/3 8psk do 
 work but this transponder doesn't. It worked fine until december 3rd when 
 uplink moved to Vienna. I think they changed a parameter like rolloff or 
 inversion and the dvb-s2 part of stb6100 is buggy.

Oh jeez, non-wrapping mail...  Anyway, without bothering to see
what I'm replying to, here's the value I get from parsing the
NIT table today:

  Frequency: 18023029 (=  11.30275 GHz)
  Orbital_position: 402 (=  19.2)
  West_East_flag: 1 (0x01)  [= EAST]
  Polarisation: 0 (0x00)  [= linear - horizontal]
  Kind: 1 (0x01)  [= DVB-S2]
  Roll Off Faktor: 0 (0x00)  [= Alpha 0.35]
  Modulation_type: 2 (0x02)  [= 8PSK]
  Symbol_rate: 2228224 (=  22.)
  FEC_inner: 2 (0x02)  [= 2/3 conv. code rate]

Now, I get the following for a different transponder, with a
different roll-off:

  Frequency: 17920117 (=  11.17075 GHz)
  Orbital_position: 402 (=  19.2)
  West_East_flag: 1 (0x01)  [= EAST]
  Polarisation: 0 (0x00)  [= linear - horizontal]
  Kind: 1 (0x01)  [= DVB-S2]
  Roll Off Faktor: 1 (0x01)  [= Alpha 0.25]
  Modulation_type: 2 (0x02)  [= 8PSK]
  Symbol_rate: 2228224 (=  22.)
  FEC_inner: 2 (0x02)  [= 2/3 conv. code rate]

But at the same time I see the same roll-off reported on all
but the 0,25 transponder within the limited NIT table I
nabbed, regardless of 9/10 FEC or 2/3+22000.

I don't know if the above NIT data is 100% accurate, or if
it reflects a change from what it was before.  Actually, I
don't know if I'm parsing everything, because I vaguely
recall there are other selectable options on a real receiver
(which I've never had in front of me) pertaining to pilot
on or off, which apparently affect tuning ability.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Fwd: DVB-APPS patch for uk-WinterHill

2009-12-03 Thread BOUWSMA Barry
On Thu, 3 Dec 2009, Justin Hornsby wrote:

 Since 02 Dec 2009 the UK WinterHill transmitter site has been
 broadcasting on different frequencies  in a different mode with
 different modulation.  Channels have been re-arranged to occupy five
 multiplexes and the original BBC 'B' mux is now broadcasting DVB-T2
 for high definition services (which of course cannot yet be tuned by
 mere mortals). The 'WinterHill B' transmitter stopped broadcasting on
 02 Dec.
 The attached file is a patch to reflect these changes.

 +T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 +T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 +T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 +T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 +T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

While the DVB-T2 multiplex (MUX B) cannot be tuned by existing
DVB-T-only devices, and I don't know if the dvb-apps are being
prepared for DVB-T2 (there don't appear to be any of the
known DVB-S2 transponders listed in a couple positions), the
modulation parameters, for future reference, are probably
something like

+# T2 73800 8MHz 2/3 NONE QAM256 32k 1/128 NONE #E54 DVB-T2 HD MUX B

There may need to be additional details specified, I'm no expert.
These values are, of course, unconfirmed.

The same would be true for Crystal Palace at 10kW, but on channel
E31, or 55400, no offset.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: CH???, Bandwidth 8MHz, Fec_Hi 1/2, Modulation QAM64, Mode 8K, Guard 1/4, fails to tune\demux

2009-11-21 Thread BOUWSMA Barry

I'm afraid that your posting is horribly unclear, with the
apparently important information present in the Subject: header,
as such:

``Subject : Re: CH???, Bandwidth 8MHz, Fec_Hi 1/2, Modulation QAM64, Mode 8K,
  Guard 1/4, fails to tune\demux''

I'm going to go out on a limb and ass-u-me that you are writing
to ask about the DVB-H multiplex which is broadcast by SBC on
several different allocated SFN frequencies throughout
Confœderatio Helvetica.  The DVB-T services use a more 
conventional FEC of 5/6 in a denser network of transmitters.

Note that these frequencies are partly re-used in areas where it
is possible to receive simultaneously the out-of-area DVB-T
signals on the same frequency, which renders both impossible to
receive, in spite of a healthy signal strength.  I don't know if
this might affect you.

Not only is this multiplex sent in DVB-H standard, but it is
also a subscription service.  Therefore at best you can read the
PIDs corresponding to the various services, but you aren't going
to be able to watch anything, as different utilities may come to
terms with the datastreams in different ways.  Most Linux 
utilities likely don't know anything of the DVB-H parsing needed
for this service.

Note that I want to verify that this multiplex uses the more
robust QAM16 along with 1/2 FEC rather than the QAM64 you have
given, in order to permit best operation in diverse terrain,
but I can't find my parse results from the datastream amongst
my active disks.  In any case, you can try this tuning option
to see if you get a lock.

In order to receive these broadcasts, you will need to be a
subscriber to this service -- I suggest that you get in touch
with your nearest Swisscom to point you at the provider, though
Sunrise or Orange or anyone else can probably point you to the
provider of this service, who is unknown to me.  I doubt you
will achieve any Linux-based satisfaction here.

If this is not that to which you refer, then please re-formulate
your question in a less ambiguous and more geographically-specific
way, and sorry that I've wasted your time.

barry bouwsma

On Fri, 20 Nov 2009, g_remlin wrote:

 02:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
 Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget/Hauppauge
 WinTV-NOVA-T DVB card
 Flags: bus master, medium devsel, latency 32, IRQ 17
 Memory at e3001000 (32-bit, non-prefetchable) [size=512]
 Kernel driver in use: budget dvb
 Kernel modules: budget
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2

2009-11-04 Thread BOUWSMA Barry
Replying to myself is the first sign that I need to be committed
to a mental institution.  So here goes.

On Wed, 4 Nov 2009, BOUWSMA Barry wrote:

 The other possibility, given that two of the four inputs to
 your multiswitch work, is that the two low-band inputs have
 been crossed.

Thinking more about this, I don't think this is the case,
if someone hasn't already corrected me -- there is a range
of frequencies which, last time I scanned, were shared by
both polarisations, with identical symbol rates.  Although
this was not legitimate input for an earlier `scan' and I've
hacked a script to work around this.

### frequency pairs, h+v, mostly 27500 from 11200 upwards
S 11222170 H 27500
S 11223670 V 27500
S 11259670 V 27500
   This has an odd SR NO MORE...  S 11264470 H 22000
S 11261170 H 27500
S 11307000 V 27500
S 11307000 H 27500
S 11343000 V 27500
   This has an odd SR  NO MORE...  S 11344000 H 22000
S 11344500 H 27500
S 11388830 H 27500
S 11390330 V 27500

This continues, more or less, through 11500.  In other words,
if your two low-band inputs to the multiswitch were reversed,
you'd still get something on the above frequencies, even if
the actual parameters you'd be reading wouldn't match what is
actually transmitted.

Sorry for the misleading info I posted earlier.  If there is
any cabling problem, I'm positive it would have been noted
as the BBC channels are certain to be ones checked by any
halfway competent technician.

As far as the possibility that your tuner card isn't
properly switching into low-band, if you were to modify
your scan file so that the successfully-tuned frequencies
above 11700 are repeated but with a value corresponding
to the different IF frequency, and you can again receive
the same services, then that would point to that problem.

I'd give an example, but that would require me to think.
But here's the idea -- if you've tuned 11720, that's with
an IF of 10600.  With an IF of 9750, you'd want to be tuning
to 11720 - (10600-9750) MHz.

If that makes any sense.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2

2009-11-03 Thread BOUWSMA Barry
On Wed, 4 Nov 2009, TD wrote:

 removed linux-dvb x-post

Oooh, that's a mistake (from my view) -- it means your reply
doesn't appear in my inbox, and it's only through luck that I
find it amongst the uninteresting (to me) posts that I check
infrequently on linux-media via gmane -- I thought there was
to be a separation between developer mail, and dvb-user mail,
and this clearly falls into the latter.  And is more my bag.
But that's a rant I don't want to get into, as I'm in the
minority here.

  Therefore the failure to tune DVB-S2 transponders has nothing
  to do with reception of Freesat.
 I wasn't aware - I thought the Freesat HD channels were DVB-S2, that's why I
 got that card.  Now upon further research, it appears that talk of DVB-S2 with
 Freesat has died down, so looks like I've wasted some money (for now).

Happy to offer the background.  I wouldn't say you've wasted
money -- rather, you've future-proofed yourself.  Sadly the
Freesat specs don't appear to have mandated the more efficient
H.264 AVC video codec for SD resolution services, so there is
no possibility of that for a Freesat-only (no BSkyB) service
that wants to save transmission costs, yet still be received
by the handful of non-HD-able receivers out there.  I'd liken
it to my decision not to buy any DAB-only receiver without the
DAB+ (and DMB) capability that is presently in use (if not in
the UK or other countries), or any further DVB-S cards without
-S2.  And DVB-T2.  What seems like a waste of money today will
guarantee you don't have to spend as much later -- with your
DVB-S2 card and a suitably positioned dish, you could be
receiving the french-german `arte' where occasional programmes
capture my interest, as well as other FTA services that have
not yet interested me in a pure -S2 form.

Also, while the Beeb may not presently be transmitting -S2 for
their HD service, I wouldn't rule it out.  There's a long and
sordid history behind Freesat and the Continent that limits
what is available via Freesat and its quality to what the 2D
satellite can deliver, and any future services (such as the
recent Freesat `Five') will need to be shoehorned into that
already overfilled space.

 My channels.conf contains both horizontal and vertical channels, but nothing
 below 11700.  So it looks like I'm not getting anything via low band?

Thanks for confirming this.  This points to a potential, but
unlikely, problem with your device, that it can't switch into
the low band (I had a problem where one of my devices could
not receive anything in the high band without hackery, or a
multiswitch which spoke to it differently).

If you are not aware of it, in case it helps, the switching
between low (below 11700-ish) and high band is normally
accomplished with a 22kHz tone signal, absent for low band.
It can also be accomplished by a particular DiSEqC signal
which my one device speaks to the multiswitch I got which
solved that problem, that being the opposite to what you are

The other possibility, given that two of the four inputs to
your multiswitch work, is that the two low-band inputs have
been crossed.

  If you have a complete lack of any results with one particular
  polarisation/band combination, then suspect possibly your
  cabling, unless a regular FTA/Freesat/Sky receiver connected
  to the same is able to successfully find all services.
 As per my OP:
 = The setup is that this is a newly-built flat, with a double F-socket on the
 = wall.  I followed it down to the distribution panel in the basement, and 
 = connected to a Delta MS 5024 N multiswitch.  From what I could make out, 
 = switch has four cables going in (vertical 0khz, horiz 0khz, vertical 22khz,
 = horiz 0khz), and lots of cables going to the flats.
 Surely it must be the switch, I don't see what else it can be, especially if
 there is no special signal that a Sky box sends down the wire to the switch,
 that my setup would need to replicate.

Yeah, a third possibility could be the switch.  I glossed over the
details in your original post about the switch, and completely
forgot it was newly-built.

While I would normally expect everything to work in a new
installation, I've read enough to convince me otherwise.
As a confession, when I have to replace the cabling into my
multiswitch, these days I determine the proper wiring by a
process of elimination as to which of the four cables goes
where.  I recently had to do this with my dish pointed at
28,2/28,5°E and I'm always wary when I have the mathematically
improbable result of the randomly selected cables being
connected to the right inputs.  But enough of my confessions
why you wouldn't hire me to install anything you care about.

 There is a caveat above, which is that we are the first people in the block,
 so who knows what reception others are getting.  I've already had the cables
 from the switch to our flat moved to a different switch, as when I mentioned

Different switch, or different 

Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2

2009-11-02 Thread BOUWSMA Barry
On Tue, 3 Nov 2009, TD wrote:

 On 2009-11-02, Goga777 wrote:
  Приветствую, TD
  you have to use scan-s2
 Hi, and thanks for your quick reply.
 I tried it but no better:
 initial transponder DVB-S  12692000 V 19532000 1/2 AUTO AUTO
 initial transponder DVB-S2 12692000 V 19532000 1/2 AUTO AUTO
 -- Using DVB-S
  tune to: 11720:hC34S0:S0.0W:29500:

First of all, some background info, in case you aren't aware:

All Freesat services are presently DVB-S.  There are currently
no DVB-S2 transponders carrying any FTA services, although
there is always the possibility that the existing FTA HD services
which are on DVB-S transponders may move to DVB-S2 in the not-
too-distant future, particularly when the terrestrial UK
DVB-T2 services start before the end of the year, and Channel 4
and Five join the existing ITV and BBC HD services.

Therefore the failure to tune DVB-S2 transponders has nothing
to do with reception of Freesat.

Enough background, what I see from the above is that the
frequency of 11720 has a symbol rate of 29500 which I know
is what is used by the BSkyB encrypted programmes.  So your
ability to tune isn't going to help you see any additional
services, just as those in your original post are also
scrambled Sky programmes.

If it concerns you that you can't tune this DVB-S2 transponder,
then you'll need the advice of others with DVB-S2 familiarity.

 and the channels.conf was no better than before - it didn't include *one* BBC
 channel, for example.

The BBC channels, as well as most ITV, Channel 4, and similar
``interesting'' Freesat services, are on the Astra 2D satellite,
as per your subject.  This bird covers the frequencies from
10714250 h 22000 through 10935500 v 22000.  Its footprint is
a narrow beam focussed on the UK, and can only be received
with some difficulty elsewhere that the remaining signals
from the other Astra and Eurobird satellites deliver useable
signals.  That is, were you to be somewhere outside the UK,
you might need to more accurately position your dish.  But
that shouldn't be your problem as per your original message.

 Once I got it working, same:
 Astra 2A/2B/2D/Eurobird 1 (28.2E) 10714 H DVB-S QPSK 22000 5/6 ONID:0 TID:0
 AGC:0% SNR:0% 
 Can't tune

 Where do I go from here?

I note that your first listed frequency is 11720, just above
the transition from low to high band, in your first message.
Do you get any results with success at any frequencies below 
11700, and do your successes above 11700 include both horizontal
and vertically polarised services?

If you have a complete lack of any results with one particular
polarisation/band combination, then suspect possibly your
cabling, unless a regular FTA/Freesat/Sky receiver connected
to the same is able to successfully find all services.

You should be able to receive services from 11200 to 11700
in both bands with DVB-S, as well as above 11700, as the
former are not on a particular spotbeam.

Hope this info helps.  Feel free to send me off-list your
`scan' output (DVB-S) if you can't spot any patterns.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] what is the current status of the DVB-T2 supply chain for the UK ?

2009-08-31 Thread BOUWSMA Barry
On Mon, 31 Aug 2009, david may wrote:

 its been a while since i had need to post anything but iv got a very
 serious problem as to the status of the current status of the DVB-T2 supply 
 chain for the UK ?
 there doesn't seem to be any, and if anyone knows what's happening, then
 its the linux DVB-T guys  ;)

That's correct, but how is it a serious problem for you?

It is a chicken-egg type of problem.  The first consumer equipment
is likely to appear around the end of the year in limited 
quantities, and perhaps cut to fit the UK market's parameters --
remember how many Freeview receivers were limited to 2k and are
now being obsoleted by the switchover to 8k DVB-T.

Next year, you may start to see more on the retail shelves, but
likely to be a trickle at first, plus more full-featured devices.
Also, over time the prices should slowly fall from the early-
adopter levels that should give first-time buyers pause.

  there doesn't seem to be anything advertised here to buy, and no
  PCI(-E)or USB2 sticks with DVB-T2 chipsets/SOC included that i can

This is likely to be some time into 2010 before the first such
devices appear on the market -- and it will be more time before
such devices could possibly be used with Linux -- there is not 
yet proper support for all the additional possibilities of DVB-T2
over DVB-T in the DVB API.

  if the worlds OEMs are to be ready for that UK market and date,
  then it seems they Must be in full manufacture by now or
 already available on the shelf some were.

This is not the case -- the Beeb (and ITV and Channel 4) will 
start their broadcasting before the wide availability of consumer
equipment.  Like I said, chicken and egg.

I know of one chipset which was being prototyped some months back.
I know neither its current production status, nor whether there
are additional chipsets capable of DVB-T2 in some state of 
development or production.

 has anyone here got any information regarding the potential
 availability of such USB2 DVB-T2 sticks for PC use and whats the
 status of any drivers and support code for that? if any.

Your best bet to keep up-to-date, as well as with experts better
tuned to the UK market, would be Digital Spy, if you can avoid the
showbiz and soap opera tripe and get down to the technical gems
of details hidden within.

I can't speak for Linux support, but that will depend on how fast
the DVB-T2 enhancements get incorporated into the Linux DVB API,
and more importantly, how cooperative any chipset manufacturers
will be to work with developers in making programming information

For starters, you'll be stuck with one or two set-top boxes for
some time.  Maybe a Windows-only PC device will be introduced
sometime in mid-or-so 2010, but my crystal ball is currently out 
of service to be fit with one of those new prototype chips, so I
can't tune in any better predictions.

  but i really do hope someone here is already working with something
  we can put in and directly use in the UK with these BBC HD AVC DVB-T2
  finally going mainstream with the winterhill NW transmitter switch

And expect to pay an arm and a leg.  I suggest that if you have
access to a Freesat, BSkyB, or conventional satellite dish, you 
invest in a DVB-S2 device that you can use today.  Even though
the BBC has reduced the bitrate of its HD channel recently, maybe
to the level required for DVB-T2 terrestrial broadcast, you can
now tune in that programming.  How ITV-HD will fit into the 
picture and what changes will happen to Freesat to accommodate
that, as well as whether Channel 4 HD will be available as well,
or only via Sky for some time or DVB-T2, I cannot say.

Otherwise be patient.  Expect months to pass, but also expect a
quick uptake as other countries will be jumping on the DVB-T2
bandwagon very soon.

Hope this helps to answer your concern.  Sorry, I'm not an insider
so I don't know any more than the above.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] Anysee E30 C Plus + MPEG-4?

2009-08-18 Thread BOUWSMA Barry
On Tue, 18 Aug 2009, Pásztor Szilárd wrote:

 direction so I'm a step further now. With scan -vv I could find the video PIDs
 for the HD channels and indeed they were missing in my channels.conf (values
 were 0) as scan detected them as OTHER, but with a type 0x1b addition with
 which I don't know what to do for the time being...

Okay, so you are using a `channels.conf' file, which is used for
tuning directly by `mplayer' into a particular service.

The `scan' utility you use does not recognise the H.264 video 
service as a video stream, which is why you don't get that as
your video PID.  A common problem, I would guess.

 After adding the correct PID values, mplayer still can't demux the incoming
 stream but the video is there, and with -dumpvideo a h264 elementary stream
 gets produced in the file that can be played back if I specify -demuxer
 h264es on the command line. What are beyond me now are:
 1) how can mplayer not demux the stream if it can dump the video out
 (shouldn't a video dump involve a demux operation before all?)

`mplayer' does not (yet?) understand native H.264 video.  Whether
this is purely an `mplayer' limitation, or something which also
will affect other players, I cannot say -- I haven't looked into

As a result, even if you have both the video and audio PIDs in
your stream, you still need the additional PID from which 
`mplayer' can get the needed identification of the video as H.264.
This is found in the PMT PID (for BBC-HD in my example, 258 or
whatever 3-digit PID was there -- my memory is going...)

I said it before and I'll say it again, what `mplayer' needs is
 -- I mean, I don't know if it would be possible for `mplayer' to
identify the video as H.264, but for me, it needs this additional
PID stream to do that.  That is something for the `mplayer' 
developers or for someone more familiar with H.264 in DVB to

I'm guessing your `channels.conf' file is simple with one field
for video and one for audio, but no extra fields.  If this is the
case, then what you will need to do as a test would be to write
more of the stream to a file; the example I gave in my earlier
reply for BBC-HD is what I pass to `dvbstream'.  Then `mplayer'
should be able to play this file with no problems.

 2) is it a missing feature of mplayer that no metastream is processed that
 would carry the necessary information about the muxed streams? It would be

Like I say, I don't know if the video stream alone contains the
needed info that in theory `mplayer' could identify it as H.264.
Although it is outside of your reception as is BBC-HD via 
satellite, the british ITV HD service is broadcast as H.264 but
without a stream identifying it as such.  As a result, I've had
to hack `mplayer' to treat the video as such in order to be able
to watch the recordings I've made.

Note that my observations are made about `mplayer' from almost a
year ago, and if there have been changes made since, such as a 
more comprehensive `channels.conf' file, I'm not aware of them.

Hope this helps to understand your problem a bit better...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Digital Audio Broadcast (DAB) devices support

2009-07-03 Thread BOUWSMA Barry
Hmmm, seems my original reply didn't make it into the archive I 
use, or else the list...  No matter...  Anyway, sorry for the
delay in this reply:

On Wed, 1 Jul 2009, Andrej Falout wrote:

 Thanks for that Barry, it seems Terratec Cinergy Piranha was indeed
 discontinued, as I cant find it in shops anywhere? It's still on the
 web site (

These days you will probably have the best luck via ebay or
similar, though I had seen some shops which appeared to be
wanting to clear out their old inventory -- this may depend on
where you search, though.

 But on Terratec site, there is no mention of Linux drivers for this product.

This is -- to me, with background knowledge -- no big surprise, as
the support which exists is not so much `drivers' as you might
expect to find packaged on a CDROM with loads of other useless
drivel, but rather, more of an expert-playground thing where the
linux driver is patched to give access to a proprietary API which
gives you access to be able to tune into the DAB family of

There does not even exist an official application for tuning into
a particular broadcast stream, although for someone familiar with
DAB broadcasting and the API which Siano has made available, this
should be no problem -- one list subscriber had in fact written a
somewhat primitive tuning application which I've been using (and
many thanks, you know who you are), though it in no way matches
the needs of today's GUI-infested youth.

You will want to search the linux-dvb mailing lists for posts
from one Uri Shkolnik to find pointers to the needed patches
that can be used with the Siano devices.  But as I say, if you
want a polished product that you can plug in and use, that is
likely still a way off.  What Uri, Siano, and the author of the
utility I use to tune, have provided, is a ground-level 
introduction to the DAB family, that can be scripted for tuning
a particular service, but which is unsuitable for channel zapping
or other non-dedicated listening.

I suspect that what Siano has made available is intended more for
suppliers who include their chipsets in integrated handy devices
or similar receivers which hide their function from the end-user.

Still, if you have a particular service you wish to receive via
the DAB family, with minimal interest in zapping to other stations
during advertising or tediously-repeated songs, then the ``hacker-
oriented'' solution made available to the not-faint-hearted may
be a good solution.  Obligatory disclaimer:  ``It werkz fer me''
so for the masses, fergiddabou'it.

 Anyone else know of something equivalent that works on Linux?

For laughs, I g00gled again to see what is new in the last months.
There appear to be a number of chinese products out there which
can tune DBM as well as the DAB family.  However, I see no mention
of chip manufacturer.  Probably the best one can do here is to
plug in such a device -- if readily available -- and see if the
USB ID corresponds to Siano or some similar manufacturer.

I don't know how widespread these devices are, nor do I know if
any of today's devices include the chip announced by (I believe)
Dibcom a year or more ago.  Apart from the handful of Siano
devices, I am not aware of any DAB-family devices with any sort
of linux support, but I would hope that as this form of 
broadcasting gains prominence in certain countries, that more
devices will make available support for linux.  With the current
political situation, this appears to focus on chinese and
similar manufacturers, even where development is mandated for
France, Switzerland, Germany, and other european countries.

As far as the V4L or linux-dvb interface is concerned, as the
Eureka 147 family of broadcasts is very different from the DVB
family, there is not yet any provision for any application to
access the former, so for now, you will have to make do with
the API offered via Siano for their devices.  Whether this will
change is up to the manufacturers or distributors of any such
devices, or an expert on the Eureka-147 family, and whether
such changes can get added into the appropriate Linux API.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Digital Audio Broadcast (DAB) devices support

2009-07-01 Thread BOUWSMA Barry
On Wed, 1 Jul 2009, Andrej Falout wrote:

 Does V4L framework support DAB devices?

Jein.  The V4L framework at present lacks some of what is needed
to control and de-encode the Eureka 147 DAB/DAB+ family 

However, there is at least one set of chipmaker's devices out
there which can be used under Linux, making use of a vendor-
supplied library to take care of the tuning and demultiplexing
of one audio stream.  This chipmaker, Siano, is present in this
forum, and either has already, or is in the progress of submitting
patches to make it trivial to use their devices.  (I've stopped
following closely)

Search the list archives, as well as those of the original
linux-dvb list, for pointers to their library and documentation,
as well as to patches which I've successfully applied months ago.

As far as devices with this family of chip, the only one I am
aware of is the Terratec Cinergy Piranha, which I believe has
been discontinued, and I'm not sure how widely through the world
it has been available.  I don't know of others, and while I have
read that at least one other chip manufacturer has a combination-
format chipset in production, I don't know which products might
contain it, or whether support under linux is possible.

There is also a `dabusb' device available in the kernel, but
this is for one particular device, and probably not that
relevant to today's products.

As far as extending the V4L framework to handle DAB, that will
need someone far more familiar with the DAB family, and with the
devices now available which can receive it, than I am.

However, I can presently receive broadcasts under linux with the
vendor-provided software, which is a start, and enough to keep
me quiet.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: Aspect ratio change does not take effect (DVB-S)

2009-06-02 Thread BOUWSMA Barry
Moin Sören,

On Tue, 2 Jun 2009, Soeren D. Schulze wrote:

 right now, but there seems to be a little bug:  When watching the TV
 stream using and szap and mplayer, changes in the aspect ratio of the TV
 program do not take effect until mplayer is restarted.  This used to
 work with the former device!

This should be an issue with `mplayer' -- the aspect ratio is
simply part of the datastream sent as an MPEG transport stream
as encoded by the broadcaster.

`mplayer' is known to have this issue with the option `-vc mpeg12'
while in recent mplayer, the default is `-vc ffmpeg12' where this
aspect ratio switching works properly.  Try adding that latter
option and see if it works as expected.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [PULL]

2009-05-23 Thread BOUWSMA Barry
Moin Devin, thanks for the reply.

On Fri, 22 May 2009, Devin Heitmueller wrote:

[cut my drivel]
 The dvb core does have infrastructure to support hardware pid

If you don't mind, and this is a serious question, could you
give me some keywords to look for?  I've come up with some
obvious winners in dvb-usb with uppercase FILTER, but lowercase
filter didn't give me any serious Aha! moments for other
devices, in an attempt to determine device capabilities by
simple code reading.  Thanks!  (And I'll gladly eat my shoes
when it turns out to be something stupendously simple, as I'm
no code-reader)

   I don't know too much about the DVB standards, but I know
 that ATSC is 19.39MB/s and QAM as deployed in US cable systems is
 about twice that.  Neither would fit in a 12Mbps stream.

Bleedin' 'ell, I knew things were bigger in Texas, but I
didn't know they wuz that big!  ;-)  Just kidding, I know
what you meant...

Just for background, the overall bandwidth of DVB-T will be
determined by choice of frequency at one transmitter site or
whether shared by several and how far apart, as well as other
factors that are basically able to be simplified as a tradeoff
of reliability over distance against bandwidth.  There's a wide
variance here, but in even the most widely-reaching Single-
Frequency-Networks that are meant to be received at large
distances under difficult conditions, where available overall
bandwidth is less than that of a single transmitter serving
a local area, said overall bandwidth is generally going to
exceed that which I've achieved from USB1.1.  A certain DVB-H 
network with 1/2 FEC and 1/4 guard interval drops below
10 000kbit/sec but isn't likely to represent common usage
for broadcast TV services.

On the other hand, the individual services within each
multiplex will generally be well within the USB1.1 available
bandwidth, provided hardware PID filtering can be applied.
Bitrates for television services can be from some 2Mbit/sec
up to over 5Mbit/sec at times, depending on whether that
service has been configured to get the lion's share of the
bandwidth at the expense of the other services with rates
dynamically varying based on picture content thanks to
statistical multiplexing.

In any case, while I've been able to watch average-per-second
bitrates of different PIDs on different multiplexes, I've
just realized that I haven't actually used any DVB-T
receivers for any length of time on a USB1.1 port to see
if instantaneous bursts will exceed that bandwidth, as is
the case for quality services delivered via DVB-S and USB1.1.

But I've read that it's the exception rather than the rule
that a particular service will be privileged to get more
than its proportional share of overall bandwidth, to be free
of most artifacts and be watchable, so I'd be willing to posit 
that a full service (video, multiple audio, PMT, teletext, and 
the like) will fit onto USB1.1.

So much for background.  Anyone still bothering to read?

 If I knew of a em2874/em2884 device that also didn't use the drx, I
 would consider it worthwhile to spend the time to do the work for the
 hardware filtering.  Until that happens though, I've got better things
 to spend my time on.

No argument there.  I had a look through Herr Rechberger's
code (simply because it's had a wider variety of included
hardware, not to say anything about the linuxtv code) to get
a feel for how many devices were exclusively DVB-T, or at
least didn't include some baseband video.

It appears that a group of EM2870 devices (may well be the
2874 in reality, I just numbly scan the code) are limited
to DVB-T, including Terratec Cinergy T XS, Pinnacle PCTV DVB-T,
a couple KWorld 35xU DVB-T devices, and a Compro VideoMate.
Apart from that, all remaining devices (apart from DMB and
the like) appear to have the ability to handle analogue
signals, and need USB2.0 to reach full potential.

 filtering in conjunction with USB 2.0.  The fix is really in response
 to users with older PCs trying to capture a full ATSC stream (or
 analog capture), and being *very* confused.  If there is really a
 concern that we should be supporting USB 1.1 ports, even though USB
 2.0 has been around for almost ten years, I guess I can add a modprobe
 option to allow the user to override the check.

I actually have dredged from the dank dingy decaying dumpster 
depths or doom a machine fast enough to decode and display SD 
images, even without XVMC MPEG-2 acceleration, after replacing 
most of the electrolytic condensers/capacitors on the board, yet 
the internal USB ports are again 1.1.  Given all the Blinkenlights
it's probably an ex-gamer machine, but compared with my machine
at some 1/7 the CPU clock, it's not as obsolete as it could be,
though that still doesn't stop me from periodically wanting to
hurl it across the room every so often.

So there are probably still a fair number of boxen out there
with internal USB1.1 ports, that would be my guess.  And while
I've added 

Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)

2009-05-07 Thread BOUWSMA Barry
On Sat, 25 Apr 2009, Luca Olivetti wrote:

  The above observations are so far, just observations, and I
  don't expect anyone to be able to `fix' anything
 They're nevertheless interesting, since I'm in a similar position: my vdr
 machine is using (almost flawlessly) a Skystar 2 (though I don't believe in
 this new fangled disecq thing and I use an old fashioned actuator to move my
 dish) and it's running a 2.6.17 kernel.

Rule number one -- never upgrade a working system ;-)
Actually, it seems to be a tradeoff -- some things get fixed,
or start working, work better, and a roughly equal number of
things break.  Make sure you can trivially revert to your
known working system, or else bite the bullet, spend time
figuring out what's broken, patch, hack, patch again, before
giving up and reverting your system...

If you don't use DiSEqC to switch between different LNBs, you
may well not have a problem.  My observations have been that
I'd had little to no difficulty with services at position 1/4,
which would be tuned by a device not supporting, or not set up
to use DiSEqC switching.

 I'll probably have to update one day (especially if I want to keep up with the
 latest and greatest vdr), but I'm not really in a hurry, even less so seeing
 your problems.

Rather than immediately replace this card with a DVB-S2-able
device that tunes better the frequency extremes, I decided to
pull it out and experiment a bit more, in a different box.
My observations:

Here's some more info, in case it would be of interest...

I'd suffered interrupt and other problems with the test server
I'm building, having tried the SkyStar2 2.6D card in it without
major success -- apart from most transponders on position 1/4.

Generally I'd have about a 1 in 10 to maybe 1 out of 5 chance
of success when tuning the BBC radios on position 3/4 -- usually
it would appear to lock to the ZDF transponder at position 3/4.

Attempts to tune a particular transponder at 2/4 and at 4/4
would fail around 100% of the time.

Usually my first attempt after a reboot would tune successfully.

While operating, the machine somehow got in a state where the
USB ports were no longer working completely right.  Interestingly
at this time, I'd be able to tune the SkyStar and get about a
50% success rate or better when tuning 2/4 and 3/4.  Also, one
higher-frequency transponder at 1/4 which would result in a TS
with errors (and thus errors in the radio stream audio) then
tuned cleanly.

So I decided to strip as much out of the machine as possible
and play a nice round of musical PCI-slots, in case there might
be a magical slot where it would work, or where I would not
be sharing the IRQ with anything.

Unfortunately, none of the four freed slots worked with the
SkyStar perfectly.  Three of them were shown by /proc/interrupts
as sharing an IRQ; the one which did not, was shown to be sharing
the IRQ, with `lspci'.

Now, I did confirm one thing -- after each reboot, all my first
tuning attempts, regardless of position 4/4, 3/4, 2/4, or 1/4,
were always successful.  This using `dvbstream'.  Any following
attempts to repeat that tuning, or tune elsewhere, failed or
had a negligible success rate, except for position 1/4.  This
appears to be the case both for cold boots from poweroff and
for warm reboots.  It doesn't appear to affect the case of the
weak radio stream, which may be near the card's weakened
sensitivity limit (it's become this way over time, it seems),
that could vary in strength during the day.

An attempt to `scan' the transponders at 3/4 got far more of
the 1/4 transponders, and failed more than not with active 3/4
frequencies.  If there's any pattern, it could be that the
successful transponders were largely vertical, with horizontal
polarised transponders rarely tuning.  The same cable feeding
a couple external USB boxen delivered clean signals on all
tuning attempts.

Probably I do need to bisect my way from 2.6.26-ish back to
2.6.14-ish to determine where things went boom.

However, I've observed that a second PCI DVB-T card (BT878-
based) has not only failed to deliver a clean signal, but has
also resulted in normally-clean signals from USB devices
becoming similarly corrupted every minute or so, so that card
will also suffer the musical-PCI-slot treatment to see if it's
an IRQ problem.

And if I motivate myself, I'll see about trying the SkyStar
in the two used slots, or trying to give it a truly-free IRQ.
By which time I'll probably have become insane trying to keep
track of which cards get which IRQs in which slots.

Man, sometimes I wish PC hardware weren't so illogical, or
that the logic were to be clearer...

Preliminary results of juggling BT878-DVB-T card -- if it is
sharing its IRQ with either my EHCI card (NEC, IRQ10), or
the sound card (CMIPCI, IRQ7) at boot, the machine will lock
up solid.  Presumably an interrupt storm, or something, as I
know little about such.  Otherwise it appears to work fine,
though with a few 

Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)

2009-04-25 Thread BOUWSMA Barry
Sorry for digging out an old message.  But...  (I also started
to write this a couple weeks back, then set it aside to do
more observation, so dates referenced may be inaccurate)

I've been intending for some time to gradually migrate my
production machine from its 2005-era solid-like-rock kernel,
to something more recent which has proved reasonably stable,
to make better use of new hardware.

This production server has one Flexcop PCI SkyStar card, and
three USB devices, with too many hacks to get things working.
The SkyStar card has been my primary card, and out of hundreds
of uses, only about two times has it failed to tune, with the
2.6.14-to-15-era kernel.

The kernel I've updated to is a 2.6.27-rc4, with patches for
things which have broken for me in a several month test period
to see if this kernel crashes on a test box.  In the meantime,
I tried an older 2.6.26-era kernel, as well as newer ones, to
the git-snapshot of the day at the time.

Unfortunately, my testing on the new kernel today on the
production server showed none of the stability I expected of
the older kernel.  I still need to do more work and verify
my observations, but my disappointment with the SkyStar on
the more recent kernel reminded me of this message, which I
had to dig out...

On Fri, 16 Jan 2009, Patrick Boettcher wrote:

 Hi lists,
 For years there has been the Video Data Stream Borken-error with VDR and
 Technisat cards: The error occured randomly and unfrequently. A work-around
 for that problem was to restart VDR and let the driver reset the pid-filtering
 and streaming interface.
 In fact it turned out, that the problem is worse with setups not based on VDR
 and the VDSB-error could be really easily reproduced (I'm not sure if this
 applies to all generations on SkyStar2-card). I'm skipping the description of
 the problem here...

Unfortunately, this (and later messages in this thread) is not
related to what I'm now seeing, oh well...

Anyway, to describe what I observed a couple weeks ago, when
swapping out a USB stick with the old 2.6.14-ish OS/kernel for
a reasonably fresh OS/kernel, without changing anything else
with the hardware:

The problem I'm experiencing is apparently DiSEqC-related, as
I'm switching between four positions.  Position 1 is Astra 19E2,
and I've noticed the problem too often with position 3, Astra 28E.

Also, while I had no new problems with position 1/4, at least
half of my attempts to use position 3/4 simply failed to tune,
so I had to stop using this card for that position.  (Positions
2/4 and 4/4 see infrequent use, exclusively with a different
device as it's only radio there of interest)

Another thing to notice is that according to `dmesg' the card
was identified incorrectly, although that did not stop it from

[   14.802703] b2c2-flexcop:B2C2 FlexcopII/II(b)/III digital TV 
receiver chip loaded successfully
[   15.352877] flexcop-pci: will use the HW PID filter.
[   15.353082] flexcop-pci: card revision 2
[   15.392836] DVB: registering new adapter (FlexCop Digital TV device)
[   15.400031] b2c2-flexcop: MAC address = 00:d0:d7:0c:75:7a
[   18.683487] b2c2-flexcop: found 'ST STV0299 DVB-S' .
[   18.683787] DVB: registering adapter 1 frontend 0 (ST STV0299 DVB-S)...
[   18.685308] b2c2-flexcop: initialization of 'Air2PC/AirStar 2 
ATSC 3rd generation (HD5000)' at the 'PCI' bus controlled by a 
'FlexCopIIb' complete

I have no ATSC card!  Lawdy, have mercy!

Anyway, this appears to have been IRQ or similarly-related, as
when I swapped in a different PCI-USB adapter which didn't work
so I had to exchange its position with a sound card to get the
IRQs recognized, then things started working:

[   14.250005] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV 
receiver chip loaded successfully
[   15.469994] flexcop-pci: will use the HW PID filter.
[   15.469994] flexcop-pci: card revision 2
[   15.509998] DVB: registering new adapter (FlexCop Digital TV 
[   15.519996] b2c2-flexcop: MAC address = 00:d0:d7:0c:75:7a
[   15.519996] b2c2-flexcop: i2c master_xfer failed
[   15.519996] b2c2-flexcop: i2c master_xfer failed
[   15.519996] CX24123: cx24123_i2c_readreg: reg=0x0 (error=-121)
[   15.519996] CX24123: wrong demod revision: 87
** [   15.519996] b2c2-flexcop: now doing stv0299_attach...
** [   18.71] b2c2-flexcop: stv0299_attach succeeded...
[   18.71] b2c2-flexcop: found 'ST STV0299 DVB-S' .
[   18.71] DVB: registering frontend 1 (ST STV0299 DVB-S)...
[   18.71] b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 
DVB-S' at the 'PCI' bus controlled by a 'FlexCopIIb' complete

** debuggery I added expecting it to fail

Now, while it's properly identified, it still fails to tune
reliably to position 3/4.  The following was noted when it was
identified wrong, in the same hardware configuration which worked
fine with 2.6.14-ish

Apparently with the newer kernel, the SkyStar isn't sending a
reliable DiSEqC signal all the time for position 3, and often it

Re: [PATCH] add new frequency table for Strasbourg, France

2009-03-19 Thread BOUWSMA Barry
(sorry for not answering sooner, I got distracted by good weather
and the need to replenish my reserve of beer, depleted during the
long wintry weather)

On Tue, 17 Mar 2009, Benjamin Zores wrote:

  Anyway, to the original poster, Benjamin, can you make a short
  recording of, oh, say, ten seconds, of just PID 16 of only the
  five or six french muxen which you receive, and somehow deliver

 Here it goes.
 See attachment.

Thanks -- except, um, somehow the attachments got mangled in the
process of being MIMEd.  It seems your mailer (Thunderbird) has
chosen to tag the files as something like text/xemacs (similar,
I can't remember exactly what) and performed some strange 
irreversible conversion of much of the binary data into character
0x3f, which breaks `dvbsnoop'.

I attempted to convert those characters to the padding used to
fill out the 188-byte Transport Stream packet, but it still was
not enough, as that's not the only character that got mangled.

Here's your ARD multiplex (722MHz) dumped after my conversion:

from file: /tmp/hexrev

  :  47 40 10 17 00 40 ff 52  30 38 ff 00 00 ff 05 40   g...@...@.R08.@
  0010:  03 41 52 44 ff 40 38 01  21 14 ff 3a 5a 0b 04 35   .a...@8.!..:Z..5
  0020:  45 40 1f 41 3b ff ff ff  ff 41 0c 00 ff 01 00 02   e...@.a;A..
  0030:  01 00 03 01 00 06 01 62  1d ff 03 ff ff 40 04 1c   ...b.@..
  0040:  ff 40 04 4d ff 40 04 66  19 40 04 7e ff 40 04 ff   @.m.@@.~.@..
  0050:  ff 40 04 ff 57 40 29 ff  74 08 ff ff ff ff ff ff   @..w@).t...

And here's how it should have looked (the sequential number is
different, but the others should be similar or identical):

from file: /tmp/ard-fs-DVB_T-17.Mar.2009-04h-NIT.ts

  :  47 40 10 1e 00 40 f0 52  30 38 d7 00 00 f0 05 40   g...@...@.R08.@
  0010:  03 41 52 44 f0 40 38 01  21 14 f0 3a 5a 0b 04 35   .a...@8.!..:Z..5
  0020:  45 40 1f 41 3b ff ff ff  ff 41 0c 00 e0 01 00 02   e...@.a;A..
  0030:  01 00 03 01 00 06 01 62  1d ff 03 df d2 40 04 1c   ...b.@..
  0040:  db 40 04 4d af 40 04 66  19 40 04 7e 83 40 04 8a   @.m.@@.~.@..
  0050:  b8 40 04 af 57 40 29 df  74 08 ff ff ff ff ff ff   @..w@).t...

It appears anything above 0x80 (decimal 128, or with high-bit
set) is converted by Chunderbird to the 0x3f -- that is, any
non-US-ASCII value gets mangled.

So I'll ask, can you send the files again, but first make them
ASCII-safe, either by `uuencode' or `xxd' or some base64
encoder, before attaching them?  And send them directly to me,
no need to bother the whole list with them.  (Or if you have
access to a different mailer which will attach the files as
simple octet-stream, that will work with no need to pre-encode)

One more question, can you receive anything at 858MHz, channel
69?  I have this listed in the frequency allocations from several
sources for Strasbourg.  If not, I may be able to check myself
in the next month or so, if I remember...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [PATCH] add new frequency table for Strasbourg, France

2009-03-16 Thread BOUWSMA Barry
On Sat, 14 Mar 2009, Benjamin Zores wrote:

 Attached patch updates the current dvb-t/fr-Strasbourg file with
 relevant transponders frequency values.


I have a problem with some of these values.  Well, to be truthful,
all of these values.  I don't have a good 'net connection to be
able to check these things online at the moment, so I'm going to
have to go by some possibly-outdated downloads...

First, every frequency is given an offset from the nominal centre
frequency of the 8MHz envelope.  I am aware this is common in the
UK where the switchover is happening gradually so as not to
interfere with adjacent analogue services, and I also know that
last I checked, the number of french analogue services I could
receive weakly had dropped, but at least one was still visible.

I've also read in a forum that complete analogue switchoff is
planned Real Soon Now with a corresponding increase in ERP from
the Alsace transmitters, but I don't know details.

My mailer doesn't include the attachment in the reply, so I've
had to paste the lines below...

+T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

I have some recent german Bundesnetzagentur (BNetzA) data, and
this lists the Nordheim frequencies as
TVDRStrasbourg22   482.000KT
that is, no offset.  I still have not wrapped my head around
the meaning of the `KT' status field.  The rest of the fields
match what I predicted earlier (pasted from my file created
for the neighbouring part of germany):
### In the west to southwest, one may receive a number of broadcasts from
### the Alsace in France.  These are horizontally polarised.
###  Strasbourg Nordheim22-47-48-51-61-69
# ACHTUNG!  file fr-Strasbourg contains no content!  FIXME!
### need to verify FEC 2/3 + GI 1/32 (MFN), fix freqs
# T 48200 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K22
# T 68200 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K47
# T 69000 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K48
# T 71400 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K51
# T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K61
# T 85800 8MHz 2/3 NONE QAM64 8k 1/32 NONE  # K69

Now, back to your diffs...

+T 570167000 8MHz 2/3 NONE QAM16 8k 1/32 NONE

This frequency looks very suspicious, as it is (without
the offset) in use with different parameters by a Single-
Frequency Network along the Hoch- and Oberrhein, including
a non-directional 50kW tower at the Totenkopf, Vogtsburg/
Kaiserstuhl, and somewhat closer at Baden Baden Fremserberg,
which should blast well into much of the Alsace.  Certainly,
when I was within walking distance of the Totenkopf but
within the Rhein valley, I had no problems receiving the
analogue french broadcasts with a simple indoor antenna.
These may have been from Colmar, much closer.

I can't imagine that the french would either try to
re-use this frequency or attempt to jam it...

+T 618167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

My BNetzA data lists an additional frequency that neither
your list, nor mine, includes:
TVDRStrasbourg40   626.000K4
As I said, I don't know how to interpret the `K4' status
field to match up with today's reality.

Your frequency, however, is different, and matches a
second frequency used non-directionally from the
Totenkopf (but this time, not in a SFN with Baden Baden).
However, nearly all the modulation parameters bear no
similarity to the ones you give.

My BNetzA data lists another additional allocation:
TVDRStrasbourg46   674.000K4
This, like the above, is a 47dBW non-directional field,
with multiplex labels such as F___F__00428, which should
be situated 3 metres higher up the tower from the other
existing frequencies, all of which are directional with
about 40dBW, reduced by 6dBW -- somewhere I've saved graphs
of the directional pattern, but I can't find them now --
the reduced strength is usually towards germany.

+T 682167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 690167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

These match the BNetzA data, and my predictions, apart
from the offset.  The analogue BNetzA data lists two
frequencies for a `Strasbourg', one being for `Strasbourg
Port Du Rhin', with the geographic data and antenna data
matching the latter.  No analogue frequencies are presently
shown for the Alsace Strasbourg (or Elsaß, Straßburg), though
one is listed for Mulhouse, which is probably what I was
seeing a year or so ago, so I'm not sure whether an offset
is really needed, as I have not been paying much attention
to the process of switching on the digital, and eventually
switching off the remaining analogue frequencies in this
area...  (For example, Colmar is assigned digital frequencies
with vertical polarisation, directional, and about 20dBW less 
power toward germany, but I know only of Mulhouse and Strasbourg 
being in operation)

+T 698167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

This is not listed in the BNetzA data, but tramples on
a multiplex out of Baden Baden (see 618MHz above with the
same content, 

Re: [PATCH] add new frequency table for Strasbourg, France

2009-03-16 Thread BOUWSMA Barry
On Mon, 16 Mar 2009, wk wrote:

 Benjamin Zores wrote:
  BOUWSMA Barry wrote:
   First, every frequency is given an offset from the nominal centre
   frequency of the 8MHz envelope.  I am aware this is common in the
   UK where the switchover is happening gradually so as not to
   interfere with adjacent analogue services, and I also know that
   last I checked, the number of french analogue services I could
   receive weakly had dropped, but at least one was still visible.
  These were discovered through w_scan application.

Then there must be something ``wrong'' with `w_scan' making
incorrect assumptions about the data which it's parsing.

It would be too easy for me to look at the source of `w_scan'
and see what it might be doing wrong.  Too easy.  So of course,
I'd rather do something else, like look at the raw data it's
using -- the NIT data of the french muxen, in case there is
something within that being processed in error.

The fact that while germany makes much use of SFNs which need
to transmit coördinated frequencies and data, while each site
in france uses different frequencies from its neighbours,
would mean that any NIT data would need to be generated
individually for each transmitter site, unless the entire
pool of available frequencies allocated to france (or to the
particular mux operator/composition) is listed within the
NIT table from a central site, which is then distributed to
all the transmitters.

For me to see the NIT contents, I'd have to ask the original
poster if it would be possible to make a short recording of
PID 16 on each of the five or six frequencies in use from
Nordheim (these would be chans 22-47-48-51-61-69 based on
data I downloaded in 2006), and either mail them to me, or
run `dvbsnoop -s ts -tssubdecode -if /name/of/recorded.ts 16'
to get a text parsing of the NIT table contents.

Usually three seconds is enough to see at least one full set
of NIT data, though sometimes ten or more seconds would be

This will give me the other half of what `w_scan' is working
on, something which I am not able at present to see myself.

   +T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 If that information was found by w_scan, that information was found by parsing
 the NIT ot this channel.

This data is correct.  It's the other mangled data from the
german SFNs that is incorrect, and without looking at the
`w_scan' code until later, I have a couple ideas about what
it could be doing wrong.

 Since in Germany no transmitter uses any freq offsets, the information comes
 from the French one.
 And for France finding that freq offsets is quite normal.

I did notice that a few scanfiles other than uk-foo did
include such offsets.  I agree that the frequencies listed
in the initial scan files should be as accurate as possible
with technical details -- I presume the BNetzA data is based
on the nominal assigned allocations rather than the (perhaps
temporary?) current practice.

Which makes me wonder, as these offsets are used in the case
of a simulcast phase, will they still remain in effect after
analogue switchoff, or will they be dropped at the time when
powers of the DVB-T broadcasts will be increased?

What has disturbed me is how this offset has been applied
across the board by `w_scan', as have the guard interval and
modulation type (with one exception), to the received german
frequencies, yet the NIT data from said german frequencies
appears nowhere.  In particular, the ZDFmobil mux:

 +T 570167000 8MHz 2/3 NONE QAM16 8k 1/32 NONE
   wrong^^  ok  ok  correct!  WRONG

Here is what one sees with `dvbsnoop' on the NIT data, which
appears that it's generated for each SFN Cell, as opposed to
being centrally generated once:
(working my way backwards from bottom to the top)
A list of frequencies used by ZDFmobil...
  DVB-DescriptorTag: 98 (0x62)  [= frequency_list_descriptor]
  descriptor_length: 101 (0x65)
  reserved_1: 63 (0x3f)
  coding_type: 3 (0x03)  [= terrestrial]
 Centre_frequency: 02d34440  (= 474000.000 kHz)
 Centre_frequency: 02df7940  (= 482000.000 kHz)
 Centre_frequency: 04a32240  (= 778000.000 kHz)

A list of Cell IDs and frequencies (the same frequency is shared
by distant cells)...
  DVB-DescriptorTag: 109 (0x6d)  [= 
  descriptor_length: 40 (0x28)
 cell_id: 515 (0x0203)
 Center frequency: 0x0365c040 (= 57.000 kHz)
 subcell_info_loop_length: 0 (0x00)
 cell_id: 560 (0x0230)
 Center frequency: 0x038a5f40 (= 594000.000 kHz)
 subcell_info_loop_length: 0 (0x00)

Modulation for the particular Cell of interest:
  Center frequency: 0x0365c040 (= 57.000 kHz

Re: TS sample from freeview, anyone?

2009-02-15 Thread BOUWSMA Barry
Ciao Andrea,

On Tue, 10 Feb 2009, Andrea Venturi wrote:

   i'm looking for a full TS sample of a freeview mheg RedButton

  How much are you looking for -- in other words, do you need
  the full service including video that a RedButton service

 i'd like to have a couple of minute of a full TS from Freeview, to give a
 quick glance to Red button service.

I will guess that as you are replying to this message, you
did not receive any reply from someone in the UK with
access to Freeview  :-)

I am myself not in the UK, and so I cannot help you with a
stream of one or more Freeview Muxen; also, I do not know
the details about Red Button via Freeview there, or such
details as `channels 301 and 302' which I must translate
in my head into the satellite equivalents which I receive.

However, if my experience is enough, Freesat has given
me the `quick glance' I needed to see that Red Button
exists, and that I can receive it, and, other than that,
I'm not impressed -- but it works, and that's the
important thing!

I should first point you to (if you do not already know)
the programs:
redbutton-download  and
(which I think are on sourceforge).  These were written
for Freeview (DVB-T) and did not work via sat until the
launch of Freesat; then they worked automagically for me  :-)

  dish in Zuerich long before I was aware of the spotbeam.

 i know that i could try freesat albeit has a tight footprint, but i just have
 a fixed dish toward 13 east

Actually, Freesat itself consists of both services on the
tight Astra2D footprint, consisting of the BBC television
services, plus the other commercial/PSB broadcasters, as
well as services which can be received easily throughout
Europe on Eurobird or a different Astra satellite.  But
the Red Button services are limited, as far as I know, to
the BBC UK television and radio services, and perhaps some
of the other PSB broadcasters -- most of which are on the
UK spotbeam.

Of course, this does not help if you only have one dish,
but it does give you an alternative if nobody can send you
the full transport stream you wish  ;-)

  However, the BBC radio services are on a pan-european beam

 is there really MHEG over the BBC radio service?

Yes, but...  I have probably confused you by the difference
between the domestic BBC UK services, and those of BBC
Worldwide or the World Service...

A selection of the BBC UK radio services, just as the
television programmes, are broadcast at 28E2.  While the
latter TV programmes are sent via Astra 2D on a spotbeam
tightly focussed on the UK, the radio services (Radio 1,
2, 3, 4 and family, plus 6music and Radio 7) are at 28E
at -- if I remember -- 11953MHz, which can be received
throughout most of Europe -- that is, if you have a dish
you can aim towards 28E...

These services, plus Radio London, and several others in
different languages, do carry a minimal MHEG service, and
I've been able to see that with `redbutton-browser', but
it's pretty much the station logo, some information about
the present programme, and similar fluff.  Which is why
I've said, woo, I can see it, now back to work...

 do you mean on these BBC World service at 13 degree?

No, none of the BBC programming directed at the Real
World (ooops, guess I can't immigrate into the UK now)
carry MHEG info, as far as I know.  That means, neither
the televisio World Service or BBC Prime (to move to 9E),
nor any of the many radio services on Hotbirds, which do
not include the domestic services (Radios 1 through 7).

So no, you will not see MHEG from the BBC on Hotbirds.

Unless I am wrong, but then, I think it would have long
since been public...  (this is a disclaimer, in case I
am wrong  :-)

First, an apology, in case I am writing at a level which is
too simple for you, and also in case I am writing about
things which you do not yet understand...

Anyway, what I see with `redbutton-download' are directories
with the MHEG data, which is transmitted in a cycle, so that
you will be receiving identical data after a short time...

b...@ralph:/usr/local/src/mini_dab$ ls -alrt /home/beer/carousels/
total 36
drwxr-xr-x  3 beer dialout   4096 Oct 14 04:08 3846
drwxr-xr-x  3 beer dialout   4096 Oct 14 04:08 3847
drwxr-xr-x  3 beer dialout   4096 Oct 14 04:45 3852
drwxr-xr-x  3 beer dialout   4096 Oct 14 05:36 3845

The directory structures under this are too much to show in
this mail, but I suspect these refer to four of the BBC
radio services on that day when I could not sleep and
decided to check out the radio MHEG services.

So, what I am trying to say, is that a snapshot of a
minute or two will give you the PIDs of the carousels
for the MHEG data on one particular multiplex, but it
will not give you the complete extent of possibilities
for additional services beyond digital teletext, which
includes the occasional trigger for ITV-HD or the varied
multiscreen offerings on Freesat, which require changing
to a different transponder for 

Re: channels.conf file for danish DVB-C provider AFDK (

2009-02-10 Thread BOUWSMA Barry
On Mon, 9 Feb 2009, Christoph Pfister wrote:

  I sent you the wrong file, it occured to me.. The right one goes here :
 Added, thanks :)

  C 38600 6875000 AUTO QAM64

Looking at all the other dvb-c scanfiles, would it not be most
likely that the FEC here would be also NONE, like all others,
regardless of comparable symbol rate or modulation?

I am ignorant about DVB-C practice, and don't have access to
the NIT tables of any providers, so I'm happy to be wrong...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

DAB SFN (was: Re: [linux-dvb] dib0700 buggy sfn workaround or equivalent)

2009-02-09 Thread BOUWSMA Barry
On Mon, 9 Feb 2009, Patrick Boettcher wrote:

 It has nothing to with the channel bandwidth. In Australia, and maybe in 
 other places too, the DVB-T radio-channels (not to mix up with a radio 
 service) which are used in single-frequency-networks (SFNs) are 
 transmitted buggy: different transmitters are not using the same tps-data 
 (cellid IIRC). The dibcom-demods are using this information to improve the 
 reception robustness. This leads to synchronization losses, when the SFN 
 is not set up correctly...

Hijacking this bit of information...

Is it in theory possible that this may be the source of some
problems I experience receiving DAB radio, using a multi-
element directional antenna, regardless of orientation, in
a location with reception from at least two and possibly more
than four senders within eyesight, or close to that?

It's a completely different manufacturer (Siano) and the
problem disappears when I simply use a short indoor whip
antenna with adequate S/N ratio.

Note that so far, I haven't been able to extract more than
a subset of the metainformation which accompanies the
different audio streams, and I've had other hardware
problems, but I've been puzzled why I had not been able
to overcome the regular periodic mangling of the audio.

My knowledge of DAB is dismal, to start with, anyway.
So be gentle.  Unless you don't feel like it, or need
to let off steam.  Or whatever, treat me like a dog...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)

2009-01-29 Thread BOUWSMA Barry
On Thu, 29 Jan 2009, Christoph Pfister wrote:

  I intend to take Christoph's files and massage them to add
  bits of info, reviewing the info by hand, adding missing info

 I don't mind adding those further bits. They need to be after the main
 block in the file, so that they don't get overwritten when those files
 are updated e.g. because of a new pdf.

Hmm, actually, the first thing I was planning to do would be
to sort the entries by, for lack of a better term, provider.
That is, roughly, ARD multiplex when appropriate, ZDFmobil,
and regional Dritte multiplex everywhere, and in selected
regions, the remaining of the seven assigned GE06 allocations
or, in short, private providers.

This is intended to provide an overview of these allocations
and the particular sites where they can be found, as well as
to handle the potential cases of frequency re-use in widely-
separated areas between two muxes with incompatible
parameters -- how often this will occur, I cannot say, as I
do not yet have a complete overview.

This also can help the case of Tobi, who would prefer to use
two or three transmitter-site files, in that it would be easy
to see which frequencies would be ``local'' (shades of Royston
Vasey here, ``You'll Never Leave'').

But I'm not sure how well this would work with a PDF-skimming

As a concrete example, what I would create, would look like:

# DVB-T Sachsen-Anhalt
# Created from
# mercilessly mangled by hand, please file in /dev/null
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy

### ZDFmobil multiplex; E22, E30, E31
T 48200 8MHz 2/3 NONE QAM16 8k 1/4 NONE # CH22 Halle
T 54600 8MHz 2/3 NONE QAM16 8k 1/4 NONE # CH30 Brocken, Magdeburg, 
T 55400 8MHz 2/3 NONE QAM16 8k 1/4 NONE # CH31 Dequede

### MDR-S-A multiplex; E34, E35, E38
T 57800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH34 Brocken, Dequede, Magdeburg
T 58600 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH35 Halle
T 61000 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH38 Wittenberg

### ARD multiplex; E24, E29, E41
T 49800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH24 Halle, Wittenberg
T 53800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH29 Brocken, Magdeburg
T 63400 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH41 Dequede

(This also can make it somewhat more 80-column-friendly, for
at least some regions)

Tobi, if I may ask you -- I have seen use made of, for example,
`K21' in german web fora to refer to the frequency spanned by
470 to 478MHz, while in swiss web fora, I often see `E21' for
the same.  I know that `K' can be both seen as `Kanal' (channel)
and `Kabel' (cable), while I would guess that `E' refers to
Europe, to differ the 8MHz spacing from that of, say, Australia
or some other land whose name I can't remember but which sort
of features prominently in parts of Thee Interweb.

But in my experience, cable-TV frequencies by channel number
do not always match over-the-air frequencies for that channel.
Are you familiar with the `E' usage, can you tell me if there
is an accepted international usage that covers all languages,
as my attempts to search `e' in g00gle were not impressive...


Anyway, with the above, after I pull out a map, I can say,
oh, this group of transmitters (probably) forms a SFN for
ZDF, and that group covers mdr, and so on.  That overview
was one of the things I was trying to obtain earlier, and
will be when I really work on Sachsen-Anhalt.

And to Christoph, the danger, as I'm sure you know, of
pulling from a PDF or other single source of information,
is that those will not always be infallible, as we've seen
with a centre-frequency ending in `3' and paste-errors
for Hamburg between VHF and UHF parameters, as well as
absent info for the specific cases of the frequency change
in HH; or for BW, the change planned for Aalen plus the
to-be-in-service status of Bad Mergentheim.

I suppose I ought to write the originator of the PDF to
point out errors, but I suspect I'll get at best a reply
from TV Licensing saying they have no record of me in
their database and that as a non-resident, I have no
grounds for criticism of their offering and I should
stick to the programmes for which I pay the license fee.
(How else can I explain the years-running errors in
linking of teletext pages, that are again changed to
errors when those pages are relocated?  ZDF, I'm looking
at you for failing to list your extended programme guide
following ttx page 380...)

Oops, off-topic again.

 They shouldn't be too excessive,

Oh dear.  The question is, how do I skate the thin line
between providing too much information, and failing to
include useful information?  I guess, it depends on your
interest.  If all you care about are just the frequencies,
and if I were to say to you `ERP' you would say, ``Oh, do
excuse yourself, you glutton'', then the existing files are
fine.  But if you need transmitter sites and info to
help you 

Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)

2009-01-27 Thread BOUWSMA Barry
Grüezi mitenand!

*Whew*, that was a lot

On Tue, 27 Jan 2009, Tobias Stöber wrote:

 ... and sorry Barry that I've to correct you on some parts of your
 summarization ;) I hope you don't mind.

No worries.  I've tried to give a view that an outsider could
use to better understand the situation and place a logic onto
the channel assignments, as it is a bit more detailed than the
situation in, say, Switzerland.  Or France.

  exist national public service, regional public
  service,national/regional private commercial, and local broadcasters.
 So what do you mean with local broadcasters? Or what is the difference in
 regional private versus local?

Local broadcasters here would include, as examples, HH1, only
available in the Hamburg region, or perhaps some of what can
be seen in Leipzig, though that appears not to be included in
the .pdf file frequency list.  Likewise I'd include the
different services which can be seen via DVB satellite making
up FrankenSat and the like -- simply because I'm not familiar
enough with them and their reach -- I'd assume TRP is available
in Passau, but not throughout Oberbayern, for example.

By a region, I mean either a Bundesland, as opposed to those
which cover just a large city (Berlin, HH, Bremen...) or a
large part thereof.  For example, RTL has available a service
for Austria and the german part of Switzerland, and for HH SH
and HB NDS available via satellite, as does Sat1 with services
SAT1 National, SAT1 NRW, SAT1 NS/Bremen, SAT1 HH/SH,
SAT1 RhlPf/Hessen, and for Bayern, Test BY.  (info may be some
months out-of-date)

Unfortunately, I am not very familiar with the multitude of
private broadcasters out there and their coverage areas, due
to receiving satellite signals, which lack most of these.
Only occasionally will something catch my interest -- for
example, was tm3 a local München service, which happened to
be available nationally before it perverted into Neun Live
and wormed its way into DVB-T multiplexes?  And likewise, the
service which Hornauer took over before finally sputtering off
satellite after a shell game into Austria, whose original name
I can no longer remember...

 The stations must also be licensed in one of the federal states and are
 required to broadcast are local/regional programme there(!), which results in
 the fact, that on DVB-T (and before on analogue TV) there are programmes
 targeted to the region and which are not available on satellite TV. For RTL in
 Niedersachen/Bremen there is a programme called Guten Abend RTL between
 18h00 and 18h30, or on Sat.1 there is then a programme called Sat1 - 17.30
 live NDS/Bremen between 17h30 and 18h00.

Actually, these services are now available nationally (and through
europe) via DVB-S.  Earlier, these were sent at least in part via
low-bandwidth transponders in the style of SNG feeds; today they
make use of dynamic PMT switching within a full-bandwidth 
multiplex, in the same way that WDR in particular switches to its
many regions for part of the day.

 There are then also some special local DVB-T phenomena, like radio stations
 over DVB-T in Berlin or special projects like the private Leipzig 1 -
 multiplex which experiments with a small cell SFN nework of low-power
 transmitters within a very small area (area of the city of Leipzig) with 6
 transmitters in that (Leipzig-Mitte, Leipzig-Messe, Leipzig-Grünau,
 Leipzig-Markkleeberg and Leipzig-Lößnig). This project does include TV and
 radio stations (Leipzig Fernsehen, Infokanal Leipzig, BBC World, Bibel TV,
 Radio Horeb, Radio Leipzig).

If I remember, there is also an occasional multiplex in, if I
remember, Nürnberg...  I do need to look more in detail at these

What I do notice is that in the frequency list, Leipzig includes
only the three PSB multiplexes, including one on VHF channel 9,
which eventually should be moved, I would expect.

Also of note is that the dvb-apps scanfile for Leipzig does not
include the frequency for that low-power network.  I think I
need to do some homework...

  The practical example of this would be that while onecan see the same
  content via ZDFmobil anywhere, theso-called ARD multiplex may
  contain, by region, EinsPlusor EinsFestival, or perhaps in that
  region, that regionalmanager's so-called ``Dritte'' (third, after ARD
  beingfirst and ZDF being second) programme.
 Not correct, the ARD-Das Erste multiplex does NOT contain regional (third)
 programmes! There is always a seperate multiplex for the third programmes.

I hate to disagree, but Brandenburg appears to mix rbb-Brandenburg
with ARD, with the `dritte' multiplex containing `arte'; this is
also the same for Berlin and rbb-Berlin -- I'm not sure if the PMT
switching is used here to make the Brandenburg and Berlin local
programming available through the entire area for the few hours
per day when they differ.

Similarly in Bremen, Radio Bremen TV is found where one normally
would see one of the EinsFoo digital services.

Hessen is the 

Re: [linux-dvb] getting started with msi tv card

2009-01-27 Thread BOUWSMA Barry
On Tue, 27 Jan 2009, Daniel Dalton wrote:

[Now, ideally, a teletext service, being text-based, can be]
  trivially converted to braille or spoken.  I'm not sure about
 Braille..., what format do they originate in? Is it tv signal, or some
 kind of text guide or something?

The teletext service I hope you would be able to get, is sent
as part of the digital service.  Here I will quickly explain
that a Transport Stream, which is used by DVB-T, mixes together
digital versions of several services, including audio soundtrack,
or radio, as well as video signals, and additional data services,
with each component being able to be identified by its own ID.

A conventional set-top-box will convert the video from its
digital form to an analogue equivalent, then convert the audio
soundtrack into its analogue form, and decode and add the
teletext to the video signal, perhaps also including its own
internal teletext decoder for user convenience.

Then these analogue signals are delivered to your tv by one of
many means, be it as an RGB signal through a SCART connector,
or in the worst case, by modulating an RF carrier.

But your Linux machine will be working with the Transport
Stream directly, selecting the particular IDs of interest.
When you look at that particular ID, you see merely a
datastream including the payload.

So, just as your TV audio will be carried in a form which
will be similar to the mp3 files you've certainly used, or
whatever format, you can also write the teletext data to
a file and work with that.

When you get your tuner working, or one that does, if you
do receive a teletext service, I'll guide you through the
steps needed to actually see the content being broadcast.

As a little teaser, I will paste part of a hexdump of an
update to today's rates of the example I posted earlier.

01c0  20 20 20 20 20 cb 61 6e  61 64 61 ae ae ae ae 20  | .anada |
01d0  a8 43 c1 c4 29 83 20 20  31 2c b6 31 38 37 02 20  |.C..).  1,.187. |
01e0  ab b0 2c b3 37 25 07 31  32 ba b0 37 20 d3 fd 64  |..,.7%.12..7 ..d|
01f0  61 e6 f2 e9 6b 61 ae 20  a8 da c1 52 29 83 20 31  |a...ka. ...R). 1|
0200  b3 2c b3 37 b6 31 02 20  ab b0 2c b5 b6 25 07 31  |.,.7.1. ..,..%.1|
0210  31 ba b5 b0 20 c8 ef 6e  67 6b ef 6e 67 ae ae 20  |1... |
0220  a8 c8 cb c4 29 83 20 31  b0 2c 32 b5 b6 37 02 20  |). 1.,2..7. |
0230  ab b0 2c 31 b6 25 07 31  31 ba 34 b9 20 d3 e9 6e  |..,1.%.11.4. ..n|

There are some readable parts of words (Canada, Hongkong)
to be seen in the ASCII dump at the right, but it is not
quite a simple text dump.

The program I hacked to display this in text form does
the conversion into ASCII with the added characters for
the particular language in use.

So, to answer your question, essentially it is a text

Now, the MHEG service, in contrast, is Java based, and I
have downloaded a good number of files, both text and
binary, that would be used to display a particular page.
However, I can't see a simple way to get at the text
info within and display it.  That would be for someone
who has studied and understands this service.

 Thanks, that looks interesting, so does it all depend on what service is
 available here in Australia?

That is correct.  One more thing I should note, is that
this text type of teletext supports, and broadcasters
generally make heavy use of, features such as colours,
double-height and blinking characters, and in particular,
parts of character blocks that can be used to create
simple graphics.  Think of some sort of ASCII art, or,
with the most common use made of these graphics by
commercial broadcasters, ASCII pr0n.


This pr0n is made worse by the fact that my console font
does not include the full range of teletext partial blocks,
so I've substituted characters such as `*' and `X' to try
and give a feel for how the graphics should appear.
Maybe a full Unicode X font will include such characters
and I can simply map them to UTF8, but I'm primarily
interested in the text content information on my text console.

Here's the pr0n...

  █X█X*XX*???*?██   XXX*AMI
  █X?█??*█ █X?* █  **

No, this is not going to work.  There are too many characters
which are not yet converted to something and I'm having to add
as `?' by hand.  Anyway, the blocks on the left are used to
form words; to the right the blocks would be forming the top
of a female head.

 auszuziehen.Magst *X*███XX*██
 Du mir die Kleider *XXX* ██
 vom Leib reissen? XX██* X█*

At the right, part of a stomach and arm

Well, anyway, if these non-ASCII full blocks have made it
through intact and are diplaying correctly anywhere, 

Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)

2009-01-27 Thread BOUWSMA Barry
On Tue, 27 Jan 2009, Tobias Stoeber wrote:

  In reality, when I've been in a new location and done a scan
  without knowing transmitter site details, I've just used a
  general purpose scanfile I've created which goes from 474 in
  8MHz steps up to 850 or so, like
  ### Kanal 68 UHF
 So why then not provide a generic scan file listing all freq with AUTO

It's a nice idea, but apparently there are some devices which
do require particular values and don't work with `AUTO'.

Also, it will take some time to scan all these frequencies,
so I prefer to limit it where possible to known and nearby
in-use frequencies, rather than waiting half an hour to see
that just one frequency tunes.

And third, while it's the case for germany and most if not
all nearby countries, that the actual frequency in MHz will
be divisible by two (except for the few remaining VHF) and
have no fractional MHz values, this is not the same in all
countries where DVB-T is in use.

That could be due to the pretty much hard switchover/off
having largely happened, with no or a coordinated simulcast,
while other areas have to play with offsets, but I'm not so
familiar with the status and progress of switchover

There are apparently also some devices which need to have
any offset specified precisely, or they can't tune to that
particular frequency.

Anyway, one of my reasons for creating my version of de-BW
was not only to list the frequencies, but also to provide
info as I absorbed it about the transmitter sites and more,
that you wouldn't get in a generic universal frequency list.
That was prompted by an interest in trying to get my head
around the GE06 frequency plan and allocations, which would
also mean I'd need to try and understand the planning of the
SFNs.  That file can be shrunk and expanded by the use of
comments to make it more relevant to a particular area --
if you're basking on the Bodensee, you don't need to know
anything about France, Hessen, or some 2/3 of all the
frequencies scattered throughout the B-W file, and my
comments should make that easy.

After all, it wasn't until you pointed me to the first pdf
list that I was aware that QAM64 was in use in germany, save
for bleed out of france, and it will be interesting once I
get around to noting the transmitter sites on a printed map.

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Unicode Teletext (was: Re: [linux-dvb] getting started with msi tv card)

2009-01-27 Thread BOUWSMA Barry
On Wed, 28 Jan 2009, Daniel Dalton wrote:

  Maybe a full Unicode X font will include such characters
  and I can simply map them to UTF8, but I'm primarily
  interested in the text content information on my text console.
  Here's the pr0n...
???X???X*XX*???*???   XXX*AMI
???X??*??? ???X?* ???  **
  No, this is not going to work.  There are too many characters
  which are not yet converted to something and I'm having to add

 ah, ok... I kinda get it... :-)

Actually, your `mutt' mailer has managed to convert the
UTF-8 encoding which I hope you received into ASCII and
substituted its own `?' for those block characters which
should have appeared as correct UTF-8, though I'll need to
check an archive.

And after quite a few too many hours, I still don't get it,
and I'm going to have to ask help from the collective
knowledge pooled here.

I've seen that the 10646 encoded fonts available usually
have the familiar box-drawing and related characters I've
partly been able to use for a few of the graphics.

Unfortunately, these seem to be either based on a 2x2 set
of quads, or a 3x4 array.  While the teletext graphics in
use uses a 2x3 array.

I've come upon two sets of fonts which supposedly cover
the teletext character set with a 10646 encoding.  But
the first one, which does include the 2x3 graphics chars
that otherwise need a `fontspecific' encoding, seems to
have hijacked existing assigned unicode characters in
order to display the graphics.

That is, with this font, these characters no longer display
properly (selection limited due to pasting from a 512-char
console font)
[◆]  U+25C6   #9670;  BLACK DIAMOND
[◊]  U+25CA   #9674;  LOZENGE
This is matched by reading the code:
const wchar_t graphutf8[128] = { // Graphic characters on an unicode terminal 

I'm still trying to determine whether the second font has any
graphics and where they would be hidden -- even the handy
[█]  U+2588   #9608;  FULL BLOCK
character is missing.

Does anyone know whether the various 2x3 graphics used in
teletext fonts are in fact present in Unicode?  I haven't
been able to convince google to give me the answer I want.
I would think that with everything I do see with a unifont
font, that such widely-used characters wouldn't have been
left out...

thanks for any pointers,
barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)

2009-01-26 Thread BOUWSMA Barry
On Mon, 26 Jan 2009, Christoph Pfister wrote:

  On Fri, 23 Jan 2009, Tobias Stöber wrote:
  There is a complete listing including parameters from in area and also
  out of area (but with reception in the area) transmitters at

 I've quickly built a collection of scan files according to this
 document - do you mind having a look at them (although the change that
 will happen in Hamburg sometime and possibly other changes that
 happened since 25th November aren't considered yet)?


Just as a background, for the one or zero persons who care,
the situation in germany can be vaguely described thus:

There exist national public service, regional public service,
national/regional private commercial, and local broadcasters.

In general, the local and private broadcasters focus their
attention on large markets (Berlin, Frankfurt/Main, Hamburg,
München, and so on), and are not to be found so much outside
these limited regions -- with exceptions, like in Oberbayern
from the Wendelstein, but while the public service broadcasters
have a remit to reach the general population, the private
broadcasters have chosen to focus their financial investment
in those markets where they can reach a larger audience
share for little investment.  That is, the RTL and Pro7Sat1
families can be seen in, say, Hamburg, but far from these
metro areas, you are pretty much limited to a subset of the
public broadcasters.

Of the national and regional public broadcasters, the DVB-T
situation can be pretty much described as thusly...

There is a truly national broadcaster, the second german
broadcaster, ZDF, which has a multiplex known as ZDFmobil
which is available nationally, and is identical whether
received in Flensburg or Passau (hey, no heckling, that was
a beloved train ride for me years ago).

The other nominally national broadcaster, ARD, known as the
first german broadcaster (Das Erste), suffers regionalisation
both through a local identity in a particular Bundesland,
as well as a regional DVB-T multiplex management that does
not always translate well to match those of neighbouring

This regionalisation is due to sub-management by a third
party, which, perhaps as a super-regional manager, is
responsible for more than one Bundesland (for our original
case of Hamburg, this would be NDR, together with its
daughter Radio Bremen).  These `third parties' taken
together form that first german broadcaster, as well as
having their own distinct regional identities.

The practical example of this would be that while one
can see the same content via ZDFmobil anywhere, the
so-called ARD multiplex may contain, by region, EinsPlus
or EinsFestival, or perhaps in that region, that regional
manager's so-called ``Dritte'' (third, after ARD being
first and ZDF being second) programme.

In other words, nationally, one can receive the ZDF
multiplex, plus two others, which will depend on how
the regional management has decided to configure their
multiplexes.  Services such as Phoenix and `arte' will
be available nationally, while the `dritte' multiplex
will contain a selection of out-of-area regionals of
interest due to geography or whatever.

Now, while ZDF has a unified national service, the same
is not necessarily true for what you can receive in
a selected Bundesland.  For example, in Hessen, depending
on where you are, you may be able to receive the local
programming from the nearest Bundesland; in the south
of Bayern you can see SWR Baden-Württemberg but temporarily
not Hessen (or the DVB-H which replaced it), while in
the north you will instead see `mdr', although you may
have previously received SWR, which is the reason that
Bad Mergentheim in BaWü, near the border, will need its
own DVB-T transmitter sometime this year.

Now, anyway, for the zero readers who care, that's my
summary of german public broadcasters approach to DVB-T.
I'm happy to be corrected, because I'm an outsider.

So, anyway, there's been forces to cause merging of the
different regional broadcasters; NDR covers several
Bundesländer, with Radio Bremen retaining a bit of
independence; SWR has engulfed SWF and pretty-much-
programming can be seen on SWR-RP, SWR-BW, and even
SR from the Saarland.  This can probably be seen by
looking at the different frequency plans, although I
am too lazy and disinterested to do so now.  Anyway,
the Genève frequency allocations look to be based on
geographical locations, independent of the regional
broadcast administrator responsible.

What am I saying by all this tripe?  Well, there is a
regional frequency allocation that is presently used
by the public service broadcasters, but so far has
seen spotty adoption by the local and commercial
broadcasters apart from a handful of larger metro
regions, leaving most of the land by area dependent
upon satellite reception for these programmes.

Anyway, now that I 

Re: [linux-dvb] Siano subsystem (DAB/DMB support) library for linux?

2009-01-18 Thread BOUWSMA Barry
On Sun, 18 Jan 2009, Uri Shkolnik wrote:

  You know, it might help if I actually looked at the files
  hacking on, instead of blindly assuming they work like
  and create the node in the current directory  :-)

Well, I guess that has blown my chances of ever getting
a job again ;-)   Now the world will see this post and
say that something about my claim to having written an
operating system in my spare time just doesn't add up...

But now that the cat is out of the bag, and you've made
the Linux library available to all, I figure it's time
to post my hack to the public.

Attached as a file is a replacement for the MAKEDEV-like
script which can be found in contrib/ in the download
from Siano.  It tackles the following issues:

* eliminates the DOS-type line-endings, which did not
  agree with my flavour of /bin/sh
* attempts to figure out where the Siano library should
  be looking for its devices -- this is useful for the
  case where the desired major number 251 is already in
  use, and one has to specify a module load parameter
  (I think I've described this as best I could in an
  earlier message to linux-dvb)
* allows the user to specify the major and/or minor
  numbers given as module parameters
* unlinks potentially existing nodes in case of the need
  to recreate them with different major or minors

This is a total hack, and can be rewritten to probably
half the number of lines by anyone with a Clue, say,
using a for loop and simplifying my logic (note to future
employers:  look into my eyes, my eyes, not around the
eyes, you did not see this, you are suddenly interested
in the shiny toys on your desk)

So, feel free to improve on this, or to use it in place
of that supplied from the Siano ftp site.

   It was not hardware debugging needed, so it seems.  On

  Or...  was it?  Not only with major 249 on the newer build,
  but now, again with 249 on my notebook, I also see success.
  Could it be that the USB device into which I plugged the
  TerraTec Piranha caused the problems?  Maybe, because into
  a different USB hub, I have success on the notebook...

  Now, the interesting thing is that a USB2 DVB-S connected
  through this same hub delivered streams that were corrupt
  every few minutes, while the same device connected to a
  different hub has been delivering flawless streams.  Now
  I need to check whether the USB1 Piranha can deliver the
  clean streams, or if again, cheap hardware will cause me

An update to this, in case it would be of interest...

After several attempts to tune potential if weak signals,
I once again reached the point where attempts to initialise
the device would timeout -- exactly what I had seen originally,
but this time after half a dozen successful attempts to use
it and at least get to the tuning stage.

So now I've moved the device to a different USB hub port,
and once again it's working fine.  How long will this last?

I still haven't tried it in the hub where my other DVB
device works flawlessly, but it may come to that...

 Cool, I'm just CC the ML
 I get questions (sometimes the exact same questions) from various of people. 
 Lets use the ML to sync all...

Well, I hope that by making a fool of myself, I can post
this info so that others can benefit from it, and you
won't be bothered by these same questions.

In summary:

I've had success with DAB signals with the following:

The default_mode= module loading parameter works set to =2.

The firmware I've used is that which I downloaded some time
back as part of the DVB-T in-kernel siano support, and looks
-r-xr-xr-x 1 beer besoffen 40096 May 17  2007 

There are firmware files of different size on the Siano ftp
server, such as
-rw-rw-r-- 1 beer staff 38428 2008-12-31 16:26 tdmb_stellar_usb_12mhz_downld.inp
-rw-rw-r-- 1 beer staff 38720 2008-12-31 16:26 

I have not yet done anything with these to see if these might
be a better choice.

If, like me, your `cat /proc/devices` is full, and major 251
is assigned to something else, when you go to load the siano
smsmdtv.ko kernel module, you will need to specify an alternate
major number (minor can also be specified, should you need)
smschar_major=249  (tweak as you need), for example.

You can give the major number as 0...
In this case, the first available major number will be
automatically assigned.  The script which I attach attempts
to find this, assuming `procfs' is available and mounted,
and does its best to create the proper devices.

Should that fail, you can optionally specify the major (and,
should you wish, the minor) as options to the script, which
should explain itself in the comments if you read it.

Here's hoping this is useful...
(followup as appropriate; /dev/null is where this should have 
barry bouwsma
Description: Hacked version of contrib/

Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)

2009-01-17 Thread BOUWSMA Barry
On Sat, 17 Jan 2009, Patrick Boettcher wrote:

  Same here -- never experienced this ever in some four-ish years
  with one SkyStar2 of model long forgotten, with that card being

 Using VDR or a single application (like kaffeine), you most likely don't see
 the error anymore thanks to the work-around which is already in place. It is
 resetting the streaming interface at the end of a streaming-session, ie. when
 the pid-filter count is going from 1 to 0. This happens all the time with VDR
 (and similar) when it is retuning.

Okay, I've been using `dvbstream' standalone, also modified so
that it and related utilities get an exclusive lock on the
adapter (otherwise when I'd make a mistake, the second invocation
of `dvbstream' would not only fail, but the first recording was
also messed up, so less than useless).

`scan' has also been used, although in my latest installation
(including a 12-output multiswitch), the card I have has been
unable to lock or to get error-free output from transponders at
the ends of the frequency range -- this affects at Astra 19E2
the ORF transponders among others, and at 28E many of the Channel 
4 family, while all other devices on the same multiswitch have
no difficulties at even higher frequencies and can scan the
entire range perfectly.  I've also guessed this could be due to
spiders taking up residence in the warm interior of the tuning
circuits.  Anyway, someday I'll replace this card with an -S2
or perhaps dual- hybrid- whatever is available later.

 Now when you launch an application which is just requesting a pid and another
 one which is tuning independently, you can fall easily in this problem.
 PS: how to reproduce:
 shell 1: $ tzap channel
 shell 2: $ dvbtraffic
 [lots of output that streaming is working]
 shell 1: $ C-c
 shell 1: $ tzap channel2_which is on a different frequency
 shell 2: no output of dvbtraffic any longer... (problem)

This lack-of-output is something that I've experienced with
other cards (a dvb-usb DVB-T device), which I did not
investigate further.  If I remember rightly, and with a
more recent kernel.

Note that in my `dvbstream'-exclusively use of the SkyStar2, I
have never seen the error message (since trimmed from the
quoted original post).

I'll see if I can reproduce this on my production machine once
it's idle, or if my hacks might be involved, and report back
about this...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re[3]: [linux-dvb] dvb-t config for Ukraine_Kiev (ua)

2009-01-17 Thread BOUWSMA Barry
Hello Dmitry, I am pleased that I was able to help you!

But there is one thing that caught my interest, so I am again
posting this question to the -dvb mailing list, and I guess
to linux-media too:

On Fri, 16 Jan 2009, vdp wrote:

 But when I add -tm8 (THANK YOU FOR AUDIT ):
 it start 
 dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 -f 65000 -net 4311 4312

 tuning DVB-T (in United Kingdom) to 65000 Hz, Bandwidth: 8

To the readers of the list, and of linux-media, the default
of `dvbstream' here is to use FFT transmission mode 2k, as
was introduced in the UK, and it's clear how UK-centric this
utility is based on the above line.  (UK not meaning UA or

Now as part of DSO in the UK, the multiplexes are slowly to
convert from 2k to 8k, and most other parts of the world are
presently using 8k.

In fact, as I `grep' the latest dvb-apps scan files, only the
UK sites listed seem to be using 2k, for now.

Does anyone familiar with DVB-T know whether 2k transmission mode 
is used elsewhere in the world?

If not, would it not be reasonable to default to 8k for this
code, to make it applicable to the parts of the UK that have
switched as well as most of the rest of the world?

Reading the CVS RCS files, this doesn't seem to have been
updated for several years, and presumably distributed binary
packages are using the UK defaults, the code of which seems
unchanged from 2002, so I imagine this could use reworking.

 wonderful word !!! You, from other country help me, real-time and free 

It is indeed my pleasure.  While I have not made a visit to
your country, with the closest being in Košice, SK, I prefer to
think that we are in the same part of the world, with much
in common...

 with best regards, Dmitry
 Odessa, Ukraine

Now, back to the original subject of this message, a scanfile
for Kиïв, with proper modulation values...

Can you run the following commands for me, then send me the
files in /tmp/stream-* so that I can verify the modulation?

These will record three seconds worth of the NIT data with
the modulation, into several small files in /tmp, for all
the different multiplexes.

First, the command you used above to stream 5 ĸaнaл :

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \
   -f 65000  -o:/tmp/stream-650.ts -n 3  16

Now try it with the other frequencies and see if you still can 

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 3_4 -bw 8 \
   -f 63400  -o:/tmp/stream-634.ts -n 3  16

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \
   -f 71400  -o:/tmp/stream-714.ts -n 3  16

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \
   -f 81800  -o:/tmp/stream-818.ts -n 3  16

And last, a frequency where the services are in MPEG-4:

dvbstream -tm 8 -c 0 -I 2 -qam 64 -gi 32 -cr 2_3 -bw 8 \
   -f 68200  -o:/tmp/stream-682.ts -n 3  16

If you have success, then you can send me all the files
in /tmp/stream-*.ts, and I will look at them, make sure
that all the data in the scanfile is correct, and confirm
it to Christoph Pfister...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] Where to buy a Dual PCI-e DVB-s2 card in switzerland ?

2009-01-17 Thread BOUWSMA Barry
(Feckin' Reply-To header makes it difficult to send a personal
reply as well as a followup to the desired place...  Grrr...)

On Sat, 17 Jan 2009, Gregoire Favre wrote:

 Igor Liplianin just announced support for XpressVu PCIe Dual Tuner Card
 and I was wondering where I could buy one, preferably in Switzerland.

Seems that it is not yet widely available...

Can I assume you are in the Suisse Romande, and somewhat far
from Germany/Basel, or perhaps somewhere like Zürich?  You
can often save enough and get Mwst back if you shop over the
border.  Feel free to respond privately if you do not wish
to make your location public...

In any case, I would suggest perhaps waiting a few weeks, and
then seeing where it can be found in various online shops and
price comparison sites...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] Cross-posting linux-media, linux-dvb etc

2009-01-16 Thread BOUWSMA Barry
On Fri, 16 Jan 2009, Patrick Boettcher wrote:

 Why not closing linux-dvb (and video4linux) and transferring the currently 
 subscribed users to linux-media automatically?

Can I offer my opinions to differ?

First, I'm only subscribed to -dvb in order to post, yet still
I haven't posted what I originally planned to post before
unsubscribing until another device fails to work.  Luckily
the video4linux list was impossible to access (even the
archives needed subsciption, furrfu).

Anyway, soon after the creation of -media, I saw that the
crossposts from v4linux were of no interest to me (I'm only
interested in delivery of already-digital payloads, and am
not concerned with webcams, analogue radio or TV, remote
controls, and so on) -- since then I've skipped something
like 2/3 of the posts on -media, and today, I wouldn't want
it to appear in my mailbox.  But that's just my interest.

Also, I seem to recall that one intent of -media was to
focus on developer interest, as the initial posts revealed,
which also frees developers with better things to do than
to explain how to, for example, get a list of channels, or
stream a particular channel and be bothered by beginner or
simple questions that could be answered by those without
developer abilities.  Like me.

Anyway, it's no big deal to me.  I'm used to how the one
FreeBSD -multimedia list covers everything including sound,
yet typically gets fewer posts in a week than -dvb could
see in a day, and I can't see myself investing in another
DVB-type receiver soon until DVB-S2 support gets properly
rounded out and 100% reliable for all `experimental'-tagged
devices, so I'm quite content to browse the list just as I
skim the kernel list, or peer in on a few dozen other BSD-
type lists whenever I feel like it.

barry bouwsma
off to answer a newbie question next
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)

2009-01-16 Thread BOUWSMA Barry
On Fri, 16 Jan 2009, AlexW wrote:

 Patrick Boettcher wrote:

  For years there has been the Video Data Stream Borken-error with VDR and
  Technisat cards: The error occured randomly and unfrequently. A 

  In fact it turned out, that the problem is worse with setups not based 
  on VDR and the VDSB-error could be really easily reproduced (I'm not 
  sure if this applies to all generations on SkyStar2-card). I'm 

 Which generation of cards have this problem? I did not see any VDSB with 
 my two Skystar 2.6D.

Same here -- never experienced this ever in some four-ish years
with one SkyStar2 of model long forgotten, with that card being
the primary one used whenever possible...

(in use typically several times per day, sometimes half a day
uninterrupted, but on a production machine at 2.6.14-ish)

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at

Re: [linux-dvb] [PATCH] Siano (SMS) DTV driver [WAS: Re: Introduction]

2009-01-13 Thread BOUWSMA Barry
(Leaving the original recipient list intact, although I'm not
sure if I need to send to `linuxtv-commits@' as I don't keep
up-to-date with much of anything...)

On Tue, 13 Jan 2009, Uri Shkolnik wrote:

 [Uri S.] I'm attaching to this email an archive of patches.

Hello Uri, and first let me thank you for making available the
Siano Mobile Host-lib, as the header files included have answered
most of the questions I had about using Siano devices in 
non-DVB-T applications.

This does not mean that I've yet received and decoded any such
signals, as Real Life[tm] has gotten in the way, but at least it
has saved me from asking you stupid questions which were answered
in the header file  :-)

But, back to the real subject of this mail:

The patches you've supplied set a particular device major ID
from the `available' range, that unfortunately has already been
made use of by other services on a recent (sort-of) machine I'm

I've already noted this in mail to the dvb@ mailing list, but it
probably doesn't hurt to repeat this...  Or maybe it does

Anyway, here's a cut-n-paste or copy-n-paste or whatever is 
correct, from the patches you sent in the mail I'm replying to...

+/*!  Holds the major number of the device node. may be changed at load
+int smschar_major = 251;

The problem is that there is no guarantee that on a 
full-functional Linux system, this major number is actually
free.  For me, it wasn't.

I would imagine that changing this will adversely affect any
embedded-product vendors, or the like, who today can happily
use this major number...

Anyway, thanks to the library you provided me and associated
files, I see there's a simple script that creates the devices,
which presumably the SMS library accesses by name, not number,
and this can be hacked in my case to match reality.

However, I'm not sure if this can be a solution in the general
case.  Given the scarcity of major numbers, I can't expect there
to be a major dedicated to these devices, but I wouldn't be
surprised if someone could come up with some magic to make use
of a DVB major number for alternative non-DVB-T access to these
products.  (This probably would require making public the ten-
or-so lines of the script that creates the alternative access
dev thingies, which shouldn't violate your IP much)

That might break plug-in compatibility with devices which today
depend on major 251 being free, but such is life, eh?

Sorry for any typos or errors in grammar or logic, I'm typing
this in total darkness in an unheated room, and the amount of
not-freebeer I've consumed to try to keep warm has probably
somehow affected my ability to ``think'' as it were.  Maybe.
Plus I can't see the keyboard...

barry bouwsma
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
More majordomo info at