Beiträge von Tschennings

So - unter der kompletten Angabe im Befehl klappt die (temporäre) Umstellug der Frequenz.

Zitat

xrandr --output DVI-D-0 --mode 1920x1080 --rate 60.00

...allerdings ändert sich nur die Häufigkeit und "Geschwindigkeit", mit welchen die Interfernenzstreifen durchs Bild ziehen- egal bei welcher Frequenz, es ist immer da.

Bur bei Zoom - irgendjemand damit Erfahrungen, ob / wie man den Zoom-Client diesbezüglich modifiziert starten kann?

Hallo,

o.g. Problem lag vor dem Bildschirm - am Ziel bin ich aber immernoch nicht.

Leider bekomme ichs nicht gebaken, die Frequenz zu ändern (siehe Bild).

Hat jemand nen Rat für mich?

Zitat

xrandr -d :0.0 -s 1920x1080 -r 60

Rate 60.00 Hz not available for this size

und:

xrandr --query

Can't open display

gibts da einen anderen Weg?

probier ich aus! Danke!

nein - noch nicht, wie mache ich das?

Zitat

gedit ~/.config/monitors.xml

so?

Hallo Seahawk,

das ist es nicht, denke ich - auch das Fenster, in dem sich erst noch das Videobild aufbaut, flackert stark noch während die "Sanduhr" darin läuft (zudem unabhängig von der Beleuchtungsart). Auch das Settings-Fenster von ZOOM kommt immer wieder mit weißen und schwarzen "Zeilenfehler" daher.

Andere Programme auf dem Desktop zeigen das Verhalten nicht, auch welche mit Camera-Livebild (Google Duo z.B.).

tschennings

Hallo,

YaVDR ansible läuft nun bei mir problemlos produktiv und die Familie ist happy. Zusätzlich wird der VDR auch für div. andere Späße genutzt wie Google Earth etc. Zuletzt habe ich ZOOM installiert. Dies startet grundsätzlich richtig und läuft, allerdings flackert das Bild (v.a. das Live-Camera-Bild) extrem. Waran kann das liegen oder in welche Richtung kann ich suchen? Danke für Eure Ideen...

tschennings

Ich hab zweierlei Maßnahmen gestartet: a) bei mir ist der VDR inzwischen dauerhaft attached (sehe bei mir vom detachen keinen Vorteil) und b) der Skin ist gefixt. Ich geh davon aus, dass es mit dem Skin zusammenhing. In jedem Falle kein Problem mehr diesbezüglich!

Läuft! - Sehr gut! Ihr seid Spitze!!

Cool - morgen nachmittag werd ich es auch schaffen, ich probiers dann und gebe Feedback!

Hi Kamel5,

wie bekomme ich den Fix auf mein System? Einfach per update (sudo apt update && sudo apt full-upgrade)?

Zitat

nopacity via Skindesigner könnte dein Problem lösen.

Zu der Frage welche Funktion kann ich nichts sinnvolles Beitragen - bin ich überfragt.

Kann das wer bestätigen, das nOpacity via Skindesigner das Problem lösen würde? Wäre dankbar um eine Bestätigung, bevor ich alles umbaue...

Ich geh davon aus, dass es egal ist, ob nOpacity "direkt" oder via Skindesigner installiert ist?

Hi Alexander,

hier gabs einen Patch für dieses Problem?

Link

siehe oben:

Zitat

Genau darum gehts offenbar - ein anderer Skin macht keinen Stress

nur: der WAF benötigt dringend den nOpacity-Skin

verhält sich nOpacity aus dem Skindesigner-Menu heraus installiert genauso oder kommt das nur wenn man ihn direkt installiert hat?

also -der Workaroung mit dem entfernten -D in der /etc/vdr/conf.aviable/softhdevice.conf hat leider nichts gebracht.

anbei mal ein paar Auszüge per journalctl -u vdr -l -b:

14 Zeilen von unten - da ploppt das Problem auf...

Hallo Seahawk!

ok - das Log reiche ich nach - dazu muss ich den Crash erst mal wieder provozieren. Das mit dem Fehlerpotential mit allgemein detachten Frontend kann ich bestätigen - hab nur noch keine solche Reproduzierbarkeit wie mit den Timerkonflikten erkannt.

Zitat von seahawk1986

also das -D aus den Plugin-Argumenten von softhddevice

wo genau finde ich das?

Zitat

