Posts by SHF

    Nach Kanalwechsel hin und zurück ist der Empfang ok.

    Gäbe es eine Möglichkeit, das zu erkennen und ein retuning auszuführen?

    Für mich sieht das nach einem abgestützten Decoder aus ein retuning bringt da nicht viel. Dafür aber ein Decoder-Reset.


    Ich würde zum Test mal auf einen anderen Kanal auf dem gleichen Transponder umschalten.

    Da sollte nicht neu getunt werden. Wenn das hilft ist ein retuning unnötig und der Fehler liegt im Ausgabeplugin.



    femon zeigte eine sehr niedrige, ca 5%, Qualität an.

    Normal ist die Besser?

    Es gibt Karten, die da keine sinnvollen Daten liefern.


    Normalerweise ist es Aufgabe des Tuners den Kanal zu halten und nach zu tunen. Wenn das nicht mehr geht, würde ich auf einen schleichenden Hardware-Defekt tippen.

    Als langjähriger EPG-Search User hatte ich schon öfters verhunzte Aufnahmen durch EPG-Fehler. Ganz neu ist das Thema also nicht.

    Wirklich vertrauen tu ich den EPG-Machern jedenfalls nicht mehr.

    Seit ich das EPG von anderen Transpondern ignoriere, ist es insgesamt schonmal besser geworden und die Zahl an abgebrochenen Aufnahmen deutlich gesunken (siehe: Arte EPG verhindert Suchtimeraufnahmen).


    Vor dem Akzeptieren der EPG-Events wäre IMHO ein Test auf Plausibilität ratsam. Primär geht es ja um Überschneidungen, die sollten sich recht einfach finden lassen. Dann ist man sicher, dass das EPG stimmig ist, das würde auch den EPG-Search Usern helfen.

    Ausserdem fallen so alle Fehler auf, nicht nur die, wo zufällig jemand einen Timer gesetzt hat.


    Im aktuellen Fall ist die VPS-Zeit von 23:50 sowieso komisch, üblich ist doch eher vor dem offiziellen Start?

    Wenn man die VPS-Zeit wegen Überlappung auf 23:49 oder besser 23:20 korregiert hätte, wäre das Problem doch nicht aufgetreten, nehme ich an?


    Apropos VPS:

    Komplett falsch gesetzte Running-Flags (oder ist das now and next?) hatte ich auch schon.

    Da war den ganzen Abend eine Sendung vom Vormittag drin und das auch auf einem anderen Receiver.

    Ich habe die DVBSKy S952 (v.2.x und v.3.x) hier am laufen und die Karten sind an sich sehr zuverlässig.


    Den Stromstecker auf der Karte hast du aber doch angeschlossen? Ohne gibt es merkwürdige Empfangsprobleme!


    Ich würde die Ursache eher im PCIe-Passthrough / Virtualisierung suchen.

    Problem ist halt, dass die DVB-Daten in Echtzeit rein kommen und auch von der Karte abgeholt werden müssen. Zudem sind die Puffer auf den Karten oft eher klein.

    Wenn die Interrupt-Verarbeitung etwas zu lange braucht, ist schnell der Puffer auf der Karte übergelaufen. Mehrere DVB-Karten im System verstärken das Problem natürlich noch.

    Das betrifft prinzipiell aber alle DVB-Karten, daher habe ich meine Zweifel, ob ein einfacher Kartentausch wirklich eine Lösung ist.


    Ich weiss nicht, was du schon versucht hast, aber ich würde Richtung Latenz minimierung / realtime / Interrupt-Zuweisung schauen.
    VM-Ware verwende ich zwar nicht, aber auch da sollte sich eigentlich was zu dem Thema finden lassen.

    evtl. testweise mal sie tiefsten CPU-Sleepstates deaktivieren.

    btw.: Was läuft denn sonst noch so alles auf dem Rechner?


    Ansonsten hilft halt die Karten aus dem Server zu verbannen (zB. SATIP) oder auf die Virtualisierung zu verzichten.

    Braucht man trotz Multischalter die Extra-Stromversorgung?

    Ja!

    Ohne die Schaltspannung hast du auch an einem Multischalter nur die vertikalen Kanäle (wenn überhaupt).


    Die LNB-Versorgung hängt ausschliesslich an dem Stecker!

    Afaik auch Teile des Tuners. Ohne Stromstecker geht es bei der Karte jedenfalls nicht!



    Der Stecker ist der übliche 6polige Stomstecker für Grafikkarten. Adapter von 5-1/4" Floppy oder SATA-Stromsteckern hat eigentlich jeder Computerfritze liegen.


    Quote

    DVBSky S952 S2 Twin PCI-e Rev.1.0b mit Chipsatz Montage DS3103/TS2022

    DVBSky S952 S2 Twin PCI-e Rev.2.0a mit Chipsatz Montage M88DS3103

    DVBSky S952 S2 Twin PCI-e Rev.3.0a mit Chipsatz Montage M88RS6000

    Die PCI-Bridge unterscheidet sich auch:

    Rev.1.x und Rev.2x Karten haben die CX23885 von Connexant.

    Rev.3.x Karten haben SM-2032 von Somagic (Chip) bzw. Spin Master Ltd (Treiber).

    Die Rev.3 ist praktisch eine komplett andere Karte.

    Im März 2011 ist diese Option wieder rausgenommen worden, die Option heisst immer noch "If Present", verhält sich aber wie das alte "Yes".

    Ich scheue mich etwas, an der Schraube zu drehen, weil sich wohl die Mehrheit an das Verhalten gewöhnt hat oder es richtig findet.

    Setz den Schlagschrauber an, meine vollste Unterstützung hast du! :]


    Ich hab mich an diese blödsinnige Änderung nie gewöhnen können. So wie es momentan ist, ist die Funktion für mich jedenfalls unbrauchbar und kann nur abgeschaltet bleiben.

    Besonders nervend ist das Verhalten, wenn ab und an Serienspecials kommen, die keine Untertitel haben. Hat bei mir eine ganze Weile gedauert, bis ich raus hatte, was da los ist.

    Die deutsche Beschreibung ist mit "wenn vorhanden" ist IMHO momentan auch völlig irreführend.

    Edit: "vorraussetzen", "erzwingen", "zwingend", "strikt" oder "immer" würden das aktuelle Verhalten eher beschreiben.


    btw.:

    Die Funktion "Timer nach Löschen neuprogrammieren" greift auch für von EPGsearch selbst gelöschte Timer, was IMHO nicht sinnvoll ist.

    Wenn EPGsearch den Timer löscht, dann macht es das aus dem Grund, weil das Event nicht mehr im EPG ist. (Programmänderung, EPG-Ausfall, ...) Wenn das Event wieder auftaucht, sollte der Timer auch wieder gesetzt werden, alles andere macht keinen Sinn.

    Ich hatte mich hier mal an einem Patch versucht, weiss aber nicht, ob das so sinnvoll ist.

    Da das "ö"s in "Die_Höhle_der_Löwen" vorhanden sind halte ich den Zeichensatz als Ursachen für unwahrscheinlich.


    Wie sollte denn der Titel von "P5LLAW~P" eigentlich lauten? Vielleicht bringt einen das auf eine Idee.


    Meine Vermutung ist, dass da eher ein Verzeichnisnahme zu lang geworden ist. Daher das --dirnames

    ... da anscheinend niemand wirklich eine Idee hat.


    Mich erinnern diese Tilden "~" in den Dateinahmen an die langen Dateinamen von Windows 95, wie sie unter DOS aussahen.


    Meine Vermutung daher, dass die Dateinamen zu lang sind, oder da irgendwelche Zeichen drin sind, die zu den Problemen führen.


    VDR-Option --dirnames=250,40,1 (alias --vfat) wäre IMHO einen Versuch wert.

    Wenn ich für Lancom dann allerdings noch ewige Konfig hab, bin ich nicht viel besser dran, als mit OpenWRT.

    Von der Konfiguration finde ich OpenWRT angenehmer und logischer als die Fritzboxen.


    Zum SMS-Send via HTTP empfehle ich einfach mal in deren Forum die Frage zu stellen. Kostet ja nichts und ist schnell gemacht.

    Da wird sicher jemand LTE verwenden und sich besser auskennen als ich DSL-User.

    "Local server" ist korrekt gesetzt?


    Interessant ist, dass hier die Domain mit angehängt ist, obwohl ich die beim nslookup nicht angegeben habe.

    "Expand hosts" macht das, falls aktiviert (Advanced Settings).


    Ist eventuell "All Servers" oder "Strict order" aktiviert? Sollten beide aus sein.


    Die domain 'tvdr.de' ist öffentlich. Das könnte die Ursache sein, warum "Filter private" nicht geht.

    Bei mir OpenWRT 19.7 tritt das Problem nicht auf, allerdings hab ich ein 192.168.x.x Subnetz eingerichtet.

    SMS-Versand per Shell-Befehl soll bei OpenWRT gehen, ich hab eben mal geschaut.

    Aus dem Webinterface kann man Shell-Befehl ausführen. Man kann so auch einen Befehl beim Aufruf einer URL ausführen, das verwende ich selber. Irgendwie soll man da auch Parameter übergeben können, damit habe ich mich aber noch nicht beschäftigt.

    Das Senden einer vorgefertigten SMS an immer die gleiche sollte also auf dem Weg also schon mal gehen. Eigentlich müsste man auch Nummer und Text als Parameter an das Skript übergeben können, der Text ist bei einer SMS ja nicht so lang. Muss ich bei Gelegenheit mal Probieren, was da geht, wollte ich eh mal machen.


    Der Zusammenbau und das Aufspielen der Software war übrigens Problemlos und schnell erledigt (ich klammere jetzt mal die Virtualisierung aus).

    OpenWRT soll auf dem Board auch von einer SD-Karte laufen können, habe ich irgendwo gelesen. Da erübrigt sich die Installation.


    Das Einzige Problem, auf das ich bei OpenWRT gestossen bin, ist, dass PPPOE ondemand nicht ging. Sobald man ondemand aktivierte, fehlte die default Route und er baute deswegen die Verbindung nicht auf.

    Ich hab das inzwischen hingebogen, die Ursache muss ich aber im Winter mal ergründen. (Auch bei mir ist derzeit die Zeit knapp ;))

    Ich habe seit über 15 Jahren einen von Bauckhage laufen und bin zufrieden damit.

    Verbrauch inklusive LNB etwa 5W.

    Das dürfte der Nachfolger sein, sieht sehr ähnlich aus: https://www.reichelt.de/multis…eil-bms-508nt-p72615.html


    Inzwischen würde ich aber ein getrenntes Nezteil bevorzugen:

    https://www.reichelt.de/multis…il-bms-508dc-p211421.html

    Da ist man in der Wahl des NT frei und kann ein effizientes nehmen.

    https://www.reichelt.de/stecke…-mw-gst25e18-p171100.html

    Ohne NT wäre nicht mein Ding, da dann immer die Receiver / VDR den Multischalter und LNB speisen müssen.

    Der Nachteil ist die "feste Verdrahtung".

    Das ist aber auch der Vorteil!


    PARTLABEL und UUID dürfen nur einmal im System vorkommen, sonst passiet Chaos mit unvorhersehbarem Ergebnis.

    Einen 1:1 Clone von der Rootpartition, zB. zu Testzwecken oder als Sicherheit, auf einer anderen Partition liegen zu haben geht also nicht.

    In die Falle bin ich damals getappt :motz4.


    PARTLABEL ist halt so lang oder so kurz wie gewünscht, nicht diese elend langen Zeichenketten in der fstab

    Neben der Optik in der fstab lässt sich ein selbstausgesuchtes PARTLABEL auch geringfügig besser merken :lachen2.

    Was ändert sich für eine gemountete Partition, wenn dahinter noch eine oder mehrere neue Partitionen angelegt wurden ?

    Dass man an einer Platte mit gemounteten Partitionen nicht rum partitionieren soll, war schon "immer" so. Quelle hab ich aber leider keine mehr.

    Gpartet weigert sich AFAIK auch so eine Platte zu bearbeiten.


    Nachtrag:

    Die Variante PARTLABEL in Verbindung mit der internen Kernel-Commandline (und dem geeigneten fstab Eintrag versteht sich) scheint mir die sinnigste Variante zu sein.

    Das Umstellen auf PARTLABEL habe ich vor einer Weile mal mit dem damals aktuellen Debian probiert.

    So wirklich geklappt hat es aber nicht, da einige Skripte da nicht mit gemacht haben.

    Ob es nach der Umstellung auf systemd besser geht müsste man mal probieren.


    Da inzwischen aber auch schon die Swap-Partitionen mit UUID in der initrd eingetragen sind, befürchte ich, dass es nicht so einfach sein wird die UUIDs los zu werden.

    Eigentlich würde auch ich, zumindest auf einigen Rechnern, gerne wieder auf /dev/sd... zurück zu gehen. Wenn man weiss, was man macht, hat das im handling auch einige Vorteile.

    Da ich liebend gerne eine Variante hätte, die es ermöglicht, quasi aus einem tarball heraus eine Installation vorzunehmen, die dann auch sauber mit ihrem /root bootet, sind Varianten mit UUID nicht so sinnig, weil ich die nicht wirklich beeinflussen kann.

    Die UUID kann auch einfach ändern.

    zB. mit tune2fs oder swaplable einfach ändern.

    Bei einem anderen Partitionstypen wird es mit dem entsprechenden Tools auch irgendwie gehen, denke ich.


    ummerweise scheint cgdisk ein syncing-Problem zu haben, falls man die Physische Disc anpackt, auf der das aktuelle root liegt

    Man sollte nie eine Partitionstabelle bearbeiten, solange eine der Partitionen noch gemountet ist.

    Mit LTE hab ich zwar nicht zu tun, aber ich habe mir kürzlich ein APU2 angeschafft, auf dem (unter anderem) openWRT als Router läuft.

    Die Kombination APU2 / openWRT scheint aber auch als LTE Router recht beliebt zu sein, da liest man öfters davon.


    Ob da der SMS-Versand wie gewünscht geht müsstest aber selber mal schauen, ich kenne mich damit nicht aus.

    Festnetztelefon am APU2 anschliessen ist eher schlecht, ich bin den Weg einer externen VOIP-Box gegangen. Wobei, ist das bei LTE überhaupt VOIP?

    Eventuell gibts da auch einen anderen Router, wo man ein Festnetztelefon anschliessen kann.

    Ich würde mal bei openWRT im Forum vorbei schauen, der Markt ist ja kaum zu überblicken.

    Dass jeder, der die Fernbedienung in die Finger bekommt, alles nach Lust und Laune löschen/verstellen kann, ist mir auch schon aufgefallen.

    Eine Art Benutzerverwaltung, mit der man sowas verhindern kann, würde den VDR IMHO wirklich bereichern.


    Es gab da AFAIk mal ein Patch/Plugin, aber ich bezweifele, dass das mit VDR 2.4 noch geht.


    Ob das mit dem chattr +a funktioniert, müsste man mal probieren.

    Mit ACLs habe ich mich aber noch nicht näher beschäftigt, es klingt aber interessant.


    Mit normalen Dateirechten könnte man auch die Verzeichnisse, in denen sich die Videos befinden (also die mit dem Datum im Namen), auf readonly setzen. Besser vielleicht sogar nur die Dateien, die nicht geändert werden (marks zB. nicht).

    Dazu müsste man ein Skript schreiben, was das bei jedem Systemstart tut.

    Oder, falls der vdr durch läuft in gewissen Abständen. In dem Fall muss man aber aufpassen, dass auf die Verzeichnisse nicht gerade zugegriffen wird.

    Wenn man einfach mit make LCLBLD=1 baut wird versucht die Plugins nach /usr/local/lib/vdr zu installieren.

    Besonders unschön ist das wenn man als root arbeitet, da man dann nicht mal eine Fehlermeldung erhält. In dem Fall hat man u.U. Chaos im System angerichtet, ohne wirklich zu merken, was passiert ist.


    Natürlich ist INSTALL korrekt beschieben, dass man den Parameter LCLBLD=1 setzen und Make.config.template nach Make.config kopieren muss.

    Da ich ausser setzen von LCLBLD=1 nichts ändere, bin ich zum wiederholten male in die o.g. Falle getappt.


    Ursache ist, dass ohne Make.config die Verzeichnisse für make LCLBLD=1 nur teilweise stimmen.

    Die Fehlenden sind in der Makefile recht einfach zu ergänzen:

    Jetzt hat man auch mit make LCLBLD=1 das Verhalten der "alten" Makefile, ohne sonst irgendwas ändern zu müssen.


    Es funktioniert sowohl mit Plugins mit neuer als auch "alter" Makefile. Getestet mit VDR 2.4.1.

    Soweit ich es mir angesehen habe, sollten die Defaults, so wie ich sie eingefügt habe, auch mit nichts kollidieren.

    Ja der ist innerhalb von ein paar Minuten von 330 auf 370MB gewachsen.

    Das ist nach den Start normal.

    Scheint am EPG zu liegen.

    Man muss eine Weile warten, bis sich das stabilisiert hat.

    Das ganze EPG glaube ich kaum. Das wäre deutlich mehr.

    Ob es wirklich vollständig ist, hab ich natürlich nicht kontrolliert, aber geschätzt 20% von dem Dump sind EPG.


    370MB kann man sich im Hexeditor nur Stichprobenhaft ansehen. Selbst durchblätter ist nicht in sinnvollem Zeitrahmen möglich!


    Da stehen auch Massenweise Strings drin wie 333333 oder auch Sachen die IBEV oder anderes Kryptisches.

    Das hat so ein Dump an sich ;-).

    333333 ist z.b sehr oft vorhanden

    Ist das normal? Oder schon ein Hinweis auf ein Leck?

    Kann ich nicht beurteilen, "333333" sagt mir nichts.

    Das kann default Wert in irgend einem Datenfeld sein oder sonstwas, was zufällig den String "333333" ergibt.


    Der Speicheranstieg ist bei Bedienung (OSD) viel höher als wenn der VDR so füt Aufnahmen läuft.

    Dann versuch es doch bitte mal ohne Skin-Plugins.

    Wenn dann der Speicheranstieg nicht mehr auftritt, weiss man, dass es an den Plugins liegt.

    Dann kannst du auch die Dumps vergleichen und sehen, ob die "333333" noch so häufig sind.


    Speicheranstieg ist bei Bedienung (Transponderwechsel) kann aber auch am EPG liegen. Das sollte sich aber nach einer Weile Zappen auf einem Niveau einpendeln.

    Bei den Strings steht eine menge zeug drin. Einiges könnte vom skin sein...

    Ich denke der Dump ist vom Block:5645341c6000-56454ac39000 rw-p 00000000 00:00 0 [heap]?

    Der passt von der Grösse und es ist auch einzige, wo sich nennenswert was tut.


    So wie ich das sehe ist da der komplette EPG drin.

    Das Vorgehen hilft also auch nicht weiter.



    Ich empfehle nochmal, die Plugins auf das nötigste zu reduzieren und zu schauen, ob es dann immer noch auftritt.

    Den Skin-Plugin kann man jedenfalls ohne einschränkung Benutzbarkeit zum Test mal raus nehmen.