You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

21

Friday, July 9th 2010, 11:29am

xine-lib vdpau profiling patch

Hallo,

so habe mich jetzt mal ein wenig mit der Problematik der "Hänger" beschäftigt.
Untersucht habe ich das Problem mit einem 15 minütigen Ausschnitt einer 1280x720p Aufnahme aus dem ÖR mit dem sich die Hänger einigermassen verlässlich reproduzieren lassen.
Die Aufnahme wird dabei direkt im xine player abgespielt, ist also unabhängig vom VDR bei der Wiedergabe.
Die Hänger passieren auf meinen Systemen offenbar immer während die Verarbeitung innerhalb einer VDPAU Library-Funktion abläuft. Dabei verteilen sich diese auf unterschiedliche VDPAU Funktionsaufrufe. Das Problem ist also vermutlich im nvidia Treiber zu suchen womit meine Möglichkeiten der Analyse leider enden.

Ich habe im Anhang mal einen Patch gegen die aktuelle hg Version der xine-lib-1.2 angehängt mit dem entsprechende Profiling-Funktionen für die VDPAU-Funktionsaufrufe hinzugefügt werden. Weiterhin modifiziert der Patch auch die Anzahl der vdpau display surfaces die in der vdpau display queue verwendet werden um überhaupt auf langsamen Systemen einen vernüftige Wiedergabe hinzubekommen. (Die Verbesserung ist auch schon lange im bekannten vdpau extensions patch von mir enthalten)

Im xine log werden mit diesem Patch jetzt alle paar Minuten Statistiken über die Zeitdauer diverser VDPAU-Funktionsaufrufe ausgegeben. Treten ungewöhnliche Peaks (z.B. bei den Hängern) auf werden diese zusätzlich ausgegeben.

Es wäre schön wenn Ihr auch mal mit diesem Patch testet um zu sehen, ob die Probleme auf euren Systemen in ähnlicher weise wie bei mir auftreten. Die xine logs dann bitte in diesem Thread veröffentlichen.

Meine Testumgebung ist:
nvidia Treiber 256.35, neuste xine-lib-1.2 (nur mit dem profiling patch versehen) und xine-ui hg version
Systeme siehe Signatur

Wer meine Testaufnahme probieren möchte schicke mir bitte eine PM.

So sieht z.B. ein Hänger im xine log aus:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
video_out_vdpau: (vdpau_display_frame:1813) peak: 1,431 ms  avg: 0,043 ms  calls: 9000
video_out_vdpau: (vdpau_display_frame:1817) peak: 0,546 ms  avg: 0,006 ms  calls: 9000
video_out: Verwerfe Bild mit pts 36585243, weil es zu alt ist (Unterschied: 1986).
vdpau_h264: (vdpau_decoder_render:590) peak: 75,813 ms  avg: 0,204 ms  calls: 3316  
vdpau_h264: (vdpau_decoder_render:590) peak: 66,039 ms  avg: 37,925 ms  calls: 2      
200 Bilder angezeigt, 0 Bilder ÃŒbersprungen, 1 Bilder verworfen
video_out: Verwerfe Bild mit pts 42530581, weil es zu alt ist (Unterschied: 3316).
vdpau_h264: (vdpau_decoder_render:590) peak: 64,815 ms  avg: 0,078 ms  calls: 3302 
vdpau_h264: (vdpau_decoder_render:590) peak: 67,507 ms  avg: 32,422 ms  calls: 2     
200 Bilder angezeigt, 0 Bilder ÃŒbersprungen, 1 Bilder verworfen
video_out_vdpau: (vdpau_display_frame:1701) peak: 0,140 ms  avg: 0,029 ms  calls: 9000
video_out_vdpau: (vdpau_display_frame:1813) peak: 1,418 ms  avg: 0,043 ms  calls: 9000
video_out_vdpau: (vdpau_display_frame:1817) peak: 0,832 ms  avg: 0,006 ms  calls: 9000
vdpau_h264: (vdpau_decoder_render:590) peak: 38,341 ms  avg: 0,064 ms  calls: 9000
vdpau_h264: (vdpau_decoder_render:590) peak: 178,066 ms  avg: 0,046 ms  calls: 1381
vdpau_h264: (vdpau_decoder_render:590) peak: 200,681 ms  avg: 61,069 ms  calls: 3
video_out: Verwerfe Bild mit pts 61254186, weil es zu alt ist (Unterschied: 4064).
video_out: Verwerfe Bild mit pts 61255972, weil es zu alt ist (Unterschied: 2478).
video_out: Verwerfe Bild mit pts 61257759, weil es zu alt ist (Unterschied: 2784).
200 Bilder angezeigt, 0 Bilder ÃŒbersprungen, 3 Bilder verworfen
video_out_vdpau: (vdpau_display_frame:1701) peak: 0,165 ms  avg: 0,007 ms  calls: 9000
video_out_vdpau: (vdpau_display_frame:1813) peak: 0,433 ms  avg: 0,043 ms  calls: 9000
video_out_vdpau: (vdpau_display_frame:1817) peak: 0,132 ms  avg: 0,006 ms  calls: 9000
video_out: Verwerfe Bild mit pts 50526844, weil es zu alt ist (Unterschied: 15611406).
200 Bilder angezeigt, 0 Bilder ÃŒbersprungen, 1 Bilder verworfen

