Einige Kanäle werden mit w_scan bei redirect für Cine CT nicht gefunden [war: w_scan + VDR fügen ORF eins HD nicht in channels.conf ein (DVB-C Liwest)]

Hallo und schönen guten Morgen,

ich betreibe yaVDR 0.5.0a 64bit als headless-VDR in einer KVM virtuellen Maschine mit einer Digital Devices Cine CT 6 (V6.1 lt. dmsg) + CI an TAB 2 und habe anfänglich die channels.conf-Datei für Liwest (AT/Linz) aus dem vdr-wiki (http://www.vdr-wiki.de/wiki/index.php…-At-Linz-Liwest) verwendet. Als Client komt XBMC 12.2 unter Windows und VNSI zum Einsatz. Im großen und ganzen funktioniert dieses Setup auch. Aber in dieser channels.conf-Datei fehlen der Sender »ORF eins HD« und ein paar Radiosender bereits. Laut Liwest und meinem TechniSat Receiver liegt der »ORF eins HD« auf 394MHz. Am Receiver, an einer anderen CATV-Enddose mit separatem Kabel vom CATV-Verteiler, ist der Empfang kein Problem.

Da der VDR, bei entsprechendem Setup, neue gefundene Sender automatisch in die channels.conf einfügt, habe ich einfach einige Tage gewartet, damit dieser die fehlenden Sender hinzufügen kann. Jedoch passierte das selbst nach über einer Woche dauerbetrieb nicht; andere Sender wurden jedoch in der Liste ergänzt oder umbenannt. Daher habe ich einen Suchlauf per »w_scan« gestartet. Jedoch fehlt auch hier der Sender»ORF eins HD«. Um dem Problem auf die Schliche zu kommen habe ich dann noch folgendes probiert:

# w_scan -v -v -fc -cAT -o7 &> test.txt

Dabei habe ich folgnedes rausgefunden:

[...]
Using DVB API 5.6
frontend 'STV0367 DVB-C DVB-T' supports
INVERSION_AUTO
QAM_AUTO
FEC_AUTO
FREQ (47.12MHz ... 865.00MHz)
SRATE (0.870MSym/s ... 11.700MSym/s)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
	===================== STV0367 DVB-C DVB-T ==============================
	len = 2
	0x00: 01 03                                       	:  
	========================================================================
73000: sr6900 (time: 00:00) sr6875 (time: 00:03) 
[...]
386000: sr6900 (time: 01:36) sr6875 (time: 01:38)
394000: sr6900 (time: 01:41) (time: 01:42) signal ok:
	QAM_AUTO f = 394000 kHz S6900C999
NIT (actual TS)
	===================== parse_nit ========================================
	len = 997
[...]
	========================================================================
	===================== parse_cable_delivery_system_descriptor ===========
	len = 11
	0x00: 07 14 00 00 FF F0 05 00 69 00 00            	:     	i 
	========================================================================
undefined outer fec
undefined inner fec
	new transponder:
   	(QAM_256  f = 714000 kHz S6900C999) 0x4044
	===================== parse_cable_delivery_system_descriptor ===========
	len = 11
	0x00: 07 22 00 00 FF F0 05 00 69 00 00            	:  "  	i 
	========================================================================
undefined outer fec
undefined inner fec
[...]

Hier wird im ersten Scandurchlauf bei 394MHz eine Liste von verwendeten Transpondern übertragen, die Liwest verwendet. Wobei ich nicht weiß, was genau »undefined outer fec« und »undefined inner fec« zu beduten haben.

Dannach beginnt der zweite Scandurchlauf von w_scan und spuckt folgendes aus:

73000: sr6900 (time: 04:33) sr6875 (time: 04:35) 
81000: sr6900 (time: 04:38) sr6875 (time: 04:40) 
[...]
tune to: QAM_256  f = 394000 kHz S6900C999 
(time: 08:53) >>> tuning status: 0x00 (NO LOCK)
>>> tuning status: 0x1f (LOCK)
PAT
	===================== parse_pat ========================================
	len = -2
                                                      : 
	========================================================================
[...]
	===================== parse_cable_delivery_system_descriptor ===========
	len = 11
	0x00: 07 06 00 00 FF F0 05 00 69 00 00                :         i  
	========================================================================
undefined outer fec
undefined inner fec
SDT (actual TS)
	===================== parse_sdt ========================================
	len = 246
[...]
	===================== parse_service_descriptor =========================
	len = 19
	0x00: 02 06 4C 69 77 65 73 74 0A 4C 69 66 65 20 52 61 :   Liwest Life Ra
	0x10: 64 69 6F                                        : dio
	========================================================================
	service = Life Radio (Liwest)
	===================== parse_service_descriptor =========================
	len = 18
	0x00: 02 06 4C 69 77 65 73 74 09 4B 72 6F 6E 65 20 48 :   Liwest Krone H
	0x10: 69 74                                           : it
	========================================================================
[...]
	===================== parse_service_descriptor =========================
	len = 20
	0x00: 01 06 4C 69 77 65 73 74 0B 4F 52 46 20 65 69 6E :   Liwest ORF ein
	0x10: 73 20 48 44                                     : s HD
	========================================================================
	service = ORF eins HD (Liwest)
Info: no data from NIT(other)

Der Sender »ORF eins HD« und auch andere werden hier als Service gefunden. Jedoch ist hier interessant zu sehen das die PAT eine Länge von -2 hat. Auf anderen Transpondern mit TV-Sendern ist die PAT nicht leer und es gibt auch Daten der PMT, wie unten zu sehen ist. Und obwohl das Service gefunden wird, wird es nicht in die channels.conf übertragen. Ich vermute mal wegen nicht gefundener PIDs für das Service.

tune to: QAM_256  f = 714000 kHz S6900C999 
(time: 09:04) >>> tuning status: 0x00 (NO LOCK)
>>> tuning status: 0x1f (LOCK)
PAT
	===================== parse_pat ========================================
	len = 54
	0x00: 00 00 E0 10 00 02 E0 6C 00 05 E4 10 00 07 E1 06 :        l        
	0x10: 00 23 E1 1D 11 FB E1 93 16 56 E0 CD 16 5E E0 D7 :  #       V   ^  
	0x20: 16 61 E0 EB 1C 85 E1 0E 2B 19 E0 5C 70 04 E1 96 :  a      +  \p   
	0x30: 70 09 E1 9D 70 0A                               : p   p 
	========================================================================
PMT 0x0196 for service 0x7004
	===================== parse_pmt ========================================
	len = 45
	0x00: E5 FF F0 06 09 04 0B 00 F9 6E 06 E0 21 F0 0A 52 :          n  !  R
	0x10: 01 0A 56 05 64 65 75 09 00 02 E5 FF F0 03 52 01 :   V deu       R 
	0x20: 02 03 E6 00 F0 09 0A 04 64 65 75 01 52          :         deu R
	========================================================================
	CA ID	: PID 0x0b00
  TELETEXT  : PID 33
  VIDEO     : PID 1535 (stream type 0x2)
  AUDIO     : PID 1536 (stream type 0x3)

Woran kann es liegen, dass »ORF eins HD« nicht in die channels.conf aufgenommen wird und wie kann ich das Problem lösen? Ich gehe jetzt nicht von einem Hardwareproblem meinerseits aus, da auch bereits die channels.conf vom VDR-Wiki ORF eins HD nicht beinhaltet. Kann es sein, dass der Transportstrom für den Transponder auf 394MHz nicht ganz in Ordnung ist?

Danke schonmal für's bis hier her lesen. Ist wegen dem Log etwas länger geworden.

MfG
Günther

Mir ist noch aufgefallen, dass mehrere Läufe von w_scan eine unterschiedliche Anzahl an Sendern (bzw. service_ids) finden.

Hallo,

ich hab jetzt die DVB-C Karte Cine CT V6 in einen anderen PC gesteckt und dort yaVDR 0.5.0a + linux-media-dkms zum Testen installiert. Dabei haben erste Tests gezeigt, dass die Anzahl der Service die w_scan findet davon abhängt ob ich

options ddbridge adapter_alloc=3

in /etc/modprobe.d/ddbridge.conf und

echo "00 01" > /sys/class/ddbridge/ddbridge0/redirect

aktiviert habe oder nicht.

Tatsächlich hat sich die Vermutung bestätigt, dass es mit den Treiberoptionen für die Cine CT zusammenhängt.

Ich habe mit folgendem Befehl getestet

# w_scan -fc -cAT -o7 -Q1 -S0 -a /dev/dvb/<adapter>/<frontent> | sort > file.txt

-) Wurden weder die Moduloption adapter_alloc=3 noch redirect gesetzt, kann ich auf den Tunern /dev/dvb/adapter0/frontent0 und /dev/adapter1/frontent0 einen ordentlichen Scan durchführen und bekomme auch 392 Kanäle inkl ORF eins HD, um den es ursprünglich ging.

