@Inj
Thank you for that information.
If you mean with latest Intel GPU the UHD7xx of the 11th and 12th generation of Intel CoreI CPUs, needing the iHD driver for va-api, it is a problem to test that with the current version of MLD.
The current version 5.5 of MLD does only support va-api on Intel-GPUs up to the 9th generation of Intel CoreI CPUs, because the used mesa version (18.3.6) does not yet have the iHD driver.
@ Inj
I just tested new Version 1.9.6 in MLD 5.5 unstable and it works fine.
Thanks a lot!
VDPAU.
Mit Cuvid verpixelt das Bild beim Umschalten kurz. Nicht doll, aber doch störend. VDPAU läuft perfekt.
Ich habe mittlerweile die ersten Tests mit einer nVidia GT630 und GT1030 und VDPAU gemacht.
CUVID kann ich mit MLD sowieso nicht testen, da es aufgrund von Problemen mit dem alten Legacy Treiber deaktiviert wurde.
Ich kann deine Aussage bestätigen, dass die GT1030 (Pascal GPU) das Problem nicht hat.
Ich habe sowohl den 390.144 (Paket xorg-nvidia) als auch den 515.76 (xorg-nvidia.latest) positiv getestet.
Der alte Legacy Treiber 340.108 (xorg-nvidia.legacy) läuft mit der GT1030 sowieso nicht.
Update: Beim 390.144 tritt das Problem mit der GT1030 doch sporadisch auf.
Nur beim 515.76er Treiber tritt das Problem nicht auf.
Bei der GT630 (Keppler GPU wie bei GT710) tritt das Problem sowohl mit dem Treiber 340.108 als auch 390.144 auf.
Mit dem 390.144 gibt es außerdem OSD-Probleme, von denen im MLD-Forum schon vorher in Verbingung mit älteren nVidia-GPUs (GT7XX und GT6XX) berichtet wurde, weshalb dieser Treiber für diese GPUs nicht geeignet ist.
Noch ältere GPUs laufen sowieso nur mit dem Legay-Treiber und haben somit auch alle das Problem.
Es hängt also von der Kombination aus nVidia Treiber und nVidia-GPU ab, ob das Problem auftritt oder nicht.
Thanks a lot.
In the meantime version 1.9.3 is a workaround for MLD 5.5
Va-api confirmed, I'll look it.
Vdpau and cuvid no problems, I'll test yet.
As I wrote in my post before, I will do some tests with nvidia.
The MLD user who reported the Problem with a GT710 used an older nvidia driver 340.108.
Maybe this old driver causes the problem and the newer drivers not.
Die Aufnahme wird bei mir völlig normal abgespielt.
Du verwendest ja eine nVidia GT1030 mit nVidia-Treiber 470.141.
Evtl. gibt es ja das Problem mit einer aktuelleren nVidia-GPU und einem aktuelleren Treiber wie dem 470.141 nicht.
Verwendest du bei softhddevice VDPAU oder CUVID?
Ich selbst habe das Problem noch nicht versucht mit nVidia-GPUs zu testen.
Ich verwende derzeit produktiv nur Intel-GPUs (HD500, HD630, UHD605 und UHD630) und bei allen tritt das Problem auf.
Ein MLD-User der das Problem mit einer nVidia-GPU (GT710) berichtet hat, verwendet einen alten Legacy nVidia-Treiber 340.108.
Ich baue mal heute Abend ein Testsystem auf nVidia um und teste mal mit einer älteren GT630 und einer GT1030 sowie den jeweils passenden Treibern.
Als neuere Treiber für die GT1030 sind 515.76 und 390.144 in MLD 5.5 enthalten
Die GT630 kann ich mit dem Legacy nVidia-Treiber 340.108 und dem 390.144 testen.
Ich werde berichten, was dabei herauskommt.
There is a problem when playing a record or only in live mode?
If there is a problem when playing a record, please upload the record.
The problem is more critical in live mode but I have it also in recordings.
When playing recordings the sound problems are starting after some seconds but it takes often more than a minute till the video also starts stuttering and problems with artefacts are starting.
I did some tests with the ZDF HD channels by recording and then playing the recordings on a system with softhddevice 1.9.3
On this system (va-api) live tv an playback of all recordings are OK.
In the recording list of the plugin live these recordings are all marked as OK.
Then I transfered this recordings to a second system (va-api) with softhddevice 1.9.5.
When playing this recordings on this systems after a few seconds the problems are starting with the stuttering sound.
One of these recordings i uploaded on my dropbox
https://www.dropbox.com/scl/fo…4u6fanj480okmk9pgz3by1upl
I can provide other recordings if needed.
Hollo Zusammen,
ich nutze mittlerweile MLD 5.5 testing auf einigen meiner VDR's und habe zusammen mit anderen MLD-Usern das Problem, dass seit einigen Tagen nach einem Dist-Upgrade bei den Sendern ZDF HD und ZDF Neo HD sofort nach dem Umschalten auf diese Sender das Bild zu ruckeln beginnt.
Außerdem gibt es Artefakte und Tonstörungen.
Wir konnten im MLD-Forum eingrenzen, dass dieses Problem seit dem Update von softhddevice auf die Version 1.9.5 besteht.
Bei den Versionen 1.9.3 und 1.9.4 tritt das Fehlerbild noch nicht auf.
Hier mal der Link zu diesem Thema im MLD-Forum
ZDF HD und ZDF Neo HD ruckeln...
Meine Vermutung war, dass diese Änderung vom 01.11.2022 die in Version 1.9.5 eingeflossen ist, evtl. das Problem verursacht.
Fixed interlace detection. Fixed VDPAU half resolution (720x288, 1920…
Wie man hier sieht ist nicht nur VDPAU sondern auch VA-API von den Änderungen betroffen.
Wir konnten das Problem auch sowohl auf Systemen mit nVidia-GPU (VDAPU) als auch mit Intel-GPU (VA-API) eingrenzen.
Kann jemand, der nicht MLD aber die aktuelle Version 1.9.5 von softhddevice nutzt, dieses Problem bestätigen?
Evtl. ist das Problem ja auch schon beim Entwickler von softhddevice bekannt.
Gruß
Klaus
Das AsRock Q1900 ITX hat 1 PCIe 2.0 x1, 1 mini-PCIe drauf und dazu könntest du auch dann die oben genannte Riser Karte verwenden.
http://www.asrock.com/mb/Intel/Q1900-ITX/index.de.asp?cat=
Mit diesem MB kann man aber weder die Riser-Karte noch eine DD Octopus verwenden, da diese einen miniPCIe Steckplatz mit voller Bauhöhe benötigen.
Das MB hat aber nur einen miniPCIe halber Bauhöhe für z.B. WLan-Karten.
@ Boss666
Dein HDReady wird also laut xrandr mit 50Hz angesteuert.
1280x720 50.0*+
Du hast als schon mal kein 60Hz-Problem.
Dass dein HDReady-TV mit 50Hz angesteuert wird, hatte ich nach dem Test mit meinem alten HDReady-LCD (ein 32" ITT LCD-TV von 2005) fast vermutet.
Meiner wird bereits vor dem Start von X per KernelModeSetting (KMS) mit 1280x720@50Hz (also 720p) angesteuert.
Da bräuchte ich für 720p also überhaupt keine speziellen Settings in der xrog.conf.
Mich hatte schon gewundert, dass in deiner xrog.conf keine Modeline für 720p enthalten ist.
Vermutlich wird auch dein HDReady bereits per KMS mit 720p angesteuert, was beim Start von X übernommen wird und Du könntest deine xorg.conf auch löschen.
Nachdem ich in meiner xorg.conf die Modline für 720p angepasst hatte, funktioniert jetzt auch 720p auf meinen FullHD-TVs.
Aber wie gesagt, brauchst Du für 50Hz keine andere xorg.conf, da bei Dir die Video-Ausgabe sowieso mit 1280x720@50HZ läuft.
Die Video-Qualität von SDTV mit 720p auf meinem HDReady ist zwar nicht so gut, wie bei den FullHD-TVs mit 1080p (oder auch 720p), ist aber auch nicht schlechter, als SDTV -> 720p mit einem nVidia-Sytem auf diesem HDReady-TV.
Es ist halt ein 9 Jahre altes HDReady LCD-Panel, das von der Qualiät einfach nicht an die neuen FullHD LED-Panels ran kommt.
So schlecht, wie Du SDTV bei Dir beschrieben hast, ist es aber definitiv nicht.
Wie gesagt, die Video-Qualität ist vergleichbar mit der eines nVidia-Systems auf dem gleichen HDReady-TV.
Daran, dass dein TV nur 720p kann, scheinen deine SDTV Problem also nicht zu liegen.
@ Boss666
Der Hinweis von johns richtet sich vermutlich an mich und meinen Versuch SDTV über die Readeon per 720p auf einem FullHD-TV auszugeben.
Ich hatte das aber nur mangels eines griffbereiten HDReady-TV gemacht, da ich mir grundsätzlich mal anschauen wollte, wie SDTV auf 720p mit der Radeon ausschaut und ob ich da auch solche Probleme habe, wie Du.
Normal gehe ich immer direkt mit 1080p auf meine FullHD-TVs und somit sollte SDTV nur einmal über softhddevice und die GraKa nach 1080p skaliert werden.
Den Test mit SDTV -> 720p mache ich heute Abend mal mit meinem alten HDReady-TV.
Bezügl. xrandr versuche es mal auf Konsole oder über putty mit:
xrandr -d :0Kannst Du Dir bei deinem Monitor anzeigen lassen, ob er mit 50Hz oder 60Hz angesteuert wird?
Wenn ja, was kommt da beim Monitor an?
Im log sehe ich nur, dass HDMI-0 mit 1280x720 angesteuert wird, aber nicht ob mit 50 oder 60Hz.
[ 21.640] (II) RADEON(0): Output HDMI-0 using initial mode 1280x720
Ich habe mal bei zwei meiner FullHD-TVs versucht, diese von einem AMD-System mit 1280x720@50HZ anzusteuern zu lassen.
Ich bekomme nur mit 1280x720@60HZ ein Bild.
Mit 1280x72@50Hz wird beim Start von X der Bildschirm mit der Meldung "Nicht unterstützter Modus" schwarz.
Mit einer nVidia bekomme ich an diesen TVs auch 1280x720@50Hz angezeigt.
Mit 1280x720@60HZ ist die Bildqulität bei SD-Kanälen zwar schlechter als mit 1080p, aber nicht so grotten schlecht, wie Du es beschrieben hast.
Ich hab noch einen HDReady-TV, an den ich aber heute nicht mehr rankomme.
Ich werde Morgen mal schauen, ob ich dort 1280x720@50Hz angezeigt bekomme.
Poste bitte auch noch deine aktuelle xorg.conf.
Hi Boss666,
ich teste seit ca. 3 Wo. AMD-VDPAU mit mehreren ITX-Kabini-MBs (AM1-MBs von Asrock, Asus und MSI mit 5350, 5150 und 3850 CPUs sowie ein Biostar mit fest verlöteten Kabini) unter Gentoo (modifizierte Gen2VDR V4 Distri).
Unter meinen Test ITX-MBs ist auch das Biostar A68N-5000 mit fest verlötetem Athlon A4-5000, wie Du ihn auch nutzt.
Bei mir läuft SD über HDMI mit 1080p (1920x108050Hz) astrein.
Mit 720p habe ich bisher noch nicht getestet, kann ich aber mal nachholen.
Hängt dein HDreadyTV am HDMI-Ausgang?
Bist Du Dir sicher, dass X11 tatsächlich mit 720p (1280x720@50Hz) läuft.
Kannst Du mal eine aktuelle xorg.0.log posten.
Gruß
franky93128
Das streamen funktioniert bei den meisten Kanälen problemlos. Nur bei ARD, ZDF und einigen der dritten Programmen funktioniert es nicht. Welche nicht funktionieren hat irgendwie auch kein Muster. Es liegt nicht an Transponder oder Umlauten im Kanalnamen, weil andere Sender des Transponders usw funktionieren.
....
Kann sich zufälliger weise einer vorstellen woran das liegen kann?
Hallo Andreas,
bist Du dir sicher, dass andere Sender vom ARD und ZDF-Transponder funktionieren?
Welche Sender sind das denn?
Das Problem liegt eindeutig beim Server und nicht beim Client.
An dieser Meldung des Servers sieht man, dass xvdr keinen oder keinen brauchbaren Datenstrom geliefert bekommt, um den Stream aufzubauen und deshalb die Verbindung zum Receiver unterbrochen wird.
Sep 27 23:30:58 server vdr: [24382] XVDR: returning from streamer thread, receiver is no more attached
Sep 27 23:30:58 server vdr: [24382] XVDR: sending detach messageDie Ursache ist aus den wenigen Informationen nicht erkennbar.
Gruß
Klaus
...
Nach dem auch decode_MPG2 aktiviert ist, kommt über RPi nun bei SD für ca 2-3 Sekunden Bild. Danach kommt wieder Das Bild mit dem Sessel.
HD geht nun nicht mehr.
Auf dem Tablet stürzen nun SD Kanäle ab. Die App verschwindet und muss neu gestartet werden. HD läuft noch.
Hab den vdr vorsoglich neu gestartet - ohne das es was gebracht hätte.
Hallo Jürgen,
bei Dir laufen ja neben vnsi noch weitere Streamingserver.
Greifen da evtl. zur gleichen Zeit noch andere Clients parallel auf den vompserver bzw. streamdev-server zu?
Bei 2 Tunern wird das dann schon problematisch.
Hast Du evtl. mal ein log des vdr?
Gruß
Klaus
...
Nun bekomme ich von den SD Programmen laufenden Ton, - aber immer noch kein Bild.
Hallo Jürgen,
Ton bei SD bekommst Du auch ohne MPEG2-Lizenz.
Bei SD kein Bild aber Ton kann auch bedeuten, dass der MPEG2-Lizenz-code nicht funktioniert.
Bist Du Dir sicher, dass Du die Lizenz korrekt eingetragen hast.
Der Lizenz-Code muss ja in die config.txt, auf der Boot-Partition, die beim Booten gelesen wird.
Bei Openelec gibt es ja bereits einen Abschnitt für die Lizenz-codes, die Beispiele in der richtigen Schreibweise enthält.
Die Beispiele kannst Du natürlich verwenden, musst dann halt am Zeilenanfang das # entfernen.
Hast Du nach dem Eintragen der Lizenz auch neu gebootet?
Gruß
Klaus
...
Hat mier auch die datei erzugt und ich habe mein Netz angepaßt.Dennoch bekomme ich fehler vom openELEC vnsi adon - es verbindet sich nicht.
Ein Rat für mich?
Lg
Jürgen
Hallo Jürgen,
das /etc/vdr/plugins/vnsiserver4 deutet darauf hin, dass Du dir den vnsiserver aus dem falschen Branch (vermutlich master-Branch von Opdenkamp) geholt hast.
Der vnsiserver4 unterstützt nur Clients mit dem neuen Protokoll4, weshalb sich der RPI nicht verbinden kann.
Denn die VNSI-PVR-Clients in OpenelElec für den RPI (ich habe Openelec 3.0.6 im Einsatz und auch 3.1.7 getestet) brauchen noch vnsiserver3 mit Protokoll3.
VNSI-PVR-Client und vnsiserver müssen immer die gleiche Protokoll-Version unterstützen.
Den vnsiserver3 findest Du im Frodo-Branch des Opdenkamp-Git
Seahawk hatte doch einige Beiträge weiter oben beschrieben, wie man nach zum frodo-Branch wechselt.
Alternativ kannst Du auch gleich den frodo-Branch clonen.
Ich mache das z.B. so:
git clone https://github.com/opdenkamp/xbmc-pvr-addons.git -b frodo xbmc-pvr-addons-ODK-frodo.gitGruß
Klaus
Hi,
Ich steh auf dem schlauch. Hab die files aus Git geholt. Und dachte ich kann sie nach /usr/local/src/VDR/PLUGINS/src copieren und dann den VDR mit Plugins compilieren.
Kann kein HowTo finden noch steht im VDR Wiki auf der VNSI plugin seite wirklich eine tolle Beschreibung.
RPi OpenELEC mit VNSI addon läuft schon.
Danke für n tip.
Hi,
wenn deine Signatur noch stimmt, würde ich sagen, dein vdr-1.7.15 ist zu alt für das aktuelle vnsiserver-Plugin.
Ich hatte auch schon vergeblich versucht aktuelle vnsiserver-Versionen aus dem git von Opdenkamp und FernetMenta mit 1.7.16, 1.7.18 und 1.7.21 zu bauen.
Ich habe nicht alle vdr-Versionen nach 1.7.21 getestet, aber mit vdr-1.7.31, 2.0.0 und 2.0.2 haben sich die aktuellen vnsiserver-Versionen bei mir einwandfrei bauen lassen.
Gruß
Klaus
Hallo Pit,
ich hatte das gleiche Problem, als ich einen älteren Samsung (UE37D5700) gegen einen neuen F-Serie Samsung (UE40F8090) getauscht habe, an dem ein VDR mit ION1-MB (AT3IONT-I deluxe) angeschlossen war.
Am alten D-Serie Samsung hatte ich Ton am neuen F-Serie keinen.
Ich habe außerdem noch einen UE40D6500 und einen UE40F6500.
An diesem 6500er F-Serie Samsung war ein VDR (Zotac D2550 Wifi mit GT610 onboard) angeschlossen, mit dem ich Ton hatte.
Ich hatte dann die VDRs an den F-Serie Samsungs getauscht und wieder keinen Ton am ION1-VDR.
Auch mit zwei weiteren ION1 Systemen (AT3IONT-I und Zotac ION-G-E) das gleiche Ergebnis - kein Ton an den F-Serie Geräten aber Ton an den beiden D-Serie Geräten und einem älteren ITT LCD-TV.
Andere VDRs mit G210 und GT610 hatten Ton an den F-Serie-Geräten und auf allen VDRs war die gleiche VDR-Distri Gen2VDR (V3 und V4) installiert.
Daher war mein erster Verdacht, dass die ION1-Systeme ein generelles Problem mit den neuen 2013er Samsung-TVs haben.
Letztendlich gab es dann aber doch einen gravierenden Unterschied bei den Systemen und das war der nVidia-Treiber.
Bei einem weiteren ION1 Systeme (ebenfalls ein Asus AT3IONT-I) hatte ich nämlich plötzlich doch Ton an beiden F-Serie Samsungs.
Ich habe dann herausgefunden, dass dieses ION1-System noch einen "alten" nVidia-Treiber 295.75 installiert hatte.
Bei allen VDRs ohne Ton hatte ich mal einen "neueren" nVidia-Treibern von 310.19 bis 325.08 installiert.
Ich hatte dann verschiedene Treiber Versionen neuer als 295.75 getestet und bis zum 304.88 Ton an den F-Serie Geräten.
Darauf hin habe ich auf den ION1-Systemen ohne Ton ein Downgrade auf 304.88 gemacht und danach bei allen wieder Ton an beiden F-Serie Geräten.
Ich vermute mal, dass Du das Problem mit deinem VDR1 (Zotac ION-ITX, wahrscheinlich ION1) hast und der Samsung-TV neuer als die D-Serie (also E- oder F-Serie) ist.
Der aktuelle nVidia-Treiber bei MLD, das Du ja verwendest, ist laut MLD-Homepage 319.32, mit dem auch meine ION1 keinen Ton an meinen neuen Samsung-TVs hatten.
Wenn diese Annahmen (ION1 und neuer Samsung-TV) bei Dir zutreffen, würde vermutlich auch ein Downgrade des nVidia-Treibers auf Version 304.88 oder niedriger helfen.
Bei MLD habe ich aber keine Ahnung, wie man ein Downgrade des nVidia-Treibers durchführen könnte.
Gruß
Klaus
Alles anzeigenHallo Klaus,
Das stimmt so nicht ganz.
Ich habe im November 2012 einen VDR mit dem Zotac D2550 und einer Cine S2 V5.5 aufgebaut und er läuft noch heute bei meinem Vater. Siehe Beitrag Qvdpautest Zotac D2550.
Weiterhin kann man die älteren CineS2 auf eine CineS2 V5.6 bei Linux4Media upgraden lassen, Upgrade zur CineS2 V5.6 und somit dürfte sie auch ohne den Kernelparameter in einem D2550 laufen.
Ciao Stefan
Hallo Stefan,
ich hatte letzten November mit dem Zotac D2550 alle Typen der Micronas-Karten (CineS2 V5.4 und 5.5 bzw. PCIe- und miniPCIe-Bridge) erfolglos getestet.
Der freie miniPCIe-Slot (volle Höhe) beim Zotac D2550 scheint besonders problematisch zu sein, da er laut HB anscheinend nur für mSATA-SSDs geeignet ist.
Gleiche Probleme hatte ich bei einem Intel D2700MUD (GT610 im PCI-Slot - miniPCIe frei) mit der miniPCIe-Bridge.
Sobald eine DD-Karte mit Micronas-Chip eingebaut war, konnte bei beiden MBs überhaupt nicht mehr gebootet werden.
Nach ausfühlichen Kontakt mit dem L4M-Support, hatte ich dann Ende November die abschließende Nachricht erhalten, dass sämtliche Modelle mit ngene- (Micronas-) Chip nicht mit CDT arbeiten.
Außerdem könne man derzeit nicht davon ausgehen, dass es hier noch ein Update geben wird und dass es auch zweifelhaft ist, ob das Problem hier überhaupt softwareseitig lösbar wäre.
Die Lösung wäre jedoch eine CineS2 V5.6 bzw. V6.X oder eine Octopus-Bridge, da es sich bei dem neuen Chip um ein FPGA handelt, bei dem eben einiges über Software (Firmware) korregiert werden kann und hier auch schon eine Lösung gefunden wurde, die man auch bei älteren Karten per FW-Upgrade einspielen kann
Mir wurden auch Tauschangebote (gegen Aufpreis) für die CineS2 V5.5 in V5.6 sowie die Micronas-Bridges in Octopus-Bridges gemacht.
Ich hatte dann das Tauschangebot für die Bridges angenommen, da ich noch keine Octopus-Bridges hatte.
Meine erste CineS2 V6.2 war damals in einem ION-MB verbaut, in dem ja auch die V5.5 problemlos läuft.
Da hab ich dann lieber die CineS2 durchgetauscht und den Aufpreis für das L4M-Tauschangebot eingespart.
Ich musste dann nur festgestellen, dass die V6.2 doch eine zu alte FW drauf hatte, da das D2550 zwar mit eingebauter CineS2 V6.2 gebootet hat, aber keine frontends vorhanden waren.
Nach dem Update der FW (auf einem anderen Windows-System) läuft die V6.2 seitdem ohne Probleme im D2550 (immer alle frontends vorhanden).
Dass dieser Kernelparameter "nolapic" das Problem mit CineS2 V5.5 im D2550 lösen kann, war mir bis heute unbekannt, weshalb ich es auch nie getestet hatte.
Ich hab mal etwas gegoogelt und herausgefunden dass mit "nolapic" als Nebeneffekt nur noch ein Kern einer Multi-Core-CPU, wie der D2550, nutzbar ist.
Hast Du eigentlich noch andere Nebeneffekt, wie evtl. Beeinflussung des ACPI-Wakeup, feststellen können?
Gruß
Klaus