Die Funktion vdpau_decoder_render:590 braucht hier zu viel Laufzeit.

- durchflieger
durchflieger has attached the following file:
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

This post has been edited 2 times, last edit by "durchflieger" (Jul 9th 2010, 11:42am)


22

Friday, July 9th 2010, 12:41pm

Hi durchflieger,

wird gemacht und: Vielen Dank für deinen Einsatz!

Gruß
Holger

Atechsystem

Professional

Posts: 1,115

Location: NRW

Occupation: Informationstechniker

  • Send private message

23

Friday, July 9th 2010, 2:49pm

Quoted

Vielleicht ist es ja noch keinem aufgefallen, aber weitere "ich auch" Meldungen helfen nicht weiter, solange sie nicht auch Lösungsansätze erhalten. Was glaubt ihr denn, was wir mit den Posts machen? Statistiken erstellen? Gerald


Es trägt nicht zur Lösung bei aber zeigt, dass es noch andere gibt die dieses Problem haben und es sich nicht um einen Einzelfall handelt. Ausserdem kann man meiner Auflistung unten entnehmen, dass es sich nicht um yavdr handelt - was ja evtl. auch helfen kann. Da du mich damit aber heute echt auf dem falschen Fuß erwischt hast werde ich hier nicht mehr zu dem Problem Posten.

Atech
HTPC:
Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, Satix S2 Sky V2 USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

gda

Im Forum Zuhause

Posts: 14,280

Location: HH

  • Send private message

24

Friday, July 9th 2010, 3:18pm

Quoted

Original von Atechsystem
Da du mich damit aber heute echt auf dem falschen Fuß erwischt hast werde ich hier nicht mehr zu dem Problem Posten.

