You are not logged in.

[Tester gesucht] Verbessertes DVB-S Tuning mit STB0899 Satkarten (Mantis Bridge, u.a.)

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

newsy

Intermediate

Posts: 298

  • Send private message

21

Monday, September 13th 2010, 10:40pm

hier meine Ergebnisse (Astra only, bin Rotor User)

TT S2-3200:

Quoted


reading channels from file './Astra_only.txt'
...
lok_errs =0, runs=1207 of sequ=3333, multi=0, multi_max=0

real 19m5.371s
user 0m0.116s
sys 0m15.225s


Quoted

Original von dimsa
I have tried your patch, and it works much better than before.
I have moving dish, and one of my biggest problem is rotating the dish on channel change. With your patch it is much better, but it is still not perfect, when I switch from FTA on one satellite to any channel on other satellite using VDR it now rotates the dish perfectly, however from coded channel to any other it does not.

I will provide Astra only test results as soon as possible, but I can not test Astra+Hotbird use the moving dish.
Is there any way to run the test using diseqc 1.2?

how do you rotate your dish? with rotor plugin or with the vdr patch?

Quoted

Original von dimsa
off the topic, I have also applied the stb0899_signal_strength_v3.patch which finally seems to provide some meaningful numbers, however I don't think that are quite correct, since they give very different results for dvb-s and dvb-s2 chanels on same satelite

Thank you for testing. I also think those values are not 100 % correct, but I think this patch is still very useful, without it you are not able to align a dish correctly, now you can and as long more signal means a higher value everything is fine. But if 100 % correct values are needed a professional measuring equipment is necessary.

dimsa

Beginner

Posts: 22

  • Send private message

22

Monday, September 13th 2010, 10:54pm

For the rotation of the dish I use the built in VDR functionality with diseqc.conf without any patch. I use rotor for setting of positions, however I will now test it using rotor for rotation.
What I have noticed so far is that if I'm on an encrypted channel I can not rotate the dish manually using rotor. I can do that when I'm on FTA.
Before this patch, even on FTA it was very random so I used another receiver.

Lou

Professional

  • "Lou" started this thread

Posts: 887

  • Send private message

23

Monday, September 13th 2010, 11:17pm

Here is a quick howto how I created and customized channel lists if anyone plans to add different satellites:

Source code

 
1
2
3
4
5
6
7

#scanning using scan-s2
scan-s2 -s [DISEQC OUT] -t 3 -o zap -n -I 50 /usr/local/share/dvb/dvb-s/Astra-19.2E >astra.conf
#separate DVB-S / DVB-S2:
grep :5$ astra.conf >astra_dvbs.conf
grep :6$ astra.conf >astra_dvbs2.conf
#randomize
sort -R -t : -k 2 astra_dvbs.conf >astra_dvbs_randomized.conf

Edit1: added scan.tar.bz2 with the scan-s2 binary + transponder lists + rotor.conf
Edit2: inside you will also find HB_random.tar.bz2 for those who like to test hotbird_only using zap/ezap2
Lou has attached the following file:
  • scan.tar.bz2 (72.22 kB - 115 times downloaded - latest: Mar 31st 2013, 3:43pm)
MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

This post has been edited 1 times, last edit by "Lou" (Sep 14th 2010, 11:43am)

newsy

Intermediate

Posts: 298

  • Send private message

24

Tuesday, September 14th 2010, 12:02am

Quoted

Original von dimsa
For the rotation of the dish I use the built in VDR functionality with diseqc.conf without any patch. I use rotor for setting of positions, however I will now test it using rotor for rotation.
What I have noticed so far is that if I'm on an encrypted channel I can not rotate the dish manually using rotor. I can do that when I'm on FTA.
Before this patch, even on FTA it was very random so I used another receiver.




I think the problem is the 22khz signal for LOW / HIGH band. It always has to be enabled (or was it disabled, I don't remember) before a DISEqC signal can be sent, just another bug of TT s2-3200 or its driver.

2 of the following cases of channel switching didn't move the dish:

1)Satellite 1 low band -> Satellite 2 high band
2)Satellite 1 high band -> Satellite 2 low band
3)Satellite 1 low band -> Satellite 2 low band
4)Satellite 1 high band -> Satellite 2 high band

