Beiträge von HelmutB

  • t2scan: neues DVB-T/T2 Channel Scan Tool basierend auf w_scan

    Um zu funktionieren müssen diese *_AUTO Parameter vom Frontend auch unterstützt werden.

    Für DVB-T habe ich nicht nachgesehen, aber für DVB-T2 gibt es in den Kernelquellen derzeit nur fünf verschiedene Frontends und alle können damit umgehen. Daher sollte bei einem Scan mit einer (und für eine) DVB-T2 Hardware die kurze Parameterangabe auch genügen (die AUTO-Parameter werden dann im Betrieb von VDR mit den Daten aus der NIT ersetzt).


    Für deine Hardwareliste: t2scan funktioniert auch mit meinem Astrometa DVB-T2 USB-Stick:

    /dev/dvb/adapter2/frontend1 -> TERRESTRIAL "Panasonic MN88473": very good :-))


    Helmut

  • [gelöst 0.6] dhclient: No DHCPOFFERS received [suspend to ram]

    Die LEDs zeigen üblicherweise die Verbindungsgeschwindigkeit. Bei meinem Netgear Router bedeutet grün einee Gigabit-Verbindung (1000baseT) und gelb entweder 100baseT oder 10baseT, das wIrd bei deinem Switch ähnlich sein.

    Wie es aussieht verbinden sich 0.5 und 0.6.2 hier unterschiedlich.


    Zu ethtool: Ich sehe bei mir auch ohne Netzwerkkabel "Advertised link modes:"

    Code
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Speed: Unknown!
    Duplex: Unknown! (255)

    Und bei meinem VDR im Netz:


    Da habe ich bei dir nichts gesehen. Versuche vielleicht noch: 'ethtool -s p2p1 advertise 0x3F'


    Helmut

  • [gelöst 0.6] dhclient: No DHCPOFFERS received [suspend to ram]

    Ok - dann kann man den Router als Fehlerquelle ausschließen.

    Ich verwende kein Ubuntu/Debian aber vielleicht hilft dir das von hier weiter: https://askubuntu.com/question…nd-autonegotiation-issues

    Das Problem klingt ähnlich und es betrifft auch Ubuntu 14.04:


    Edit: u.U. musst du ethtool zuvor instalieren: 'sudo apt-get install ethtool'


    Solution:


    Open /etc/network/interfaces and configure the ethernet interface one of these following ways:


    DHCP


    auto eth0

    iface eth0 inet dhcp

    pre-up ifconfig $IFACE up

    pre-up ethtool -s $IFACE speed 100 duplex full autoneg off


    Static


    auto eth0

    iface eth0 inet static

    post-up ethtool -s $IFACE speed 100 duplex full autoneg off

    address x.x.x.x #Internal IP

    netmask 255.255.255.0

    gateway x.x.x.y #Gateway IP

    dns-nameservers 8.8.8.8 #Google DNS


    Helmut

  • [gelöst 0.6] dhclient: No DHCPOFFERS received [suspend to ram]

    habichthugo : Der Hostname ist nicht wichtig. Der DHCP-Server sieht nur die MAC-Addresse.

    Was mir im Moment einfällt:

    Was gibt 'sudo dhclient -v' ?

    Teste einmal mit 'sudo dhcpcd -T' sowie 'sudo dhcpcd -T p2p1'.

    Hast du den DHCP-Server im Router selbst eingerichtet? Schau dir die Einstellungen einmal genauer an.

    Genügt es vielleicht auch das Netzwerkkabel auf einer der beiden Seiten abzuziehen, etwas zu warten und dann wieder anzuschließen ?

    Helmut

    Edit: Hab ich vrgessen: <NO-CARRIER> bei 'ip link' sehe ich wenn kein Netzwerkkabel angeschlossen ist. Versuche einmal einen anderen Port am Router und schau dir dann die syslog Meldungen an.

  • [Patch] Bei manuellem Start wird EPGscan für den letzten scanList-Eintrag nicht mehr durchgeführt

    Da mit dem letzten Device->SwitchChannel() auch die scanList leer wird und ScanList->Count() das erkennt, wird bei manuell gestartetem EPGscan nun auf den urspünglichen Kanal zurückgeschalten. Ds ist aber voreilig, denn damit wird der gerade vorbereitete NIT/SDT/EIT scan für den letzten Listeneintrag sofort wieder abgebrochen.

    Da auch über AnyDeviceSwitched erkannt werden kann ob ein Scan aktiv ist (#true) oder die ScanList Leer/keine verwendbaren Einträge hat (#false), kann ScanList->Count() entfernt werden und das Zurückschalten geschieht erst nach dem nächsten ScanTimeout.


    Helmut

  • t2scan: neues DVB-T/T2 Channel Scan Tool basierend auf w_scan

    Ich habs kurz getestet und würde sagen es passt.

    Bei Aufruf mit

    gentoo64vdr ~/down/t2scan-master # ./t2scan -t 2

    wird die PLP 1 für AT verwendet.


    Scandauer 3:30 min, dabei 7 Transponder gefunden, 2 weitere mit 11 sec. PAT timeout. (findet alle vorhandnen 6 MUXe + einen auf einer zweiten Frequenz noch einmal)

    Die Version vom 29.April 2018 braucht 3:13min, ebenfalls 7 Transponder gefunden und 2 mit 2 sec PAT timeout.


    Helmut

  • [Patch] kleiner Fix bei für das Hinzufügen neuer Transponder in nit.c

    In nit.c wird bei der Transpondersuche schon bei Übereinstimmung von Netzwerk- und Transportstream-ID der bool-Wert "found" auf "true" gesetzt.

    Das sollte aber erst dann geschehen, wenn auch der Channel->Transponder() überprüft wurde und so veraltete oder unrichtige Channels Einträge nicht zu einem falschen Ergebnis führen.


    Helmut

  • t2scan: neues DVB-T/T2 Channel Scan Tool basierend auf w_scan

    mighty-p Ja, es gibt (derzeit) in AT nur die PLP 1 im Single-PLP Mode (SISO).


    Das mit der Kanalaktualisierung ist richtig und ein guter Hinweis für GTC - sie darf NICHT auf auf "neue Transponder hinzufügen" eingestellt sein, Dann bleiben die Transponderdaten und damit auch die PLP unverändert.


    Wenn man nur DVB-T/T2 verwendet bringt diese Option derzeit sowieso recht wenig, da hier neue Transponder nur Alternativ-Frequenzen des gleichen Multiplex und damit der gleichen Programme sind. Ausnahme ist vielleicht das eine oder ander Lokalprogramm.


    Helmut

  • [Patch] Aktualisierung der Programme bei fehlerhafter NIT (DVB-T) und nun auch bei DVB-T2 (nit.c)

    Zum SDT-Trigger.

    Es ist mir jetzt erst aufgefallen das im "vdr-2-4-0-nit-1-trigger-sdt-v2-patch" 3 Zeilen stehen die erstens gar nicht dazu gehören und zweitens - viel schlimmer - auch noch Unsinn sind. Bei den 3 Frequency-Loops muß natürlich wie gehabt immer bei Index 0 begonnen werden. Im Anhang jetzt die bereinigte Version 3.


    Mein DVB-T2 Patch ist ohne Berücksichtigung der Transponder für die der T2DeliverySsystemDescriptor gilt auch keine Verbesserung zum Ist-Stand. Ich werde noch versuchen ihn zu vervollständigen.


    wirbel : Ich habe das Internet durchstöbert und auch einiges über S2-Multistream gefunden (z.B. bei Enigma2 und dddvb auf github), aber nichts darüber wie ein S2-Descriptor richtg behandelt wird.
    Und so wie ich die Spezifkation verstehe: es ist richtig - ein S2-Descriptor muß nicht vorhanden sein und er soll sogar nicht vorhanden sein wenn er nicht wirklich erforderlich ist (das wäre: kein Multistream und scrambling_sequence_index=0).

    Aber wenn er doch benötigt wird, dann nur zusätzlich zu einem SatelliteDeliverySystemDescriptor.

    Wie dem auch sei, vielleicht werde ich noch fündig.


    Helmut

  • t2scan: neues DVB-T/T2 Channel Scan Tool basierend auf w_scan

    Naja, das ist so ein "Haudrauf" Patch der bestenfalls im Single-PLP Mode funktioniert.

    Die PLP-Id sollte eigentlich nur gegen den aktuell getunten Transponder und Sender auf Sinnhaftigkeit geprüft werden.

    Ich versuche mich ja gerade an der Vervollständigung des Transponderupdate für DVB-T2, dabei werde ich das dann hoffentlich besser einbauen.


    Helmut

  • [Patch] Aktualisierung der Programme bei fehlerhafter NIT (DVB-T) und nun auch bei DVB-T2 (nit.c)

    Zitat von wirbel

    Es bedeutet nur, wenn es den S2 descriptor gibt, dann sollte (aber muss nicht) es den anderen auch geben,


    Eigentlich genau umgekehrt - das wirst du aber auch so gemeint haben: den SatelliteDeliverySystemDescriptor gibt es immer (ob für DVB-S oder DVB-S2 sagt das modulation_system Bit), den S2-descriptor nur falls erforderlich und als Ergänzung zu Ersterem.
    Mit dem S2-descriptor alleine fängt man gar nichts an, da man Ihn ja keinem Transponder zuordnen kann. Und die StreamId daraus auf alle Kanäle mit gleicher Nid und Tid zu übertragen wie es jetzt in VDR gemacht wird, stört vermutlich nur deshalb die meisten nicht weil es auf S19.2E und S13.0E keine Transponder mit DVB-S2 Multistream gibt: DVB-S2 Multistream

    Die S2-descriptoren die ich auf S19.2E gesehen habe folgen unmittelbar einem SYSTEM_2-satellite-descriptor (auch in der gleichen NIT-section). Das hat auch auch eine gewisse Logik, da die beiden ja zusammengehören.


    Hier ein Auszug aus den DVB-SI Implementation Guidelines dazu:


    Zitat von wirbel

    Gibt es in dem Netzwerk T und T2 gemeinsam, werden die natürlich beide gesendet.


    Da hast du vermutlich recht. Aber die Transponder Parameter gelten entweder für DVB-T oder für DVB-T2, und Parameter des anderen Systems aus dem channels.conf Eintrag zu übernehmen bringt keinen Mehrwert.

    Deshalb habe ich diese Code-Zeilen entfernt.


    Helmut

  • [Patch] Aktualisierung der Programme bei fehlerhafter NIT (DVB-T) und nun auch bei DVB-T2 (nit.c)

    Hier eine neue Version des SDT-Trigger Patch. Damit wird der Trigger immer nach Verarbeitung der letzten NIT-Section durchgeführt (das ist normalerweise dann ein mal pro Kanalwechsel)


    Nun habe ich nach dem Durchlesen der verschiedenen ETSI DVB Dokumente auch ein paar Ideen für Ergänzungen bei der Behandlung der DeliverySystemDescriptorTags. Ich habe sie zu besseren Lesbarkeit in einzelne Patches aufgeteilt.


    DVB-S/S2 - vdr-2.4.0-nit_2-dvb-s2-v1.patch:

    Die Parameter für beide Systeme werden grundsätzlich im SatelliteDeliverySystemDescriptor beschrieben. Für besondere Fälle wie z.B. Multistream kann als Ergänzung der S2SatelliteDeliverySystemDescriptor nötig sein. Da dieser -falls vorhanden - unmittelbar dem SatelliteDeliverySystemDescriptor folgt werden nun beide zugleich eingelesen. Im Fall von Multistream werden außerdem Kanäle mit anderer StreamId nicht modifiert


    DVB-T/T2 - vdr-2.4.0-nit_3-dvb-t2-v4.patch:
    Im Unterschied zu DVB-S2 sind die Parameter für DVB-T2 keine Ergänzung zu DVB-T sondern eigenständig, T und T2 Descriptoren kommen auch nicht gleichzeitig in der NIT vor. Die wenigen Angaben zusammen mit der PLP-Id genügen der T2-Hardware/Firmware um die übrigen Parameter aus dem Signal auszulesen und einzustellen.

    Auch hier werden nun bei Multi-PLP Kanäle mit anderer StreamId nicht modifiziert. Zusätzlich prüfe ich bei Single-PLP die Sinnhaftigkeit der StreamId (das brauche ich für manche ORF Transponder).


    Bei meine Tests habe ich mit diesen Patches keine Auffälligkeiten bemerkt, Was ich aber nicht testen kann ist Multistream (gibt es z.B. auf Eutelsat 5W) oder DVB-T2 Multi-PLP (haben wir in AT nicht).

    Hier sollten - wenn ich es nicht ganz falsch verstanden habe - nun für neue StreamIds oder PLPs auch entsprechende Kanäle in der Channels.conf auftauchen.

    Vielleicht hat ja jemand Interesse und Zeit das zu testen (in DE wird doch Multi-PLP bei DVB-T2 verwendet ?).

    Dazu hätteich noch einen kleinen Patch der das nitdbg aktiviert und die Ausgaben ins syslog schreibt.


    Helmut

  • [Patch] Aktualisierung der Programme bei fehlerhafter NIT (DVB-T) und nun auch bei DVB-T2 (nit.c)

    Bei passendem Wetter kann ich noch DVB-T Kanäle aus der Slovakei empfangen. Dabei ist mir aufgefallen, dass die Transponderinfo (Sendername oder neue Sender) von VDR nie aktualisiert wird. Der Grund dafür liegt in falschen Frequenzangaben im DeliverySystemDescriptor. Und da die tatsächliche Frequenz des aktuellen Senders nie aufscheint wird sdtFilter->Trigger(Source) auch nie ausgeführt.

    Der keine Patch behebt das Problem und triggert nun sdtFilter für den aktuellen Sender zumindest ein mal.

    Er behandelt derzeit nur DVB-T und DVB-T2 (das war bisher noch gar nicht implementiert), kann aber auch für Kabel und Sat erweitert werden- ich habe es nur noch nicht getestet.


    Helmut

  • VDR 2.4.0 with ddci2 does not get subscription updates

    I have now watched the updates of the entitlements. The CAM was last in use 12 days ago. I switched to "ORF2W HD" (the recommendet channel for me). After about 5 minutes I checked the Cam-Menu and could see the changes (Interestingly with the date of yesterday).


    The ECM / EMM counter can be found in this CAM under a menu item named "Universal Client Status



    I used VDR-2.4.0 with ddci2 and the camstwaks patch, and everything looks normal to me.


    Helmut

  • VDR 2.4.0 with ddci2 does not get subscription updates

    Hello !

    The patch only replaces the reply to query for CAMs that do not support this. And this is only needed if more than one program should be decrypted, with only one active program, the patch has no effect.

    I have not noticed any negative effect yet. If I did not use my CAM for DVB-T2 for a longer time (2 weeks or so), the subscrption will be updated within 30 seconds.

    But I'll check it again tonight.


    Helmut

  • UHD über Astra

    Die UHD Sender aus meiner channels.conf - Fashion 4K und SES UHD Demo sind frei empfangbar.

    Code
    gentoo2 ~ # cat channels.conf | grep -i -e "4k\|uhd"
4K UHD - EVENEMENT;CSAT:11934:vC23M5O25S1:S19.2E:29700:1010=36:0;1021=@106,1022=@106:0;1042,1043:1883:8910:1:1076:0
Fashion 4K;SES ASTRA:11111:hC23M5O35S1:S19.2E:22000:2815=36:2816=eng@3:0:0:12510:1:1043:0
SES UHD Demo Channel;SES:10993:HC56M5O35P0S1:S19.2E:22000:511=36:0;512=deu@122:0:0:1:1:1035:0
UHD1 by ASTRA / HD+;SES ASTRA:10993:HC56M5O35P0S1:S19.2E:22000:101=36:102=deu@3:0:1830,1843,1860,186A,186D,9C4,98C,98D:2:1:1035:0
Travelxp 4k;MX1:10993:HC56M5O35P0S1:S19.2E:22000:767=36:768=deu@15:0:1830,1843,1860,186A,186D,9C4,98C,98D:6202:1:1035:0
Sky Sport Bundesliga UHD;SKY:11797:hC910M2O35S1:S19.2E:27500:1791=36:0;1795=@106,1796=@106:0:98C,98D,9C4:552:133:16:0

    Helmut


    Edit:

    Ein aktueller Scan findet auch noch diese Sender:

    Code
    INSIGHT TV UHD;SES ASTRA:12343:hC23M5O20S1:S19.2E:30000:255=36:256=eng@3,257=eng;259:0;261,263:1867,624,500,9C4,98C,98D:2000:1:1097:0
INSIGHT TV UHD SPAIN;SES ASTRA:12343:hC23M5O20S1:S19.2E:30000:255=36:256=eng@3,512=spa:0;261:1867:2001:1:1097:0
INSIGHT UHD Russia;SES ASTRA:12343:hC23M5O20S1:S19.2E:30000:255=36:256=eng@3,1280=rus:0:1867:2005:1:1097:0
PEARL TV 4K UHD;SES ASTRA:12343:hC23M5O20S1:S19.2E:30000:2815=36:2816=deu@3:0:0:2010:1:1097:0
QVC UHD;MX1:11288:vC23M5O20S1:S19.2E:22000:255=36:256=deu@3:57:0:4230:1:1006:0
RTL UHD;MX1:11391:hC56M2O0S0:S19.2E:22000:2815=36:0;2816:42:1830,1842,1843,1860,186A,186D:12410:1:1013:0

  • Tastenbelegung geht nach Umschalten mit KVM-Switch verloren

    Also: Leap 15.0 KDE Live von USB, mit Sprache Deutsch, Tastatur Deutsch, beides einfach über YAST (vom Startmenü) eingestellt und dann X neu gestartet ergibt folgendes:

    Code: /etc/sysconfig-Editor
    YAST_KEYBOARD
german,pc104
    Code: xorg.0.log
    [   742.664] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio0/input/input0/event0"
[   742.664] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD, id 13)
[   742.664] (**) Option "xkb_model" "pc105"
[   742.664] (**) Option "xkb_layout" "de"
[   742.664] (**) Option "xkb_variant" "nodeadkeys"
[   742.664] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"
[   742.664] (II) event0  - AT Translated Set 2 keyboard: is tagged by udev as: Keyboard
[   742.664] (II) event0  - AT Translated Set 2 keyboard: device is a keyboard
    Code: /etc/locale.conf
    LANG=de_DE.UTF-8
    Code: /etc/vconsole.conf
    FONT=eurlatgr.psfu