-) Wurde nur die Moduloption adapter_alloc=3 gesetzt aber kein redirect, so kann ich auf dem Tuner /dev/dvb/adapter0/frontent0 einen ordentlichen Scan durchführen und bekomme auch fast alle (>390) Kanäle rein. Führe ich einen Scan auf /dev/dvb/adapter0/frontent1 durch, werden gar keine Kanäle gefunden.

-) Wurde sowohl Moduloption adapter_alloc=3 als auch das redirect gesetzt, kann ich auf dem Tuner /dev/dvb/adapter0/frontent0 einen Scan durchführen; bekomme aber jedesmal eine ganz unterschiedliche Anzahl von Kanälen wobei viele dann nur mit "service_id...." betitelt sind. Ein Scan auf Tuner /dev/dvb/adapter0/frontent1 findet wie oben keine Kanäle.

Mit "Kanäle finden" meine ich die Anzahl der Zeilen die w_scan am ende ausgibt [dumping services (x)].

Eine Lösung für das Problem habe ich aber noch nicht.

Hi,

ich glaube der Thread wäre besser unter VDR Hardware/DVB-Karten aufgehoben, oder? Von mir aus wäre ein Verschieben ok.

Hi,

da es sich um ein Phänomen handelt, dass einem unter Umständen nicht gleich auffällt ist das nicht verwunderlich. Außerdem ist es IMHO im falschen Subforum, weil ich eher als Fehlerursache meinen Kabelprovider Liwest in Verdacht hatte. Das es am Redirect liegen könnte hätte ich ehrlich gesagt nicht gedacht.