So you should try it with this patched rotor version rotor-0.1.4mh-v1.2
This version does have this issue fixed.

MarMic

Intermediate

Posts: 446

  • Send private message

25

Tuesday, September 14th 2010, 9:35am

Quoted

Original von newsy
hier meine Ergebnisse (Astra only, bin Rotor User)

TT S2-3200:

Quoted


reading channels from file './Astra_only.txt'
...
lok_errs =0, runs=1207 of sequ=3333, multi=0, multi_max=0

real 19m5.371s
user 0m0.116s
sys 0m15.225s


hi newsy,

sau gute werte! hast du mal zufällig vor den änderungen gescannt? wäre intressant.

greetz
SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-3.0.1

WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-3.0.1

SDVDR: Dell Optiplex GX150: P3 1Ghz - 256Mb Ram - 20Gb HDD - Technotrend Premium C-2300 Hybrid - KabelBW - MLD-2.0.0 @Eltern

dimsa

Beginner

Posts: 22

  • Send private message

26

Tuesday, September 14th 2010, 1:09pm

Quoted

Originally posted by newsy

Quoted

Original von dimsa
For the rotation of the dish I use the built in VDR functionality with diseqc.conf without any patch. I use rotor for setting of positions, however I will now test it using rotor for rotation.
What I have noticed so far is that if I'm on an encrypted channel I can not rotate the dish manually using rotor. I can do that when I'm on FTA.
Before this patch, even on FTA it was very random so I used another receiver.




I think the problem is the 22khz signal for LOW / HIGH band. It always has to be enabled (or was it disabled, I don't remember) before a DISEqC signal can be sent, just another bug of TT s2-3200 or its driver.

2 of the following cases of channel switching didn't move the dish:

1)Satellite 1 low band -> Satellite 2 high band
2)Satellite 1 high band -> Satellite 2 low band
3)Satellite 1 low band -> Satellite 2 low band
4)Satellite 1 high band -> Satellite 2 high band

So you should try it with this patched rotor version rotor-0.1.4mh-v1.2
This version does have this issue fixed.


Thank you very much for the information. I have already used this version of rotor that you mentioned when I tested in my previous post, however I was using the old patch for VDR rotor.
The functionality that you mentioned was actually in the patch provided with rotor-0.1.4mh-v1.2.
After applying the correct patch, finally my card works as it should. Thanks again.

newsy

Intermediate

Posts: 298

  • Send private message

27

Tuesday, September 14th 2010, 1:47pm

Quoted


Original von dimsa
Thank you very much for the information. I have already used this version of rotor that you mentioned when I tested in my previous post, however I was using the old patch for VDR rotor.
The functionality that you mentioned was actually in the patch provided with rotor-0.1.4mh-v1.2.
After applying the correct patch, finally my card works as it should. Thanks again.

great you also got it working. You're welcome

Quoted

Original von MarMic
hi newsy,

sau gute werte! hast du mal zufällig vor den änderungen gescannt? wäre intressant.

greetz


