Re: [linux-dvb] Updated scan file for uk-EmleyMoor
Philip Pemberton wrote: > Here's a scan file for Emley Moor with the correct frequencies and tuning > parameters... Seems the one in the linux-dvb distribution has frequencies > with > a -133kHz or so offset, and without the correct QAM parameters. Probably my > fault, because IIRC I submitted that tuning file... > > Data sourced from www.ukfree.tv, and works fine on my HVR-3000. > > # Emley Moor, West Yorkshire > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > T 62600 8MHz 2/3 3/4 QAM64 2k 1/32 NONE > T 65000 8MHz 2/3 3/4 QAM64 2k 1/32 NONE > T 67400 8MHz 3/4 3/4 QAM16 2k 1/32 NONE > T 69800 8MHz 3/4 3/4 QAM16 2k 1/32 NONE > T 70600 8MHz 3/4 3/4 QAM16 2k 1/32 NONE > T 72200 8MHz 3/4 3/4 QAM16 2k 1/32 NONE Have you looked at the Ofcom site? You may find that the current frequencies are actually correct. Apparently all the transmitters at Emley Moor have a 166kHz offset, either + or - depending on the channel. See http://www.ofcom.org.uk/static/reception_advice/dtt_pocket_guide_3_0.pdf which lists all the UK transmitters and their offsets. www.ukfree.tv seems to ignore the offset and just include the base channel number. Generally it doesn't matter since the bandwidth of the tuner will be more than sufficient. Of course, it would be a good idea to fix the QAM parameters if they're wrong. David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Multiproto ???
Stephen Rowles wrote: >> A long time ago multiproto was said to be integrated in *near* future... >> to my great disapointment it still isn't, which is certainly not a good >> thing for the user at least... >> >> Could we hope to be *near* inclusion now ? >> >> In the meantime I am really thankfull to all who made multiproto >> available, and I hope the problems of the past could be forgiven. > > I would like to add a note to this, for those that haven't heard the BBC > will be starting a new satellite service soon, spring 08 according to > their website http://www.freesat.co.uk/home.php. > > This will be DVB-S2 transmissions including HD content, and will use the > Eurobird 1 satellite situated at 28.5° east (from what I can find on the > web). You may be right about this but so far everything I've seen suggests that Freesat will be DVB-S. I've not seen anything about DVB-S2. Do you have a reference for this? David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Hauppaug Nova T 500
Dave wrote: > > [EMAIL PROTECTED]:/home/dave# scan > /usr/share/doc/dvb-utils/examples/scan/dvb-t/uk-Craigkelly > scanning /usr/share/doc/dvb-utils/examples/scan/dvb-t/uk-Craigkelly > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > initial transponder 49000 0 2 9 3 0 3 0 > initial transponder 51400 0 2 9 1 0 3 0 > initial transponder 53800 0 2 9 3 0 3 0 > initial transponder 57000 0 2 9 1 0 3 0 > initial transponder 61800 0 2 9 1 0 3 0 > initial transponder 64200 0 2 9 1 0 3 0 > >>> tune to: > 49000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > WARNING: >>> tuning failed!!! It seems the guard interval is wrong. It should be 1/32 not 1/4. Try the file below. It worked for me just now. I have a Nova T-500 and get both Craigkelly and Black Hill. I've also adjusted a couple of the frequencies although that doesn't seem essential. David # uk Craigkelly # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 48983 8MHz 2/3 NONE QAM64 2k 1/32 NONE T 51383 8MHz 2/3 NONE QAM16 2k 1/32 NONE T 53800 8MHz 2/3 NONE QAM64 2k 1/32 NONE T 57000 8MHz 2/3 NONE QAM16 2k 1/32 NONE T 61800 8MHz 2/3 NONE QAM16 2k 1/32 NONE T 64200 8MHz 2/3 NONE QAM16 2k 1/32 NONE ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
Oliver Endriss wrote:
> Janne Grunau wrote:
>> Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
>> result in deterministic dvb adapter numbers.
>>
>> Besides following changes in dvb-core and dvb-usb core the patch adds to
>> all drivers
>> ...
>
> While I don't care much whether there is an option for this in the
> driver, I'd like to point out that this is the wrong approach (imho).
>
> Citing Greg Kroah-Hartman (udev-113/docs/udev_vs_devfs):
> |...
> |2) udev does not care about the major/minor number schemes. If the
> | kernel tomorrow switches to randomly assign major and minor numbers
> | to different devices, it would work just fine (this is exactly
> | what I am proposing to do in 2.7...)
> |3) This is the main reason udev is around. It provides the ability
> | to name devices in a persistent manner. More on that below.
> |...
>
> According to this, adding such an option is a step into the wrong
> direction. The right way is to fix the udev scripts...
I've just written udev rules for my set-up. udev may be the correct way
to do this but it is far from easy. Having the adapter number specified
as a driver option would be much simpler.
I have an Opera DVB-S USB device and a Nova T-500 containing two DVB-T
devices. Depending on whether the Opera is in warm or cold state the
kernel may number the Opera as 0 and the two Nova devices as 1 and 2 or
the Nova as 0 and 1 with the Opera as 2. For Myth, though, I want to be
sure that the Opera has a specific device (e.g. /dev/dvb/adapter7/*)
while the Nova devices have two other specific devices (e.g.
/dev/dvb/adapter0/* and /dev/dvb/adapter1/*).
Writing a udev rule to pin the Opera to a specific adapter number was
fairly easy. Since there is only a single device I could match on the
USB identifiers. The Nova, though, has two devices and these are
indistinguishable, at least from what udevinfo provides. That means
that it isn't possible to write a udev rule that would match one device
and make it /dev/dvb/adapter0 and a different rule to make the other
/dev/dvb/adapter1. I was reduced to writing a script that would detect
whether /dev/dvb/adapter{0,1} existed and if it did whether the entries
that were already in that directory had the same minor device number
divided by 64 as the minor device number of new device, divided by 64.
This was the only way to make sure that /dev/dvb/adapter0 and
/dev/dvb/adapter1 contained the correct devices and entries weren't
mixed up.
There may be another way to do this but I couldn't think of one. Maybe
the Nova device driver should be changed to ensure the two devices are
distinguishable in some way. If udev is being relied upon as the only
way to pin device entries there needs to be a library of udev rules for
each device that people can copy. Otherwise I think Janne's patch is a
sensible way to go.
David.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
