Hi,
ich bin hier absolut kein Experte, trotzdem mal ein paar Gedanken von mir zum Thema:
Zitat:Es betrifft anscheinend nur die ARD-Sender
Ich kann hier nach ein paar kurzen Versuchen bestätigen, dass Aufnahmen von ARD HD, Arte HD, HR HD beim schnellen Spulen relativ schnell und zuverlässig abzustürzen scheinen. Aufnahmen von 3Sat HD, ZDF HD und WDR HD sowie diverse SD-Aufnahmen sind hier beim Testen jetzt auch bei längerem Spulen nicht abgestürzt. Ob das nur Zufall ist bzw. ich die letzteren Aufnahmen nur nicht lange genug gespult habe oder ob's bei den ersteren ein grundsätzliches Problem gibt kann ich natürlich auch nicht sagen.
Nachdem ja anscheinend das Zusammenspiel von softhddevice mit ffmpeg das Problem ist, mag es vielleicht sein, dass die "ARD Sender" irgendein Feature benutzen, das hier problematisch ist. Ich habe mal spasseshalber eine Arte HD und eine 3Sat HD Aufnahme an mediainfo gefüttert, die Ausgabe sieht schon leicht unterschiedlich aus. Als Laie sagt mir das allerdings nicht viel, und selbst wenn würde es wohl erstmal auch nicht weterhelfen
Zitat:Eine alte VDR Version scheint ohne Probleme zu funktionieren
Die VDR Version ist, wenn ich's richtig im Kopf habe, sowohl bei der Easyvdr-3.0 als auch bei der Easyvdr-3.5 VDR-2.2. Die 3.0 verwendet aber eine andere ffmpeg Version. Mit Easyvdr-3.0 habe ich hier diese Probleme nicht.
Zitat:Meine nächster Schritt wäre eigentlich mal eine komplett neue Installation (auf leerer/ neu formatierter Platte) der V3.5
Hier traten die Probleme direkt nach Installation auf, scheint mir persönlich also eher wenig vielversprechend.
Zitat:Alte Aufnahmen, die früher definitiv keine Probleme machten, crashen jetzt
Die Probleme scheinen (zumindest bei mir) immer häufiger/ intensiver zu kommen - ohne dass ich am System (weder Hardware noch Software) etwas geändert habe
[*]
Falls sich das bestätigt und nicht nur "gefühlt" so ist, könnte da nicht vielleicht auch ein neu aufgetretenes Hardwareproblem eine Rolle spielen?
Zitat:wenn ich Zeit investiere, dann in V4 oder wenigsten eine komplette (leere Platte) Neu-Istallation von V3.5
[*]
Wenn du ein "easy" zu installierendes stabiles System willst, solltest du vielleicht auch die 3.0 in Erwägung ziehen, falls du nicht aus irgend einem Grund unbedingt die neuere Version brauchst.
Hi,
gehört jetzt zwar eigentlich nicht mehr so recht hier her, aber weil's zum Thema passt:
Habe mir gerade auf eine freie Partition die Easyvdr-4 installiert; ein kurzer Spul-Test brachte hier auch bei einer Aufnahme von Arte HD den VDR nach kurzer Zeit zuverlässig zum Absturz. Zur Sicherheit habe ich nochmal kontrolliert, mit der 3.0 scheint mit der Aufnahme alles ok zu sein, kein Absturz auch bei hartnäckigem Spulen.
Das gleiche passierte bei einer kurzen Testaufnahme von ARD HD (beim Abspielen mit der 3.0 scheinbar alles ok).
Andere Arte HD Aufnahmen konnte ich beim kurzen Testen mit der 4 aber nicht zum Absturz bringen, darunter auch eine, die gestern mit der 3.5 zuverlässig Abstürze erzeugt hat.
Fragt sich jetzt ob das jetzt tatsächlich irgend etwas mit den Aufnahmen, bzw. Sendern an sich zu tun hat oder ob da ein gewisser Zufallsfaktor mit rein spielt.
Hi,
Das Softhddevice von der 3.0 in 4.0 zu bauen, könnte man probieren, ob das so einfach geht, weiß ich nicht... Und ob es daran liegt oder am ffmpeg...
Ich bin da aber nicht der Experte, das müsste jemand anderes mal versuchen. Hab im ppa noch nie was gebaut.
Evtl geht auch ein Softhddevice - openglosd oder so...
Mfg Stefan
Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, Mygica t230 Stick als Tuner, nvidia Slim-GT218 512MB PCIe x1 - v3.5-64
VDR2 in Rente
VDR3 in Rente VDR4: MSI G31M2 v2, Intel E5200, 6" t6963c gLCD, 2GB, WD Red 4TB, 2x TT3200, ASUS GT730-SL-2GD3-BRK, mod. Digitainergeh. - v3.5-64 VDR5: GIGABYTE GA-G31M-S2L, Intel E5200, GT630 passiv, 2GB, 3TB, 6" t6963c gLCD, mod. Digitainergeh. - v3.5-64 VDR6: MSI MS-7236, Intel E2140, GT630 passiv, 2GB, WD Green 2TB, 6" t6963c gLCD, 2x TT3200 - v2.5-64 Hilfe gefällig? Dann brauchen wir ein easyInfo aus easyPortal!
Hi,
zum Testen könnte ich das hier ja mal lokal bauen, bin da jetzt aber etwas verwirrt.
Laut vdrinfo ist die Version bei der Easyvdr-3.0 vdr-plugin-softhddevice-0.1.3, bei der Easyvdr-4 sehe ich an der gleichen Stelle "Version: 3".
Auf https://projects.vdr-developer.org/proje...vice/files sehe ich als letzte "offizielle" Version aber 0.6.0, die auch schon sechs Jahre alt ist.
Beim schnellen Websuchen finde ich noch hier: https://github.com/jojo61/vdr-plugin-softhddevice eine Version (vermutlich ein Fork?) ohne spezielle Versionsangabe.
Wo finde ich also die Sourcen der jeweiligen Versionen?
(08.10.2019, 20:02)klappnase schrieb: Laut vdrinfo ist die Version bei der Easyvdr-3.0 vdr-plugin-softhddevice-0.1.3, bei der Easyvdr-4 sehe ich an der gleichen Stelle "Version: 3".
das ist keine Version 3 sondern Version "0.7~git20180203" wie man im changelog des Plugins sieht.
* new upstream snapshot
* sources: https://github.com/rofafor/vdr-plugin-softhddevice
* commit:c99afc2 - Switch to posix compaatible sched_yield
Siehe -> https://git.easy-vdr.de/easyvdr/four/src...it20180203
1:,2: etc. wird benötigt wenn man z.B nee neue Version gebaut hat diese aber nicht so funktioniert
wie angedacht.Deshalb setzt man ein 1:,2: etc. vor die alte Version da Launchpad(PPA) keine andere
Möglichkeit bietet.Siehe auch FFmpeg -> ffmpeg-7:3.4.4-2easyVDR0~bionic
Achtung mit dem Sources.Meine das auch der Fork von jojo61 nicht mehr mit VDR-2.2.0 kompatibel
ist.Github rofafor dort wurde alles mit nvidia enfernt nur noch vaapi.
Zuvor hies das Plugin softhddevice-vpp das man nach anpassen des Makefiles für
Nvidia oder Intel nutzen konnte.Dies waren auch die letzten Versionen die noch mit VDR-2.2.0 kompiliert
werden konnten.Das Plugin auf "https://projects.vdr-developer.org" hat keinen Maintainer mehr.
Plugins von ea-3.5 zu ea-4.0 sind mit wenigen Ausnahmen die gleichen Versionen.
P.P.S
Da das Problem beim Spulen nicht bei allen HD-Sendern auftritt,kann es nur am Stream der Anbieter liegen.
libavcodec steigt da ja nicht ohne Grund aus.Das nvidia danach auch aussteigt,ist vmlt. eine Folgereaktion.
Hallo,
danke für die Klarstellung.
Dann habe ich also, wenn ich das jetzt richtig aus den Changelogs sehe, bei der Easyvdr-4 die 0.7~git20180203, bei der 3.5 die 0.6.1rc1.git20171212 und bei der 3.0 die 0.6.1rc1.git20151103, die Sourcen für letztere sind dann wohl hier: https://git.easy-vdr.de/easyvdr/trusty-n...it20151103
Wenn sich das auf der 3.5 bzw. der 4 noch bauen liesse, könnte das ja mal einen Versuch Wert sein, aber ich schätze es gibt ja sicherlich einen Grund, dass ihr auf die neuere Version gewechselt habt.
Hatte schon mal spasseshalber versucht, mir die Sourcen herunterzuladen, aber für den Zugriff muss man wohl freigeschaltet sein (oder ich bin nur zu blöd)?
Mit der 3.5 baut das Paket und funktioniert auch zumindest soweit, dass der VDR startet und läuft. Ein erster Spultest mit einer Aufnahme die vorher immer gern Abstürze produziert hat sah auch vielversprechend aus
Um zu wissen ob's stabil läuft muss natürlich erstmal noch ausführlich getestet werden.
Mit der Easyvdr-4 bricht das Kompilieren ziemlich schnell mit einer Fehlermeldung ab:
Code:
In file included from softhddevice.cpp:46:0:
video.h:63:13: error: use of enum ‘PixelFormat’ without previous declaration
extern enum PixelFormat Video_get_format(VideoHwDecoder *, AVCodecContext *,
^~~~~~~~~~~
video.h:64:16: error: use of enum ‘PixelFormat’ without previous declaration
const enum PixelFormat *);
^~~~~~~~~~~
softhddevice.cpp: In member function ‘virtual eOSState cSoftHdMenu::ProcessKey(eKeys)’:
softhddevice.cpp:2168:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
HotkeyState = HksInitial;
~~~~~~~~~~~~^~~~~~~~~~~~
softhddevice.cpp:2169:2: note: here
case HksRed: // red and first number
^~~~
<eingebaut>: recipe for target 'softhddevice.o' failed
ebenso wie mit der 3.5 wenn man statt der "opti"-Versionen der ffmpeg-libs die *-dev Pakete der neueren "easyvdr"-Versionen verwendet (hab ich spasseshalber auch mal probiert). Sieht aus, als will diese Plugin-Version halt nicht mehr mit dem neueren ffmpeg.
Ich habe das Paket mal angehängt, falls Lincoln oder jemand anderes das mal ausprobieren möchte.
(10.10.2019, 20:04)klappnase schrieb: Mit der 3.5 baut das Paket und funktioniert auch zumindest soweit, dass der VDR startet und läuft. Ein erster Spultest mit einer Aufnahme die vorher immer gern Abstürze produziert hat sah auch vielversprechend aus
wenn das Plugin unter EA-3.5 gebaut werden kann,liegt das an ffmpeg-2.8 aus PPA 3.0-base-stable.
Wie ist die Ausgabe von
Code:
apt-cache policy libavcodec-ffmpeg-opti-dev
depends z.B mit "libavcodec"
softhddevice aus EA-3.0 -> depends zu libavcodec-ffmpeg-opti-dev
softhddevice aus EA-3.5 -> depends zu libavcodec-ffmpeg3-dev
softhddevice aus EA-4.0 -> depends zu libavcodec-dev
(10.10.2019, 20:04)klappnase schrieb: In file included from softhddevice.cpp:46:0:
video.h:63:13: error: use of enum ‘PixelFormat’ without previous declaration
extern enum PixelFormat Video_get_format(VideoHwDecoder *, AVCodecContext *,
^~~~~~~~~~~
video.h:64:16: error: use of enum ‘PixelFormat’ without previous declaration
const enum PixelFormat *);
^~~~~~~~~~~
softhddevice.cpp: In member function ‘virtual eOSState cSoftHdMenu:rocessKey(eKeys)’:
softhddevice.cpp:2168:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
HotkeyState = HksInitial;
~~~~~~~~~~~~^~~~~~~~~~~~
softhddevice.cpp:2169:2: note: here
case HksRed: // red and first number
^~~~
<eingebaut>: recipe for target 'softhddevice.o' failed
Yep,hier fehlen die Anpassungen für ffmpeg -> 3.xx
habe gerade keinen Zugriff auf die 3.5, aber die lib*-ffmpeg-opti-dev Pakete sind auf jeden Fall jetzt alle installiert, sonst hätte (wie ich dann auch gemerkt habe) das mit dem Bauen ja nicht funktioniert.
Hi,
DVB-T2 ist das nicht (wenn in Deutschland). Das ist DVB-T2 HD und somit h. 265. Das ist etwas völlig anderes, da anderer Codec.
Deutscher Sonderweg...
Mfg Stefan
Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, Mygica t230 Stick als Tuner, nvidia Slim-GT218 512MB PCIe x1 - v3.5-64
VDR2 in Rente
VDR3 in Rente VDR4: MSI G31M2 v2, Intel E5200, 6" t6963c gLCD, 2GB, WD Red 4TB, 2x TT3200, ASUS GT730-SL-2GD3-BRK, mod. Digitainergeh. - v3.5-64 VDR5: GIGABYTE GA-G31M-S2L, Intel E5200, GT630 passiv, 2GB, 3TB, 6" t6963c gLCD, mod. Digitainergeh. - v3.5-64 VDR6: MSI MS-7236, Intel E2140, GT630 passiv, 2GB, WD Green 2TB, 6" t6963c gLCD, 2x TT3200 - v2.5-64 Hilfe gefällig? Dann brauchen wir ein easyInfo aus easyPortal!
11.10.2019, 13:16 (Dieser Beitrag wurde zuletzt bearbeitet: 11.10.2019, 14:19 von mango.)
Hallo!
(11.10.2019, 00:19)klappnase schrieb: habe gerade keinen Zugriff auf die 3.5, aber die lib*-ffmpeg-opti-dev Pakete sind auf jeden Fall jetzt alle installiert, sonst hätte (wie ich dann auch gemerkt habe) das mit dem Bauen ja nicht funktioniert.
OK,dann ist nur Plugin sofhddevice gegen ffmpeg-2.8.6 gebaut.Andere Plugins unter EA-3.5 die nee depends zu ffmpeg haben nutzen aber ffmpeg-3.3.0
Wenn das mischen der Versionen keine Probleme verursacht,warum nicht.
Freie Software,jeder kann wie er will!
(11.10.2019, 12:48)SurfaceCleanerZ schrieb: Deutscher Sonderweg...
Ja, Sonderregelungen/Sonderwege von D-Land sind ja bekannt.Schreien ein paar Lobbyisten
laut genug,ist der Gedanke vereintes Europa schnell vergessen.
Zitat:OK,dann ist nur Plugin sofhddevice gegen ffmpeg-2.8.6 gebaut.Andere Plugins unter EA-3.5 die nee depends zu ffmpeg haben nutzen aber ffmpeg3-3.3.0
Wenn das mischen der Versionen keine Probleme verursacht,warum nicht.
das war mir so jetzt nicht bewusst. Mein Bauchgefühl sagt mir da "keine gute Idee" (aber was weiss schon der Bauch...).
Habe gerade noch mal was anderes versucht, und zwar habe ich gesehen, dass Debian Patches hat mit denen ältere Versionen des Plugins ffmpeg3-kompatibel werden. Habe mir dann spasseshalber mal die Debian-Sourcen von https://packages.debian.org/source/stret...fthddevice heruntergeladen. Ist mir jetzt nicht ganz klar woher die eigentlich stammen, sieht aber ein bisschen so aus, als wäre das noch die Original-Johns-Version, vermutlich irgendwie gepatcht.
Habe dann mal versucht, das Paket zu bauen, allerdings erstmal nur unter Easyvdr-4. Dazu musste ich im debian/rules File erst noch die Zeile
Code:
dh $@ --with vdrplugin
ändern nach
Code:
dh $@
(das vdrplugin ist offenbar ein Debian-spezifisches Perl-Skript, das sicherlich auch irgendwas macht), dann hat es hier auch gebaut (btw: ffmpeg und die dazugehörigen libs habe ich hier in den "easyvdr"-Versionen, nicht die Ubuntu-Bionic Versionen installiert, ich nehme an, das sind die richtigen?).
Nach Installation des so gebauten Pakets und Neustart des VDR läuft das jetzt auch, die ersten Spultests sahen auch gut aus. Kann natürlich sein, dass die Abstürze später noch kommen, oder dass Spulen funktioniert und es dafür an anderer Stelle knirscht...
Ich hab das so gebaute .deb mal angehängt, falls jemand das mal testen möchte.
Zitat:Kann natürlich sein, dass die Abstürze später noch kommen,
ist leider so, lange genug gespult, dann stürzt der VDR doch wieder ab, ältere Plugin Version mit ffmpeg3 bringt hier also nichts.
Habe danach noch eine Weile die 3.5 mit dem gegen ffmpeg-2.8 gebauten Plugin getestet. Hier gab's bisher bei etlichen Spulversuchen keine Abstürze. Der Verdacht drängt sich auf, dass softhddevice womöglich grundsätzlich ein Problem mit ffmpeg3 hat.
Zitat:Wenn das mischen der Versionen keine Probleme verursacht,warum nicht.
So weit um das zu testen kommt man dann leider nicht wg. Abhängigkeitskonflikten (libavcodec56-ffmpeg zieht sich libkvazaar, was im Konflikt mit libkvazaar3 steht, welches von libavcodec-ffmpeg57 benötigt wird); z.B. vdr-plugin-mpv (vermutlich auch diverses anderes) lässt sich deshalb nicht mehr installieren.
(11.10.2019, 14:30)klappnase schrieb: das war mir so jetzt nicht bewusst. Mein Bauchgefühl sagt mir da "keine gute Idee" (aber was weiss schon der Bauch...).
Wie bereits geschrieben kann das jeder halten wie er will!
Diese Patches sind in neuren Version bereits includiert!
(11.10.2019, 14:30)klappnase schrieb: Habe dann mal versucht, das Paket zu bauen, allerdings erstmal nur unter Easyvdr-4. Dazu musste ich im debian/rules File erst noch die Zeile
Code:
dh $@ --with vdrplugin
ändern nach
Code:
dh $@
Das liegt an vdrargs das von e-tobi für die Plugins eingeführt wurde.Mit dem Script vdrctl(CReimer) kann man dann
Plugins enable/disable oder auch Prio sowie die Startparameter der Plugins ändern
Jedes Plugin hat eine *.conf in dem dann die Parameter gesetzt werden.
Da wir jedoch noch das setup Plugin verwenden,ist der Parameter "--with vdrplugin" obsolet.
Mehr dazu-> https://www.yavdr.org/documentation/0.6/de/ch01s06.html
Da sich das setup Plugin aber nicht mehr mit >> VDR-2.3.x/2.4.x übersetzen lässt müssen
wir auch auf Plugin menuorg und vdrargs umstellen,wenn wir z.B VDR-2.4.1 nutzen wollen.
Dies ist jedoch ein riesen Aufwand da Setup-Tool,Scripte,easyPortal etc. auf Plugin setup
zurückgreifen.
(11.10.2019, 16:46)klappnase schrieb: So weit um das zu testen kommt man dann leider nicht wg. Abhängigkeitskonflikten
(libavcodec56-ffmpeg zieht sich libkvazaar, was im Konflikt mit libkvazaar3 steht, welches von libavcodec-ffmpeg57 benötigt wird);
z.B. vdr-plugin-mpv (vermutlich auch diverses anderes) lässt sich deshalb nicht mehr installieren.
Das liegt halt an den unterschiedlichen Versionen von ffmpeg,dass ja auch noch Abhängigkeiten zu anderen Paketen hat.
Auch bei install Paket easyvdr/easyvdr-depends sind die Versionen von ffmpeg als depends vorhanden.
Wer keine Ausgabe über Intel-GPU oder DVB-T2(HEVC) benötigt,kann auch bei EA-3.0 bleiben.
P.S
Pakete die man selbst übersetzt(*.deb) sollte man nach install auf hold setzen da sonst das Paket
bei apt upgrade wieder das standard Paket installiert wird.
z.B
danke für die Erläuterungen (und für deine Geduld!).
Zitat:Wer keine Ausgabe über Intel-GPU oder DVB-T2(HEVC) benötigt,kann auch bei EA-3.0 bleiben.
Werde ich jetzt auch so machen; die Experimente mit der 3.5 schienen erstmal einen Versuch wert, aber letztlich schaffe ich mir damit nur neue Baustellen. Werde dann mal lieber versuchen, die verbliebenen Baustellen in der 3.0 hinzubekommen und eventuelle Experimentierwut auf die 4 verlagern
rocessKey(eKeys)’:
