Beiträge von frosch01

Zitat von seahawk1986

Der Zweig für VAAPI wird soweit ich weiß getrennt weiterentwickelt (vgl. [Announce] VA-API/VPP Support for vdr-plugin-softhddevice https://github.com/pesintta/vdr-plugin-softhddevice

Das ist ja schon mal prima. Vielen Dank für die Info. Kennnt jemand einen Status?

Ich lasse mich seit einigen Monaten nur noch vom yavdr Service verwöhnen. Ich müsste also erst mal wieder anfangen zu basteln und dazu müsste ich erst mal Intel HW kaufen.

Zitat von 3PO

Ehrlich gesagt, kann ich Intel verstehen, wegen den paar Leuten, die Linux als Desktop OS verwenden, würde ich auch keine Zeit und Geld in die Treiberentwicklung stecken....

Ich sehe das defintiv anders. Linux ist im Multimedia-Bereich Standard. Oder kennt jemand noch ein Embedded Gerät, auf dem Windoof XXX läuft - außer den 3% Windoof Telefonen die von M$ subventioniert verkauft werden? Das Problem für Intel ist aber, dass all diese Geräte auf ARM Basis aufgebaut werden. Mein VDR bedient auch einen Vomp auf einem PI und das sieht schon super aus. Ich würde auch gerne komplett auf ARM wechseln, aber da fehlt einfach ein Konzept zur Integration der Tuner. Und bei ARM ist nun mal nur USB möglich. Dann liegt ein Tuner aber bei 90€, man hat zig Netzteile und einen riesen Kabelverhau. Das macht die Sache unattraktiv und man landet eben doch wieder beim Mainboard.

Wahr ist, dass die wenigsten Multimedia-Geräte auf einem XServer aufsetzen. Aber da sehe ich auch kein Problem. Beim PI wird auch einfach in den Frame Buffer geschrieben. Die GPU muss nur irgendwo ein Bild rendern. Das Übertragen bekommen die Leute dann schon hin. Aber es scheitert bei Intel ja schon daran. Folglich gibt es keine erfolgreiche Embedded HW auf Intel Basis. Das passt also schon alles ins Bild. Nur möchte Intel daran wohl nichts ändern, warum auch immer.

Wenn einer der Mobo Hersteller mal einen ARM auf einen ITX Formfaktor bringen würde, könnte man Intel ja ablösen. Aber die sind wohl so unter der Knute von Intel und M$, dass sich da einfach nichts entwickelt. Beim PI verkaufen sich 2000000 Stück/a. Ich glaube nicht dass da jedes Mobo mithalten kann. Wo ist also das Hindernis?

Ich würde sogar für eine vernünftige Lösung bezahlen. Beim Drucker habe ich auch für die Treiber bezahlt. Warum nicht 10€ dafür abdrücken? Das täte keinem weh. Für die M$ Treiber wird ja immer direkt abkassiet. So könnte es evtl. mal eine Linux Edition einer HW geben. Die kostet dann ein bisschen mehr. Dafür könnte man dann auf die M$ Gebühr verzichten.

Hallo Leute,

ich habe den Thread komplett duchgewerkelt. Einige Leute sind zufrieden, andere nicht. Läuft das jetzt, oder eher nicht? Ich habe hier ein low power System (~28W) mit Atom330 und das Teil wird mir langsam zu lahm, auch wenn die NVIDIA Grafik super ist. Aber das wird wohl nichts mehr nachkommen und die neue Atoms (J1900) bieten eine super Performance zu einem wirklich guten Preis und extrem geringer Leistung (<10W). Das ist doch zum Heulen, wenn man diese Systeme nicht nutzen kann.

Wenn ich auf die Hompage des softhddevice schaue, steht da, dass Johns plant VAAPI aus dem plugin zu entfernen:

Zitat

• planned: remove VA-API support

....

• VA-API needs latest release or git (staging) version
• VA-API !OpenGL output does no v-sync with H264 interlaced streams
• These bugs will be fixed by removing VA-API support

Das sieht nicht wirklich gut aus. Oder gehen jetzt alle den Weg über OpenElec/Kodi und das VDR-Frontend hat ausgedient?

Hallo,

auf Anregung von seahawk1986 habe ich folgendes an dieser Stelle nochmal gepostet. Der ursprüngliche Beitrag ist hier zu finden: vdr-plugin-vompserver hat einen Überlauffehler bei Dateigrößen > 4GByte

Um nur noch eine Datei pro Aufnahme zu haben (macht dlna + samba einfacher) habe ich in den Einstellungen die Dateigröße auf 25GByte erhöht. Dann kam es bei der Wiedergabe über VOMP zu dem Problem, dass die Wiedergabe einer Aufzeichnung plötzlich wieder am Anfang begann. Ich habe folgenden Hinweis auf dieses Problem im Loggytronic Forum gefunden (mit der freundlichen Unterstützung durch Marten): http://forum.loggytronic.com/index.php?topic=757.0.

Dieses Problem lässt sich demnach sehr leicht beheben. Ich habe das Source für YAVDR Paket geholt, das Patch eingebaut, übersetzt und installiert. Das Problem ist jetzt weg.

Aus dem Loggytronic-Forum:

--- vompserver-0.4.1/recplayer.c	2014-02-16 22:11:49.000000000 +0100
+++ vompserver-0.4.1.new/recplayer.c	2014-11-23 14:25:40.815182313 +0100
@@ -168,7 +168,7 @@
   ULONG yetToGet = amount;
   ULONG got = 0;
   ULONG getFromThisSegment = 0;
-  ULONG filePosition;
+  ULLONG filePosition;
 
   while(got < amount)
   {
@@ -186,7 +186,7 @@
       getFromThisSegment = segments[segmentNumber]->end - currentPosition;
 
     filePosition = currentPosition - segments[segmentNumber]->start;
-    fseek(file, filePosition, SEEK_SET);
+    fseeko(file, filePosition, SEEK_SET);
     if (fread(&buffer[got], getFromThisSegment, 1, file) != 1) return 0; // umm, big problem.

     // Tell linux not to bother keeping the data in the FS cache

Ok, ich mache noch ein Ticket auf...

Hallo,

um nur noch eine Datei pro Aufnahme zu haben (macht dlna + samba einfacher) habe ich in den Einstellungen die Dateigröße auf 25GByte erhöht. Dann kam es bei der Wiedergabe über VOMP zu dem Problem, dass die Wiedergabe einer Aufzeichnung plötzlich wieder am Anfang begann. Ich habe folgenden Hinweis auf dieses Problem im Loggytronic Forum gefunden (mit der freundlichen Unterstützung durch Marten): http://forum.loggytronic.com/index.php?topic=757.0.

Dieses Problem lässt sich demnach sehr leicht beheben. Ich habe das Source Paket geholt, das Patch eingebaut, übersetzt und installiert. Das Problem ist jetzt weg. Evtl. möchtet ihr das auch anderen Usern zur Verfügung stellen.

Aus dem Loggytronic-Forum:

--- vompserver-0.4.1/recplayer.c	2014-02-16 22:11:49.000000000 +0100
+++ vompserver-0.4.1.new/recplayer.c	2014-11-23 14:25:40.815182313 +0100
@@ -168,7 +168,7 @@
   ULONG yetToGet = amount;
   ULONG got = 0;
   ULONG getFromThisSegment = 0;
-  ULONG filePosition;
+  ULLONG filePosition;
 
   while(got < amount)
   {
@@ -186,7 +186,7 @@
       getFromThisSegment = segments[segmentNumber]->end - currentPosition;
 
     filePosition = currentPosition - segments[segmentNumber]->start;
-    fseek(file, filePosition, SEEK_SET);
+    fseeko(file, filePosition, SEEK_SET);
     if (fread(&buffer[got], getFromThisSegment, 1, file) != 1) return 0; // umm, big problem.

     // Tell linux not to bother keeping the data in the FS cache

Hallo Alex,
bei mir hat es geklappt Danke für die Anleitung,

rs

Hallo,
ich habe ebenfalls ein ION system am Laufen. habe eben auf die neuen Frequenzen umgestellt. Bisher habe ich aber nichts von Schwierigkeiten bemerkt.

Ich hatte aber vergangenes Jahr einmal ähnliche Schwierigkeiten (alte Frewuenzen). Dann habe ich festgestellt, dass im Kernel (s. Signatur) noch die ngene_15.fw geladen wurde. Ich nutze den 2.6.38 von Natty. Damit war klar, dass die V4L-Treiber im Standard-Kernel schon älter sind. Habe darauf hin die Treiber aktualisiert und diese laden jetzt auch ngene_18.fw.

> dmesg...
[97538.749620] nGene PCIE bridge driver, Copyright (C) 2005-2007 Micronas[97538.749739] ngene 0000:02:00.0: PCI INT A -> Link[LN0A] -> GSI 18 (level, low) -> IRQ 18[97538.749786] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner[97538.752521] ngene 0000:02:00.0: setting latency timer to 64[97538.752611] ngene: Device version 1[97538.758174] ngene: Loading firmware file ngene_18.fw.[97538.769170] ngene 0000:02:00.0: irq 42 for MSI/MSI-X...
> modinfo ngene...srcversion:     533BB7E5866E52F63B9ACCB...

Meine .xine/config_xineliboutput enthält folgende Zeile:

engine.buffers.video_num_frames:22

Seit dem ich den Treiber aktualisiert habe ist Ruhe und das Ganze geht auch mit den umgestellten Frequenzen (Testzeitraum bei mir bisher: 45 Minuten). Das Tunen an irgendwelchen Buffern hatte beim mir abgesehen von "Hoffnungen" nichts gebracht. Irgenwann hatte ich dann eine Aufnahme mit Bildfehlern gefunden. Dann war klar, dass es nicht an der Rechenleistung / am vdpau liegt, sondern an korrupten Daten.

Vielleicht hilft diese Information weiter.

Halle in meinem ION ein ähnliches Problem. Sah' in den Aufnahmen dann auch meist besser aus. War aber am Ende ein Problem mit der ngene Karte. Fehler im Datenstrom hatten bewirkt, dass vdpau den Löffel abgegeben hat.

Ein Update auf die aktuelle Version des v4l hat das Problem gelöst. Seitdem wird auch die aktuelle Frimware ngene_18.fw anstelle ngene_15.fw verwendet (dmesg). Wenn der Datenstrom trotzdem mal einen Knacks abbekommt (z.B. durch hohe Systemlast durch das burn plugin) kommt es noch immer zu vdpau Problemen. Diese tauchen nur i.d.R. nicht auf. Mplayer hat sich hier übrigens als resistenter erwiesen.

Ich habe Servus HD jetzt seit 20 Mintuen am Laufen. Scheint also zu gehen....

Hallo,

ich habe auf meinem VDR die Distribution KUbuntu Natty mit den YAVDR Paketen. Dabei hatte ich Probleme mit dem Burn Plugin. Der Abbruch kam durch ein Segfault von Spumux. Dies konnte ich in den Logfiles die in /tmp angelegt wurden erkennen. Die Ursache ließ sich aber nicht erkennen. Wenn ich das selbe Kommando auf der Konsole ausgeführt habe, lief Spumux.

Die Ursache war, dass beim Aufruf des Burn-Scripts (/usr/share/vdr-plugin-burn/vdrburn-dvd.sh) wohl die Umgebungsvariable HOME nicht gesetzt war. Und genau das nimmt Spumux übel. Es hat mich einge Stunden gekostet dahinter zu kommen. Am Ende hatte ich ein X Terminal im Script gestartet, damit ich das Problem in genau der Umgebung untersuchen konnte, in der das Script ausgeführt wurde. So kam ich schließlich auf die Lösung.

Folgende Zeile zu Beginn des Scripts hat das Problem gelöst.

if ! [[ $HOME ]]; then export HOME=/tmp; fi

Das sollte es für das Script tun. Evtl. findet diese kleine Anpassung ihren Weg in YAVDR oder in das Burn Plugin.

Danke! Werde es morgen mal versuchen.

Hotzenplotz,

hast Du vielleicht einen Kontakt zu einem Xine Entwickler dem ich das Video zukommen lassen könnte? So etwas sollte doch eigentlich für einen Entwickler von Interesse sein.

Um sicher zu ghen,dass ich keine fauligen Pakete drin habe, habe ich die Source.list aktualisiert. Ich habe jetzt folgende Einträge in der Sources.list

deb http://ppa.launchpad.net/yavdr/main/ubuntu natty main
deb http://ppa.launchpad.net/yavdr/testing-vdr/ubuntu natty main

Leider kommen da die selben Pakete wie mit den vorigen Paketquellen.

Mag sich die Sache keiner ansehen?

Ich habe habe auf meinem vdr ein Kubuntu natty mit den zusätzlichen yavdr Paketquellen:

deb http://ppa.launchpad.net/hotzenplotz5/natty-yavdr/ubuntu natty maindeb http://ppa.launchpad.net/yavdr/main/ubuntu natty maindeb http://ppa.launchpad.net/yavdr/unstable-vdr/ubuntu natty main

Als Frontend nutze ich vdr-sxfe über vdpau. Manchmal kommt es dabei zu Störungen in Bild und Ton. Wäre jetzt nicht so schlimm, wenn der Resync wieder klappt. Leider geht bei mir genau dieser schief. Danach flackert das Bild an einigen Stellen (bestenfalls) oder es kommt zu einem kompletten Hänger, ggf. bricht vdr-sxfe ganz ab (auch mit segv). Es hilf dann nur Zappen oder Neustart von vdr-sxfe, also einen kompletten Resync zu machen. Ich habe bereits mehrere Versionen von vdr-sxfe und dem nvidia Treiber durch, ohne dass eine Besserung/Veränderung in Sicht wäre.

Heute habe ich parallel zum Live TV eine Aufzeichnung laufen lassen, bis die Störung wieder auftrat. Dann die Aufzeichnung wieder abgespielt und der Fehler ist noch da. Ich hatte dies schon einmal versucht, da hatte es mit dem Resync bei der Aufnahme besser geklappt als Live. Beim erneuten Versuch konnte ich den Fehler auf der Platte "fangen".

Ok, dann einige Player mit dem .ts file geprüft:

• mplayer mit vdpau: Erkennt ein Problem im Stream (an der Console) und macht einen Resync.
  

• xine mit vdpau : Erkennt das Problem nicht (an der Console keine Ausgabe)
  

• vlc: Kann bei mir mit h.264 nicht umgehen

Gibt es jemanden der in der Lage ist, nach dem Problem in der libxine zu suchen? Eine Lösung scheint es zu geben, nur fehlt diese in der libxine. Ich habe bei diesem Thema leider zu wenig Durchblick. Das File hat so 300MByte. Ich würde dies dann per CD zusenden. Für einen Upload brauche ich mit meinem DSL zu lange. Evtl. kann ich auch versuchen, die Szene zu verkürzen.

Also, wer hat den Durchblick und kann sich die Sache mal ansehen?

Hallo,

ich habe mir das Plugin jetzt selbst erstellt. Allerdings ohne jegliche Berücksichtigung des Paket-Managements. Folgende Schritte habe ich durchgeführt.

I. Übersetzten

• Stable-Version von http://www.loggytronic.com/vomp.php herunterladen und entpacken.
• Paket vdr-dev installieren (apt-get / aptitude)
• Im Makefile VDRDIR = /usr/include/vdr setzen. Der originale Pfad geht davon aus, dass das Plugin im vdr source tree übersetzt wird. Da hier das Paket vdr-dev verwendet wird, ist diese Anpassung notwendig.
• make all... Das Kopieren des Plugins am Ende geht schief. Macht aber nichts. Das Plugin ist trotzdem da.
• Plugin (libvdr-vompserver.so) als root oder mittels sudo nach /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.18 kopieren.
• Als root/sudo "service vdr restart" ausführen. Das Plugin sollte beim Start des vdr automatisch laden.

II. Konfigurieren

Die Konfiguration habe ich mir bei den originalen Paketen abgeschaut. Dazu habe ich das lucid Paket heruntergeladen:

Vompserver YAVDR paket

Das Paket habe ich mit

dpkg -x vdr-plugin-vompserver_0.3.1.3-9yavdr3~lucid_amd64.deb /tmp/vomp

entpackt. Die darin enthaltene Struktur habe ich selektiv in mein System übernommen. Zuerst etc und usr/share/vdr-plugin-vompserver ins System übernehmen. ACHTUNG: Beim kopieren cp -a verwenden, damit die Softlinks auch Softlinks bleiben. Zuletzt var (enthält nur Softlinks) übernehmen.

Jetzt die Konfigurationsdatei in /etc/vdr/plugins/vomp.conf anpassen.

Zuletzt noch von der Plugin-Homepage die passende Firmware herunterladen und nach /usr/share/vdr-plugin-vompserver/vomp-dongle kopieren.

Jetzt den vdr nochmal starten, damit die geänderte Konfiguration übernomen wird.

Have fun!

Hallo,

weiss jemand, ob es im YAVDR Packetarchiv für Natty auch das Vompserver Plugin geben wird. Das Plugin fehlt mir, da ich noch eine MVP am TV stehen habe. Da ich auch noch die libxineoutput + vdpau benötige, hänge ich am YAVDR Archiv. YAVDR ist da einfach spitze! Nur der Vompserver fehlt zur Zeit

Ich ziehe die YAVDR-Packete für Natty über folgenden Eintag in der Sources.list:

deb http://ppa.launchpad.net/yavdr/unstable-vdr/ubuntu natty main

Hallo NetWraith,

ich habe die Erfahrung gemacht, dass der Treiber die Karten nicht mehr richtig in Gang bekommt. Darum solltest Du vor dem STR den vdr stoppen, dann den Treiber entladen und nach dem Resume wieder den treiber laden und den VDR neu starten.

Viel Erfolg!

Ok, danke für die Hinweise. ich werde einen Link auf den Thread an Digital Devices senden. Evtl. können die etwas dazu sagen. ASUS hatte ich bereits kontaktiert. Die wissen von nichts und wollen natürlich, da Linux zu wenig einheitlich ist, auch nichts machen. Mal sehen was Digital Devices herausbekommt.

Sie mal in /etc/default/grub nach. Da sind so einige einstellungen vorzunehmen. Näheres im Web. Und nicht vergessen update-grub auszuführen.

Ok, das mit dem "Workaround" war natürlich insgesamt eine Lösung mit vielen anderen Vorteilen. Trotzdem sollte das Board doch an sich funktionieren.

Hat jemand mal eine andere PCIe-Karte in einem ION ausprobiert?

Weiss jemand, ob das Wakeup-Problem nur bei einer gesteckter ngene auftritt oder ein generelles Board-Problem ist?