Beiträge von DonCamillo

Ein Panasonic "Touchboob"?

Habe ich gleich mal gegoogelt und jede Menge Treffer gefunden - nur Notebooks waren nicht dabei

Greetz
DonCamillo

Die folgende Lösung hat unter yaVDR 0.5 funktioniert, erhebt aber keinen Anspruch auf Vollständigkeit. Ist meine Premiere im compilieren.

Development-Tools installieren und Sourcecode des vompserver Plugins laden:

sudo apt-get update
sudo apt-get install vdr-dev
apt-get source vdr-plugin-vompserver
cd vdr-plugin-vompserver

Änderungen an Datei recplayer.c gemäß Thread im Loggytronic Forum . Danke an MartenR und ulrhom.

--- vdr-plugin-vompserver-0.4.1.orig/recplayer.c
+++ vdr-plugin-vompserver-0.4.1/recplayer.c
@@ -168,7 +168,7 @@ unsigned long RecPlayer::getBlock(unsign
   ULONG yetToGet = amount;
   ULONG got = 0;
   ULONG getFromThisSegment = 0;
-  ULONG filePosition;
+  ULLONG filePosition;


   while(got < amount)
   {
@@ -186,7 +186,7 @@ unsigned long RecPlayer::getBlock(unsign
       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.
..

Paket mit Änderungen compilieren, installieren und VDR neu starten:

dpkg-source --commit
dpkg-buildpackage
cd ..
sudo dpkg -i vdr-plugin-vomp*.deb
sudo service vdr restart

Gruß
DonCamillo

Gefunden, das Problem ist bekannt: http://forum.loggytronic.com/index.php?topic=757.0

Hat sich damit erledigt.

Gruß
Don Camillo

Hallo Zusammen,

vorab: Habe mir einen Raspberry Pi2 zugelegt und wollte meinen VOMP-Server reaktivieren und den RPi als VOMP-Client nutzen. Mir ist bewusst, dass es Distris mit vollständigen VDR Implementierungen für den RPi gibt. Aber aufgrund der Erfahrungen in der Vergangenheit gefällt mir VOMP auch wegen des guten WAF-Faktors.

Habe den RPi2 mit dem VOMP-Client gemäß Anleitung im Wiki installiert (einziger Unterschied: Version 0.4.1 statt 0.4.0 wie dort beschrieben). Der Server ist ein yaVDR-Backend mit dem yaVDR-VOMPServer Plugin. Der Client funktioniert auch einwandfrei - mit einer Ausnahme:
Bei der Wiedergabe von Aufnahmen bei rund 1h fängt die Wiedergabe einer HD-Aufnahme nach Ablauf dieser Zeit von vorne an - im OSD wird es so dargestellt, als ob die Aufnahme normal fortgesetzt wird. Springe ich in der Wiedergabe testweise auf 80%, zeigt er zwar im OSD je nach Länge der Aufnahme z. B. 1:35h an, gibt aber den Inhalt der Position 0:50h wieder. Verlasse ich dann die Aufnahme, starte ich sie erneut mit "Fortsetzen" ist das OSD bei 0:50h. Tritt bei unterschiedlichen HD-Aufnahmen bis dato immer zwischen Minute 45 und 1h auf - bei der gleichen Aufnahme ist es reproduzierbar immer die gleiche Stelle. Dort ist keine Schnittmarke gesetzt. De facto kann ich keinen Film > 1h zu Ende sehen. VDR Server ist so eingestellt, dass die Aufnahmedateien nicht gesplittet werden - kann es ggf. daran liegen?

Durchgeführte Kreuztests:
- VOMP-Client für Windows 0.4.1 -> Gleicher Fehler
- yaVDR-Client per streamdev -> normales Wiedergabeverhalten

Habe bereits Google - hoffentlich mit den richtigen Suchbegriffen - befragt, bin aber nicht fündig geworden. Ist das Verhalten bekannt?

Update:
Habe das Logging des VOMP-Server aktiviert. Zum betreffenden Fehlerzeitpunkt ist dort folgendes zu sehen:

12:57:56.606524 [debug] RecPlayer - FILENAME: /srv/vdr/video.00/Top_Gun/2015-03-07.20.13.13-0.rec/00001.ts
12:57:56.606631 [debug] RecPlayer - File 1 found, totalLength now 9520623056, numFrames = 15256239635194640758
12:57:56.606694 [debug] RecPlayer - FILENAME: /srv/vdr/video.00/Top_Gun/2015-03-07.20.13.13-0.rec/00002.ts
12:57:56.606808 [debug] RRProc - Rescan recording, wrote new length to client
12:57:56.606850 [debug] RRProc - threadMethod waiting
12:57:56.607251 [debug] Client - Received chan=1, ser=3900, op=7, edl=140385301037068
12:57:56.607300 [debug] RRProc - recvReq
12:57:56.607349 [debug] RRProc - recvReq set req and signalled
12:57:56.607390 [debug] Client - Waiting
12:57:56.607401 [debug] RRProc - thread woken with req, queue size: 1
12:57:56.607477 [debug] RRProc - getblock pos = 4251731032 length = 100000
12:57:56.607518 [debug] RecPlayer - openFile called for index 1 string:/srv/vdr/video.00/Top_Gun/2015-03-07.20.13.13-0.rec/00001.ts

Offenbar sucht er nach der 00002.ts, obwohl es diese nicht gibt und startet dann aus Verzweiflug die 00001.ts wieder. Habe den Thread-Titel aktualisiert.

Jetzt wäre es trivial, das Splitting der Aufnahmedateien wieder einzuschalten aber mit mehreren Aufnahmedateien pro Film hat mein Plex-Server Stress.

Kann man das anderweitig abstellen?

Danke & Gruß
DonCamillo

Hallo C.M.,

das gibt es schon. Such mal nach "vdrnfofs". Das ist ein virtuelles Filesystem, das die interne Struktur der VDR Dateiablage virtuell so darstellt, wie Du es oben beschrieben hast. Nebenbei werden die EPG Informationen noch als NFO Format angeboten.

Bei yavdr ist das bereits als Paket enthalten.

Edit: seahawk1986 war schneller...

Zitat von CKone

afaik funktioniert bei so einem Client das Umschalten nicht wie bei einem "normalen vdr"

Doch tut es - kein Unterschied in der Bedienung.

Zu pip kann ich nichts beitragen, das nutze ich nicht.

Hallo,

bei mir ist es jetzt auch gelöst - ohne Patch.

Mein Fehler: Am Ende der channels.conf hatte ich auf dem streamdev client und server einige verschlüsselte Kanäle aufgeführt, die nicht entschlüsselt werden konnten.

Mittlerweile habe ich ein Abo erworben, erforderliche plugins installiert UND workaround 1 aus Post #16 von schmirl angewendet. Seither ist die Umschalt-Performance für alle - auch für unverschlüsselte - Kanäle tadellos. Keine Probleme mehr.

Hallo,

das Problem kenne ich auch auf meinem HD-Client (s. Signatur)

Tritt bei mir
- unter xine als auch unter xinelib-output auf
- im Live-Betrieb als auch beim abspielen von Aufnahmen
- sowohl DD als auch bei Stereo über das VDR-Menü
- sowohl bei HDMI-passthrough über den Fernseher (Samsung LE37B679) als auch über optischen Digitaleingang der Soundbar (Samsung HW-C450)
- ein Zusammenhang mit bestimmten Sendern konnte ich noch nicht feststellen

Einzig auffällig ist, daß die Soundbar nach einem solchen Problem kurz ihren Modus anzeigt (DD oder PCM je nachdem welches Signal anliegt) als ob der Eingang resettet wurde.

Ich kann in den Logfiles in den betreffenden Zeiträumen nichts auffälliges erkennen.

Puffer werde ich reinschauen, bin aber der Meinung, dass ich die bereits erhöht hatte.

Nur damit nicht der Eindruck entsteht, daß das Ganze ausschließlich in Verbindung mit verschlüsselten Sendern auftritt: Ich nutze kein Jehova-Plugin und das von MarkusH im ersten Mail beschriebene Problem tritt hier mit unverschlüsselten Sendern auf.

Zitat von schmirl

Vermutlich sind die SAT-Karten nicht gerade die schnellsten beim Umschalten.

Naja, wenn ich am Server ein Frontend aktiviere und lokal umschalte geht es aus meiner Sicht recht zügig - wobei das natürlich ein subjektiver Eindruck sein kann.

Schmirl ist der Experte, insofern harre auch ich gespannt der Dinge, die da kommen...

Hallo Keine_Ahnung,

danke, werde ich ausprobieren.

Zitat

Oder du schaltest es in /etc/default/avahi-mounter einfach mit "enabled=0" ab. Das nächste mal schau dort doch einfach mal vorher nach bevor du mit den überkomplezierten ideen kommst.

War mir nicht bewusst, das man das da auch einstellen kann. Bin bei der Konfiguration laut yaVDR-Doku vorgegangen, da wird unter dem Absatz "Configuration" für den Server-Einsatz die o. a. Anpassung der Datei /var/lib/vdr/.avahi-mounter empfohlen.

Habe mal nach "TSPIDS,FILTERS,PRIO" gesucht. In einem anderen Thread Link gab es den Hinweis, daß das Deaktivieren der Filterdaten das Problem löst.

Bei mir ist es deaktiviert, laut dem o. g. conf-File auch bei MarkusH (streamdev-client.StreamFilters = 0).

Trotzdem lautet die Meldung im Log:

Zitat

Streamdev: Connected to server 10.10.1.60:2004 using capabilities TSPIDS,FILTERS,PRIO

Eigentlich ein Widerspruch

Hallo Zusammen,

Vorgeschichte: Meine Media-MVPs via VOMP-Plugin hängen sich beim Erstellen der Aufnahmeliste auf, wenn der avahi-mounter auf dem Server (siehe Signatur) aktiv ist. Daraufhin hab' ich diesen deaktiviert, indem ich den Eintrag in der Datei /var/lib/vdr/.avahi-mounter auf enabled=0 setzte. Problem gelöst, Familie glücklich...

Nach dem nächsten dist-upgrade trat das Problem erneut auf und der o. g. Eintrag stand wieder auf enabled=1. Beim Upgrade gab es keine Nachfrage, was mit der bestehenden conf-Datei passieren soll. Daraufhin schlussfolgerte ich, dass für diese Datei wohl ein Standard-Template existieren muss, welches den Wert wieder zurücksetzte. Ich machte mich also zunächst auf die Suche nach dem betreffenden Template, wurde aber unter /usr/share/yavdr/templates/var/lib/vdr/ nicht fündig.

Ist die Erstellung eines custom-Templates zur dauerhaften Änderung der Einstellung in diesem Fall überhaupt zielführend - laut Wiki Artikel yaVDR/Templates kann dieses ja nur "Standard-Templates ergänzen oder Teile von ihnen überschreiben". Wenn aber kein Standard-Template zu existieren scheint?

Was muss ich tun, damit die Änderung das nächste dist-upgrade übersteht? Über Hinweise würde ich mich freuen.

EPG-Scan deaktivieren änderte bei mir auch nichts - habe auf dem Streamdev-Server
- externes EPG installiert
- unter System - Einstellungen - EPG - Zeit bis zur EPG-Aktualisierung auf 0 gesetzt (dito auf dem Client)
- unter System - Einstellungen - DVB - Kanäle aktualisieren auf "nein" gesetzt
- rebootet (dito den Client)

Effekt und Fehlermeldung bleiben leider bestehen, wie im Eingangspost von MarkusH beschrieben.

Hallo,

das Problem habe ich auch, ebenfalls über LAN, ebenfalls Twintuner.

johns,
wie kommst Du denn dann an Deine EPG-Daten - externer Provider oder über Deinen 2. Server?

Hallo vdrjoe,

hier läuft die Zbox HD-ID41 als Streamdev-Client mit yavdr 0.4.

Vorgehensweise, wie hier unter "Client" von joda999 beschrieben. Ergänzungen: Zusätzlich in OSD Einstellungen Streamdev-Client "Client starten" auf "Ja" - das war vorher nach meiner Erinnerung nicht erforderlich. Die channels.conf habe nicht übers Webinterface sondern direkt vom Server kopiert.

Habe die Einträge in der setup.conf nicht manuell reinkopieren müssen wie von hotzenplotz5 angemerkt. Kann mir das nur so erklären, daß diese scheinbar erzeugt werden, wenn man im OSD Menü auf die Einstellungen des Plugins geht.

Das wars.

Hallo,

so sieht das log bei mir aus, wenn in den Einstellungen des streamdev-client-plugins der Punkt "Client starten" auf "Nein" steht.

Hallo Angel,

wollte zumindest mal vermelden, daß VOMP unter yavdr 0.4pre1 grundsätzlich funktioniert.

Habe das Plugin vdr-plugin-vompserver über das Webinterface installiert und den Dongle mittels "sudo apt-get install vdr-vompclient-mvp". Dann noch Anpassung der /etc/vdr/plugins/vomp.conf (servernamen angeben, BOOTP- und TFTP-server auf enabled = yes). Wenn ich mich recht erinnere, war das schon alles.

Danach gibt es bei mir nur noch zwei Schönheitsfehler:
- VOMP kommt mit der UTF-8 Codepage von yavdr nicht so richtig klar - dt. sonderzeichen werden also von der MediaMVP "alternativ" dargestellt. Könnte man manuell durch Anpassung der Codepage beheben - stört mich weniger.
- 16x und 32x Vor-/Rücklauf funktionieren nicht - Fehler findet sich auch in anderen Threads im Zusammenhang für VOMP Version 0.3.1-3 (also nicht yavdr spezifisch). Hierfür habe ich noch keine Lösung.

Ein Ansatz zur Fehlersuche nach dem Hinweis von MartenR: Welche Dongle-Version wird denn im Hauptmenü Deiner MediaMVP links oben in der Ecke angezeigt? Es sollte "0.3.1-3" sein.

Gleiches Verhalten bei meiner ZBOX ID41 - hängt wohl mit USB3 zusammen.

Habe ullek's Rat befolgt - danach geht er in den S3.

Zitat

Original von Miru
ich habe auf meinen MVPs (alle D3A) seit dem letzten Dongle-Update gelegentlich das Problem, dass beim Ein- oder auch Ausschalten via FB die Kanalinfo unten noch angezeigt wird, aber nix passiert mehr ... kein Bild und kein Ton. Die MVPs reagieren zwar noch auf das FB-Signal ... die Front-LED blickt dann ... aber es hilft nur Netz-Stecker ziehen und wieder reinstöpseln ... dann tut alles wieder bis zum nächsten Mal.

Habe exakt das gleiche Problem. Tritt immer nach dem Ausschalten der MVP auf. Hat jemand eine Lösung?

Hi,

wenn Du "nur" Strom sparen möchtest, wird andersherum mit VMWare ein Schuh daraus:
- virtualisiere Deinen bestehenden Server
- installiere ctvdr auf der Server-Hardware inkl. FF-Karte
- installiere den VMWare-Host im ctvdr
- Pack die VM des vorherigen Servers und die anderen VM-Clients in den neuen Host

Fertig. Funktioniert bei mir prima.

Gruß,
DonCamillo