Beiträge von Eisbaer128

Hallo,

Ich habe heute auch auf die neuste Version upgedated und mir 45 Minuten Fussball angeschaut, dabei hatte ich nur ein Mal ein Ruckler, den finde ich jetzt auch im Logfile

Jun 16 17:57:27 apple vdr: [1678] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)Jun 16 17:57:30 apple vdr: last message repeated 589 times

Umschalten funktioniert wieder ziemlich gut, jetzt wieder ohne Pixel-Müll.Ich musste natürlich auch gleich den neuesten Nvidia Treiber aus dem Unstable Repo einspielen, geht soweit ich habe hin und wieder aber ein tearing. Keine Ahnung wo das jetzt herkommt.

Genauere Infos findest du in meinem Howto zu Mac Mini und yaVDR

Das mit der Fernbedienung ist nicht ganz richtig. Ich verwende den Mac Mini internen Empfänger mit einer Logictech Fernbedienung und das funktioniert wuderbar und auch mit mehr als den klasischen 5-6 Mac Tasten, sondern es können alle Logitech Tasten belegt werden.

Macmini 2009 geht auf jedenfall mit Linux und VDR ich habe das produktiv mit yaVDR 0.2 am laufen mit einer TT 3600 USB DVB-S2 Lösung. Sieht gut aus, ist schnucklich klein und wirklich leise. Neben dem recht hohen Preis gibt es nur einen weiter Nachteil und das ist die Bootzeit. Nachdem das über den BIOS Kompatibilitätsmodus geht dauert es ziemlich lange bis Linux überhaupt mal anfangen kann zu booten.

Actually I think the vdr translation is done in the skin file. Assuming you are using the PearlHD skin the check for the Translation files of the PearlHD skin I guess this should be the right place.

O.K misunderstanding I though you want to translate the yaVDR specific part which is the web-Interface. The whole yaVDR is Unbuntu based so maybe you have to install some standard Lucid Ubuntu packages to get the correct localization. Or do you want to add localization for vdr, xbmc or the used pearlHD skin in vdr ?

Hello,

You can find the required information in the following thread

Zur Theorie mit dem CPU Frequency Scaling: Ich habe jetzt mal die CPU auf die höchste Frequenz fixiert und ich sehe keinen Unterschied, zumindest bei ist das Frequency Scaling keine Ursache.

Zu dem Eintrag video_num_frames. Soweit ich das verstehe ist der Eintrag so gewollt und die Warnung darf ignoriert werden

Ich bin gestern Abend auch auf den aktuellen stable Stand umgestiegen und habe ähnliche Erfahrungen wie
iamhermes in dem Englandspiel habe ich eigentlich nur einen grossen Ruckler ganz am Schluss ansonsten maiximale wenige kleine, geht also in die richtige Richtung. Ich habe auch einige gut bekannte Einträge in dem syslog:

Jun 12 21:26:45 apple vdr: [1599] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)Jun 12 21:28:05 apple vdr: last message repeated 923 times

Ich habe vier solche Einträge während des England-Spiels.

Also ich habe jetzt mal die testing gegen die unstable Version beim Fussball ausprobiert und sehe da leider keine wesentliche Besserung. Ich habe immer noch eine Reihe von kleineren Rucklern. Ist natürlich besser als die Standard Version aber ganz weg sind sie leider noch nicht. Kann es vielleicht sein, dass auch eine der xinelib Einstellungen etwas damit zu tun hat ?

O.K. werde ich spätestens morgen beim nächsten Fussballspiel ausprobieren

Ich habe das testing build ohne die Patches aus dem testing Zweig heute mal zur Halbzeit eingespielt. In der erste Hälfte hat ich noch eine Reihe von Rucklern nach der Pause mit dem neuen xinelib build hatte ich dann nur noch einen. Kann aber natürlich auch Zufall sein. Ich teste mal weiter.

Hallo,

Solche Effekte hatte ich auch schon öfters. Aus meiner Sicht ist das die autocrop Funktion in xinelibout, zumindest wenn ich die abgeschaltet hatte ging es wieder ohne Problem, deshalb ist die Funktion bei mir inzwischen ausgeschaltet. Das hat nichts mit den kleinen Rucklern zu tun.

Ich habe das selbe Problem mit ziemlich den gleichen Setup, ich vermute mal das ist eher ein Problem des xinelibout Setups, ist so auch erst seit einigen Wochen vorher hatte ich da keine Probleme.

Hallo,