Schade, dass du dir den Schuh anziehst, da du ja konstruktives zum Thema bei zusteuern hattest. :(.

Gerald

HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
Samsung UE55H6470

25

Friday, July 9th 2010, 5:27pm

gelöscht da es hier um xineliboutput geht, und ich aber mit vdr-xine getestet habe

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 42.1 64bit, Kernel 4.4.13 mit dddvb 0.9.23, nvidia 367.27, vdr 2.2.0 mit Patchen (checkts, naludump, statusleds, ...)

This post has been edited 4 times, last edit by "jrie" (Jul 9th 2010, 10:19pm)


26

Saturday, July 10th 2010, 12:17pm

Hi,

@all
Jetzt bitte nicht gleich eingeschnappt sein. Es stimmt schon: Reine "me too" postings bringen uns nicht weiter. Alles, was nähere Details liefert allerdings schon. Im übrigen habe ich diesen Post auch absichtlich nicht im yaVDR-Unterforum eröffnet, da es kein yaVDR-Problem ist, sondern ein allgemeines.

@jrie
Das war jetzt Quatsch. Hier geht es sowohl um xinelibouput als auch um vdr-xine. Es sind beide betroffen und durchfliegers Patch bezieht sich auf den gemeinsamen "Unterbau" die xine-lib 1.2

@durchflieger
momentan wird scheinbar an zwei "Fronten" nach dem Fehler gesucht. Ich gebe mal eine Aussage von rnissl frei wieder (was hoffentlich o.k. ist). Evtl. ist das auch interessant für dich:

In der Datei "/src/video_out/video_out_vdpau.c" hat er seinerzeit auf eine fehlerhafte "libxcb" reagiert, indem er guarded functions eingesetzt hat. Im Code der xine-lib 1.2 erkennbar an: "#define LOCKDISPLAY /*define this if you have a buggy libX11/xcb*/". Die in deinem Patch überwachte Funktion ist eine dieser guarded functions. Zwischenzeitlich haben wir eine libxine gebaut, die darauf verzichtet, da zumindest in Ubuntu Lucid der Fehler in der "libxcb" nicht mehr existiert. Die "Hänger" treten leider immer noch auf, aber der Watchdog bleibt jetzt stumm. Kannst du das bei dir nachvollziehen?

Wie gesagt, wollt's nur mal weitergeben ;)

Gruß
Holger

This post has been edited 1 times, last edit by "HolgerR" (Jul 10th 2010, 12:38pm)


27

Saturday, July 10th 2010, 12:57pm

Hallo,

ich habe folgendes im Einsatz und keine Ruckler mehr:

Treiber: 256.35

aktuelle xine-lib und xine-ui aus dem HG resp. mit folgenden patchen:
- xine-lib-1.2-stream-start-patch-100614.diff
- xine-lib-1.2-vdpau-extensions-v11-20100612.diff

ffmpeg-0.6

aktuelle xineliboutput-cvs.

Auflösung ist auf 1080p mit 50hz eingestellt.

Das ganze läuft bei mir auf gen2vdr3.0beta7.

Viele Grüße
kaminkehrer
VDRMB2 (Wohnzimmer) :
Gehäuse: Activy 330 FP mit TTL Wandler am Serial
Intel DH61BE ; Geforce GT630 ; 2x2GB ; CineS2 5.6 ; 128GB SSD ; 1TB HDD
Harmony 650 ; Samsung UE40C6200
- Gen2VDR 5.0 -

VDRMB1 (Schlafzimmer) :
Gehäuse: Activy 300 FP mit TTL Wandler am Serial
POV 330-1 ; 60GB SSD ; Mystique SaTiX-S2 ; 2x2 GB RAM
Harmony 300 ; LG 32LG450
- Gen2VDR 5.0 -

VDRMB4 (Keller) :
Gehäuse: Activy 300 FP mit TTL Wandler am Serial
Zotac ionitx F-E ; CineS2 5.4 ; 2x2 GB RAM
Original Activy FB
- Gen2VDR 5.0 -

VDR3 u. 5 :
Gehäuse: Activy 300 FP mit TTL Wandler am Serial
Zotac ionitx F-E ; CineS2 5.4 ; 2x2 GB RAM
Original Activy FB
- Gen2VDR 3.0 -

28

Saturday, July 10th 2010, 1:21pm

Quoted

Original von HolgerR
@durchflieger
momentan wird scheinbar an zwei "Fronten" nach dem Fehler gesucht. Ich gebe mal eine Aussage von rnissl frei wieder (was hoffentlich o.k. ist). Evtl. ist das auch interessant für dich:

In der Datei "/src/video_out/video_out_vdpau.c" hat er seinerzeit auf eine fehlerhafte "libxcb" reagiert, indem er guarded functions eingesetzt hat. Im Code der xine-lib 1.2 erkennbar an: "#define LOCKDISPLAY /*define this if you have a buggy libX11/xcb*/". Die in deinem Patch überwachte Funktion ist eine dieser guarded functions. Zwischenzeitlich haben wir eine libxine gebaut, die darauf verzichtet, da zumindest in Ubuntu Lucid der Fehler in der "libxcb" nicht mehr existiert. Die "Hänger" treten leider immer noch auf, aber der Watchdog bleibt jetzt stumm. Kannst du das bei dir nachvollziehen?

Wie gesagt, wollt's nur mal weitergeben ;)

Gruß
Holger

Bei gesetztem LOCKDISPLAY verschärft sich das Problem nur weil jetzt langlaufende VDPAU-Calls durch die weitergehende Serialisierung mehr Threads im Player zum stillstand bringen. Lang laufende VDPAU-Calls treten aber mit oder ohne LOCKDISPLAY auf.

Für die weitere Analyse wäre es sehr hilfreich, wenn Ihr Tests mit den profiling patch durchführt und die xine logs hier veröffentlicht. Das Profiling zeigt im log genau ob Probleme auftreten, unabhängig davon, ob diese auch wirklich sichtbar werden bzw. vom Tester auch gesehen werden (das Testen ist ja auch viel einfacher weil man gar nicht mehr zuschauen muss).

Ich denke es läuft letztendlich auf eine Fehlermeldung direkt an den nvidia Support heraus. Dafür brauchen wir aber auch Testvideos mit dem sich das Fehlverhalten reproduzieren lässt. Deshalb am
besten mit Aufnahmen testen und schauen ob sich die Probleme bei wiederholten abspielen sicher
reproduzieren lassen.

Gruss
durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


29

Saturday, July 10th 2010, 1:32pm

@kaminkehrer
Dann bist du vermutlich (wie scheinbar viele) nicht von dem beschriebenen Problem betroffen. Fakt ist -wie bereits geschrieben- : Mit dem 256.35 treten die Probleme nach wie vor auf. Der letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.

@durchflieger
Du hast völlig recht: "Lösen" kann das Problem wohl nur Nvidia und für einen Bugreport, der sich auf eine schon seit einigen Treiberversionen existierende Regression bezieht, brauchen wir wohl jede Menge Stichhaltiges. Was schlägst du vor? Profiling Patch mit oder ohne LOCKDISPLAY?

Gruß
Holger

This post has been edited 1 times, last edit by "HolgerR" (Jul 10th 2010, 1:32pm)


30

Saturday, July 10th 2010, 1:37pm

Mahlzeit,

um einen exakten Bugreport abzuliefern solltet ihr diesen Post bei Nvidia beachten.

Stephan Warren schaut sich das dann in der Regel sehr schnell an.

Wichtig sind die Nvidia-debug-Ausgaben und das ganze sollte auf einer der betroffenen Maschinen laufen.

Hier mal die kompletten benötigten Angaben:

http://www.nvnews.net/vbulletin/showthread.php?t=123819

PS: Mir gehts wie kaminkehrer, keine Probleme

Gruß
Wolfgang
Hardware: -
Software: -

This post has been edited 1 times, last edit by "wbreu" (Jul 10th 2010, 1:38pm)


31

Saturday, July 10th 2010, 1:42pm

Quoted

Original von HolgerRDer letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.

Wäre es dann nicht möglich einfach diesen Treiber zu verwenden? In yavdr oder anderen Distris ließe sich der doch sicher einfach einbauen. Oder ist der zu alt für die aktuelle xinelib?
VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

32

Saturday, July 10th 2010, 1:48pm

Quoted

Original von avanix

Quoted

Original von HolgerRDer letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.

Wäre es dann nicht möglich einfach diesen Treiber zu verwenden? In yavdr oder anderen Distris ließe sich der doch sicher einfach einbauen. Oder ist der zu alt für die aktuelle xinelib?


Klar. Immer, wenn ich in Ruhe einen Film schauen möchte, verwende ich den 195.30 ja auch. Aber damit wäre das Problem ja nicht aus der Welt ;)

