Posts by Fourty2

Wo Du einmal an der Stelle bist:

Ich hatte da letztens bzgl. der VPS Timer geguckt, was da schief läuft.

Testcase:

Zwei VPS-Timern auf unterschiedlichen Transpondern zur gleichen Zeit. Liveprogramm auf drittem Transponder.

Zunächst schaltet der VDR mit zweiter Karte abwechselnd auf Kanal A/B bis ein epg2vdr Timerupdate kommt, in diesem Moment (setzen auf No Event / Event) hört das auf... und er nimmt nichts auf, bis man live auf einen der aufzunehmende Transponder wechselt.

Nur das warum ist mir noch nicht klar.

Danke. Hatte ich gestern schon gesehen:

Stefan

Wenn man sich einmal ein "privates" PPA eingerichtet hat, ist das ja auch kein großer Umstand.

1. per debian/rules make-orig das Git-Update ziehen und ein Archiv dazu erzeugen

2. per dpkg-buildpackage die Erzeugung starten

3. per reprepro das erzeugte Paket ins PPA verschieben

4. in diesem Fall hier einmal mysql und co anhalten..

5. einmal apt update && apt upgrade

6. alles wieder starten.

Und wenn man schon dabei ist, kann man die eigenen Pakete auch gleich "Pinnen".

42

Hallo zusammen,

habe ich bei 1080i 16:9 Quellen (per vaapidevice, auf 50p / 1920x1080 festgetackert) auch.

Gut, dann war das Problem nicht mein vaapidevice Patch ...

VA- und Inteltreiber ist aktuell aus dem GIT.

Kodi hat das Problem nicht - also sollte der Treiber nicht schuld sein.

D.h. sowohl Intel, als auch Nvidia erzeugt das gleiche Problem.

Die Ursache dürfte also in älteren Teilen des Softhddevices oder neueren FFMPEGs liegen.

Stefan

Also prinzipiell tat mein VDR das schon immer:

Deshalb ist mir das mit den 400k Links ja auch nicht aufgefallen. Wenn die in ca. 3 Jahren Laufzeit gesammelt wurden hätte er trotzdem > 1000 Links pro Tag verlieren müssen. Scheint mir etwas unwahrscheinlich. Da müßte was anderes passiert sein. Nur was?

Mein VDR läuft natürlich nicht durch, der epgd schon.

Stefan

Nach epgd Update gestern (die SQL-Fehler), haben heute auch die Links abgenommen:

48 ungenutzte Bilder, 72 ungenutzte Links.

Wäre also möglich, daß der Serverprozess die Ursache war. Behalte das mal im Auge...

Stefan

Das wäre dann (derzeit) das Ergebnis. Ich warte mal das nächste EPG-Update ab, ob was gelöscht wird.

42

Natürlich gibt es das Paket in Buster gerade nicht ...

MySQL-Connector als Download

Ich habe 439 überflüssige Bilder. Hmm...

Auch wenn es mir - eigentlich - um die Links auf diese ging.

42

horchi wrote:

Ansonsten habe ich den Thread leider nicht komplett verfolgt und gerade keinen Überblick, ist sonst noch etwas offen und hat sich das mit den Ladezeiten geklärt?

Die "Lade"zeiten bedingten vermutlich die 395k Links auf 8000 Bilddateien in /var/lib/epgimages

Soweit ich ich da kurz durchgeguckt hatte, waren alle Links gültig. Habe aber noch ein Backup, wenn man über die IDs was klären kann.

seahawk1986 :

Ich hatte während der Tests mal mehrmals "plug epg2vdr update" benutzt, um das Update-Delay (die 5 ms/Schleife) zu testen. Das hat also offenbar auch keine Links entfernt..

Stefan

seahawk1986

Da das epg2vdr Plugin ja nicht notwendigerweise auf dem gleichen Rechner läuft, wie der epgd scheint mir der Ort nicht sehr zielführend. Das müßte dann in den epgd, für die Bilder aus dem epg Download.

