Tipp: Wenn Du das Git mit --depth=1 klonest, sind es "nur" etwa 600 MB.
Posts by Fourty2
-
-
Das "rpihddevice: unknown video frame format: 0x0@0p PAR(0:0)" hatte ich auch mal.
Irgendwas hab ich gepatched. Gucke morgen mal, ob ich das noch finde.
Stefan
-
Das INSTALL Verfahren zerschießt dann das Paket-Management, keine gute Idee.
Aber ich hab mal den Paketbauer für die vdr-Pakete getreten. Also mich.
Der hat dann das rules File mal aufgeräumt.
Das "MAKE_OPTIONS = VDRDIR=/usr/include/vdr" konnte ja nur verunglücken...
Stefan
-
Hmm...
was will mir denn das sagen:
Der Code zum finden der vdr.pc ist in anderen, funktionierend Plugins identisch.Die Datei liegt, wie immer, in /usr/lib/pkgconfig.
Hatte das debian-Verzeichnis aus Bequemlichkeit aus dem normalen alten Markad kopiert...
Grüße,
Stefan
-
Das Problem macht wohl das rpihddevice. Es fehlen (nach Umschalten) auch Einträge zum Bildformat im Log.
Denke durch "firmware: video_decode: Only shutdown codec on both ports being disabled" bekommt da irgendwas die Änderung nicht mit. Menü -> Restart und Bild ist da. Also fehlt vermutlich ein Codec-Reinit.
(Als Hinweis an reufer )
Grüße,
Stefan
-
TomJoad :
Habe das Logging bereits aktiviert,
Sind ja noch 5 Folgen aufzunehmen, vielleicht passiert es ja nochmal.
Stefan
-
TomJoad :
Unwahrscheinlich. Nach dem letzten epg2vdr EPG-Update erfolgten noch Suchtimer-Updates, die den Timer nicht wiederfanden.
Als ich geschaut habe, was los ist, war der Himmel Atlantic EPG vollständig. Das manuelle Suchtimer-Update hat die Timer dann sofort erstellt.
Mehr Log "ist nicht" - lief ja alles
Sender aus DE (Himmel Atlantisch), EPG per TVSP, VPS aus wegen epg2vdr.
Stefan
-
Hab das Log durchsucht. Der Timer wird per SVDRP gelöscht:
Beim EPGSearch verschwindet der Eintrag aber sehr viel früher.
Startpunkt:
Bis zum 20.12. 11:23:34 wird er gefunden:
Beim nächsten Update passiert dann der (wie ich gerade merke) erste Unfall (->Timer 2)l:
-> Vor dem Suchtimer-Update wird das Menü geöffnet (Bildskalierung) und noch ein Timer manuell gesetzt
Letztes EPG Update war am 21.12. um 17:04, falls EPG fehlte, hätte das EPGSearch den Timer bis 18:04 wieder haben müssen, EPGSearch Update erfolgt stündlich.
Ist mir - ehrlich gesagt - spanisch...
Stefan
-
Hatte für gestern zwei Serien-Timer (nächste Staffel - frisch und nie aufgezeichnet) für 20:10 (Doppelfolge).
Kurz vor 20:00 noch was programmiert, um 20:12 gewundert, das man noch frei umschalten konnte - Serientimer verschwunden ...
Zum Test manuelles Suchtimer-Update, beide Timer wieder da und korrekt aufgezeichnet. Eigenartig. Nix im Log.
Stefan
-
Display MoreCode
Allerdings mit eigenen VDR-Paketen und SysV Init.
Ursprünglich per unattended-net-installer installiert (o.s.ä.).channels.conf und epg.data sind ganz ...
Stefan
-
Eine vorhanden 64-Bit Installation läuft ohne den Patch problemlos. Kann sein, dass hier ein 32/64Bit Problem vorliegt? Hat jemand anderes die aktuelle git-Version erfolgreich auf einem Raspi laufen?
Habe die GIT Version auf einem RPi2 (V1.1) laufen. Schien mir soweit problemlos.
Das ist aber ein VDR-Streamdev Slave:
EPG, der epg2vdr/scraper2vdr-Cache und Channels.conf werden beim Start per rsync vom Hauptsystem gezogen (die 5k Aufnahmen brauchen ja schon 15 Min...)
Edit:
Habe allerdings Kernel 5.4.51 (meine ich) laufen, da der Aktuelle mit rpihddevice nicht vernünftig läuft (kein Bild nach umschalten - EPG ist aber da und ok)
Stefan
-
Zusätzlich zu vdr-2.4.5-pat-fix-channels-lock-fail-02.diff oder stattdessen?
Edit: Ersteres. Test läuft.
Stefan
-
Denke, der Patch
vdr-2.4.5-pat-fix-channels-lock-fail-02.diff
ist soweit ok. Hatte zwar in zwei Aufnahmen gestern TS-Cont. Fehler, aber da bei der RPi2 Bastelei was "kurz" blockierte, war es vermutlich nur die Last.
Hat zufällig jemand ein Tool, was nicht die Zahl der TS-Fehler, sondern deren Zeit ausgibt?
Stefan
-
So, der rpi2 auf obigem Patchlevel läuft wieder.
Die rpi-update Firmware ist (zumindest) ab 5.4.79 nicht mit rpihddevice nutzbar.
Mit 5.4.51 gehts wieder. Dann arbeiten wir uns mal Firmwaretechnisch vor, bevor wir den Haupt-VDR anfassen...Stefan
-
Gerade noch schnell eingebaut, Start mit zwei Aufnahmen, VDSB. Hmm.
==> /var/log/vdr.log <==
Dec 11 10:23:10 roadrunner vdr: scraper2vdr: epgd busy, trying again in 60 seconds ...
Dec 11 10:23:14 roadrunner vdr: [7371] ERROR: video data stream broken
Dec 11 10:23:14 roadrunner vdr: [7371] emergency exit request ignored according to setup
Dec 11 10:23:16 roadrunner vdr: [7357] VAAPI-ERROR: video/vaapi: black surface displayed
Dec 11 10:23:16 roadrunner vdr: [7357] VAAPI: video: --:--:--.--- +0 0 0/\ms 0+0 v-buf
Beim zweiten Start ging es aber. Untersuche das später/am WE noch genauer, da gestern auch der per Streamdev angeschlossene RPI nur für das Startprogramm Bild zeigte, nach Umschalten oder bei Abspielversuch Bild weg ... hab' dann erstmal mit was anderem spielen "müssen"...Stefan
-
Ähem ...
Got lost. Was nun?
Stefan
-
Patchstand (quilt series):
#vdr-2.4.5-pat-lock-channels-early.diff
vdr-2.4.5-pat-fix-channels-lock-fail-01A.diff
##vdr-2.4.4-pat-log-GetChannelsWrite.patch
#vdr-2.4.4-pat-fix-shared-pmt.diff
##vdr-2.4.4-pat-lock-channels-resetSid.diffLäuft bisher wie mit dem ersten Klaus'schen diff.
Weitere Tests dann, wenn ich der elterlichen Heizung das F28 abgewöhnt habe
Stefan
-
HelmutB :
Restart mit zwei aktiven CI-Timern:
Fängt sich zwar nach einer halben Ewigkeit, aber ... irgendwas klemmt da mehr als bei Klaus' Fix.
(Läuft auch beim zweiten Versuch in das Problem)
Log per PN.
Stefan
-
HelmutB :
Teste ich nach 22:15
Bisher sieht der ...early-02 sehr gut aus:
bei zwei laufenden CI-Timern kann ich nun sogar einen Aktiven löschen und damit Livebild-Umschalten (nächster CI-Timer) riskieren, ohne daß der VDR die VDSB-Grätsche macht. Fein.
Die Aufnahmen hatten auch keine TS-Fehler.
Stefan
-
Nochmal zum gucken den Patch von Helmut an das Klaus'sche diff angepaßt:
"Gefühlt" wird GetChannelsWrite jetzt häufiger aufgerufen, als ohne diff, aber es scheitert nicht mehr entgültig.
Grüße und Danke,
Stefan