ich war auch sehr von den guten Werten überrascht. Doch nur kam die Ernüchterung
irgendwie zeigt sich kaum ein unterschied :(

mit alter stb0899_algo.c aus dem aktuellen s2-liplianin:
lok_errs =0, runs=1207 of sequ=3333, multi=0, multi_max=0

real 18m44.389s
user 0m0.028s
sys 0m14.845s

mit Lous stb0899_algo.c:
lok_errs =0, runs=1207 of sequ=3333, multi=2, multi_max=1

real 18m46.137s
user 0m0.036s
sys 0m14.717s

auf jeden Fall funktioniert Lous Algo einwandfrei und vielleicht kann er besonders bei niedrigeren Symbolraten seine Stärken ausspielen, auch wenn der Effekt wie es scheint bei der S2-3200 nicht so groß ist.

Vielen Dank dafür Lou!

Ich versuche momentan auf Astra 3A 23.5 °Ost das SCPC Paket mit Antenne Bayern zu locken.
12661 V SR: 477 FEC: 1/2

Allerdings ist in der stb0899_drv.c noch der Wurm drinnen, denn dort ist 1000 kSym/s die niedrigste vorgesehene Rate.
folgendes habe ich schon geändert

Source code

 
1
2

1502:        if (INRANGE(i_params->srate, 100000, 45000000)) {
1917:        .symbol_rate_min               =      100000,


leider ohne Erfolg :(
@Lou: du hast auch keine Idee was ich da noch ändern müsste oder?

MikeDK

Trainee

Posts: 129

Location: Wien, Österreich

Occupation: Programmierer

  • Send private message

28

Tuesday, September 14th 2010, 2:55pm

Hoi!

Ich hab ne TT-Connect S2-3600 und ne TT-Connect S2-3650 CI ... beide haben ebenfalls den stb0899 verbaut ... werde das heut oder morgen Abend mal auf beiden Receivern durchlaufen lassen, und dann die logs hier posten...

Gruss,
Mike
HW: ASUS P5G43T-M Pro, C2D E8400, 4GB DDR3, TeVii S470, TT-connect S2-3650 CI, TT-connect S2-3600, HDD: Seagate Barracuda Green 5900.3 2TB
SW: Debian 6.0.2.1 AMD64, Kernel 2.6.32, vdr 1.7.21, xbmc vom pipelka rep

MarMic

Intermediate

Posts: 446

  • Send private message

29

Tuesday, September 14th 2010, 3:23pm

hi mikedk,

könntest du zap dann mit den standard treibern und dann noch mit den gepatchten treibern durchlaufen lassen?

intressiert mich einfach welche verbesserungen es je karte bringt!

greetz
SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-3.0.1

WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-3.0.1

SDVDR: Dell Optiplex GX150: P3 1Ghz - 256Mb Ram - 20Gb HDD - Technotrend Premium C-2300 Hybrid - KabelBW - MLD-2.0.0 @Eltern

Lou

Professional

  • "Lou" started this thread

Posts: 887

  • Send private message

30

Tuesday, September 14th 2010, 3:56pm

@newsy: die Unterschiede sind vorallem bei den Mantis Bridges augenfällig, weil lock_errs, die vorher immer da waren, die sind bei meinem Code weg. Deine Werte sind bei beiden Algos gut, und bewegen sich im Rahmen der natürlichen Schwankung von Satempfang. Der eine oder andere multi wird euch bei wiederholtem Durchlauf reinschlüpfen, sehr wichtig ist: keine errors mehr zu haben, auch beim verwenden der Mantis Bridge.

Edit: Vielleicht mach ich hier auch mal ein kleines Rechenbeispiel:

runs=1207 entsprecht der Anzahl durchlaufener Sender
real 18m46.137s das sind 18*60+46=1126s Durchlaufzeit
macht im Schnitt pro Sender 1126/1207=~0,93s

Rund eine Sekunde pro Sender ist gut, beim Tv schauen gehen dann bei SD/HD Material noch 1-3 Sekunden drauf, bis der Puffer gefüllt ist, und das Bild sauber entfaltet. Das macht unter 5 Sekunden, bis man ein stabiles Bild hat. Bisher waren es einfach 10 Sekunden oder 20, oder gar keins wegen lock_errs :)

Wenn es dir nichts ausmacht: kannst du mir das zap.log von beiden Algos zusenden?

Quoted


Allerdings ist in der stb0899_drv.c noch der Wurm drinnen, denn dort ist 1000 kSym/s die niedrigste vorgesehene Rate.
folgendes habe ich schon geändert

Source code

 
1
2

1502:        if (INRANGE(i_params->srate, 100000, 45000000)) {
1917:        .symbol_rate_min               =      100000,


Das müsste ich mir ansehen - gibt es auf Astra 19.2/Hotbird einen Sender mit ähnlich tiefer SR zum testen?
Ich mag mich wage an eine Diskussion in der linux-dvb ML erinnern, bei dem der Maintainer (manu) warnte, so tiefe SR seien für den Chip ungesund. Das wird auch im linuxtv wiki Artikel zur 1041 noch erwähnt . Ich müsste das im ML Archiv mal wieder raus suchen. Ich hab das damals nur wage mitverfolgt.
MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

This post has been edited 1 times, last edit by "Lou" (Sep 14th 2010, 4:30pm)

MarMic

Intermediate

Posts: 446

  • Send private message

31

Tuesday, September 14th 2010, 7:58pm

hi lou,

habe das zap verhalten des vdrs testen lassen und mir wurde gesagt, dass es nun gar keine verzögerungen mehr gibt. soll nun super laufen! wenns genug positiven feedback gibt hoffe ich auch ne aufnahme in den v4l-zweig, das wäre einfach nur SUPER

vielen dank!

greetz marmic
SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-3.0.1

WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-3.0.1

SDVDR: Dell Optiplex GX150: P3 1Ghz - 256Mb Ram - 20Gb HDD - Technotrend Premium C-2300 Hybrid - KabelBW - MLD-2.0.0 @Eltern

newsy

Intermediate

Posts: 298

  • Send private message

32

Tuesday, September 14th 2010, 9:10pm

Quoted

Original von Lou
@newsy: die Unterschiede sind vorallem bei den Mantis Bridges augenfällig, weil lock_errs, die vorher immer da waren, die sind bei meinem Code weg. Deine Werte sind bei beiden Algos gut, und bewegen sich im Rahmen der natürlichen Schwankung von Satempfang. Der eine oder andere multi wird euch bei wiederholtem Durchlauf reinschlüpfen, sehr wichtig ist: keine errors mehr zu haben, auch beim verwenden der Mantis Bridge.

Edit: Vielleicht mach ich hier auch mal ein kleines Rechenbeispiel:

runs=1207 entsprecht der Anzahl durchlaufener Sender
real 18m46.137s das sind 18*60+46=1126s Durchlaufzeit
macht im Schnitt pro Sender 1126/1207=~0,93s

Rund eine Sekunde pro Sender ist gut, beim Tv schauen gehen dann bei SD/HD Material noch 1-3 Sekunden drauf, bis der Puffer gefüllt ist, und das Bild sauber entfaltet. Das macht unter 5 Sekunden, bis man ein stabiles Bild hat. Bisher waren es einfach 10 Sekunden oder 20, oder gar keins wegen lock_errs :)

ja, das sind verdammt gute Werte, Bei Paketen mit Symbolraten < 10 MSym/s habe ich das Gefühl, dass es mit deinem Algorithmus schneller locked als mit dem alten.

Quoted


Wenn es dir nichts ausmacht: kannst du mir das zap.log von beiden Algos zusenden?

schick mir mal bitte deine Emailadresse als PM, ist zu groß für Pastebin.


Quoted


Allerdings ist in der stb0899_drv.c noch der Wurm drinnen, denn dort ist 1000 kSym/s die niedrigste vorgesehene Rate.
folgendes habe ich schon geändert

Source code

 
1
2

1502:        if (INRANGE(i_params->srate, 100000, 45000000)) {
1917:        .symbol_rate_min               =      100000,


Das müsste ich mir ansehen - gibt es auf Astra 19.2/Hotbird einen Sender mit ähnlich tiefer SR zum testen?

leider nein, dürfte momentan der einzige empfangbare Satellit sein, wo solch eine niedrige SR verwendet wird.

Quoted


Ich mag mich wage an eine Diskussion in der linux-dvb ML erinnern, bei dem der Maintainer (manu) warnte, so tiefe SR seien für den Chip ungesund. Das wird auch im linuxtv wiki Artikel zur 1041 noch erwähnt . Ich müsste das im ML Archiv mal wieder raus suchen. Ich hab das damals nur wage mitverfolgt.

bist du dir sicher, dass es um niedrige SRs ging? Ich erinnere mich um eine Diskussion zwischen Manu und Alex Betis, wo es um SR > 45 Mbit/s ging und Igor M. Liplianin die Chipfrequenz erhöht hat und dann auf einmal ein Lock möglich wurde. Oder meinst du wieder etwas anderes? Hast du nen link zu dem Artikel im Wiki? Konnte es leider nicht finden.

Ich hab auch mal einen Blick in die stb6100.c geworfen. Abhängig von der SR wird ein Gain von 9,11 oder 14 gewählt, aber warum?

Diese Zeile bringt mich auch etwas zum grübeln

Source code

 
1

stb6100_set_bandwidth(fe, srate);/* or srate * 2 ? */


Ich hab so langsam das Gefühl, dass es durch SRs < 1000 Kbit/s zu divisons by zero sowohl im stb0899_algo.c als auch im stb0899_drv.c kommen könnte. Nur weiß ich überhaupt nicht, welchen Wert man einsetzen sollte statt der 0.

This post has been edited 3 times, last edit by "newsy" (Sep 14th 2010, 9:30pm)

balta

Intermediate

Posts: 315

Occupation: Student der angewandten Informatik

  • Send private message

33

Wednesday, September 15th 2010, 1:55am

Leider kann ich mit meiner Technisat Skystar HD2 nicht testen, ich erhalte nur folgendes (original-2.6.34-Treiber)

Source code

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

./short 
Zapping adapter 0 ..
FE_SET_PROPERTY DTV_CLEAR failed: Invalid argument

lok_errs=0, runs=1 of sequ=4, multi=0, multi_max=0
opening frontend failed: Device or resource busy

lok_errs=0, runs=2 of sequ=4, multi=0, multi_max=0
opening frontend failed: Device or resource busy

lok_errs=0, runs=3 of sequ=4, multi=0, multi_max=0
opening frontend failed: Device or resource busy

lok_errs=0, runs=4 of sequ=4, multi=0, multi_max=0
channel not found
lok_errs =0, runs=4 of sequ=4, multi=0, multi_max=0

real    0m0.002s
user    0m0.001s
sys     0m0.001s
./short: Zeile 5: beep: Kommando nicht gefunden.


Andere Programme (Kaffeine, VDR, szap) können die Karte aber nutzen.
VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 12.3, VDR 2.0.1, vdr-xineliboutput

newsy

Intermediate

Posts: 298

  • Send private message

34

Wednesday, September 15th 2010, 8:53am

@balta: wahrscheinlich greift noch irgend eine Software auf die Karte zu. Bist du sicher, dass du alles gekillt hast?

MarMic

Intermediate

Posts: 446

  • Send private message

35

Wednesday, September 15th 2010, 9:26am

hi lou,

da steckt n bug drin:

multi: Zählt die Anzahl Locks im 2.-10. Anlauf hoch
multi_max: Merkt sich die höchste je vorgekommene Anzahl an Lock Versuchen

nach der aussage sollte multimax immer <=10 sein. habe nun auch testweisse aus der ferne mal die alten treiber wieder eingespielt um mal vergleichswerte zu haben und hatte direkt beim 2ten sender schon komische werte:

lok_errs=0 runs=2 mulit=1312 und multimax 549
jetzt beiu run 74: errs=8 multi:7703, multimax: 803 in der zeit könnte multi ja auch maximal 7400 sein, oder?

greetz
SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-3.0.1

WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-3.0.1

SDVDR: Dell Optiplex GX150: P3 1Ghz - 256Mb Ram - 20Gb HDD - Technotrend Premium C-2300 Hybrid - KabelBW - MLD-2.0.0 @Eltern

Lou

Professional

  • "Lou" started this thread

Posts: 887

  • Send private message

36

Wednesday, September 15th 2010, 11:15am

@MarMic: ein Bug ist's nicht, aber ich habe das in der Tat missverständlich erklärt:

Wie im Text oben steht rufe ich sofort nach dem Zap die Statuswerte ab, und frage danach im 10ms Abstand die Werte weiter ab, bis 10s ohne Lock verstrichen sind, danach gibt ezap2 auf und erhöht lock_errs um 1. Die multi Spalte zählt die Abfragen total über alle Sender hoch, dadurch ist dieser Wert stark ansteigend, wenn sich die multis häufen. multi_max hingegen merkt sich die höchste je vorgekommene Abfrage bei einem Sender. Dieser Wert kann in der aktuellen Fassung von ezap2 durchaus höher sein als 10. In der früheren Fassung von ezap2 und szap-s2 wurde der Status noch gemütlich im 1 Sekunden Rhythmus abgefragt. Das war mir zu wenig fein um zu sehen, wie rasch ein Sender gelockt ist. Ich korrigiere das dann noch im Begleittext auf Seite 1...

Was bei deinem Versuch entscheidend ist: mit dem alten Treiber hast du lok_errs, die sind weg bei meinem Treiber, das ist ist die wesentliche Verbesserung zu vorhin.

Die multi Werte und multi_max müssten ja nach Aussentemperatur (Luftfeuchtigkeit), Wolken, Regen oder dem Linseneffekt während der Dämmerungszeit schwanken. Entscheidend bei hohem multi_max ist: es trifft immer wieder andere Sender, einmal ist der eine etwas höher, einmal der andere -> es gibt kein "Fehler Muster", wenn das gleiche Skript mit derselben Liste immer wieder gestartet wird.
MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

Lou

Professional

  • "Lou" started this thread

Posts: 887

  • Send private message

37

Wednesday, September 15th 2010, 11:30am

@balta; solltest du das Skript "short" verwenden, ist eine Sat Anlage mit Astra auf DiseqC A und Hotbird auf DiseqC B erforderlich, sonst stimmt die Kanal Liste nicht. Das gleiche gilt für Skript "all"

Wer nur eine Empfangsanlage für Astra hat nutzt "./zap Astra_only.txt" für die gemischte Liste (DVB-S+DVB-S2 Sender) auf Astra
MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

balta

Intermediate

Posts: 315

Occupation: Student der angewandten Informatik

  • Send private message

38

Wednesday, September 15th 2010, 11:51am

Quoted

Original von newsy
@balta: wahrscheinlich greift noch irgend eine Software auf die Karte zu. Bist du sicher, dass du alles gekillt hast?


Ja, szap direkt dahinter kann auf die Karte zugreifen.

Quoted

Original von Lou
@balta; solltest du das Skript "short" verwenden, ist eine Sat Anlage mit Astra auf DiseqC A und Hotbird auf DiseqC B erforderlich, sonst stimmt die Kanal Liste nicht. Das gleiche gilt für Skript "all"

Wer nur eine Empfangsanlage für Astra hat nutzt "./zap Astra_only.txt" für die gemischte Liste (DVB-S+DVB-S2 Sender) auf Astra


Ich habe auch mit Astra_only den selben Effekt, nur dass hier natürlich die Ausgaben sehr viel länger sind. Deshalb habe ich short verwendet, um eine kurze Ausgabe hier zum posten zu haben.
VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 12.3, VDR 2.0.1, vdr-xineliboutput

Lou

Professional

  • "Lou" started this thread

Posts: 887

  • Send private message

39

Wednesday, September 15th 2010, 12:35pm

Also vdr läuft ganz sicher nicht? Mit "pidof vdr" kannst du das prüfen. Falls er doch laufen sollte wird er in yaVDR so gestoppt: "sudo stop vdr"

Ansonsten seht im Begleittext auf Seite 1 noch etwas über das Problem mit der Adapter Nummer: Wenn eine 2. Karte installiert ist, liegt deine stb0899 Karte evtl nicht mehr auf Adapter 0. Dann müsste es Adapter 1 sein oder noch höher. In dem Fall muss der -a0 Parameter im Skript angepasst werden.

Der Fehler mit beep verschwindet , wenn du das Programm beep installierst: "sudo aptitude install beep"
oder die Zeile auskommentierst.
MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

This post has been edited 2 times, last edit by "Lou" (Sep 15th 2010, 12:37pm)

balta

Intermediate

Posts: 315

Occupation: Student der angewandten Informatik

  • Send private message

40

Wednesday, September 15th 2010, 12:58pm

Quoted

Original von Lou
Also vdr läuft ganz sicher nicht? Mit "pidof vdr" kannst du das prüfen. Falls er doch laufen sollte wird er in yaVDR so gestoppt: "sudo stop vdr"

Ansonsten seht im Begleittext auf Seite 1 noch etwas über das Problem mit der Adapter Nummer: Wenn eine 2. Karte installiert ist, liegt deine stb0899 Karte evtl nicht mehr auf Adapter 0. Dann müsste es Adapter 1 sein oder noch höher. In dem Fall muss der -a0 Parameter im Skript angepasst werden.

Der Fehler mit beep verschwindet , wenn du das Programm beep installierst: "sudo aptitude install beep"
oder die Zeile auskommentierst.


Ja vdr ist ganz sicher gestoppt, wie gesagt, szap funktioniert. Die Karte ist auch ganz sicher der Adapter 0, da ich nur eine Karte im System habe.

Das mit beep war mir klar ;) mir ging es eher um das Problem dass die Karte angeblich belegt sei. Kann das mit dem Parameterfehler (FE_SET_PROPERTY DTV_CLEAR failed: Invalid argument) vom Anfang zu tun haben?
VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 12.3, VDR 2.0.1, vdr-xineliboutput