(=> daher cron für Server)

Die hier ehemals 400000 Links auf die epg-Bilder für den VDR-epg werden ja eigentlich auch bei jedem EPG-Update gelöscht (schreibt er zumindest ins Log). Nur halt irgendwie nicht vollständig, sodaß sich im Laufe der Zeit Leichen sammeln (=> Garbage-Collection am VDR-Client nötig).

Stefan

Indem Du in /etc/cron.d eine Datei, z.B. clean-epgd folgenden Inhalts anlegst:

Bei mir liegen die Bilderlein in /srv/epgd/tvsp ... dies wird bei Dir anders sein, daher Pfad anpassen.

42.

Nein, das ist der epgd - der lädt die Bilder runter und schiebt sie in die Datenbank. Und da, wo sie abgelegt werden, bleiben sie erstmal liegen - das spart zwar das erneute runterladen bei Wiederholungen, aber es gibt keine Routine, die Altes entfernt.

Das wird auch hier einmal im Monat bereinigt. "rm" ..

(Und läuft 24/7 auf einem anderen Rechner)

Stefan

Denke, die Links werden vom VDR über die Skins (hier skinnopacity) aufgerufen. Und da es z.B. Nachrichtensendungen halt x-mal gibt, ein Bild per x Links. Scheint mir logisch sinnvoll.

Nur warum das Aufräumen - was ja offensichtlich erfolgen sollte - nicht funktioniert, wäre die Frage.

Das per rsync von Platte in die RAM-Disk und nach Ende zurückzukopieren braucht natürlich keine 10 Minuten. Die 5 ms Delay sind auch noch da. Nicht zuviele Experimente auf einmal...

Stefan

Nach Löschen der epgimages und vdr Neustart:
epg2vdr: Got 7305 images from database in 549 seconds (0 updates, 7305 new) and created 28597 links

epg2vdr: --- EPG update finished ---

Das wäre konsistent mit dem Verzeichnis:

- ca. 230 MB Daten (wie vor dem Löschen)

- 7305 Bilder (etwa wie zuvor)

- und nur noch 35900 Links. (427405 - 35900 = 391.505 nicht gelöschte Links)

Die scraper2vdr Datenkopie liegt in /var/cache/vdr/plugins/scraper2vdr.
Hier 4,6 GiB, die nicht zu stören scheinen.

System-Platte ist eine 2.5" 1 TB mit ext4 fürd system und xfs für video - Unauffällig.

Bliebe die Frage, warum die alten Links erhalten bleiben.

Klar könnte ich die zwei Verzeichnisse ins TMPFS mounten.

RAM wäre genug da und um die Größe muß man sich da nicht kümmern, macht das TMPFS bei Bedarf selbst.

Z.B. /var/log, Videotext und epg liegen da sowieso schon (hatte auch mal ein Paket gefunden was das selbständig von der HDD und zurück kopierte - leider irgendwo verloren), aber ...

... wenn man schon lokal einen Cache anlegt, so als Plugin, sollte man sich auch ums aufräumen kümmern, oder?

Kann natürlich, wie beim epgd (auf dem Server) per cron Job alle x Tage die Bilder, bzw. hier nur die Links abräumen. :-/

Stefan

time ls -Rl /var/cache/vdr/epgimages | wc

427405 4686676 40610575

real 3m59,673s

user 0m9,066s

sys 0m14,316s

für 230 MB.

Als RAM-Disk (Datein zurückkopiert):
time ls -Rl /var/cache/vdr/epgimages | wc

427405 4686676 41425900

real 0m11,520s

user 0m8,385s

sys 0m4,326s

Naja, "fast" ist ein wenig untertrieben ...

Nach dem Start und ab und zu zwischendurch gibt es Phasen, wo der vdr was von >100s Latency ins Syslog schreibt. Wenn die Kiste der FB nicht folgt drückt man dann besser keine weitere Taste ... sonst siehe Satzanfang.

