Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Wrong adapter numbering #75

Closed
manio opened this Issue Nov 5, 2012 · 14 comments

Comments

Projects
None yet
3 participants
Contributor

manio commented Nov 5, 2012

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.

Owner

pipelka commented Nov 5, 2012

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

Owner

pipelka commented Nov 6, 2012

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

Owner

pipelka commented Nov 6, 2012

BTW, device numbering now starts with 1.

Contributor

manio commented Nov 7, 2012

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

Owner

pipelka commented Nov 8, 2012

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

Contributor

manio commented Nov 8, 2012

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...

Contributor

manio commented Nov 11, 2012

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.

Owner

pipelka commented Nov 11, 2012

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

Contributor

manio commented Nov 11, 2012

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...

Owner

pipelka commented Nov 11, 2012

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.

Contributor

manio commented Nov 12, 2012

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

@pipelka pipelka closed this in 69ee531 Nov 15, 2012

Contributor

manio commented Nov 15, 2012

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.

Owner

pipelka commented Nov 15, 2012

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment