search

pipelka / vdr-plugin-xvdr

DISCONTINUED - XVDR Plugin for VDR
GNU General Public License v2.0
43 stars 21 forks source link

Wrong adapter numbering #75

Closed manio closed 11 years ago

manio commented 11 years ago

Hi Alex! As you know we have "Receive device" section in xbmc (enabled with 'o' key). This is the same info as with signal information. I have two adapters. Unfortunatelly the device number is not always correctly returned, because when i have running vdr without extra parameters then I always have receiving device as: DVB-S2 #0 Maybe it is because according to the documentation: ActualDevice() Returns the actual receiving device in case of Transfer Mode, or the primary device otherwise. i am aware of the "otherwise" :) When i am starting vdr with -D0 parameter then the device is DVB-S2 #0, when starting with -D1 then it is DVB-S2 #1, so this is correct. The problem is only when two devices are available. The simple test I've done was started recording of different transponders to make two devices busy. Then i was switching to these different channels in xbmc (during recording) and see what info brings. Do you think that you'll be able to fill this info with the correct one receiving device?

Just by the way: I can see that in vdr sources near line skinsttng.c:345 is obtained the receiving device numer, signal strength and quality.

pipelka commented 11 years ago

This would be a good opportunity for me to switch to the new VDR signal-strength API, ... On my list, now.

pipelka commented 11 years ago

Please check if 42df748 fixes this for you (branch "status").

pipelka commented 11 years ago

BTW, device numbering now starts with 1.

manio commented 11 years ago

Oh yes, now the adapter indexing seems to be ok (i have #1 and #2) so everything seems to be in order :) I cannot see the signal quality and viterbi/lock/etc statuses though, take a look: http://skyboo.net/xbmc/shot-2012-11-07_16-41-27.png

pipelka commented 11 years ago

Seems VDR can't read the signal quality from your card. Are you using 1.7.31 ?

manio commented 11 years ago

Hi, yes it is vdr 1.7.31. Can i somehow see those values in vdr itself?, eg via some menu, ofc without femon plugin...

tmn505 commented 11 years ago

Yes, You can. Since version 1.7.28: http://www.linuxtv.org/pipermail/vdr/2012-June/026391.html.

manio commented 11 years ago

Oh i saw this in LCARS but only when i was testing on TT1.3 card. This information are probably not exposed to my skincurses plugin so i don't see it. I am not currently using graphical vdr frontend, only xbmc ;) Ok - I'll try to put a debug in vdr to print those values somewhere, then I'll let you know about the results.

pipelka commented 11 years ago

Maybe your driver / kernel version doesn't support this, ...

manio commented 11 years ago

I have to dig into it, one way or another - this is how it looks before (your master branch): http://skyboo.net/xbmc/screenshot272.png but i did not test what values i've got from vdr interface, i'll try to figure it out when i have some time...

pipelka commented 11 years ago

Yes. I know. I want to use the generic VDR interface for this. Before, every type of device was queried differently. This is now unified.

manio commented 11 years ago

I've put a simple debug (INFOLOG("Device=%d, Strength=%d, Quality=%d", DeviceNumber, Strength, Quality)) and the results are: XVDR: Device=1, Strength=60, Quality=-1 and are identical with every call - so it seems the problem sits in vdr

In the same time I've got this when running femon:

FE: STV090x Multistandard (DVBS)
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 9abd | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 9a33 | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 9a0d | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 998a | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 994d | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 9b0a | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9c28 | snr 9b94 | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9c28 | snr 9adc | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 9a3b | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9c28 | snr 9bba | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 9a52 | ber 00000000 | unc 00401586 | FE_HAS_LOCK
Problem retrieving frontend information: Inappropriate ioctl for device
status SCVYL | signal 9999 | snr 99df | ber 00000000 | unc 00401586 | FE_HAS_LOCK
manio commented 11 years ago

Thanks! I think you may consider also merging the status branch, it will be much simpler if you just use the value provided by vdr instead of fetching it in the plugin. I hope that currently problems with Quality in case of my driver should be solved, one way or another it will be a vdr issue, not your plugin :)

btw: i was analyzing my logs and i can see that my Strength is changing (64, 65, 66) - before i was thinking that it is constant.

pipelka commented 11 years ago

I will do that ;-) I just let it settle some time.