Ich hab jetzt w_scan mit redirect aber ohne eingestecktem CAM (Technisat TechniCrypt CX) durchgeführt, aber mit dem gleichen Ergebnis wie mit redirect und mit CAM.

Quote

Kann aber auch daran liegen, dass der weltweit einzig verfügbare Treiber/Firmwareentwickler für DD-Produkte unter Linux gerade Urlaub hat.

Der Urlaub sei der besagten Person gegönnt. Ich hoffe dieser bringt auch Erholung.

Ich habe noch nicht genau analysiert wie "gut" das funktioniert, aber ich konnte schon mal kurz orf eins HD (per vlc und streamdev) schauen.

Quote

Vielleicht ist es ja nur ein Problem beim Scannen, weil da sehr häufig umgeschaltet wird.

Naja, aber ein Scanvorgang ohne redirect schaltet genau so häufig und schnell um, wie mit redirect. Also daran *alleine* kann es auch nicht liegen, aber ich habe auch den (ersten) eindruck, dass das Schauen besser klappt als Suchen. Könnte allerdings mit der zusätzlichen Verarbeitung die fürs CI (und CAM) bei redirect nötig ist, zusammen hängen.

ORF eins HD liegt am ersten Transponder (d.h. der Transponder mit der niedrigsten Frequenz bei 394 MHz) und den hab ich bei keinem Scanvorgang mit redirect als Kanal gefunden.

Quote from UFO

mit "redirect":
Das CI/CAM bedeutet zusätzliche Pufferung und eine gewisse Verzögerung. Wenn sich das Scannen knapp an der Timeout-Grenze bewegt, könnte ich mir vorstellen, daß es einen Unterschied macht. Wie sieht es aus, wenn man w_scan zusätzlich die Parameter "-F -t 3" mitgibt?

Ich hab mir den Sourcecode der Version 2013-03-31 von w_scan geholt (w_scan) und wie folgt geändert:

Ausgabe von diff:

