* HVR-900H dvb-t regression(s)
@ 2011-11-28 14:41 Fabio M. Di Nitto
2011-11-28 21:07 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 6+ messages in thread
From: Fabio M. Di Nitto @ 2011-11-28 14:41 UTC (permalink / raw)
To: LMML, Mauro Chehab, Stefan Ringel
Hi all,
short summary is that dvb-t on $subject doesn´t work with head of the
tree (for_3.3 branch) and scan or mplayer stop working.
Here is the breakdown of what I found with all logs. Please let me know
if you need any extra info. Can easily test patches and gather more logs
if necessary.
Also please note that I am no media guru of any kind. I had to work on
some assumptions from time to time.
Based on git bisect:
The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004
The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb
commit f010dca2e52d8dcc0445d695192df19241afacdb
Author: Stefan Ringel <stefan.ringel@arcor.de>
Date: Mon May 9 16:53:58 2011 -0300
[media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask
move from tm6000_set_reg to tm6000_set_reg_mask
Signed-off-by: Stefan Ringel <stefan.ringel@arcor.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While this commit appears rather innocent, it changes the way some
registries are set.
the original code did:
read_reg...
change value
write_reg.. (unconditionally)
the new code path:
read_reg...
calculate new value
check if it is same
if not, write_reg...
So I did the simplest test as possible by removing the conditional in
tm6000_set_reg_mask and dvb-t started working again.
something along those lines:
diff --git a/drivers/media/video/tm6000/tm6000-core.c
b/drivers/media/video/tm6000/tm6000-core.c
index 9783616..818f542 100644
--- a/drivers/media/video/tm6000/tm6000-core.c
+++ b/drivers/media/video/tm6000/tm6000-core.c
@@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8
req, u16 value,
new_index = (buf[0] & ~mask) | (index & mask);
- if (new_index == index)
- return 0;
+// if (new_index == index)
+// return 0;
return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR,
req, value, new_index, NULL, 0);
but moving this change to the HEAD of for_v3.3 doesn´t solve the
problem, possibly hinting to multiple regressions in the driver but at
this point I am slightly lost because i can´t figure out what else is
wrong. Some semi-random git bisect didn´t bring me anywhere useful at
this point.
In an poor attempt to be a good boy, I collected all the data here:
http://fabbione.fedorapeople.org/dvblogs.tar.xz
(NOTE: 76MB file, 101MB unpacked)
The file contains 5 dirs:
last-known-good-e872bb9a7ddfc025ed727cc922b0aa32a7582004
first-known-bad-f010dca2e52d8dcc0445d695192df19241afacdb
test1-change-set-reg-mask-f010dca2e52d8dcc0445d695192df19241afacdb+
head-known-bad-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1
test2-change-set-reg-mask-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1+
and each directory has:
dmesg
scan_results
tcpdump (tcpdump -i usbmod1 -w tcpdump)
usbmon0u (cat /sys.... > usbmod0u)
captures are started before modprobe tm6000-dvb and stop after a "scan
-a 0 dk"
The testX are marked "+" as they contain the workaround mentioned above
(test1 also adds a build workaround fixed a few commits later in the
tree to unexport a symbol).
Thanks
Fabio
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: HVR-900H dvb-t regression(s)
2011-11-28 14:41 HVR-900H dvb-t regression(s) Fabio M. Di Nitto
@ 2011-11-28 21:07 ` Mauro Carvalho Chehab
2011-11-29 4:53 ` Fabio M. Di Nitto
2011-11-29 11:49 ` Fabio M. Di Nitto
0 siblings, 2 replies; 6+ messages in thread
From: Mauro Carvalho Chehab @ 2011-11-28 21:07 UTC (permalink / raw)
To: Fabio M. Di Nitto; +Cc: LMML, Stefan Ringel, Dmitri Belimov
On 28-11-2011 12:41, Fabio M. Di Nitto wrote:
> Hi all,
>
> short summary is that dvb-t on $subject doesn´t work with head of the
> tree (for_3.3 branch) and scan or mplayer stop working.
>
> Here is the breakdown of what I found with all logs. Please let me know
> if you need any extra info. Can easily test patches and gather more logs
> if necessary.
>
> Also please note that I am no media guru of any kind. I had to work on
> some assumptions from time to time.
>
> Based on git bisect:
>
> The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004
>
> The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb
>
> commit f010dca2e52d8dcc0445d695192df19241afacdb
> Author: Stefan Ringel<stefan.ringel@arcor.de>
> Date: Mon May 9 16:53:58 2011 -0300
>
> [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask
>
> move from tm6000_set_reg to tm6000_set_reg_mask
>
> Signed-off-by: Stefan Ringel<stefan.ringel@arcor.de>
> Signed-off-by: Mauro Carvalho Chehab<mchehab@redhat.com>
>
> While this commit appears rather innocent, it changes the way some
> registries are set.
>
> the original code did:
>
> read_reg...
> change value
> write_reg.. (unconditionally)
>
> the new code path:
>
> read_reg...
> calculate new value
> check if it is same
> if not, write_reg...
>
> So I did the simplest test as possible by removing the conditional in
> tm6000_set_reg_mask and dvb-t started working again.
>
> something along those lines:
>
> diff --git a/drivers/media/video/tm6000/tm6000-core.c
> b/drivers/media/video/tm6000/tm6000-core.c
> index 9783616..818f542 100644
> --- a/drivers/media/video/tm6000/tm6000-core.c
> +++ b/drivers/media/video/tm6000/tm6000-core.c
> @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8
> req, u16 value,
>
> new_index = (buf[0]& ~mask) | (index& mask);
>
> - if (new_index == index)
> - return 0;
> +// if (new_index == index)
> +// return 0;
>
> return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR,
> req, value, new_index, NULL, 0);
>
> but moving this change to the HEAD of for_v3.3 doesn´t solve the
> problem, possibly hinting to multiple regressions in the driver but at
> this point I am slightly lost because i can´t figure out what else is
> wrong. Some semi-random git bisect didn´t bring me anywhere useful at
> this point.
Hmm... It occurred to me that HVR-900H has a bug at device initialization.
Sometimes, after a device connect it can't read anything from eeprom. As result,
it will print:
[ 7867.776612] tm6000: Found Generic tm6010 board
[ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7867.958753] tm6000 #1: i2c eeprom 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7868.075698] tm6000 #1: i2c eeprom 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7868.193607] tm6000 #1: i2c eeprom 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7868.310546] tm6000 #1: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7868.427507] tm6000 #1: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7868.544442] tm6000 #1: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7868.662375] tm6000 #1: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7868.779319] tm6000 #1: i2c eeprom 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7868.896238] tm6000 #1: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7869.013195] tm6000 #1: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7869.130135] tm6000 #1: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7869.247069] tm6000 #1: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7869.363981] tm6000 #1: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7869.480948] tm6000 #1: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7869.597884] tm6000 #1: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 7869.707769] Device has eeprom but is currently unknown
and the device will be miss-detected.
You can fix it by forcing the driver to use "card=9" via modprobe option.
Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the
audio issue with HVR-900H on analog mode.
>
> In an poor attempt to be a good boy, I collected all the data here:
> http://fabbione.fedorapeople.org/dvblogs.tar.xz
> (NOTE: 76MB file, 101MB unpacked)
>
> The file contains 5 dirs:
>
> last-known-good-e872bb9a7ddfc025ed727cc922b0aa32a7582004
> first-known-bad-f010dca2e52d8dcc0445d695192df19241afacdb
> test1-change-set-reg-mask-f010dca2e52d8dcc0445d695192df19241afacdb+
> head-known-bad-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1
> test2-change-set-reg-mask-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1+
>
> and each directory has:
>
> dmesg
> scan_results
> tcpdump (tcpdump -i usbmod1 -w tcpdump)
> usbmon0u (cat /sys....> usbmod0u)
>
> captures are started before modprobe tm6000-dvb and stop after a "scan
> -a 0 dk"
>
> The testX are marked "+" as they contain the workaround mentioned above
> (test1 also adds a build workaround fixed a few commits later in the
> tree to unexport a symbol).
>
> Thanks
> Fabio
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-900H dvb-t regression(s)
2011-11-28 21:07 ` Mauro Carvalho Chehab
@ 2011-11-29 4:53 ` Fabio M. Di Nitto
2011-11-29 11:35 ` Mauro Carvalho Chehab
2011-11-29 11:49 ` Fabio M. Di Nitto
1 sibling, 1 reply; 6+ messages in thread
From: Fabio M. Di Nitto @ 2011-11-29 4:53 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: LMML, Stefan Ringel, Dmitri Belimov
On 11/28/2011 10:07 PM, Mauro Carvalho Chehab wrote:
> On 28-11-2011 12:41, Fabio M. Di Nitto wrote:
>> Hi all,
>>
>> short summary is that dvb-t on $subject doesn´t work with head of the
>> tree (for_3.3 branch) and scan or mplayer stop working.
>>
>> Here is the breakdown of what I found with all logs. Please let me know
>> if you need any extra info. Can easily test patches and gather more logs
>> if necessary.
>>
>> Also please note that I am no media guru of any kind. I had to work on
>> some assumptions from time to time.
>>
>> Based on git bisect:
>>
>> The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004
>>
>> The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb
>>
>> commit f010dca2e52d8dcc0445d695192df19241afacdb
>> Author: Stefan Ringel<stefan.ringel@arcor.de>
>> Date: Mon May 9 16:53:58 2011 -0300
>>
>> [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask
>>
>> move from tm6000_set_reg to tm6000_set_reg_mask
>>
>> Signed-off-by: Stefan Ringel<stefan.ringel@arcor.de>
>> Signed-off-by: Mauro Carvalho Chehab<mchehab@redhat.com>
>>
>> While this commit appears rather innocent, it changes the way some
>> registries are set.
>>
>> the original code did:
>>
>> read_reg...
>> change value
>> write_reg.. (unconditionally)
>>
>> the new code path:
>>
>> read_reg...
>> calculate new value
>> check if it is same
>> if not, write_reg...
>>
>> So I did the simplest test as possible by removing the conditional in
>> tm6000_set_reg_mask and dvb-t started working again.
>>
>> something along those lines:
>>
>> diff --git a/drivers/media/video/tm6000/tm6000-core.c
>> b/drivers/media/video/tm6000/tm6000-core.c
>> index 9783616..818f542 100644
>> --- a/drivers/media/video/tm6000/tm6000-core.c
>> +++ b/drivers/media/video/tm6000/tm6000-core.c
>> @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8
>> req, u16 value,
>>
>> new_index = (buf[0]& ~mask) | (index& mask);
>>
>> - if (new_index == index)
>> - return 0;
>> +// if (new_index == index)
>> +// return 0;
>>
>> return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR,
>> req, value, new_index, NULL, 0);
>>
>> but moving this change to the HEAD of for_v3.3 doesn´t solve the
>> problem, possibly hinting to multiple regressions in the driver but at
>> this point I am slightly lost because i can´t figure out what else is
>> wrong. Some semi-random git bisect didn´t bring me anywhere useful at
>> this point.
>
> Hmm... It occurred to me that HVR-900H has a bug at device initialization.
> Sometimes, after a device connect it can't read anything from eeprom. As
> result,
> it will print:
>
> [ 7867.776612] tm6000: Found Generic tm6010 board
> [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 ................
[SNIP]
> [ 7869.707769] Device has eeprom but is currently unknown
>
> and the device will be miss-detected.
I don't think this was ever the case, but I can easily check the dmesg
output that I collected.
>
> You can fix it by forcing the driver to use "card=9" via modprobe option.
>
> Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the
> audio issue with HVR-900H on analog mode.
Ok, I'll try to grab them. It appears that mail relay from linux-media
to my inbox is not reliable.
As for the analog, I should be able to test it today.
Fabio
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-900H dvb-t regression(s)
2011-11-29 4:53 ` Fabio M. Di Nitto
@ 2011-11-29 11:35 ` Mauro Carvalho Chehab
2011-11-29 11:51 ` Fabio M. Di Nitto
0 siblings, 1 reply; 6+ messages in thread
From: Mauro Carvalho Chehab @ 2011-11-29 11:35 UTC (permalink / raw)
To: Fabio M. Di Nitto; +Cc: LMML, Stefan Ringel, Dmitri Belimov
On 29-11-2011 02:53, Fabio M. Di Nitto wrote:
> On 11/28/2011 10:07 PM, Mauro Carvalho Chehab wrote:
>> On 28-11-2011 12:41, Fabio M. Di Nitto wrote:
>>> Hi all,
>>>
>>> short summary is that dvb-t on $subject doesn´t work with head of the
>>> tree (for_3.3 branch) and scan or mplayer stop working.
>>>
>>> Here is the breakdown of what I found with all logs. Please let me know
>>> if you need any extra info. Can easily test patches and gather more logs
>>> if necessary.
>>>
>>> Also please note that I am no media guru of any kind. I had to work on
>>> some assumptions from time to time.
>>>
>>> Based on git bisect:
>>>
>>> The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004
>>>
>>> The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb
>>>
>>> commit f010dca2e52d8dcc0445d695192df19241afacdb
>>> Author: Stefan Ringel<stefan.ringel@arcor.de>
>>> Date: Mon May 9 16:53:58 2011 -0300
>>>
>>> [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask
>>>
>>> move from tm6000_set_reg to tm6000_set_reg_mask
>>>
>>> Signed-off-by: Stefan Ringel<stefan.ringel@arcor.de>
>>> Signed-off-by: Mauro Carvalho Chehab<mchehab@redhat.com>
>>>
>>> While this commit appears rather innocent, it changes the way some
>>> registries are set.
>>>
>>> the original code did:
>>>
>>> read_reg...
>>> change value
>>> write_reg.. (unconditionally)
>>>
>>> the new code path:
>>>
>>> read_reg...
>>> calculate new value
>>> check if it is same
>>> if not, write_reg...
>>>
>>> So I did the simplest test as possible by removing the conditional in
>>> tm6000_set_reg_mask and dvb-t started working again.
>>>
>>> something along those lines:
>>>
>>> diff --git a/drivers/media/video/tm6000/tm6000-core.c
>>> b/drivers/media/video/tm6000/tm6000-core.c
>>> index 9783616..818f542 100644
>>> --- a/drivers/media/video/tm6000/tm6000-core.c
>>> +++ b/drivers/media/video/tm6000/tm6000-core.c
>>> @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8
>>> req, u16 value,
>>>
>>> new_index = (buf[0]& ~mask) | (index& mask);
>>>
>>> - if (new_index == index)
>>> - return 0;
>>> +// if (new_index == index)
>>> +// return 0;
>>>
>>> return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR,
>>> req, value, new_index, NULL, 0);
>>>
>>> but moving this change to the HEAD of for_v3.3 doesn´t solve the
>>> problem, possibly hinting to multiple regressions in the driver but at
>>> this point I am slightly lost because i can´t figure out what else is
>>> wrong. Some semi-random git bisect didn´t bring me anywhere useful at
>>> this point.
>>
>> Hmm... It occurred to me that HVR-900H has a bug at device initialization.
>> Sometimes, after a device connect it can't read anything from eeprom. As
>> result,
>> it will print:
>>
>> [ 7867.776612] tm6000: Found Generic tm6010 board
>> [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 ................
> [SNIP]
>> [ 7869.707769] Device has eeprom but is currently unknown
>>
>> and the device will be miss-detected.
>
> I don't think this was ever the case, but I can easily check the dmesg
> output that I collected.
This may affect your bisect tests.
>> You can fix it by forcing the driver to use "card=9" via modprobe option.
>>
>> Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the
>> audio issue with HVR-900H on analog mode.
>
> Ok, I'll try to grab them. It appears that mail relay from linux-media
> to my inbox is not reliable.
I've applied them yesterday.
> As for the analog, I should be able to test it today.
On the tests I've made yesterday after applying Stefan and my patches,
analog is working fine. Audio got corrected by the patches for MSC
(the audio standard used on NTSC and PAL-M). I tested here with both NTSC
and PAL-M standards, and it worked as expected.
There are some fixes applied yesterday that are related to DTV. One of them
fixes the alloc function call used for the DVB streaming buffer inside the
USB stack:
- ret = usb_submit_urb(dvb->bulk_urb, GFP_KERNEL);
+ ret = usb_submit_urb(dvb->bulk_urb, GFP_ATOMIC);
The usage of GFP_KERNEL there may fail, causing failures at the DVB stream.
I'm now seeing if I can make the IR work on HVR-900H.
Regards,
Mauro
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-900H dvb-t regression(s)
2011-11-29 11:35 ` Mauro Carvalho Chehab
@ 2011-11-29 11:51 ` Fabio M. Di Nitto
0 siblings, 0 replies; 6+ messages in thread
From: Fabio M. Di Nitto @ 2011-11-29 11:51 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Fabio M. Di Nitto, LMML, Stefan Ringel, Dmitri Belimov
On 11/29/2011 12:35 PM, Mauro Carvalho Chehab wrote:
> On 29-11-2011 02:53, Fabio M. Di Nitto wrote:
>>> [ 7867.776612] tm6000: Found Generic tm6010 board
>>> [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00
>>> 00 00 00 00 00 00 ................
>> [SNIP]
>>> [ 7869.707769] Device has eeprom but is currently unknown
>>>
>>> and the device will be miss-detected.
>>
>> I don't think this was ever the case, but I can easily check the dmesg
>> output that I collected.
>
> This may affect your bisect tests.
The eeprom was never 00 all the way.
>
>>> You can fix it by forcing the driver to use "card=9" via modprobe
>>> option.
>>>
>>> Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the
>>> audio issue with HVR-900H on analog mode.
>>
>> Ok, I'll try to grab them. It appears that mail relay from linux-media
>> to my inbox is not reliable.
>
> I've applied them yesterday.
tested them already, I sent the results in another email.
>
>> As for the analog, I should be able to test it today.
>
> On the tests I've made yesterday after applying Stefan and my patches,
> analog is working fine. Audio got corrected by the patches for MSC
> (the audio standard used on NTSC and PAL-M). I tested here with both NTSC
> and PAL-M standards, and it worked as expected.
>
> There are some fixes applied yesterday that are related to DTV. One of them
> fixes the alloc function call used for the DVB streaming buffer inside the
> USB stack:
>
> - ret = usb_submit_urb(dvb->bulk_urb, GFP_KERNEL);
> + ret = usb_submit_urb(dvb->bulk_urb, GFP_ATOMIC);
>
> The usage of GFP_KERNEL there may fail, causing failures at the DVB stream.
>
> I'm now seeing if I can make the IR work on HVR-900H.
No luck with analog here, but I need to do more investigation as the
source might be broken all together.
Fabio
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-900H dvb-t regression(s)
2011-11-28 21:07 ` Mauro Carvalho Chehab
2011-11-29 4:53 ` Fabio M. Di Nitto
@ 2011-11-29 11:49 ` Fabio M. Di Nitto
1 sibling, 0 replies; 6+ messages in thread
From: Fabio M. Di Nitto @ 2011-11-29 11:49 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Fabio M. Di Nitto, LMML, Stefan Ringel, Dmitri Belimov
On 11/28/2011 10:07 PM, Mauro Carvalho Chehab wrote:
> Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the
> audio issue with HVR-900H on analog mode.
I just finished testing those ones and they seem to fix my specific issue.
There is still one thing that puzzles me, but maybe it´s just my
misunderstanding on how dvb-t protocol works.
> root@cerberus:~# scan -a 0 /home/fabbione/dk
> scanning /home/fabbione/dk
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> initial transponder 586000000 0 2 9 3 1 3 0
>>>> tune to: 586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE
> 0x0000 0x0065: pmt_pid 0x0065 DR -- DR1 (running)
> 0x0000 0x00d9: pmt_pid 0x0835 TV 2 -- TV 2 (Lorry) (running)
> 0x0000 0x01a1: pmt_pid 0x0191 DIGI-TV -- Hovedstaden (running)
> 0x0000 0x0066: pmt_pid 0x00c9 DR -- DR2 (running)
> 0x0000 0x006f: pmt_pid 0x0068 DR -- DR Synstolkning (running)
> 0x0000 0x0051: pmt_pid 0x0051 DIGI-TV -- OAD MUX1 (running)
> Network Name 'Mux1 kbhv-glx'
>>>> tune to: 730000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x0000
> WARNING: filter timeout pid 0x0010
> dumping lists (6 services)
> OAD MUX1:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:81
> DR1:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:111:121:101
> DR2:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:211:221:102
> DR Synstolkning:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:111:122:111
> TV 2 (Lorry):586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2111:2121:217
> Hovedstaden:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:411:421:417
> Done.
In my dk file I only specify:
> root@cerberus:~# cat /home/fabbione/dk
> # Denmark, whole country
> # Created from http://www.digi-tv.dk/Indhold_og_tilbud/frekvenser.asp
> # and http://www.digi-tv.dk/Sendenettets_opbygning/
> # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
> T 586000000 8MHz 2/3 NONE QAM64 8k 1/4 NONE
because for simple testing I don´t need to scan the whole spectrum.
Now, in some versions of the driver, it automatically picks up 730MHz (I
know it´s a good frequency in the area as I get it at my home and shares
the same channels as 586).
What I noticed is that sometimes it tunes and time outs, sometime it
tunes and scan correctly, but with the latest driver from HEAD, it
failed completely to tune with the usual error.
Not sure if this info might be relevant.
As for analog I am not able to even get scantv to find the channel
broadcasted from the VCR. I´ll need to investigate if it´s a problem
with the VCR/tuner/driver etc. (there is no analog broadcast in dk).
So far this is what I get:
> scantv -n PAL-DK -f europe-west -c /dev/video0 -C /dev/null
> [global]
> freqtab = europe-west
>
> [defaults]
> input = Television
> norm = PAL-DK
>
> ioctl: VIDIOC_S_CTRL(id=9963778;value=0): Inappropriate ioctl for device
> ioctl: VIDIOC_S_CTRL(id=9963776;value=0): Inappropriate ioctl for device
> ioctl: VIDIOC_S_CTRL(id=9963779;value=0): Inappropriate ioctl for device
> ioctl: VIDIOC_S_CTRL(id=9963777;value=130): Inappropriate ioctl for device
> scanning channel list europe-west...
> E2 ( 48.25 MHz): ioctl: VIDIOC_S_CTRL(id=9963785;value=1): Inappropriate ioctl for device
> ioctl: VIDIOC_S_CTRL(id=9963785;value=0): Inappropriate ioctl for device
> no station
(repeat the above for every single channel and no channels found)
The result is pretty much the same with or without tm6000-dvb loaded.
Fabio
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-11-29 11:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-28 14:41 HVR-900H dvb-t regression(s) Fabio M. Di Nitto
2011-11-28 21:07 ` Mauro Carvalho Chehab
2011-11-29 4:53 ` Fabio M. Di Nitto
2011-11-29 11:35 ` Mauro Carvalho Chehab
2011-11-29 11:51 ` Fabio M. Di Nitto
2011-11-29 11:49 ` Fabio M. Di Nitto
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.