Gruß
Holger

33

Saturday, July 10th 2010, 7:01pm

Quoted

Original von HolgerR
@kaminkehrer
Dann bist du vermutlich (wie scheinbar viele) nicht von dem beschriebenen Problem betroffen. Fakt ist -wie bereits geschrieben- : Mit dem 256.35 treten die Probleme nach wie vor auf. Der letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.

@durchflieger
Du hast völlig recht: "Lösen" kann das Problem wohl nur Nvidia und für einen Bugreport, der sich auf eine schon seit einigen Treiberversionen existierende Regression bezieht, brauchen wir wohl jede Menge Stichhaltiges. Was schlägst du vor? Profiling Patch mit oder ohne LOCKDISPLAY?

Gruß
Holger

Wie schon gesagt zeigen sich die Probleme im Log unabhängig davon ob LOCKDISPLAY benutzt wird oder nicht. Bei Systemen mit alter libxcb muss LOCKDISPLAY auf jeden Fall zugeschaltet sein.

Nochmals hier der Hinweis das ich zum testen mein Testvideo bereitstellen kann. Schickt mir eine PM.

Gruss
durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


34

Saturday, July 10th 2010, 7:02pm

Quoted

Original von HolgerR
@kaminkehrer
Dann bist du vermutlich (wie scheinbar viele) nicht von dem beschriebenen Problem betroffen. Fakt ist -wie bereits geschrieben- : Mit dem 256.35 treten die Probleme nach wie vor auf. Der letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.


Holger


Den 195.30 werde ich dann auch mal probieren.
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


Posts: 3,079

Location: Magdeburg/Wolfsburg

Occupation: Dipl.-Wirtsch.Inf, Spez. Data-Warehousing - Business Intelligence

  • Send private message