1608c1608
<         n = poll(poll_fds, n_running, 1000);
---
>         n = poll(poll_fds, n_running, 2500);
2803c2803
<         while ((opt = getopt(argc, argv, "a:c:e:f:hi:kl:o:p:qr:s:t:vxA:C:D:E:FGHI:LMO:PQ:R:S:T:VX")) != -1) {
---
>         while ((opt = getopt(argc, argv, "a:c:e:f:hi:kl:n:o:p:qr:s:t:vxA:C:D:E:FGHI:LMO:PQ:R:S:T:VX")) != -1) {
2871a2872,2874
>               case 'n': // do not add new frequencies
>                       flags.add_frequencies = 0;
>                       break;
3095a3099,3102
>
>       if (flags.add_frequencies)
>               info("add new frequencies from inital scan.\n");
>

Zeile 1608c: Längeres Timeout beim Warten auf POLL-Ereignisse
Zeile 2803c, 2871a,3095a: Keine neuen Transponder, die während eines Inital-Scan gefunden wurden, hinzufügen. Damit ich nicht immer das ganze Spektrum absuchen muss, sondern nur einige Testtransponder, sonst dauert dieser immer eine Stunde.

Ich habe zwei Datein mit Inital-Scan-Daten.
liwest.it mit 3 Transpondern

# C[2] <freq> <sr> <fec> <mod> [# comment]
#------------------------------------------------------------------------------
C 394000000 6900000 AUTO   QAM256       # LIWEST
C 714000000 6900000 AUTO   QAM256       # LIWEST
C 722000000 6900000 AUTO   QAM256       # LIWEST

und orf.it mit einem Transponder

# C[2] <freq> <sr> <fec> <mod> [# comment]
#------------------------------------------------------------------------------
C 394000000 6900000 AUTO   QAM256       # LIWEST

Starte ich meine gepatchte Version von w_scan mit orf.it, dann findet es immer die 11 darauf laufenden Services (Radio, SD unverschlüsselt, ein HD verschlüsselt). Das funktioniert auch, wenn ich zuvor ein
w_scan mit liwest.it laufen ließ.

./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontent0 -I orf.it

Starte ich hingegen meine gepatchte Version von w_scan mit liwest.it, dann wird bei jedem lauf eine andere Anzahl an Services erkannt (7-26 Stück). Dabei lässt sich auch kein Zusammenhang mit dem Transponder herstellen. Wobei ab und zu "Info: no data from PMT" ausgegeben wird, dass mir beim Scan mit orf.it noch nicht aufgefallen ist und einie Kanäle werden nur mit "service_id x" erkannt.

./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontent0 -I orf.it

Wirkt sich ein eingestecktes CAM bei der CI erweiterung für die Cine CT V6 auch auf das Tuning-Timing aus? Oder anders gefragt, sollte ich andere Ergenisse erwarten, wenn ich kein CAM eingesteckt aber redirect aktiviert habe und bringt mich so ein Test überhaupt weiter?

EDIT (Hinzugefügt): Also -F -t 3 löst das Problem auch nicht. Wenn es ein Timingproblem ist (von dem ich mittlerweile auch stark ausgehe) dann ist das nicht *knapp* an irgend welchen Grenzen.

Quote from UFO

ohne "redirect":
Für w_scan sollte es keinen Unterschied machen, ob man adapter_alloc verwendet oder nicht. Zufall?

Bei mir verhält sich w_scan ohne redirect deterministisch.

Ist adapter_alloc=3 *nicht aktiv* und scanne ich Tuner 0 mit

./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontend0 -I ~/liwest.it

oder Tuner 1 mit

./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter1/frontend0 -I ~/liwest.it

liefert mir w_scan immer ordentliche 36 Kanäle. Auch dann, wenn ich die Parameter -F und -t 3 weglasse.

Ist adapter_alloc=3 *aktiv* und scann ich Tuner 0 mit

./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontend0 -I ~/liwest.it

so bekomme ich 36 ordentliche Kanäle. Scanne ich jedoch Tuner 1 mit

./w_scan -n -c AT -f c -F -t 3 -a /dev/dvb/adapter0/frontend1 -I ~/liwest.it

Werden keine Kanäle gefunden und er schreibt
"Info: no data from PAT"
"Info: no data from SDT(actual)"
"Info: no data from NIT(actual)" pro Transponder.

Das Tuning dürfte aber funktionieren, weil ich auch bei frontend1 ein "signal ok" bekomme.