...(z.B. schmiert das vdr-plugin-skinnopacity IIRC gerne ab, wenn bei detachtem Frontend eine OSD-Meldung angezeigt werden soll...

Genau darum gehts offenbar - ein anderer Skin macht keinen Stress und zudem schmiert der vdr immer dann ab, wenn im LCD (wenn ein anderer Skin aktiviert ist) den Timerkonflikt anzeigt.

Läßt sich diese Timerkonflikt-Meldung beim Start irgendwie unterdrücken?

Welche Logs benötigst Du?

Hallo,

inzwischen steht mein YaVDR0.7 als Produktivsystem im Wohnzimmer - da zeigte sich folgendes Problem: Wenn ein timer angelegt wurde (manuell oder automatisch) aus dem ein Timerkonflikt resultiert, fährt das System beim nächsten Start nicht mehr hoch - der vdr startet, wird abgebrochen, startet...

Die Suche hat mir das hier gebracht - aber ob das zu meinem Problem passt, bin ich mir nicht sicher. Hat jemand die Muse, mich bei diesem Problem zu unterstützen? Danke schonmal!

Tschennings

Hallo Seahawk, und YaVDR-user,

Ich hab nun auch endlich aufgerüstet und YaVDR07 an den Start gebracht. Das System ist im wesentlichen ein Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe mit Intel Pentium Dual Core E5200 2.50GHz, Als Sat-Karten sind 2 Technotrend am Start. Systemlaufwerk eine 64 GB SSD, 2x 2T-Platten als Videodatenspeicher.

Kurze Notizen:

Ubuntu Server installiert, YaVDR Playbook drüberlaufen lassen. Channel-conf und Festplatten eingerichtet - System lief! Sehr gut!

Ich habe aus Gewohnheitsgründen den Skin Nopacity am Start. Dieser war zunächst sehr träge - mit dem softhddevice-openglosd eine dramatische Verbesserung! Sehr zu empfehlen bei dieser Konstellation.

LCD des Silverstone-Gehäuses zeigte nur Buchstabensalat. Ursache war das installierte IMONLCD. Austausch durch das imonvfd hats dann gerichtet (danke an rkp für die Tipps).

Am Desktop (wenn ich mal nicht Fernsehe damit) war Openbox aufgrund zu kleiner Schrift nicht lesbar auf meinem Fernseher (Samsung 4K) - Anpassen der Datei /var/lib/vdr/.config/openbox/rc.xml hat geholfen.

Viele weitere Plugins (VNSI für Openelec-Clients, menuorg, IPtv und Chrome für Videochats...) laufen inzwischen ebenfalls einwandfrei.

Ansonsten alles sehr prächtig - Erstmal Danke für die Tolle Arbeit!!!

nur noch ein Problem: Wenn ich manchmal heimkomme läuft das Ding (vermutlich eine Aufnahme). Wenn ich dann zur Fernbedienung greife startet der vdr neu (zu sehen am Display). Syslog zeigt folgendes:

Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: DEBUG:yaVDRFrontend:we have user activity: attach
frontend!
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: DEBUG:yaVDRFrontend:set_background with options
path: /usr/share/yavdr/images/yavdr_logo.png, fill: False
Jan 20 17:36:10
yavdr7 vdr: [2814] [softhddev]CreateOsd: left 0, top 0, level 0, using OpenGL
OSD support
Jan 20 17:36:10
yavdr7 vdr[2814]: Magick: abort due to signal 11 (SIGSEGV) "Segmentation
Fault"...
Jan 20 17:36:10
yavdr7 vdr: [2814] [softhddev]detached - OpenGl Worker Thread not tried to
start
Jan 20 17:36:10
yavdr7 vdr: [2814] [softhddev]OpenGl Thread not started successfully, using
Dummy OSD
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: DEBUG:yaVDRFrontend:set_background with options
path: /usr/share/yavdr/images/yavdr_logo.png, fill: False
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: DEBUG:VDRFrontend:user is active: True
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: ERROR:yaVDRFrontend:g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected
from message bus without replying (4)
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: Traceback (most recent call last):
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:   File
"/usr/lib/python3/dist-packages/yavdr_frontend/yavdrfrontend.py",
line 314, in start
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:    
current_frontend.start()
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:   File
"/usr/lib/python3/dist-packages/yavdr_frontend/vdrfrontend.py", line
191, in _start
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:    
self.frontend.start()
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:   File
"/usr/lib/python3/dist-packages/yavdr_frontend/frontends/genericfrontend.py",
line 155, in start
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:     if not
self.status() and not self.resume():
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:   File
"/usr/lib/python3/dist-packages/yavdr_frontend/frontends/genericfrontend.py",
line 196, in status
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:     if
self.check_state() == "attached":
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:   File
"/usr/lib/python3/dist-packages/yavdr_frontend/frontends/genericfrontend.py",
line 190, in check_state
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:     code, _
= self._svdrpcmd("stat")
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:   File
"/usr/lib/python3/dist-packages/pydbus2vdr.py", line 86, in
SVDRPCommand
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:    
plugin_proxy = self.bus.get(self.vdr_name, object_path)
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:   File
"/usr/lib/python3/dist-packages/pydbus/proxy.py", line 44, in get
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]:     ret =
self.con.call_sync(
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: gi.repository.GLib.GError: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected
from message bus without replying (4)
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: INFO:pydbus2vdr:VDR Status: stopped
Jan 20 17:36:10
yavdr7 yavdr-frontend[1452]: DEBUG:softhddevice:g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name de.tvdr.vdr was
not provided by any .service files (2)
Jan 20 17:36:10
yavdr7 systemd[1]: vdr.service: Main process exited, code=dumped, status=6/ABRT
Jan 20 17:36:10
yavdr7 systemd[1]: vdr.service: Failed with result 'core-dump'.
Jan 20 17:36:10
yavdr7 LCDd: sock_send: socket write error
Jan 20 17:36:10
yavdr7 systemd[1]: vdr.service: Scheduled restart job, restart counter is at 2.
Jan 20 17:36:10
yavdr7 systemd[1]: Stopped Video Disk Recorder.
Jan 20 17:36:10
yavdr7 systemd[1]: Starting Video Disk Recorder...

Idee, was da schiefläuft?