hmm vielleicht hab ich mich da verschaut... werde das mal mit Uwe abklären. Eventuell liegt's an seiner diseqc.conf.
Werde es mir morgen remote anschauen woher die Anfrage kommt.
hmm vielleicht hab ich mich da verschaut... werde das mal mit Uwe abklären. Eventuell liegt's an seiner diseqc.conf.
Werde es mir morgen remote anschauen woher die Anfrage kommt.
ich habe den Patch aus #11 von xblades bei mir eingebaut, und endlich sind die z.T. sekundenlangen Verzögerungen beim schnellen Durchzappen weg. Ein schwarzes Bild hatte ich dabei eigentlich so gut wie nie, aber es nervte extrem, dass mancher Kanalwechsel mehrere Sekunden dauerte. Ich hoffe, kls kann sich das rasch anschauen und vielleicht eine Version 2.4.2 veröffentlichen.
Das schwarze Bild kommt bei folgender Situation (bei Unicable)
1. Ein externer Receiver zieht die Leitung auf 18V und schaltet um (z.B ein anderer VDR während er EPG scannt)
2. Es wird ein Sender eingestellt welcher die gleichen Transpondereinstellungen hat wie der vorige. (Modulation & Symbolrate bleiben gleich). Der Tuner liefert ein Hardware Lock und VDR ist glücklich.
Sofern der neue Transponder eine andere Modulation & Symbolrate hat und VDR kein Lock bekommt versucht VDR den Transponder erneut zu tunen (also die Diseqc Befehle erneut abzusetzen).
3. VDR hängt nun auf dem falschen Transponder rum, der liefert zwar Daten aber nicht die richtigen.
Dies wurde mittels folgendem Befehl überprüft (folgender Befehl analysiert den Transportstream der aktuell übermittelt wird, die Befehle greifen auf die Interne Schnittstelle bei den Sundtek Tunern zu):
/opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0
4. Unser Treiber loggt die Diseqc Befehle, wenn Uwe die Befehle manuell absetzt (also ein Re-Tune wie bei einem fehlendem Lock durchführt) bekommt er ein Bild.
/opt/bin/mediaclient -V H
/opt/bin/mediaclient --diseqc "aa bb cc dd ee"
/opt/bin/mediaclient -V V
("aa bb cc dd ee" nimmt er aus unserer Logfile, was VDR halt geschickt hat)
Die SDT (Service Description Table) sollte überprüft werden ob der eingestellte Sender auch wirklich auf dem Transponder vorhanden ist. Falls nicht sollte der Transponder wie bei Punkt 2 behandelt werden (=re-tune)
https://en.wikipedia.org/wiki/Service_Description_Table
Das Problem tritt wohl sehr selten auf.
--- und hier noch wie Uwe es reproduziert hat ---
Jetzt habe ich wieder nachgestellt:
Apr 1 16:07:42 raspberrypi vdr: [2028] switching to channel 26 S19.2E-1-1039-10378 (SR Fernsehen HD)
Apr 1 16:07:42 raspberrypi vdr: [2217] device 1 TS buffer thread ended (pid=2028, tid=2217)
Apr 1 16:07:42 raspberrypi vdr: [2216] buffer stats: 389348 (7%) used
Apr 1 16:07:42 raspberrypi vdr: [2216] device 1 receiver thread ended (pid=2028, tid=2216)
Apr 1 16:07:43 raspberrypi vdr: [2031] frontend 0/0 locked on channel 26 (SR Fernsehen HD), tp 111053 after 284 ms
Apr 1 16:07:43 raspberrypi vdr: [2218] device 1 receiver thread started (pid=2028, tid=2218, prio=high)
Apr 1 16:07:43 raspberrypi vdr: [2219] device 1 TS buffer thread started (pid=2028, tid=2219, prio=high)
Mit dem mediaclient-Tool geschaut, was empfangen wird:
$ /opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0
media scan tp: 0
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
PMT PID: 0x14b4
Program Number: 0x286e
TransportstreamID: 1061
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: rbb Brandenburg HD
--> 0x14bf (27)
--> 0x14c0 (ISO/IEC 11172 Audio)
--> 0x14c1 (ISO/IEC 11172 Audio)
--> 0x14c2 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x14c4 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x029e (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x0880 (ISO/IEC 13818-6 type C)
--> 0x14c3 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14be
Program Number: 0x286f
TransportstreamID: 1061
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: rbb Berlin HD
--> 0x14bf (27)
--> 0x14c0 (ISO/IEC 11172 Audio)
--> 0x14c1 (ISO/IEC 11172 Audio)
--> 0x14c2 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x14c4 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x029e (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x0880 (ISO/IEC 13818-6 type C)
--> 0x14c3 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14c8
Program Number: 0x2870
TransportstreamID: 1061
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: MDR Sachsen HD
--> 0x14d3 (27)
--> 0x14d4 (ISO/IEC 11172 Audio)
--> 0x14d5 (ISO/IEC 11172 Audio)
--> 0x14d6 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x14d8 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x0b36 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x0b3c (ISO/IEC 13818-6 type C)
--> 0x14d7 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14d2
Program Number: 0x2871
TransportstreamID: 1061
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: MDR S-Anhalt HD
--> 0x14d3 (27)
--> 0x14d4 (ISO/IEC 11172 Audio)
--> 0x14d5 (ISO/IEC 11172 Audio)
--> 0x14d6 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x14d8 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x0b36 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x0b3c (ISO/IEC 13818-6 type C)
--> 0x14d7 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14dc
Program Number: 0x2872
TransportstreamID: 1061
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: MDR Thüringen HD
--> 0x14d3 (27)
--> 0x14d4 (ISO/IEC 11172 Audio)
--> 0x14d5 (ISO/IEC 11172 Audio)
--> 0x14d6 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x14d8 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x0b36 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x0b3c (ISO/IEC 13818-6 type C)
--> 0x14d7 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14e6
Program Number: 0x2873
TransportstreamID: 1061
Encrypted: No
Service type: 19
Service running: Yes
Provider Name: ARD
Service Name: hr-fernsehen HD
--> 0x14e7 (27)
--> 0x14e8 (ISO/IEC 11172 Audio)
--> 0x14e9 (ISO/IEC 11172 Audio)
--> 0x14ea (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x14ec (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
--> 0x087b (ISO/IEC 13818-6 type B)
--> 0x08de (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
--> 0x08e4 (ISO/IEC 13818-6 type C)
--> 0x14eb (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
Total found: 6 PMTs (incl. unknown 0x0000)
Scan finished after 17 packets (3196 bytes)
Alles anzeigen
hr-fernsehen HD war der Sender, der davor eingestellt war.
Jetzt schaue ich in Logfile, was der Sundtek Treiber für ein Diseqc Kommando für hr-fernsehen HD abgesetzt hat:
...
2020-04-01 16:07:42 [421] Set Voltage 18V
2020-04-01 16:07:42 [421] DISEQC> sending commands:
2020-04-01 16:07:42 [421] DISEQC> 71
2020-04-01 16:07:42 [421] DISEQC> 54
2020-04-01 16:07:42 [421] DISEQC> b3
2020-04-01 16:07:42 [421] DISEQC> 02
2020-04-01 16:07:42 [421] DISEQC> 58
2020-04-01 16:07:42 [421] DISEQC> done
2020-04-01 16:07:43 [421] Disabling High Tone (22khz)
2020-04-01 16:07:43 [421] Diseqc execution time: 95 ms
2020-04-01 16:07:43 [421] Set Voltage 13V
2020-04-01 16:07:43 [421] Set Voltage 13V
2020-04-01 16:07:43 [421] Disabling High Tone (22khz)
2020-04-01 16:07:43 [421] Setting Frequency: 1350000
2020-04-01 16:07:43 [421] Setting DVB-S2
2020-04-01 16:07:43 [421] Frequency: 1350
2020-04-01 16:07:43 [421] Symbolrate: 22000
2020-04-01 16:07:43 [421] Checking status 6275597
2020-04-01 16:07:43 [421] Frontend has locked
2020-04-01 16:07:43 [421] INIT_DTV: 0
2020-04-01 16:07:43 [421] TS Sync byte not aligned, realigning stream (0 // 0 // a5 // FEID: 0)
2020-04-01 16:07:43 [421] There have been 10 ts errors within 1 second
...
Alles anzeigen
(1)
$ /opt/bin/mediaclient -V H
Using device: /dev/dvb/adapter0/frontend0
setting voltage
18 Volt (Horizontal)
(2) > Diseqc-Kommando für hr-fernsehen HD:
/opt/bin/mediaclient --diseqc "71 54 b3 02 58"
(3)
/opt/bin/mediaclient -V V
Alles anzeigen
Sobald ich das Diseqc Kommando abgesetzt hatte (2), war sofort ein Bild auf sr-fernsehen HD zu sehen. Das sieht man auch im syslog: rpihddevice: set...
Apr 1 16:10:53 raspberrypi vdr: [2218] rpihddevice: set video codec to H264
Apr 1 16:10:53 raspberrypi vdr: [2043] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Apr 1 16:10:54 raspberrypi vdr: [2042] rpihddevice: video stream started 1280x720@50p, PAR=1/1
Apr 1 16:10:54 raspberrypi vdr: [2042] rpihddevice: display PAR=1,000, setting video render PAR=1/1
Ich weiß nicht ob das hier mit reinspielt, aber ich hatte in der Vergangenheit auch schon kaputte Aufnahmen bei meinem SCR/Unicable Setup.
Ich habe dann EPG-Scan ausgeschaltet und das schien zu helfen. Ich würde aber nicht ausschließen das es nicht EPG war sondern eventuell sogar ein anderer Receiver an der gleichen Leitung.
Ich weiß nicht ob das hier mit reinspielt, aber ich hatte in der Vergangenheit auch schon kaputte Aufnahmen bei meinem SCR/Unicable Setup.
Danke für den Hinweis.
Dieses Problem habe ich nicht und tritt nur auf, wenn die Unicable (also Kabel, Splitter ohne Dioden, End-Dosen, Splitter mit Dioden usw.)-Installation fehlerhaft ist.
Die Dioden vor dem Tuner, sollten eine Störung auf einem andere Receiver oder VDR´s verhindern... verhindern aber nicht, dass eventuell zwei Receiver zur gleichen Zeit einen Diseqc-Befehl senden...
Wenn erstmal der Sender eingestellt ist, egal welches Devices, treten hier keine Störungen auf...
Hier nochmal als komplettes Log (mit Ausgabe des Sundtek Treiber und des syslog)!
Ich schaltet auf ONE HD (14:06:17), dass Bild bleibt schwarz (14:06:18), setze 18V (14:07:09), setze manuell nochmal das Diseqc Kommando ab (14:07:37) und setze wieder 13V (14:07:44)!
Ab 14:07:37 habe ich wieder ein Bild!
Aktuell laufen 2x VDR über ein Unicable Kabel....
Gruß
Uwe
...
Apr 3 14:06:17 raspberrypi vdr: [872] switching to channel 16 S19.2E-1-1039-10376 (ONE HD)
2020-04-03 14:06:17 [401] Disabling High Tone (22khz)
2020-04-03 14:06:17 [401] Set Voltage 18V
2020-04-03 14:06:17 [401] DISEQC> sending commands:
2020-04-03 14:06:17 [401] DISEQC> 71
2020-04-03 14:06:17 [401] DISEQC> 54
2020-04-03 14:06:17 [401] DISEQC> b1
2020-04-03 14:06:17 [401] DISEQC> 02
2020-04-03 14:06:17 [401] DISEQC> 58
2020-04-03 14:06:17 [401] DISEQC> done
2020-04-03 14:06:17 [401] Disabling High Tone (22khz)
2020-04-03 14:06:17 [401] Diseqc execution time: 96 ms
2020-04-03 14:06:17 [401] Set Voltage 13V
2020-04-03 14:06:17 [401] Set Voltage 13V
2020-04-03 14:06:17 [401] Disabling High Tone (22khz)
2020-04-03 14:06:17 [401] Setting Frequency: 1350000
2020-04-03 14:06:17 [401] Setting DVB-S2
2020-04-03 14:06:17 [401] Frequency: 1350
2020-04-03 14:06:17 [401] Symbolrate: 22000
Apr 3 14:06:17 raspberrypi vdr: [1215] device 1 TS buffer thread ended (pid=872, tid=1215)
Apr 3 14:06:17 raspberrypi vdr: [1214] buffer stats: 316780 (6%) used
Apr 3 14:06:17 raspberrypi vdr: [1214] device 1 receiver thread ended (pid=872, tid=1214)
Apr 3 14:06:17 raspberrypi vdr: [1216] device 1 receiver thread started (pid=872, tid=1216, prio=high)
Apr 3 14:06:17 raspberrypi vdr: [1217] device 1 TS buffer thread started (pid=872, tid=1217, prio=high)
2020-04-03 14:06:17 [401] TS Sync byte not aligned, realigning stream (0 // 0 // b2 // FEID: 0)
2020-04-03 14:06:17 [401] TS Sync byte not aligned, realigning stream (11286 // 0 // 0 // FEID: 0)
2020-04-03 14:06:18 [401] Frontend has locked
Apr 3 14:06:18 raspberrypi vdr: [875] frontend 0/0 locked on channel 16 (ONE HD), tp 111051 after 287 ms
2020-04-03 14:07:09 [401] Set Voltage 18V
2020-04-03 14:07:37 [401] DISEQC> sending commands:
2020-04-03 14:07:37 [401] DISEQC> 71
2020-04-03 14:07:37 [401] DISEQC> 54
2020-04-03 14:07:37 [401] DISEQC> b1
2020-04-03 14:07:37 [401] DISEQC> 02
2020-04-03 14:07:37 [401] DISEQC> 58
2020-04-03 14:07:37 [401] DISEQC> done
2020-04-03 14:07:37 [401] Disabling High Tone (22khz)
2020-04-03 14:07:37 [401] Diseqc execution time: 97 ms
2020-04-03 14:07:37 [401] TS Sync byte not aligned, realigning stream (26132 // 70 // a8 // FEID: 0)
Apr 3 14:07:37 raspberrypi vdr: [878] read incomplete section - len = 4098, r = 4096
Apr 3 14:07:37 raspberrypi vdr: [1216] rpihddevice: set video codec to H264
Apr 3 14:07:37 raspberrypi vdr: [886] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Apr 3 14:07:38 raspberrypi vdr: [885] rpihddevice: video stream started 1280x720@50p, PAR=1/1
Apr 3 14:07:38 raspberrypi vdr: [885] rpihddevice: display PAR=1,000, setting video render PAR=1/1
Apr 3 14:07:38 raspberrypi vdr: [876] channel 28 (ARD-alpha HD) event Fr. 03.04.2020 13:35-14:00 (VPS: 03.04. 13:35) 'Es war einmal ... das Leben (5/26)' status 1
Apr 3 14:07:38 raspberrypi vdr: [876] channel 28 (ARD-alpha HD) event Fr. 03.04.2020 14:00-14:30 (VPS: 03.04. 14:00) 'Es war einmal ... der Mensch (5/26)' status 4
2020-04-03 14:07:44 [401] Set Voltage 13V
...
Alles anzeigen
Sundtek Kann man sich darauf verlassen, dass ein ioctl()-Aufruf an den Treiber erst dann zurückkehrt, wenn das Signal-Handling auf der Antennenleitung vollständig erledigt ist? Oder ist es möglich, dass der Treiber da was puffert und asynchron abarbeitet?
Ich frage deshalb, weil innerhalb eines VDR ja durch einen Mutex sichergestellt ist, dass immer nur *ein* Tuner die Leitung benutzt. Was aber nicht funktionieren würde, wenn der Treiber asynchron arbeitet.
Sobald ein weiteres Gerät die gleiche Leitung benutzt (anderer VDR oder Receiver) besteht die Möglichkeit einer Kollision natürlich unabhängig davon und bedarf einer Lösung im VDR.
Sobald ein weiteres Gerät die gleiche Leitung benutzt (anderer VDR oder Receiver) besteht die Möglichkeit einer Kollision natürlich unabhängig davon und bedarf einer Lösung im VDR.
Zur Info: Ich habe dieses "Blackscreen"-Problem nur, wenn ein zweiter VDR eingeschaltet ist, der auch per Unicable auf dieser Koaxleitung angeschlossen ist.
Sundtek Kann man sich darauf verlassen, dass ein ioctl()-Aufruf an den Treiber erst dann zurückkehrt, wenn das Signal-Handling auf der Antennenleitung vollständig erledigt ist? Oder ist es möglich, dass der Treiber da was puffert und asynchron abarbeitet?
Ich frage deshalb, weil innerhalb eines VDR ja durch einen Mutex sichergestellt ist, dass immer nur *ein* Tuner die Leitung benutzt. Was aber nicht funktionieren würde, wenn der Treiber asynchron arbeitet.
Sobald ein weiteres Gerät die gleiche Leitung benutzt (anderer VDR oder Receiver) besteht die Möglichkeit einer Kollision natürlich unabhängig davon und bedarf einer Lösung im VDR.
Ist synchron. Es geht im Fall von Uwe soweit ich weiß auch um 2 oder mehrere Systeme die auf der Unicable Leitung sitzen.
Uwe : versuche es einaml mit einer längeren Verzögerung nach dem setzen von 18V und vor dem zurückschalten auf 13V, z.B 100ms: S19.2E 11700 V 9750 t V W100 S0 [71 00 00 00] W100 v
Helmut
Die längere Verzögerung blockiert die 18V doch nur noch länger auf der Leitung (für den anderen Teilnehmer). Nehmen wir an dass der 2. Teilnehmer gerade EPG scannt... da wird eine Kollision dann schon deutlich wahrscheinlicher.
Wenn VDR 2 nun folgende Dinge einstellt während der VDR 1 die Leitung oben hat
Alter Transponder Symbolrate: 22msym; Modulation QPSK
Neuer Transponder Symbolrate: 22msym; Modulation QPSK
Tuner wird da dann ein OK und Locked zurückgeben, egal ob der LNB nun den Transponder wechseln konnte oder nicht - und genau das passiert hier.
Wenn VDR 2 von 22msym; Modulation QPSK auf 27.5MSYM/8PSK wechseln würde dann würde der Tuner im nachfolgendem Schritt kein Hardware-Lock zurückgeben und der VDR würde versuchen Diseqc erneut abzuschicken.
Uwe : versuche es einaml mit einer längeren Verzögerung nach dem setzen von 18V und vor dem zurückschalten auf 13V, z.B 100ms: S19.2E 11700 V 9750 t V W100 S0 [71 00 00 00] W100 v
Hallo Helmut,
wenn nur ein VDR-System aktiv ist, gibt es keine Probleme beim Tunen mit mehreren Tunern (hier ein Dual Tuner), außer die Zeiten sind zu gering. Ich kann, wie weiter oben gepostet, mit Zeiten W20/W20 arbeiten ohne Probleme. Um hier aber Probleme auszuschließen, bin ich aktuell bei W20/W40... (W100/W100 hatte ich aber auch schon...)
Ich kann mir die Finger Wund zappen , es kommt zu keinem Blackscreen... ...sobald aber ein zweiter Receiver/VDR dazu kommt (ja, beide VDR mit aktiven EPG-Scan, den möchte ich nicht missen) kommt es in selten Fällen zum „Blackscreen“...
Gruß
Uwe
Es wäre als Test gedacht. Ich könnte mir vorstellen, dass die Command-Bytes nicht vollständig zum LNB gelangen weil entweder beim Senden der Command Bytes die 18V noch nicht aufgebaut sind oder weil danach zu schnell auf 13V zurückgeschalten wird. Ich habe das bei meiner TBS5520 festgestellt, da braucht es mind. ein W50 vor dem Zurückschalten auf 13V, W20 ist zu kurz.
Helmut
Uwe . habe dein Post zu spät gelesen - hilft bei dir also nicht.
Uwe . habe dein Post zu spät gelesen - hilft bei dir also nicht.
Ich hatte mit höheren Werten auch getestet, deinen Post in einem anderen Thread habe ich gelesen, aber das löst nicht das Problem... und verlängert die Zapping-Zeiten
OK, danke an alle für die Infos.
Das Problem muss im VDR gelöst werden, und ich hab auch schon eine Idee, wie das gehen könnte.
Ich melde mich, sobald ich was zum Testen habe, denn ich habe hier keine solche Hardware-Umgebung.
Wenn du diesen Patch einspielst sieht du welcher Tuner ExecuteDiseqc() ausführt und ob es dabei Überschneidungen mit anderen Tunern gibt.
Helmut
Das obige logdiseqc.diff zeigt nur die Ausführung der Diseq Befehle der im jeweiligen VDR vorhandenen Tuner, nicht aber die von anderen VDRs oder STBs und ist daher nicht sehr nützlich.
Wie Sundtek oben beschrieben hat, weiß man trotz LOCK nicht, ob der Diseqc Befehl ordnungsgemäß durchgeführt wurde, oder ob der Transponder aufgrund einer Datenkollision gar nicht geändert wurde.
Was ich so gelesen habe um bei einem Transponderwechsel so eine Kollision zu erkennen bzw. auszuschließen ist es, zuvor einen "Unlock" zu erzwingen indem das Userband mit einem "ODU_PowerOFF" in den Standbymodus geschaltet wird. Bei einem Lock nach dem darauffolgenden "ODU_Channel_change" oder Jess "Tuning" Befehl kann dann mit sehr hoher Wahrscheinlichkeit davon ausgegangen werden, das nun der richtige Transponder eingestellt ist.
Ich nehme an, dass die Idee von Klaus auch in diese Richtung geht.
Helmut
Meine Idee geht mehr in die Richtung, die tatsächlichen Daten zu checken.
Der beliegende Patch prüft, ob die gewünschte SID in der PAT enthalten ist und löst einen Retune aus, wenn sie nicht innerhalb von 2 Sekunden gefunden wird. Eine hunderprozentige Lösung ist das freilich auch nicht, denn unterschiedliche Transponder können die selben SIDs verwenden. Eventuell müssen noch weitere Daten mit einbezogen werden (am liebsten ja die Transponder-ID, aber da habe ich auf die Schnelle keine Stelle gefunden, wo man sicher sein kann, die ID des tatsächlich getunten Transponders zu erhalten - falls da jemand drauf deuten kann, bitte her damit!).
Bitte probiert es mal damit. Aber Achtung: der Patch ist experiementell und hat noch einige Debug-Ausgaben. Das soll nur mal ein erster Ansatz sein...
kls : Da war ich etwas zu langsam, ich wollte dir nämlich gerade eine Email schreiben.
Ich habe hier einen Patch der mit ODU_PowerOff arbeitet.
Es wird dazu vor einem Programmwechsel und wenn bereits ein Lock anliegt, eine "PowerOff" Sequenz gesendet. Damit gibt es kein Signal und auch keinen Lock mehr auf diesem SCR-Channel. Dieses Kommando wird erforderlichenfalls auch mehrmals gesendet, da es ja auch dabei zu einer Datenkollision kommen kann.
Danach wird ganz normal auf den neuen kanal umgeschalten, und ein Wechsel von "Unlock" zu "Lock" zeigt, dass die diseqc-Sequenz fehlerfrei übertragen wurde. Falls es doch eine Datenkollision gegeben hat, und der gewünschte Transponder nicht eingestellt werden konnte, wird - wie sonst auch ohne Lock - nach einer Sekunde ein neuer Tuningversuch gestartet.
ich habe ihn nur ohne echte Kollisionen prüfen können, aber vom System her scheint er zu funktionieren.
Vielleicht kann man ja beide Patches kombinieren.
Helmut
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!