Das liegt aber vermutlich an der Datenbank auf einem "anderen" Rechner. Ich bastel daher die DB-Abfragen gerade auf die "Non-Blocking" Api um. Aber dies ist keine Arbeit von ein paar Tagen...

(Falls jemand Zeit hat, hier der Anfang MairaDB_NonBlocking.patch)

Zur Frage der epg2vdr Dateien (kurz mit ncdu geguckt):

427494 Links auf 7419 Bilder

Ähem... da hat mich das "find . -type f | wc -l" wohl ausgetrickst.

Das paßt dann zu > 35 Minuten bei 5 ms.

42.

Also... wir haben bspw. drei Timer (über das CAM):

A auf C1, z.B. von 10:00 - 12:00

B auf C2, z.B. von xx:xx - 11:00

C auf C3, z.B. von 11:00 - xx:xx

Timer A läuft ungestört, B ebenso, C "meist".

Falls C (nach Umschalten von C2 auf C3) keine Daten liefert, ist A davon nicht betroffen (entschlüsselt weiter), wird aber natürlich durch den VDR Neustart mit "unterbrochen". Was natürlich nicht (unbedingt) bedeutet, daß die CAM-Kommunikation funktioniert hat.

Das CAM-Reset durch das EPG-Update des epg2vdr Plugins habe ich (erstmal) in dessen update.c mit

behoben.

Das bremst das Update der ca. 5000 Links/Bilder von ca. 3 auf 50 Minuten; wird später optimiert. Das CAM hat seitdem keine Reset-Probleme mehr.

Kann das aber gerne nochmal ohne epg2vdr probieren.

42

Hallo zusammen,

leider kommt es ja bisweilen vor, daß die Entschlüsselung eines aufzunehmenden Programms nicht sofort gelingt. Insbesondere direkt nach Kanalwechsel bei bereits laufender Entschlüsselung.

Das versaut dann durch Video Datastream Broken und Restart gleich alle laufenden Aufnahmen. Blöd.

Nun gelingt es eigentlich immer, durch Um- und Zurückschalten die Entschlüsselung doch noch zu starten.

Könnte man nicht - wenn keine Daten kommen, den "Emergency Exit" auf "Retune" umbiegen?

Macht der VDR ja auch selbst, wenn sich die Kanaldaten ändern.

42

Die Abfrage der Jugenschutzpin kommt beim NDS Modul wie mir scheint, sobald irgendwas nicht funktioniert.

Habe (teilweise) den gleichen Effekt mit dem EPG-Update (durch epg2vdr), was mir beim Update der lokalen EPG-Bilder nebst Symlinks (um 4800 Stück) meist das Modul abschießt, aber gelegentlich die Pin-Abfrage triggert:

Offenbar ist das CAM I/O-zeitkritisch...

Kommt sofort zurück, sobald die Bremse gelöst ist.

Allerdings ist das in Aufnahmen eher ungünstig... VDSB -> exit.

Geht's schnell, "überlebt" es

Hier mal mit Pin-Abfrage:

Kann also auch ein Firmware-Problem (oder Absicht) des Moduls sein:
"Wenn ich kein Bild hinbekomme, frag ich mal nach der Pin..."

Das System liegt auf auf einer ext4 Disk. Außerhalb des VDR kann man treiben, was man will, da brennt nix an. Nur wenn epg2vdr losläuft, war's das meist. :-]

42.

/var/lib/vdr# cat camresponses.conf

# 3 "Please enter your PIN" 1234

root@roadrunner:/var/lib/vdr# cat camresponses.conf

# Format:

# nr: the number of the CAM this action applies to (0 = all CAMs)

# text: the text in the CAM menu to react on (must be quoted with '"' if it contains

# blanks, escape '"' with '\')

# action: the action to take if the given text is encountered

1 "Bitte geben Sie Ihre Jugendschutz-PIN ein." <PIN>