35

Sunday, July 11th 2010, 7:55am

weiß einer welcher im aktuellen yavdr 0.1 repo drin ist? Habe auf den HD Sendern auch diese Ruckler, insbesondere auf Sky Sport HD :(
:vdr1 Homepage:fans
VDR II: YeongYang A106, Fusi D1522, Celeron 2GHz, Frontend per DVB-s FF, 2xDVB-c, ATRIC-IR, YaVDR 0.3a
VDR III HDTV: Inter-Tech 2008V mit iMonLCD, Atric, ASRock Extreme3 770 AM3, AMD Sempron 140 1x 2.70GHz AM3, 1,5TB WD15EADS, 2TB WD20EARS, 2x4GB DDR3-1600, NVidia GT520 passiv, 3x DVB-c, YaVDR 0.5 @ Samsung PS-50B550

36

Sunday, July 11th 2010, 7:32pm

Quoted

Original von durchflieger
Den 195.30 werde ich dann auch mal probieren.


Und? Wie sieht's bei dir damit aus?

Ansonsten:
yaVDR 0.2 Nutzer finden im "unstable-vdr" Repository jetzt eine libxine inkl. Profiling Patch. Danke dafür @hotzenplotz5 (der selber nicht mal von dem Problem betroffen ist). Damit sollte die Hemmschwelle zum munteren gemeinsamen Bughunting ein wenig niedriger sein.

Gruß
Holger

Posts: 3,079

Location: Magdeburg/Wolfsburg

Occupation: Dipl.-Wirtsch.Inf, Spez. Data-Warehousing - Business Intelligence

  • Send private message

37

Monday, July 12th 2010, 7:50am

Das Problem muss definitiv bei xine liegen. Unter xbmc mit HD-Wiedergabe kenne ich diese Probleme nicht.
:vdr1 Homepage:fans
VDR II: YeongYang A106, Fusi D1522, Celeron 2GHz, Frontend per DVB-s FF, 2xDVB-c, ATRIC-IR, YaVDR 0.3a
VDR III HDTV: Inter-Tech 2008V mit iMonLCD, Atric, ASRock Extreme3 770 AM3, AMD Sempron 140 1x 2.70GHz AM3, 1,5TB WD15EADS, 2TB WD20EARS, 2x4GB DDR3-1600, NVidia GT520 passiv, 3x DVB-c, YaVDR 0.5 @ Samsung PS-50B550

38

Monday, July 12th 2010, 9:54am

Moin,

schaut mal im Nvidia-Forum, da hat RNissl am Wochenende 2 Threads aufgemacht.

Gruß
Wolfgang
Hardware: -
Software: -

gerdh

Professional

Posts: 1,280

Location: Leidersbach

Occupation: irgendwas mit Strom

  • Send private message

39

Monday, July 12th 2010, 10:04am

Quoted

Original von HolgerR
Ansonsten:
yaVDR 0.2 Nutzer finden im "unstable-vdr" Repository jetzt eine libxine inkl. Profiling Patch. Danke dafür @hotzenplotz5 (der selber nicht mal von dem Problem betroffen ist). Damit sollte die Hemmschwelle zum munteren gemeinsamen Bughunting ein wenig niedriger sein.

reichts wenn ich mir von da das xinlib hole oder muss ich das komplette repo einbinden und mit apt-gte upgrade druberbuegeln ?

gruss gerd
vdr => p8b75-m lx / pentium g2020t / 8 GB Ram / zotac gt 630 / cine S2 V5.5 / 60 gb ocz ssd / 640 gb wd scorpio blue / display noritake 256x64-3900 / chenbro PC71023 gehaeuse / yavdr stable / softhddevice

spielsystem => p8b75-m le / intel core i3 3220T / ubuntu lts 14.04 / 16 GB ram / zotac gt 630 / cine S2 V6.2 / yavdr stable pakete / softhddevice / pulseaudio+alsa

spielwiese => Zotac Zbox ID45 / 120 GB mSATA / via Satip => Octopus Net / yavdr stable / softhddevice

40

Monday, July 12th 2010, 10:05am

Quoted

Original von wbreu
Moin,

schaut mal im Nvidia-Forum, da hat RNissl am Wochenende 2 Threads aufgemacht.

Gruß
Wolfgang

Sehr schön. Unser Problem ist auch dabei!

Gruss
durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


Immortal Romance Spielautomat