Re: PATCH: Query DVB frontend capabilities
-BEGIN PGP SIGNED MESSAGE- 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. thanks, barry bouwsma -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Key found at http://vax.chrillesen.dk/~barry/gpg.key Comment: Anständige Signaturen und Verschlüsselung gibt es nur mit GNUpg Comment: und nicht mit De-Mail. iEYEARECAAYFAk69XqgACgkQPTWIZbDoOFfp0gCcDOxKlVrjbfGtEMLqNZ/Jkqkk ngsAn3hoMOF5rPkqzZKD2QnDTifA2+of =vN6k -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: support new Siano tuner devices.
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
> isolated.
> 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 @@
case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
request_module("smsdvb");
break;
+/* XXX HACK */
+ case SMS1XXX_BOARD_SIANO_STELLAR:
+ request_module("smsdvb");
+ break;
+
default:
/* do nothing */
break;
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix av7110 driver name
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 issue. 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", thanks, barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is anybody working on TechniSat CableStar Combo HD CI USB device?
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 reality. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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)
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 > > > days? > > > > 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 streams. > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories
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 once. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Siano SMS1140 problem
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, seba...@yahoo.it 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. thanks, barry bouwmsa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad image/sound quality with Medion MD 95700
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?
Yes.
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.
THIS IS NOT A CHANGE WHICH NORMAL USERS SHOULD TRY TO MAKE.
IT WILL ONLY WORK FOR THE ORIGINAL UN-MODDED MEDION 95700.
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
+#else
+/* XXX try to switch to using ISOC instead of BULK */
+/* XXX debug */err("attempting to use isoc transfers on alt6
ep");
+ 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad image/sound quality with Medion MD 95700
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) THIS IS NOT A PATCH TO BE APPLIED BY EVERYONE. This is only to 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 cxusb_cx22702_frontend_attach ^^^ 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad image/sound quality with Medion MD 95700
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
experience.
> > 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad image/sound quality with Medion MD 95700
On Fri, 25 Dec 2009, TAXI wrote: > I tried a Medion MD 95700 with kernel 2.6.32 (for tests: 2.6.30.9) 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 kernels. 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 versa. 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... thanks barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scan/scan-s2 doesn't tune, but dvbtune does?
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 > > > > 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. Speaking of which, is there a way to manually set > > > > the > > > > 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 > far! 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scan/scan-s2 doesn't tune, but dvbtune does?
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no locking on dvb-s2 22000 2/3 8PSK transponder on Astra 19.2E with tt s2-3200
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: DVB-APPS patch for uk-WinterHill
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CH???, Bandwidth 8MHz, Fec_Hi 1/2, Modulation QAM64, Mode 8K, Guard 1/4, fails to tune\demux
On Sat, 21 Nov 2009, g_remlin wrote: > Hi Barry, thanks for taking the time to reply (my previous more informative Happy to have helped, even though I didn't help. > This is the Terrestrial transmission standard being rolled out across the UK, Ah. I assumed `CH' referred to the country, and the FEC of 1/2 being that used for a robust yet low-bandwidth signal. Actually, there are a couple steps to the DSO in the UK, with the introduction in less than two weeks of the DVB-T2 standard at a few places, to allow HD broadcasts with some 36 or so Mbit/sec. This introduction will be taking place without any consumer equipment until next year, and cannot be received by existing hardware, as has been asked a few times on these lists. In the areas where this happens (apart from places like Crystal Palace) this is happening by converting one multiplex from DVB-T to -T2. You probably are referring to the other part of DSO, which has meant the conversion from 2k to 8k transmission mode, and the use of 64QAM modulation. > I live in one of the first areas to be upgraded to the new standard. Since the > change, my DVB-T PCI card will no longer tune (despite the signal level being Once again I'll point out what in your Subject: is likely wrong, as these are not the values I know to be used in the UK: ``Subject : Re: CH???, Bandwidth 8MHz, Fec_Hi 1/2, Modulation QAM64, Mode 8K, Guard 1/4, fails to tune\demux'' First off, the 1/2 FEC isn't used as that is used for a robust signal, as one would want from Handy-TV (DVB-H), and in the UK with its history of over-the-air broadcasting and rooftop aerials means that 2/3 and 3/4 are what I see listed (although the data I'm looking at appears to be pre-8k switchover). Also, the guard interval would not be 1/4 as the UK makes use of MFN frequencies, and this appears reflected in the value of 1/32 listed in the old data. You might try to re-scan with the above values corrected, if this would be a reason why you can't lock onto a signal. thanks, barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CH???, Bandwidth 8MHz, Fec_Hi 1/2, Modulation QAM64, Mode 8K, Guard 1/4, fails to tune\demux
Howdy. 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. thanks, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problems receiving channels with technotrend S-3200
On Wed, 11 Nov 2009, Stefan wrote: > I'v problems with receiving dvb-s channels especially all the bbc > channels on freesat (Astra 28.2) . > The card is working fine for all the dutch channels (canaal digitaal) > and in windows i have no problem receiving bbc hd > > But as soon as i tune in to for example bbchd or bbc1 i do get a lock > but no data. > > # dvbstream -f 10847000 -p v -s 22000 -v 5500 -a 5501 -o > bbchd.mpg > tuning DVB-S to Freq: 1097000, Pol:V Srate=2200, 22kHz tone=off, LNB: 0 > When i try to record bvn (a fta channel) But not found on the same satellite... > # dvbstream -f 12574000 -p h -s 22000 -v 515 -a 96 -o > bvn.mpg > tuning DVB-S to Freq: 1974000, Pol:H Srate=2200, 22kHz tone=off, LNB: 0 These indicate you are attempting to stream from the same DiSEqC LNB number. Your BVN is found at Astra 19E2 while the BBC domestic services are broadcast at Astra 28E2. You need to add a `-D #' to indicate which LNB position your Astra 28E2 can be received, which is obviously not the default (A or 1/2 or 1/4 or whatever) in your DiSEqC switch, as part of your commandline. Also note that you may need to record more of the stream in order to properly decode and play the BBC HD file than just the video payload. The particular values I used last time I looked (the BSkyB/Freesat services have a habit of changing for no good reason) were 0 258 5500 5502 5503 5504 5501 if that helps, including subtitles and all. Note that there is an active DVB-S transponder at the same frequency on Astra 19E2, last time I checked (more than a year ago, sorry) explaining why you are able to lock successfully on the wrong satellite position for the Freesat services. thanks barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2
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. thanks, barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2
On Wed, 4 Nov 2009, TD wrote: > 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 experiencing. 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 > it's > = connected to a Delta MS 5024 N multiswitch. From what I could make out, > said > = 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, o
Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2
On Tue, 3 Nov 2009, TD wrote: > On 2009-11-02, Goga777 wrote: > > Приветствую, TD > > > > you have to use scan-s2 > > http://mercurial.intuxication.org/hg/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. thanks, barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] what is the current status of the DVB-T2 supply chain for the UK ?
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 > find. 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 available. 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. cheers, barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Anysee E30 C Plus + MPEG-4?
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 this. 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 answer. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Digital Audio Broadcast (DAB) devices support
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 (http://www.terratec.net/en/products/Cinergy_Piranha_1668.html) 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 broadcasts. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Digital Audio Broadcast (DAB) devices support
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 broadcasts. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Aspect ratio change does not take effect (DVB-S)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
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 > filtering. 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 whil
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Thu, 21 May 2009, Devin Heitmueller wrote: > em28xx: Don't let device work unless connected to a high speed USB port (grrr, dyndns addresses that are actually dynamically changing) |The em28xx basically just doesn't work at 12 Mbps. The isoc pipe needs |nearly 200 Mbps for analog support, so users would see garbage video, |and on |the DVB/ATSC side scanning is likely to work but if the user tried to |tune it |would certainly appear to have failed. |It's better to fail explicity up front and tell the user to plug into a |USB 2.0 Hi Devin, I've spent the last night trying to wrap my brane around the DVB code and how it reflects on the ability of hardware to perform PID filtering or not, thereby the expected load due to interrupts and filtering in the CPU. If my current machine is being fed a single stream from a lower-bandwidth source (not sure where the filtering to a crummy audio stream is being performed, but even the full bandwidth available from a 1,5MHz-wide chunk of spectrum is well within USB1.1), load is negligible. Multicasting the filtered data back out over a USB1.1 net adapter bumps up the interrupt load somewhat, but `top' idle time remains high. As soon as I toss a dvb-usb device into the mix, which is allegedly capable of doing internal PID filtering but which presently can't, delivering a full transport stream from a 27,5MSym/sec transponder, the interrupt level goes up, in spite of the fact that the content of interest is only a slightly less crummy audio stream of some 1/250 the full transponder datarate. However, as soon as I try to listen through the internal soundcard to one of these streams, the interrupt level goes up by nearly a factor of three, the machine drops to around only 50% idle, despite that there's no significant CPU- crunching application, and the responsiveness drops, with something comparable to stuttering observed frequently when I do something on the console. Also, the CPU temperature hovers around the point where the fan turns on. So, in spite of the individual things I do hardly being any load on the CPU in themselves, apparently the load caused by handling USB interrupts is more than additive. Bring on USB 3.0, I say... I've been spoiled by hardware which does the internal filtering, and barely causes my slower machines to break a sweat, except when I do have to handle a full TS or a higher-bandwidth HDTV stream, which it can still do, and so I decided to look at which of the different devices available today are capable of delivering a filtered TS, whether via USB or PCI -- primarily I only care for audio, at up to 320kbit/sec, that happily fits on the spare USB1.1 ports and normally doesn't cause any bother. Now, with that background, I see that the dvb-usb framework makes the hardware's ability to PID filter quite obvious, as well as the b2c2 flexcop hardware. Not all devices have this ability, apparently, and I still need to go over the code when more awake to make sense of it. Now I do know that at least some of the em28xx hardware does have the ability to selectively filter and deliver only the PIDs of interest at well within USB1 bandwidth for audio, or selected lower-quality DVB-T video. And you made mention of this some months back on the list, when asking if it was worth your time. That's the problem with these composite devices -- they are fine for such things as watching Freeview or listening to that radio, not so much for decent-quality cable (where it exists), no different to the many USB1.1 DVB-T or DVB-C devices, but they are useless for the remaining analogue sources on USB1.1. And they don't fit into the dvb-usb framework. In my dream world, the em28xx devices would determine what they can do (analogue or full transport stream) based on the USB connection, rather than simply refusing to work, provided the hardware is capable of filtering the DVB TS. But, you provide the source, so in theory I should be able to fine-tune it as I wish. (Note that my experience is based on DVB-T SD video, which so far has fit into USB1.1. I know that DVB-S H.264 HD video does not, and I would imagine that if HD ATSC is really using MPEG 2 rather than AVC video compression, it would need even more than the 16Mbit/sec I see from DVB-S, or the 10Mbit/sec expected with DVB-T2 later this year, which also wouldn't fit reliably on USB1.1 if my experience with decent quality SD in MPEG 2 is any guide on my hardware. So even hardware PID filtering is no guarantee of flawless performance, but again, the user can employ it in cases which would work. Caveat emptor. Cave canem. Carpe cavy.) Just some rambling comments there. Ignore me. barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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 working: [ 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 device) [ 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, an
Re: [PATCH] add new frequency table for Strasbourg, France
(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... Thanks! barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new frequency table for Strasbourg, France
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 needed. 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) [= cell_frequency_list_descriptor] descriptor_length: 40 (0x28) Cell: cell_id: 515 (0x0203) Center frequency: 0x0365c040 (= 57.000 kHz) subcell_info_loop_length: 0 (0x00) Cell: cell_id: 560 (0x0230) C
Re: [PATCH] add new frequency table for Strasbourg, France
On Sat, 14 Mar 2009, Benjamin Zores wrote: > Attached patch updates the current dvb-t/fr-Strasbourg file with > relevant transponders frequency values. Hi, 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, exce
Re: TS sample from freeview, anyone?
Ciao Andrea, On Tue, 10 Feb 2009, Andrea Venturi wrote: > > > i'm looking for a full TS sample of a freeview mheg RedButton > > > transmission. > > 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 redbutton-browser (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 differ
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
On Sat, 7 Feb 2009, Christoph Pfister wrote: > Sorry for the late answer, No worries, I've been keeping busy by discovering yet more info. Discovering a site where not only does everyone know more than me and where all the info I could possibly want is there for the taking, but where I feel more unworthy than usual. So, while I still have yet to mangle the machine-generated output, I did observe the following: It seems that the info for Hansestadt Bremen (Radio Bremen) can be merged into that for Niedersachsen, as the presence of an RB multiplex in the latter disturbed me, until I noted that apparently all the (Bundesland) Bremen frequencies are also used in Bremerhaven. So, one less file to maintain. Not only is Hansestadt Hamburg migrating away from the VHF Band III allocation which kicked off this too-long-running thread, but at some yet unspecified time this year (2009), most if not all of the remaining Band III DVB-T transmitters will also relocate. This affects primarily Bayern, but also a few other sites (FFM, Berlin...) I don't know if the frequencies I've read are confirmed, or mere speculation; further, I know no fixed planned dates. But more importantly, I don't know if it's worth it for me to bother to announce known and confirmed changes, or if I should relax and let the official channels publish the info to be massaged into scanfiles. Any residents who might happen to read the info I post are almost certain to have already been made aware of any such changes through other media... My claim that the information for each Bundesland was not likely to change, could be an untruth. I've seen mention of additional frequency changes that were unknown to me, in addition to vacating VHF DVB-T frequencies to make available more DAB/DMB/DVB-T2 multiplexes nationally and regionally. Apparently Bundesland B-W will not only start two more ARD/SWR multiplexes in Bad Mergentheim at a lower power than the other transmitter sites, but will also start a handful of other lower power sort-of-filler sites, apparently not coordinated with ZDF. (May be R-P; my geography is poor). And there should also be some sort of pilot or comparable introduction of a Private MUX in Stuttgart, quite possibly incompatible with existing practice throughout Germany (may be use of MPEG-4 video, or perhaps DVB-T2, or maybe encryption)... > case you need to mark the individual transmitters). Actually I don't > care about the arrangement, as long as there are machine-implementable > rules for the update. Of course, first of all, I need to get off my lazy butt and actually start sorting the info you've compiled into something that will help me get an overview. Say, for Bayern, which, from the Bayerischer Rundfunk perspective, is divided into North (Franken) and South (also with good beer); to which are added a few Privates in scattered areas, partly using the same frequencies, though widely spaced... As a tradeoff, it could possibly be that some Bundesland files could be merged into a super-region -- notably the NDR and mdr regions, though this is pure speculation as I haven't rearranged any files to imbed them in my brain, and is only suggested at by the Bremen/Bremerhaven union. Talk is cheap. > >> They shouldn't be too excessive, > > I meant the number of transmitters, not the size of the file. Ah, fine, fine. As a comparison, I'll offer Helvetia. The last list of DVB-T transmitters in service I bothered to download includes some 25 pages, each with around 20 or so listed sites, for that small land. No way would I consider attempting to list these -- or even those for a particular language region or SFN part thereof, in a scanfile. > > I just updated overnight, and de-Leipzig no longer exists! > > Aieee!@ Good thing I made a backup copy of that directory > > before I updated > > hg has a good memory as well :) At my age, it's hard to unlearn the convenience of such advanced tools as `grep' and `less' on simple foo,v text files (and Attic directories) to trace a file through time. However, you're right -- I do believe that I had problems with `git' on renamed or obsolete files, and subversion appears hopeless for anything but remaining up-to-date offline, though I have enough SOCKS and https problems with that, so that I'm no longer bothered... Like they say, I learn something new every day. Pity that most days it's the same thing I learned on several previous occasions, when not each day the past week... Anyway, let this be a fore-warning that you will be likely to need to update the files for various Laender a few times this year to keep up-to-date -- and that is not to include changes to MUX contents (renaming one ZDF digital channel, or changes in Private Muxen). So I'm off to the Bundesnetzagentur to see if I can get accurate info about upcoming changes and allocations, though I believe this source will be more suitable for planning, than to generate up-to-the-minute scanfiles. barry bouw
Re: channels.conf file for danish DVB-C provider AFDK (www.afdk.tv)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TS sample from freeview, anyone?
Sorry -- I overlooked this earlier... On Fri, 6 Feb 2009, Andrea Venturi wrote: > i'm looking for a full TS sample of a freeview mheg RedButton transmission. How much are you looking for -- in other words, do you need the full service including video that a RedButton service might bring up, or do you just need a sample of, well, Digital Teletext? I'm assuming that you're in Italia (based on your mail headers). Therefore you likely would have problems in receiving television programming via satellite on Astra 2D, although I've had error-free reception with a 60cm dish in Zuerich long before I was aware of the spotbeam. However, the BBC radio services are on a pan-european beam and also (since some months) include a minimal MHEG application that I've been able to receive and view, like the BBCi services on the TV channels -- also available from the BBC (if not ITV too) via satellite/Freesat, and which is likely to be pretty much identical with that received via Freeview... So, unless you've received off-list assistance, this may be a possibility to get something barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DAB SFN (was: Re: [linux-dvb] dib0700 "buggy sfn workaround" or equivalent)
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... thanks, barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
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 application... As a concrete example, what I would create, would look like: # DVB-T Sachsen-Anhalt # Created from http://www.ueberallfernsehen.de/data/senderliste_25_11_2008.pdf # 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, Wittenberg 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... Thanks... 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 h
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
On Wed, 28 Jan 2009, Tobias Stoeber wrote: > > > should (ideally) use a 8 MHz width space from 559.25 MHz to 567.25 MHz for > > > Ch 32. > > > > Is this correct, or should the range be from 558 to 566MHz, > > apart from locations (such as the UK and Australia) where an > > offset may be used? > > Well, you may be right ... I recalled that from former norms (analogue) and > the fact, that the digital channels were expected to use the existing > boundaries. Well, the thing is, that where I came from and where I was working as a broadcast technician many decades ago, where a grandfathered norm was in use that makes a good PAL signal appear to be practically high-definition in comparison... The reason for the offset was due to the use of analogue modulation on the video carrier, which causes a sideband to be created on either side of this carrier, corresponding to the frequency of the modulating signal. For simplicity, I'll say that this blurry-o-vision would have a bandwidth of about 3MHz, with some vague colour info squezed above this, and then a separate audio carrier with an offset of 4,5MHz from the video carrier. So, *very* roughly, in ASCII graphics, the frequency spectrum of the modulated carrier could be seen like this... _ I _ / |I| \ignoring the colour and sound. __/ \I/ \__ F-3 F F+3 This would require twice the bandwidth of the actual information, or 6MHz for 3MHz baseband video, and 9MHz when you add in the sound. Strictly seen, the carrier F - modulation frequency f carries the same information as F + f, so one can transmit only the upper sideband without losing any information, and filter out the lower sideband. Because the filter is not perfect, and I've long since drank the precise values from memory, there still will remain a bit of the lower sideband... _ I _ / |I| \ __| \I/ \__ F-3 F F+3 Thus the 1,25MHz offset of F from the lower bound of the frequency range. And the upper bound will not be 8MHz higher, as that's the step to the next carrier frequency here. Those 1,25MHz belong to the leftovers of the lower sideband of the next channel up. So the maximum available bandwidth will be based on 8MHz minus the 1,25MHz, minus a bit for additional services -- I've never grasped the details of the differing norms for audio, as I've never had the need, only having picked up the above as a side-effect from my work outside of television. > http://www.kathrein.de/en/hfc/techn-infos/download/TA-163-164.pdf > it seems, that you are correct (or how to you read the info in the pdf?). I'll have to get to this later with a better net connection... But my basic understanding is that the CODFM signal can be vaguely seen as some 8192 carriers packed within that 8MHz bandwidth (or 2k in early-adopter parts of the UK), and there is not the waste of a leftover bit of sideband that needs the 1,25MHz offset -- instead you could view the carrier as the center of the 8MHz range, as is done. Now there is no guarantee that any of this is right, as I haven't attempted to absorb the multitude of information I've come across to reach the `Aha!' moment of enlightenment that I need. > > Maybe. It's better, in my mind, than the existing case of > > individual sites, which again, may or may not cover the case > > of nearby areas. > > Well, the old style of de-transmitter_region scan file had the charme, that it > is easier (at least for me) to select the transmitter sites in my direct > surrounding and I've no real use of de-federal_state. You also have the advantage of being familiar with the sites you can receive, as well as your local geography. If I were to suddenly be plopped into your general area, I'd have to dig out a map to try and see what might be nearby. I'm an outsider and don't have the background of a native, except in a few places where I've spent more time than I should have. I've only once passed through Braunschweig on the way to Danmark from the sunny south, and it won't be until I take the time to do the research, thus familiarising myself with a region which does not immediately bring to mind Weisswurst or Spätzle, that the individual site files (when they even exist, or when they are even accurate) would be as useful to me. Take a look at fr-*. That's (in my out-of-date mirror) over 100 sites. One reason this is needed is due to the fact that they chose not to make use of Single-Frequency Networks, and so nearby towns are assigned different frequencies, rather than the reuse that I've noted in my comments for B-W. Counting the number of ZDF sites on the ten pages of teletext, I come up with over 130 transmitters, most of which are shared with the ARD and others. But this is not always true, as there are a handful of sites, most in edge cases, where only the ARD/Dritte stations are being sent, so I'll estimate that Christoph will need some 130 to 140 different file
Unicode Teletext (was: Re: [linux-dvb] getting started with msi tv card)
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 ◆ BLACK DIAMOND
[◊] U+25CA ◊ LOZENGE
This is matched by reading the code:
const wchar_t graphutf8[128] = { // Graphic characters on an unicode terminal
ISO-10646
[...]
0x25A0,0x25A1,0x25A2,0x25A3,0x25A4,0x25A5,0x25A6,0x25A7,
[...]
0x25B0,0x25B1,0x25B2,0x25B3,0x25B4,0x25B5,0x25B6,0x25B7,
[...]
0x25C0,0x25C1,0x25C2,0x25c3,0x25C4,0x25C5,0x25C6,0x25C7,
[...]
0x25D8,0x25D9,0x25DA,0x25DB,0x25DC,0x25DD,0x25DE,0x25DF,
};
I'm still trying to determine whether the second font has any
graphics and where they would be hidden -- even the handy
[█] U+2588 █ 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
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 > > T 85000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > > So why then not provide a generic scan file listing all freq with AUTO > parameters? 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 everywhere. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] getting started with msi tv card
On Tue, 27 Jan 2009, Daniel Dalton wrote: > > > I'm connecting it to a co-axle point in my home; I lost the original > > > antenna. > > > I'm reasonably sure that point should work fine. > > In place of the original antenna, you can try a short > > length of wire, say, 5cm long for the UHF frequency, to > > about half a metre for the other frequencies. This will, > > What kind of wire? Ear phone? and how do I hook this up to the receiver > since it has a co-axle input plug on it. The type of wire should not matter. In fact, you may not even need to make contact between the metal of the coaxial connector and the wire conductor for a very strong signal -- although ideally you would make this contact. The idea behind this is that Antti has suggested that your tuner may not work well with strong signals, so we are wanting to get a somewhat weaker signal. It could be, though, that you will not get enough of a signal. This all will depend on the distance you are from the transmitter site, the power it sends, and what sort of terrain exists between you and the sender. One thing has popped into my mind -- there are different standards for coaxial connectors used in different parts of the world for the same function, so I may have a totally different idea of what you have... Anyway, you are connected to your wall by a cable that connects to your device. Perhaps that cable is connected to some sort of push-on or screw-on connector, or maybe it is firmly attached to the wall without a connector. The part of the connector of interest will be the centre conductor. Through europe, this exists on TV-type tuners as an outer ring, somewhat over 1cm diametre, and a smaller ring inside with a couple millimetre diametre. I can actually take a length of bell wire or thin electrical wire, fold about 1cm of it over on itself, and stick this into that centre conductor to make a simple antenna that receives strong signals. If you have a screw-on type of F connector, that was common for cable TV in america when I was there, but in europe is found primarily on satellite equipment, then the part that connects to the wall will have a centre conductor which extends somewhat, if you are lucky. This can be a bit tricky, but a clip lead, with small alligator clip can be of help, particularly if the F connector cannot be readily screwed off. Now, for the other type of F connector -- the female type, one can simply stick in the end of some bell wire, after removing a cm of insulation. The problem is that I personally can't imagine myself doing this without sight, because it's too easy to cause a short-circuit between the outer and inner conductors, which means your reception will drop to zero, and I rely on visual feedback to see this. So if you have some technically-minded friend who can help you with this, it may be easiest. (There are no dangerous voltages to be found on these sort of antenna connectors. In strong signal areas, I can get a good signal simply with my finger on the inner conductor, possibly moistened for better conductivity. This is not to say that your equipment will be at earth potential, as all this depends on the presence of and quality of your earth ground, and in fact whether all your devices make use of it, as I'm often zapped lightly when connecting USB devices to an earthed computer, due to the lack of earthing on said devices. At worst, your tuner may deliver 5v to power an active antenna, but nothing to throw you across the room.) Actually, 5cm wire for the UHF frequency in use might be a bit short, so you may be better with 20 to 100cm overall. Another thing to keep in mind, though it won't be as important as it is with a rooftop-mounted antenna, is the polarisation of the radio signals from the transmitter; the scanfiles I see here don't give any hints to that for your area, and my internet connection presently is too poor for me to look online. Anyway, good luck; it could be that with this you are unable to receive any signal whatsoever, in which case all the time I spent writing this will have been for nought, and, unless some other brilliant idea reveals itself, you will be forced to go the path of obtaining a different tuner and hoping that one works out-of-the-box... barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
Salü, Tobias...
On Tue, 27 Jan 2009, Tobias Stoeber wrote:
> You are right. 562 MHz as nominal frequency is correct, because for
> It's just a centre frequency used for tuning purposes. The DVB-T signal
> should (ideally) use a 8 MHz width space from 559.25 MHz to 567.25 MHz
> for Ch 32.
Is this correct, or should the range be from 558 to 566MHz,
apart from locations (such as the UK and Australia) where an
offset may be used?
I'd assume the 1,25MHz offset you list is due to the use of
analogue suppressed sideband, where the actual carrier to
be modulated would be, for E21: 21 471.250; the sound
carrier at some offset to this which I don't remember, not
having interest much in the many different analogue norms...
> Looking through your files in the zip archive, it rose some questions in
> my mind:
>
> a) is it really useful to have scan files by federal state (Bundesland)?
Maybe. It's better, in my mind, than the existing case of
individual sites, which again, may or may not cover the case
of nearby areas.
I'm trying to decide if a de-all type of file would make any
sense, and how to go about it, because I'm dissatisfied with
the current state of de-Wherever files.
In the case of ch-all, it makes sense, because it's a simple
case of generally a single multiplex per language region, based
on the GE06 frequency allocations, in a smaller geographic area.
> Just let me explain with an example. I live in Sachsen-Anhalt on the
> north of the Harz Mountains area. To effectivly ("best") use DVB-T I do
> combine both transmitters in Sachsen-Anhalt (Mt. Brocken) and from
> Niedersachsen (Braunschweig). This is because some channels are only
I've posted in the past my suggestion for a de-BW file, made
by hand, which tries to address this issue, as well as provide
an overview for anyone trying to make sense of the frequencies
and broadcast policies, as well as to help with antenna
orientation, towerspotting, or anything else that might interest
me, in a single location.
Have you seen this file? If not, would you care to find it in
the archives (or I'll mail you a copy) and tell me what you
think of it?
> => I personally would prefer to stay with or alternatively provide a
> region based file, so I could look up and combine the regions of
> interest. What do you think?
A Bundesland-based set of files is a region-based set, or can
you better describe the regions you are thinking of? In any
case, due to the nature of overlap, there will always be edge
cases regardless of region, bar island nations or those where
penetration is not aimed at close to 100%...
The division by Bundesland works also because of different
management in each Land, which plays out in channel assignments,
SFNs, and common use of a particular modulation, I am seeing by
the overview presented in the first pdf file.
> b) Conflicting information
>
> In your "Sachsen-Anhalt" scanfile you list on Ch 24 the ARD multiplex
> with (Halle-Stadt):
>
> T 49800 8MHz 2/3 NONE QAM64 8k 1/4 NONE
> # CH24: Das Erste, arte, Phoenix, EinsFestival
>
> which is for a large part of Sachsen-Anhalt useless (we can't receive
> that), as we actually receive on Ch 24 (from Braunschweig)
>
> T 49800 8MHz 2/3 NONE QAM16 8k 1/4 NONE
> # CH24: RTL, RTL II, Super RTL, VOX
I intend to take Christoph's files and massage them to add
bits of info, reviewing the info by hand, adding missing info
and generally trying to come up with something like the BW
file I created.
But I want feedback about that file too, rather than to have
my changes be rejected after I've done the review and work.
> => Does it matter, e.g. would instead of the unreceivable Ch24 from
> Halle-Stadt the Braunschweig Ch24 be found? (I did not test this).
This all depends on the device. At least some of my tuners
effectively will lock a signal as if I've specified `AUTO'
in place of everything, even when what I specify is wrong.
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
T 85000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
> c) You clearly missed out some information. I noticed for instance Ch 37
> in Leipzig (Sachsen) which is the "Leipzig 1" multiplex
> On the other hand I doubt, that it would be a useful entry into a
> "Sachsen" scanfile because reception is limited to the area of the city
> of Lepzig.
For cases like this, I don't know if it's better to have
a separate de-Leipzig file as today, plus something covering
a larger region. I would argue the case for keeping, say,
de-Stuttgart but losing everything else in favour of de-BW;
however, at least two locations there do not just list the
local transmitter frequencies (Ravensburg and Mannheim) but list
out-of-Bundesland frequencies (the Privates from FFM for the
latter, and austrian and maybe swiss frequencies receivab
Re: [linux-dvb] getting started with msi tv card
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... ..ngk.ng.. | 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 guide. 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. DANGER! ASCII PR0N PASTED BELOW! SENSITIVE READERS SHOULD AVERT THEIR GAZE OR SKIP TO THE NEXT MESSAGE! ^L I MEAN IT! IT COULD QUALIFY AS EXTREME PORN! ^L THAT'S IT, I TAKE NO RESPONSIBILITY FOR YOUR ACTIONS! 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 anywhe
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
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
projects.
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 o
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
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
> >> http://www.ueberallfernsehen.de/data/senderliste_25_11_2008.pdf
> 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)?
Certainly.
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
lands.
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-
identical-save-for-a-few-half-hour-bits-here-and-there
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.
Re: [linux-dvb] How to use scan-s2?
On Sun, 25 Jan 2009, Alex Betis wrote: > On Sun, Jan 25, 2009 at 6:29 PM, Hans Werner wrote: > > > On Sun, Jan 25, 2009 at 4:41 PM, Hans Werner wrote: > > > > > If you have a stb0899 device, don't forget to add "-k 3". > > > > Oh. Can someone say what's different about the stb0899 here, > > > > and how -k 3 helps ? > > > stb0899 driver (or maybe the chip?) has some buffers inside that are not > > > reset between tunnings. > > > In that case messages from *previous* channel will arrive after the > > > tunning > > > to new channel is complete. > > > Those messages will create a big mess in the results, such as channels > > > without names, duplicate channels on different transponders. > > > -k option specifies how many messages should be ignored before processing > > > it. I couldn't think of a more elegant way to ignore messages from > > > previously tuned channel. I use "-k 3" by myself, but after playing > > around > > > with "-k 2" saw that its also working. "-k 1" was still not enough. > > OK, thanks, I will check if I see that problem. Which card(s) > > did you see this with? > I'm aware only about Twinhan 1041 and TT-3200 based stb0899 cards. Both have > the same problem. This may be going typically off-topic, but I do experience similar artifacts with some STV0299 cards (looks superficially alike; I don't know), which I'll toss out here just for giggles. It turns out I have three if not four such stv0299 cards, and I either experience `scan' difficulties or recording issues, or nothing. First off, for reference: a PCI SkyStar2 card that gets priority for recordings, using a 2.6.14-ish kernel that I'm in the long slow process of planning to update on that production machine. When making two recordings separated by time from the same transponder, often the second recording will have a few video frames left over from the previous recording. This appears in my quality-control as video frames with differing timestamps as well as errors when run through `mplayer' video codec ffmpeg12, but timing data remains intact (I can `dd' away the first second or more and get a flawless partial transport stream). This is not a problem when I switch between transponders to make the second recording. And it can be many hours between recordings from the same transponder, yet the leftover data still remains. I've never noticed that this affects `scan' which changes transponders; that in itself seems to be enough to lose the buffered data. This is only a minor concern as the first few frames of confused data are almost certainly disposable, as a fraction of a second in the padding leading up to the content of interest. As exhibit number two, where I have had problems with regular `scan' seeing data from the previous transponder and causing problems getting current data, another stv0299-based device, the Opera-1 USB-connected tuner. I have *never* seen any recordings made from this device contain frames from an earlier tuning session, though. As far as `scan' tuning goes, I would regularly see previous ``phantom'' channels appearing, combined with zero-value PIDs for channels on the intended current transponder. At least until recently; my latest scans have been flawless, either due to hacks I added to that `scan' or to kernel updates on that test machine. Exhibit C, m'lud, will be -- again on the 2.6.14-ish kernel machine, but this time connected via USB 1.1 -- an early Nova-S device. Apart from bandwidth issues due to the usb1 interface, I've never noticed problems with stale packets when recording from either the same or a different transponder. I do have other issues which may be due to the age of the kernel, but `scan' also has not had problems. Now with exhibit IV, again I see problems similar to those experienced with leftover packets, but which appear to be compounded by the internal mangling of the transport stream components into a proprietary- yet-open delivery stream. This device is the ttusb- dec DEC3000-s, of unknown-based-on-kernel-code heritage, though I may have taken it apart long ago and written the results on a long-since hidden drive. This device is connected via USB1, and is incapable of delivering more than an MPEG2 video and mp2 audio stream to a recording, making it useless for multiple audio, teletext, AC3, H.264, or PMT tables to start. It also internally converts the transport stream into the PVA format, with side-effects such as that the timestamps do not match the original transport stream components, cycling after some 40 000 secs rather than the 90 000-ish seconds delivered in the streams from other devices. Recordings from this device all-too-often would have timing problems as well as leftover data from a previous recording. (Whether from same or different transponder, I cannot say. I added a hack-workaround to my recordings to tune briefly a different txp, then tune back. Sometimes it worked. Often with high load, nothing could help.) Sometimes the timi
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
Mojn, as people say in the north and to the north of northern germany ;-) On Fri, 23 Jan 2009, Tobias Stöber wrote: > Well, just have to send this message again, this time to the right & > correct mailing list linux-...@linuxtv.org. (Who by the way had the > insane idea, to set a reply-to address to another mailing list It also means that the original sender may not ever see a reply, unless one overrides this and uses the From: header, which I'm now doing in most replies, because except for a handful of developers, I really have no idea if the original poster of a message to -dvb is even subscribed to any other list. Most of the time, I'll guess they aren't. Meaning the reply stays on -dvb assuming I reply to all. As a result, pretty much everybody is crossposting between -dvb and -media rather than the so-called ``wanted'' effect of abandoning -dvb and keeping all posts in one location, that is, -media. Naturally, posts that are delivered directly to me do not contain this header, so my replies don't make it to that other list. Frankly, I ain't bothered anymore. > As for certain area in Saxony-Anhalt, Saxony and Thuringia there ahve Argh! Don't do this ;-) You're making me run for my englisch-to-german dictionary which contains none of these. But anyway... > in my area (Brunswick), where there had been an ARD Mux on Ch 8. Now it Okay, this isn't in my dictionary either, and while I could guess the others, I have no clue. Sounds Canadian to me, which says more about my background, than of non-native place names which I avoid (Milano it is; I grew up not far from Milan and I am not good-looking and sexy and sophisticated like the italians) But that is neither here nor there... > Information for the whole NDR area will normally be found at > http://www.dvb-t-nord.de. So far, only old info from last year is what I've found there. Likewise, the site for Bayern did not give me any info about plans to migrate the number of VHF frequencies into the UHF band, while it did have a few interesting bits of information not provided by the technically excellent, up-to-date, and informative BayernText teletext pages. > There is a complete listing including parameters from "in area" and also > "out of area" (but with reception in the area) transmitters at > http://www.ueberallfernsehen.de/data/senderliste_25_11_2008.pdf Interesting, thanks. This gives me the overview by region that I lack apart from Baden-Württemberg, Bayern, and the like, as to the modulation in use -- mdr and to some extent WDR do not follow the same pattern as seen in B-W I believe there is a mistake, though, in the data for HH. The guard interval of 1/8 for all frequencies, both VHF and UHF, from one Turm (font too small) does not match the 1/4 used as a general rule throughout germany, and used by all the (UHF) frequencies in the Single-Frequency-Network formed by the other Standort. (The modulation parameters provided in the initial scan file for Lübeck seem to be wrong too -- the one which caught my eye when quickly viewing all de-scanfiles) Even though my original plans to create a comprehensive list of frequencies, transmitter sites, and technical details for each Bundesland have been put on ice, as I don't expect to be doing any travel to these areas in the near future, it will be interesting for me to come up with an overview of available quality in each region, as well as to puzzle over what WDR is doing. I wonder if, in addition to moving from the remaining VHF frequencies, there will be plans in the future to convert to a unified horizontal or vertical polarisation nationally or by region. Though this does not affect tuning data, it is apparently an issue around Nürnberg... barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] getting started with msi tv card
G'day Daniel, I just came up with a couple more ideas that could be worth mentioning, that you can keep in mind for the future... On Fri, 23 Jan 2009, BOUWSMA Barry wrote: > The other output format is `pids', and here's that from > back in 2006, before the use of the second audio channel > on the german broadcasters became widespread (last year): > > ZDF (0x6d66) 01: PCR == V V 0x006e A 0x0078 \ > (deu) 0x0079 (2ch) TT 0x0082 AC3 0x007d > > Here PID 0x79 is tagged as `2ch' (it's NAR for the Beeb), > and covers both audiodescription and occasional original- > language (mostly english language) broadcasts without > overdubbing. This was before DVB subtitles were introduced. > > Oh, here's an old BBC `pids' output, also including subtitles: > > BBC 1 London (0x189d) 01: PCR == V V 0x1388 A 0x1389 \ > (eng) 0x138a (NAR) TT 0x138b SUB 0x138c Now, I want to mention in detail the TT (teletext) and SUB (subtitle) services, at least, how they are implemented in this part of europe -- other parts of the world will likely be different, but my purpose is to throw around ideas in the hope that something will stick to the ceiling and be interesting and possibly useful. I mentioned that I find the nearly 100% penetration of subtitles to be quite useful to me personally, although it and in-field signing are intended for people whose hearing is not so good as mine, but whose vision is intact. The subtitles are sent in both a selected teletext page, as well as a separate DVB-subtitle stream. Unfortunately, the support that `mplayer' has for DVB subtitles last I knew, is, well, bad to none, and basically requires completely rewriting that bit. `xine' worked better some months ago, but at that time had some timing problems. Anyway, as I understand it, DVB subtitles are sent as bitmaps, which unfortunately makes it difficult for you to use them. This also explains the difference in appearance between the BBC subtitles and those of ITV. However, I haven't seen mangled fonts due to transmission errors, while I have seen incorrect yet properly-formed characters at times. So my understanding of DVB subtitles is far from complete or correct. Standard teletext, as was introduced with analogue transmissions as part of the vertical blanking interval, has been carried over to DVB broadcasts. In the case of the BBC, this is mostly limited to subtitles on page 888, while the german services I've mentioned offer full text services, occasionally including subtitles, but on a limited set of programmes. Only the ZDF has both teletext and DVB subtitles at present, of the german public broadcasters. These DVB subtitle fonts again differ in appearance from any of the british public broadcasters. In the UK, the move has been away from conventional teletext with the introduction of digital services, replacing it with an MHEG-based service. In germany, there has been a push to supplement regular teletext with an MHP-based service, but for lack of interest and readily-available hardware, this has pretty much died out or stagnated. I seem to recall that in Australia, use is made of an MHEG service. I don't know if a regular teletext service is available -- you will see this in the results, when you have a tuner capable of scanning. Now, ideally, a teletext service, being text-based, can be trivially converted to braille or spoken. I'm not sure about the MHEG services, as they seem to place more importance on the on-screen appearance, yet they do use a TrueType font. Anyway, while conventional teletext is not simple ASCII-like, it is based on a hamming of a limited character set which can be converted back to a standard 128- or 256-character set font, and of course the normal characters can be displayed as braille. Now, here is an example of some of the useful information to be found on a full teletext service, to show that, if it were available to you, you might find it interesting. This is a page giving inter-bank exchange rates from the Euro to your own currency, and is meant as an example (it's in german, but should be trivial to understand) /GIP IG*** PHOENIX Mi 21.01.09 18:01:45 PHOENIX.text 2/2 Devisenkurse Letzte DatenabfrageDiff. Kurs- 21.01.09, 18:00 UhrVortag zeit USA... (USD) 1,2857 -0,20% 17:59 GB (GBP) 0,9369 +0,94% 17:59 Schweiz... (CHF) 1,4767 -0,13% 17:59 Japan. (JPY) 112,9800 -2,35% 17:59 Kanada (CAD) 1,6365 +0,37% 17:59 Südafrika. (ZAR) 13,0970 -1,05% 17:50 Hongkong.. (HKD) 9,9990 +0,07% 17:49
Re: [linux-dvb] getting started with msi tv card
Hi Daniel, I'm combining the replies to several messages
into one response. This includes private mail for which
there is no on-list content, but I hope that for the sake
of other list-victims, I have included sufficient context...
On Thu, 22 Jan 2009, Daniel Dalton wrote:
> >>> tune to:
> >>> 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
> >>> tuning status == 0x04
> >>> tuning status == 0x06
> >>> tuning status == 0x06
> >>> tuning status == 0x06
> >>> tuning status == 0x00
> >>> tuning status == 0x06
> >>> tuning status == 0x06
> >>> tuning status == 0x06
> >>> tuning status == 0x00
> >>> tuning status == 0x06
> WARNING: >>> tuning failed!!!
As I noted earlier (privately), the `tuning status' value gives an
indication of what sort of signal your USB stick is seeing.
I've cut most of the following frequencies, because they
mirror the above values -- you either see 0x0, 0x4, or 0x6.
Except...
> >>> tuning status == 0x1e
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x
> WARNING: filter timeout pid 0x0010
On this particular (UHF) frequency, you actually were able
to lock onto a signal. Sadly, this was not enough to get
any information from it...
> So I assume there is no signal? I'm plugging into a co-axle plug in my
> house, which we plug our tv into.
> So do you think my problem is with the card?
A status value of 0x0 means no signal whatsoever. The
values, if you are interested, can be seen in the source
file /usr/local/src/linux-2.6.27-rc4/include/linux/dvb/frontend.h
(adjust to match your path to the source -- if you are
interested, and it is fine if you are not...)
typedef enum fe_status {
FE_HAS_SIGNAL = 0x01, /* found something above the noise level */
FE_HAS_CARRIER = 0x02, /* found a DVB signal */
FE_HAS_VITERBI = 0x04, /* FEC is stable */
FE_HAS_SYNC = 0x08, /* found sync bytes */
FE_HAS_LOCK = 0x10, /* everything's working... */
The value 0x6 is obtained by ORing the above CARRIER and
VITERBI values. Normally one first gets signal, from which
carrier, viterbi, sync, and finally lock follow in quick
succession.
Basically, this all means that your tuner sees something,
but it can't quite lock onto it.
> Am I better getting a new card? I got this a couple of years ago when I
> was on windows, and never used it, so yeh I don't have the original
> aerial that came with it or the original disks...
As Antti has suggested, you may have better luck with a
new different card.
As an offside, supposedly the linux-dvb mailing list has
been abandoned by every developer, and only a few DVB-freak
luddites remain, and in theory, by posting this to the
linux-media list I should magically reach thousands of
developers who can fix the support for your card. Rght.
For these developers, seeing this for the first time, the
history behind this thread, including details about the
card being discussed, are safely archived on the linux-dvb
mailing list over the past three-or-so days.
Personally, I don't expect support for your card to
magically materialise, though I'd love to be proved
wrong. Generally it's due to lack of adequate documentation
provided by the device or chipset manufacturers. I am far
removed from this, sad to say.
> I'm chopping out the script, just to cut the size of this reply
> down. But, thanks very much for sending the script, it looks good, and
> yep, I think I'll find that very useful once I get tv going on my box.
As I always say, my script itself is probably useless,
while the ideas which went into it have value. The
general idea is that you use the Unix-type way of thinking
of using basic building-block tools stacked together to
come up with the desired result.
This requires one to think at the building-block level,
which may not yet be at your level -- but once you reach
it, if you do, then you have an understanding which almost
brings you to the level of `master of the known universe'.
I'll go over this quickly...
First of all, from the transmitter to your tuner is
something which I will just say is a black box for now,
and you don't need to know more about it, because that
won't help you under Linux -- though it would if you
were to be an engineer or hardware developer, and you
need to know details of modulation and the like.
Where Linux comes into play is the payload carried by
the broadcast. This is in the form of a (partial)
Transport Stream, which you will be able to obtain from
your device.
There are many different ways to get at this stream,
for example, `tzap' and `cat' from the DVB device, or
using `dvbstream' in my example. Generally, they are
all similar, in that the end result is the Partial
Transport Stream.
Which leads me to mention that the particular script
I provided has the custom flag `-T' not present in
normal `dvbstream' which simply causes it to Terminate
i
Re: [linux-dvb] Siano subsystem (DAB/DMB support) library for linux?
On Sun, 18 Jan 2009, Uri Shkolnik wrote: > > You know, it might help if I actually looked at the files > > I'm > > hacking on, instead of blindly assuming they work like > > `MAKEDEV' > > 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 > > grief... 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 like... -r-xr-xr-x 1 beer besoffen 40096 May 17 2007 /usr/lib/hotplug/firmware/tdmb_stellar_usb.inp 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 tdmb_stellar_usb_12mhz_eeprom_a2.brn 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... smschar_major=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 gone) barry bouwsma create_char_dev.sh Description: Hacked version of contrib
Re: [linux-dvb] Where to buy a Dual PCI-e DVB-s2 card in switzerland ?
(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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[3]: [linux-dvb] dvb-t config for Ukraine_Kiev (ua)
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 > 224.12.12.12:1234 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 Ukraine) 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 lock: 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... thanks, barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
Following up to myself is a sign of a sick mind. On Sat, 17 Jan 2009, BOUWSMA Barry wrote: > > shell 1: $ tzap channel > > shell 2: $ dvbtraffic > > [lots of output that streaming is working] > > shell 1: $ > > shell 1: $ tzap "channel2_which is on a different frequency" > > shell 2: no output of dvbtraffic any longer... (problem) > 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... Here's what I see. It may not be meaningful. This machine uses utilities from 2005 or so, sometimes hacked but still based on source from 2005. Anyway, with the SkyStar2: szap a-channel-which-locks dvbtraffic-card0 ==> output, whee ^C szap; dvbtraffic continues for a few seconds (timeout) szap the-same-channel or a-different-frequency no dvbtraffic output yet ^C szap; immediately dvbtraffic outputs again for a few secs With a DVB-T tuner: tzap a-channel-which-locks dvbtraffic-card1 ==> output, yay ^C tzap; dvbtraffic continues a few seconds tzap again no dvbtraffic output yet ^C tzap still no dvbtraffic output... But no errors are thrown up, nor does anything appear logged to the console. However, [ts]zap are system binaries from 2004; dvbtraffic is hacked, though I'm not sure how heavily, so I don't know if what I see is meaningful. Invoking `dvbtraffic' first, then `dvbstream' also produces some results for a fraction of a second, then no `dvbtraffic' output. So, at this point, I don't know what to say... barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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: $ > 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... thanks barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Cross-posting linux-media, linux-dvb etc
On Sat, 17 Jan 2009, Mike Isely wrote: > On Fri, 16 Jan 2009, user.vdr wrote: > > I think it's a lame idea to clump all media related stuff into one > > mailing list from separate ml's because 1) it's too general of a topic > > and 2) those ml's already had a lot of activity on their own. The > > idea of sifting through tons of posts of no interest is quite a hassle > > to say the least. This "solution" just doesn't seem very well thought > > out imo but it is what it is I guess. > That's still better than sifting through MULTIPLE COPIES of the same > post from different lists, which frequently is the case right now. Sounds like some opinions which won't easily change, as well as different experiences, that I'll try to explain... First, given the strong opinions people have had in the past about getting a direct reply as well as a list copy, I think it's worth a mention that it appears that both g00gle-mail and yah00! use the Message-ID as the key to a database with the result that duplicates are suppressed, in spite of the different header contents. This was at first very unnerving when I didn't get two yah00! copies of mail where I was a direct recipient, which was quite different from what I had grown used to years ago, when I was running my own simple mail server. This went from unnerving to annoying when I realized that g00gle appeared to use the Message-ID as key to a database not just covering the Inbox, but my entire mail, such that my own gmail sent-mail copy existing meant that it wouldn't ever appear in my inbox. Now I could be misunderstanding how these large providers do things internally, but in effect, duplicates there are suppressed. Maybe this is configurable, as part of their filtering, but I wouldn't know as my browser of choice was unable to access their configuration, and actually, was completely unable to access gmail last I tried. That should mean that while I include user.vdr with a cc:, that account should by default see this only once, whether or not it's subscribed to -media as well as -dvb. Just as a demonstration. Whereas Mike, you see this twice, as I stripped your personal addresses since this isn't important enough for you to see even once, let alone four times, and your provider apparently doesn't do the merging my M-ID. And yes, I am one of those who *does* wish to receive a duplicate copy of a message sent directly to me as well as to a list, if it's important enough not to get lost in the noise or overlooked. Others disagree, and I respect that. Particularly when I go back to casual 'net access, and have to sift through hundreds of messages at a time, once a week, once a month, once every eight months... Up until recently, I *did* read all linux-dvb messages, and resisted the temptation to reply to people posting about analogue devices by saying v4linux is over there ==> due to the -dvb giving a clue in the list name. While you won't be annoyed by duplicates, I'm going to be missing some posts I would have read on -dvb. Not that that's a bad thing, I'm sure most will agree, particularly anyone I've misled by trying to ``help''. Understand that my objection is not to the move to vger, which is a good thing, but to the merger of the two lists of different topics and some non-overlapping end-users who may be overwhelmed by the doubling of message volume. Here's some flamebait, and I'll probably regret this, but hey, I only get one chance to live -- why not merge in the em28xx mailing list from mcentral.de as well? That covers hybrid devices, both analogue and DVB-like, and would save me as a non-subscriber from having to crosspost, and would save subscribers there and to -dvb or -media from seeing those posts multiple times, and, um, no, I'm not serious, but separate lists of overlapping interests do exist, and crossposting/multiple copies do exist, and at least some services out there are able to minimise the inconvenience of duplicate copies... Now if you'll excuse me, I'm off to crosspost to mcentral. Haven't started a good flamewar since the last time I woke up... barry bouwsma won't someone please think of the newbies... -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Cross-posting linux-media, linux-dvb etc
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. yerz, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] [PATCH] Siano (SMS) DTV driver [WAS: Re: Introduction]
(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 using. 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 +time.*/ +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... cheers*hic*prost*hic*skaal*hic*nazdravie*hic* barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