Ich habe die neue Version von vdr-sxfe auch gleich ausprobiert aber leider gibt es auch bei mir keine Änderung (ich habe nur eine dvb-Karte in dem System):

Hier das Log-File:

Jun 2 21:09:19 apple vdr: [1428] loading /var/lib/vdr/plugins/vnsi-server/allowed_hosts.conf
Jun 2 21:09:19 apple vdr: [1428] VNSI: Client with ID 0 connected: 127.0.0.1:42274
Jun 2 21:09:19 apple vdr: [1427] VNSI: Welcome client '(null)' with protocol version '1'
Jun 2 21:09:33 apple vdr: [1428] loading /var/lib/vdr/plugins/vnsi-server/allowed_hosts.conf
Jun 2 21:09:33 apple vdr: [1428] VNSI: Client with ID 1 connected: 127.0.0.1:42277
Jun 2 21:09:33 apple vdr: [1427] VNSI: Welcome client 'XBMC Live stream receiver' with protocol version '1'
Jun 2 21:09:33 apple vdr: [1623] VNSI: Successfully found following device: 0xa0afaa0 (1) for receiving
Jun 2 21:09:33 apple vdr: [1623] VNSI: Creating new live Receiver
Jun 2 21:09:33 apple vdr: [1624] cLiveStreamer stream processor thread started (pid=1249, tid=1624)
Jun 2 21:09:33 apple vdr: [1623] VNSI: Successfully switched to channel 1 - Das Erste HD
Jun 2 21:09:33 apple vdr: [1623] VNSI: Started streaming of channel 1 - Das Erste HD
Jun 2 21:09:33 apple vdr: [1625] receiver on device 1 thread started (pid=1249, tid=1625)
Jun 2 21:09:33 apple vdr: [1625] ERROR: /dev/dvb/adapter0/dvr0: Device or resource busy
Jun 2 21:09:33 apple vdr: [1625] receiver on device 1 thread ended (pid=1249, tid=1625)
Jun 2 21:09:41 apple vdr: [1623] VNSI-Error: cxSocket::read: read() error at 0/4
Jun 2 21:09:41 apple vdr: [1624] cLiveStreamer stream processor thread ended (pid=1249, tid=1624)
Jun 2 21:09:41 apple vdr: [1623] buffer stats: 0 (0%) used

Sieht also weiterhin so aus als ob die dvb Karte nicht freigegeben wird

Hallo,

Danke an alle yaVDR Entwickler. Seit ich diese Distribution für meinen VDR verwende ist das alles deutlich einfacher´und unaufwendiger geworden. Ich setze jetzt yaVDR 0.2 schon seit einigen Wochen produktiv ein und bin damit ziemlich zufrieden

Hallo,

Wie gesagt DU bist schon auf der richtigen Spur, die UIDs der beiden vdr User sollten gleich sein. Noch was, warum hast Du eigentlich in Deinem export:

Hallo,

Ich würde den User nicht löschen sondern manuell den bestehenden User verändern (/etc/passwd).
Bei mir sieht die Zeile so aus
vdr:x:117:124:VDR user,,,:/var/lib/vdr:/bin/bash

die 117 ist die UID und die 124 ist die Defauft Gruppe (siehe /etc/groups).

Die Einträge kannst Du einfach mit einem Editor (natürlich als root) editieren.

Ich habe auch schon mit diesem Thema länger gekämpft und obwohl ich NFS V4 eingesetzt habe wo die User und Gruppen gemappt werden (das sehe ich auch so im Directory Listing), wollte der vdr nie. Es hat wirklich nur funktioniert den UID bzw GID gleich sind. Dass kann man aber relativ einfach hinbekommen:
- Einfach in der /etc/passwd bzw der /etc/group Datei die UID bzw GID ändern und dann natürlich alle Dateinen des vdr (vorallm die unter /var/lib/vdr) auf den neuen User und Gruppe bringen z.B. chown -R vdr:vdr *. Danach sollte alles funktionieren.

Fnu in Theorie hast Du sicher recht, die Frage ist doch ob sich für einen typischen "Fernseh"-Computer mit vdr, xbmc auf VDPAU Frontend (xine oa) sich ein relevanter Unterschied zeigt der es rechtfertigt sich an viellen stellen mit noch nicht 64 Bit kompatibler Software rumzuschlagen. Mir ist das bis jetzt noch nicht bekannt, deshalb fahre ich einfach ein Standard 32bit System. Gibt es denn wirklich spürbare verbesserungen mit 64bit (z.B. besser Deinterlacer oÄ ?