FONT_MAP=none
KEYMAP=de-latin1-nodeadkeys
FONT_UNIMAP=

    Helmut

  • Tastenbelegung geht nach Umschalten mit KVM-Switch verloren

    Ich habe jetzt openSUSE Leap 15.0 KDE Live ausprobiert.

    Das Keyboard habe ich in YAST auf "Deutsch" gesetzt und setxkbmap -query zeigt mir


    rules: evdev

    model: pc105

    layout: de

    variant: nodeadkeys

    options: terminate:ctrl_alt_bksp


    Nach "xkbcomp $DISPLAY" habe ich in der Datei server-0.xkb die runden und geschweiften Klammern zu Ö und Ä gelegt und die Datei mit "xkbcomp server-0.xkb $DISPLAY" geladen. Danach waren () und {} mit AltGr rund Shift-AltGr erreichbar.


    Um diese Belegung unter X11automatisch zu haben wäre das in "/usr/share/X11/xkb/symbols/de" unter "nodeadkeys" so einzutragen (natürlich nur wenn das verwendete Layout tatsächlich "de" ist)

    Code: symbols/de
    partial alphanumeric_keys
xkb_symbols "nodeadkeys" {
...
    key <AC10>    { [ odiaeresis, Odiaeresis,            braceleft, bracketleft ]    };
    key <AC11>    { [ adiaeresis, Adiaeresis,           braceright, bracketright ]    };

    Helmut