Il 13/01/2012 12:21, Mauro Carvalho Chehab ha scritto:
> Em 12-01-2012 14:22, Gianluca Gennari escreveu:
>> Il 11/01/2012 20:19, Jim Darby ha scritto:
>>> On 11/01/12 01:05, Antti Palosaari wrote:
>>>> [snip]
>>>> Also latest LinuxTV.org devel could be interesting to see. There is
>>>> one patch that changes em28xx driver endpoint configuration. But as
>>>> that patch is going for 3.3 it should not be cause of issue, but I
>>>> wonder if it could fix... Use media_build.git if possible.
>>>
>>> Well, I built the kernel and installed it. Sadly I get entries of the
>>> form: "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3
>>> call to delivery system 0" which isn't what I was looking for. I guess
>>> there's a new API? It would appear this is from the set frontend call.
>>>
>>> This is most annoying as I'd like to try out the newest code.
>>>
>>> Is there a v3 to v3 transition document anywhere?
>>>
>>> Best regards,
>>>
>>> Jim.
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Hi Jim,
>> you spotted a regression in the latest media_build release from
>> 11/01/2012.
>> I had the same problem here:
>>
>> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>> delivery system 0"
>>
>> with 3 totally different sticks (em28xx, dvb-usb, as102).
>>
>> Everything was working fine with media_build drivers from 08/01/2011, so
>> the problem originates from a patch committed in the last few days.
>>
>> In fact, I reverted this patch:
>>
>> http://patchwork.linuxtv.org/patch/9443/
>>
>> and Kaffeine started working again with all my DVB-T sticks.
> 
> Hmm... this patch shouldn't be causing troubles for an application that
> only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with 
> SYS_UNDEFINED (0)?
> 
> If so, then Kaffeine has a bug, as it is requesting a non-existent
> delivery system.
> 
> Could you please turn on the dvb-core debug, and see if it is trying to
> do a DVBv5 call with DTV_DELIVERY_SYSTEM?
> 
> Thanks,
> Mauro
> 
>>
>> Best regards,
>> Gianluca
> 
> 

Hi Mauro,
I don't think Kaffeine is (intentionally) messing up with the delivery
system.
But maybe the issue I've reported is related to this other one.

Maybe you remember that I reported a problem on the xc2028 tuner that
was reloading all the firmwares each time a new frequency is tuned.
As a consequence, the time to switch to a new channel was much higher
that usual.

I tracked down the problem to the fact that the xc2028 is put in
power-off mode and then immediately woken-up each time Kaffeine sets a
new frequency.

I investigated the issue a bit deeper (enabling debugging also in the
dvb-core) and this is what I discovered:

[ 1635.878002] dvb_frontend_release
[ 1635.878029] xc2028 9-0061: Putting xc2028/3028 into poweroff mode.
[ 1635.878041] dvb_frontend_open
[ 1635.939253] dvb_frontend_start
[ 1635.939326] dvb_frontend_thread
[ 1635.939332] DVB: initialising adapter 0 frontend 0 (Zarlink ZL10353
DVB-T)...
[ 1635.939504] dvb_frontend_ioctl (76)
[ 1635.942896] set_delivery_system() Using delivery system to 3

So the frontend is released and then reinitialized each time a new
frequency is tuned. This strange behavior was introduced with the
conversion of drivers to the DVBv5 API; before, the frontend was
initialized just one time.

This happens with all drivers: I reproduced the same issue with a stick
using the as102 driver (which is completely different from the
em28xx-dvb driver).

Here is the relevant part of the log:

[ 2339.647230] dvb_frontend_release
[ 2339.656954] dvb_frontend_open
[ 2339.665675] dvb_frontend_start
[ 2339.665872] dvb_frontend_thread
[ 2339.665878] DVB: initialising adapter 0 frontend 0 (Sky IT Digital
Key (green led))...
[ 2339.666049] dvb_frontend_ioctl (76)
[ 2339.666053] set_delivery_system() Using delivery system to 3
[ 2339.666057] dtv_property_cache_sync() Preparing OFDM req
[ 2339.666060] dvb_frontend_add_event

I'm attaching a longer log file with 2 consecutive channel switches for
each of the 2 drivers.

I have no idea if this is a bug in Kaffeine that is triggered by the new
DVBv3 emulation logic, or a bug in the emulation logic itself.

Best regards,
Gianluca