Gibt es eigentlich was neues bezüglich der Blockartefakte RASPi / IPTV Telekom Entertain?
Ich habe immer noch diese unguckbaren Bildfehler, wenn ich T-Entertain nutze.
Gibt es eigentlich was neues bezüglich der Blockartefakte RASPi / IPTV Telekom Entertain?
Ich habe immer noch diese unguckbaren Bildfehler, wenn ich T-Entertain nutze.
Alle Auffalligkeiten nochmal im Überblick:
1) Login auf Shell schlägt fehl (Login incorrect)
2) SSH Connection Refused, nach PW Reset Permission Denied
3) Im Router wird der Rechner mit fester IP .200 (sonst DHCP) nicht als Gerät im Netzwerk aufgelistet
4) SMB Freigabe vom yaVDR nicht mehr sichtbar (im Finder und auch nach smb://yaVDR funktioniert nicht möglich, evtl. Folgeproblem von 3.)
Ich fass' nicht....
Seit 3 Tagen bastel' ich an exakt dem gleichen Problem 'rum, allerdings OHNE das ich etwas zerschossen habe,
die Macken kamen VON GANZ ALLEINE zwischen 2 Neustarts!
Ausser gucken und aufnehmen wurde am Rechner nichts gemacht, weder Updates noch Konfigurationen,
da er seit 6 (!) Monaten stabil lief!
Bin gerade dabei, neu zu installieren, da das Image vom letzten laufffähigen Zustand auch nur Sch... produziert....
Ich habe im LAN einen headless VDR Server laufen, auf den mehrere Clients zugreifen.
Soweit alles im Lot.
Beim Abspielen von Aufnahmen ist mir folgendes aufgefallen:
Sehe ich mir mit einem Client mit VDR eine LAUFENDE Aufnahme an,
kann ich sie mir anstandslos bis zum Ende ansehen.
Mache ich das Gleiche mit LIve-TV unter XBMC,
spielt er die Aufnahme nur bis zum Zeitpunkt des Einstiegs ab.
D.h. wenn ich in eine laufende Aufnahme mit einem XBMC-Client nach 5 Minuten einsteige,
spielt XBMC nur diese 5 Minuten ab. Danach muss ich neu einsteigen, vorspulen, um den Rest zu sehen usw. bis zum Ende der LAUFENDEN Aufnahme.
VDR spielt unabhängig vom Einstiegspunkt anstandslos bis zum Ende durch.
Bekomme ich das bei XBMC auch irgendwie hin? Wenn ja, wie?
Achso: es ist dabei egal, welche YaVDR- oder XBMC-Version ich nehme, ist immer das gleiche.
Gruss
Andre
Moin moin Gemeinde!
Ich habe auf einem PC YaVDR0 0.3.2 ERFOLGREICH installiert.
Er läuft als Client an einem VDR-Server einwandfrei.
Gestern kam ich auf das schmale Brett, per Web-Konfiguration auf "XBMC@vdr-plugin-streamdev (experimental)" umzustellen.
Läuft soweit auch anstandslos, mit dem kleinen Makel, das der Rechner regelmässig in den StandBy-Mode herunterfährt,
wenn längere Zeit keine Aktionen per Tastatur oder Fernbedienung stattfanden.
Der PC lässt sich jedoch anstandslos wieder starten.
Ich habe mir schon die Finger nach allen möglichen Inaktivitäts-Einstellungen wundgesucht und soweit gefunden auch deaktiviert
oder auf Null gesetzt.
Und trotzdem...
Weiss einer 'n Rat oder hat noch'n Tipp,
was ich noch überprüfen kann bzw. an welcher Schraube ich drehen muss, damit es perfekt läuft?
Ansonsten grosses grosses Lob an die YaVDR-Mannen für die gelungene Arbeit an YaVDR!!!
Danke Freaks!
Hat mal wieder geklappt!
Also da lehne ich mich mal aus dem Fenster und sage das kann so nicht korrekt sein. Wenn Du wirklich auf 0.3.2 aktualisiert hättest, hättest Du VDR 1.7.22 aus "stable-vdr" auf dem Gerät und alle (!) Plugins aus dem PPA sind gegen diese VDR Version gebaut.....
Ich denke Du hast auf VDR 1.7.27 aus "testing-vdr" aktualisiert....
RICHTIG!
Aber das steht doch auch ganz oben, gucksDu...
Nun habe ich getan wie oben gewünscht, momentan kompiliert er...
Moin Gemeinde!
Ich habe die YaVdr 0.3.2 erfolgreich mit
"
#/> sudo apt-add-repository ppa:yavdr/testing-vdr
sudo apt-get update
sudo apt-get dist-upgrade
"
aktualisiert, läuft soweit alles problemlos.
Beim Nachinstallieren des VDR-PLUGIN-SVDRPSERVICE über das Webinterface bekomme ich immer
"
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
vdr-plugin-svdrpservice: Depends: vdr-abi-1.7.22-yavdr0
E: Broken packages
"
Vermutlich muss ich das Paket selbst kompilieren, oder?
Und wenn ja, wie mach' ich das?
Ich habe zwar die dev-Pakete usw., wie an anderer Stelle beschrieben, nachinstalliert,
"make" meckert aber
"grep: ../../../Makefile: Datei oder Verzeichnis nicht gefunden"
Im Makefile habe ich die Zeilen
"
### The directory environment:
VDRDIR = ../../..
LIBDIR = ../../lib
TMPDIR = /tmp
"
gefunden, da muss vermutlich was eingetragen werden.
Kann mir einer sagen, was?
Bei mir lag es schlicht und ergreifend daran, das ich bei meinen Karten das Timing in der diseqc.conf ändern musste:
S19.2E 11700 V 9750 t V S0 W1000 [E0 10 5A 00 00] W1000 V
S19.2E 99999 V 10600 t V S1 W1000 [E0 10 5A 00 00] W1000 V
S19.2E 11700 H 9750 t V S2 W1000 [E0 10 5A 00 00] W1000 V
S19.2E 99999 H 10600 t V S3 W1000 [E0 10 5A 00 00] W1000 V
Ist zumindest einen Versuch wert.
Alles anzeigen
Tja, sind dann halt langsame Karten, aber 1000ms sind aber auch für hier zuviel, versuch's mal mit 50-100 ...
Undankbarer Knopf, ist ja nicht so das die Leute nix besseres zu tun haben als Dir zu helfen ...
Regards
fnu
PS.: Und lerne mit den Format-Tags hier zu arbeiten, was soll das mit den blau markierten Code-Zeilen ...
jajajajajajaaaaaa....
Danke an alle, die sich geduldig mit mir abgegeben haben!
fnu: VORSICHT! Ich bin des öfteren in Ehingen, iss nich' weit von Böblingen...
Und blau fand ich übersichtlicher... so konnte man kopierten Text von Unsinnskommentaren besser unterscheiden, fand' ich...
Wie auch immer... setzt das einer auf gelöst oder kann ich das selbst machen?
Ach, noch was:
Auf dem Server brauche ich ja eigentlich kein Bild, das ständig angezeigt wird.
Wie konfiguriere in den VDR so, das die aktuelle Funktionalität erhalten bleibt aber auf dem Server kein Bild mehr zu sehen ist?
HA! ICH hab' ein Bild! Nä nä nä nä näääääääää näää....
Was hab' ich gemacht?
Das Timeout hat mich gestört! Also habe ich testhalber auf gut Glück die diseqc.conf folgendermassen geändert:
# SCR (Satellite Channel Routing):
#
S19.2E 11700 V 9750 t V W1000 S0 [E0 10 5A 00 00] W1000 v
S19.2E 99999 V 10600 t V W1000 S1 [E0 10 5A 00 00] W1000 v
S19.2E 11700 H 9750 t V W1000 S2 [E0 10 5A 00 00] W1000 v
S19.2E 99999 H 10600 t V W1000 S3 [E0 10 5A 00 00] W1000 v
#
Und "zack", gab's ein Bild, umschalten geht auch!
Uff!
Achja, kann ich die Kiste Bier ja selber trinken...
So, mein lieber Albert, hab' ich gemacht.
Danach steht das in der Syslog:
Apr 29 11:39:15 videoserver vdr: [6913] KBD remote control thread started (pid=6796, tid=6913)
Apr 29 11:39:15 videoserver vdr: [6914] Text2Skin: menu display update thread started (pid=6796, tid=6914)
Apr 29 11:39:23 videoserver vdr: [6796] switching to channel 1
Apr 29 11:39:24 videoserver vdr-sxfe[6873]: [6900] [input_vdr] BLANK in middle of stream! bufs queue 0 , video_fifo 0
Apr 29 11:39:24 videoserver vdr: [6884] TS buffer on device 1 thread ended (pid=6796, tid=6884)
Apr 29 11:39:24 videoserver vdr: [6877] buffer stats: 0 (0%) used
Apr 29 11:39:24 videoserver vdr: [6877] receiver on device 1 thread ended (pid=6796, tid=6877)
Apr 29 11:39:24 videoserver vdr: [6918] receiver on device 1 thread started (pid=6796, tid=6918)
Apr 29 11:39:24 videoserver vdr: [6919] TS buffer on device 1 thread started (pid=6796, tid=6919)
Apr 29 11:39:24 videoserver vdr: [6914] Text2Skin: menu display update thread ended (pid=6796, tid=6914)
Apr 29 11:39:28 videoserver vdr: [6858] frontend 0/0 timed out while tuning to channel 1, tp 111836
Apr 29 11:39:32 videoserver vdr-sxfe[6873]: [6900] [input_vdr] No data in 8 seconds, queuing no signal image
Apr 29 11:39:32 videoserver vdr-sxfe[6873]: [6900] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
Apr 29 11:39:49 videoserver vdr: [6920] Text2Skin: menu display update thread started (pid=6796, tid=6920)
Apr 29 11:39:57 videoserver vdr: [6796] switching to channel 2
Apr 29 11:39:57 videoserver vdr-sxfe[6873]: [6899] [input_vdr] vdr_flush_engine: playback is paused <0>
Apr 29 11:39:57 videoserver vdr: [6919] TS buffer on device 1 thread ended (pid=6796, tid=6919)
Apr 29 11:39:57 videoserver vdr: [6918] buffer stats: 0 (0%) used
Apr 29 11:39:57 videoserver vdr: [6918] receiver on device 1 thread ended (pid=6796, tid=6918)
Apr 29 11:39:57 videoserver vdr: [6921] receiver on device 1 thread started (pid=6796, tid=6921)
Apr 29 11:39:57 videoserver vdr: [6920] Text2Skin: menu display update thread ended (pid=6796, tid=6920)
Apr 29 11:39:57 videoserver vdr: [6922] TS buffer on device 1 thread started (pid=6796, tid=6922)
Apr 29 11:39:57 videoserver vdr: [6796] [xine..put] OSD bandwidth: 166290 bytes/s (1299 kbit/s)
Apr 29 11:39:57 videoserver vdr: [6923] Text2Skin: channelInfo display update thread started (pid=6796, tid=6923)
Apr 29 11:40:02 videoserver vdr: [6923] Text2Skin: channelInfo display update thread ended (pid=6796, tid=6923)
Apr 29 11:40:06 videoserver vdr-sxfe[6873]: [6900] [input_vdr] No data in 8 seconds, queuing no signal image
Apr 29 11:40:06 videoserver vdr-sxfe[6873]: [6900] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
Apr 29 11:40:07 videoserver vdr: [6858] frontend 0/0 timed out while tuning to channel 2, tp 111953
Apr 29 11:40:22 videoserver vdr: [6924] Text2Skin: menu display update thread started (pid=6796, tid=6924)
Apr 29 11:40:24 videoserver vdr: [6924] [xine..put] OSD bandwidth: 179396 bytes/s (1401 kbit/s)
Apr 29 11:40:26 videoserver vdr: [6796] switching to channel 3
Apr 29 11:40:26 videoserver vdr-sxfe[6873]: [6899] [input_vdr] vdr_flush_engine: playback is paused <0>
Apr 29 11:40:26 videoserver vdr: [6922] TS buffer on device 1 thread ended (pid=6796, tid=6922)
Apr 29 11:40:26 videoserver vdr: [6921] buffer stats: 0 (0%) used
Apr 29 11:40:26 videoserver vdr: [6921] receiver on device 1 thread ended (pid=6796, tid=6921)
Apr 29 11:40:26 videoserver vdr: [6925] receiver on device 1 thread started (pid=6796, tid=6925)
Apr 29 11:40:26 videoserver vdr: [6924] Text2Skin: menu display update thread ended (pid=6796, tid=6924)
Apr 29 11:40:26 videoserver vdr: [6926] TS buffer on device 1 thread started (pid=6796, tid=6926)
Apr 29 11:40:26 videoserver vdr: [6927] Text2Skin: channelInfo display update thread started (pid=6796, tid=6927)
Apr 29 11:40:31 videoserver vdr: [6927] Text2Skin: channelInfo display update thread ended (pid=6796, tid=6927)
Apr 29 11:40:34 videoserver vdr-sxfe[6873]: [6900] [input_vdr] No data in 8 seconds, queuing no signal image
Apr 29 11:40:34 videoserver vdr-sxfe[6873]: [6900] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
Apr 29 11:40:36 videoserver vdr: [6858] frontend 0/0 timed out while tuning to channel 3, tp 112603
Apr 29 11:40:55 videoserver vdr: [6928] Text2Skin: menu display update thread started (pid=6796, tid=6928)
Apr 29 11:41:00 videoserver vdr: [6796] switching to channel 4
Apr 29 11:41:00 videoserver vdr-sxfe[6873]: [6899] [input_vdr] vdr_flush_engine: playback is paused <0>
Apr 29 11:41:00 videoserver vdr: [6926] TS buffer on device 1 thread ended (pid=6796, tid=6926)
Apr 29 11:41:00 videoserver vdr: [6925] buffer stats: 0 (0%) used
Apr 29 11:41:00 videoserver vdr: [6925] receiver on device 1 thread ended (pid=6796, tid=6925)
Apr 29 11:41:00 videoserver vdr: [6929] receiver on device 1 thread started (pid=6796, tid=6929)
Apr 29 11:41:00 videoserver vdr: [6928] Text2Skin: menu display update thread ended (pid=6796, tid=6928)
Apr 29 11:41:00 videoserver vdr: [6930] TS buffer on device 1 thread started (pid=6796, tid=6930)
Apr 29 11:41:00 videoserver vdr: [6931] Text2Skin: channelInfo display update thread started (pid=6796, tid=6931)
Apr 29 11:41:05 videoserver vdr: [6931] Text2Skin: channelInfo display update thread ended (pid=6796, tid=6931)
Apr 29 11:41:08 videoserver vdr-sxfe[6873]: [6900] [input_vdr] No data in 8 seconds, queuing no signal image
Apr 29 11:41:08 videoserver vdr-sxfe[6873]: [6900] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
Apr 29 11:41:09 videoserver vdr: [6858] frontend 0/0 timed out while tuning to channel 4, tp 112544
Apr 29 11:42:01 videoserver vdr: [6861] SCR 3 assigned to device 2
Apr 29 11:42:10 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 1, tp 111836
Apr 29 11:42:14 videoserver vdr: [6858] frontend 0/0 timed out while tuning to channel 4, tp 112544
Apr 29 11:42:31 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 2, tp 111953
Apr 29 11:42:52 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 6, tp 112187
Apr 29 11:43:13 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 4, tp 112544
Apr 29 11:43:19 videoserver vdr: [6858] frontend 0/0 timed out while tuning to channel 4, tp 112544
Apr 29 11:43:34 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 3, tp 112603
Apr 29 11:43:55 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 1, tp 111836
Apr 29 11:44:16 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 2, tp 111953
Apr 29 11:44:25 videoserver vdr: [6858] frontend 0/0 timed out while tuning to channel 4, tp 112544
Apr 29 11:44:37 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 6, tp 112187
Apr 29 11:44:58 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 4, tp 112544
Apr 29 11:45:19 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 3, tp 112603
Apr 29 11:45:30 videoserver vdr: [6858] frontend 0/0 timed out while tuning to channel 4, tp 112544
Apr 29 11:45:40 videoserver vdr: [6861] frontend 1/0 timed out while tuning to channel 1, tp 111836
Habe insgesamt 5 Sender aus der Channelpedia geguttenbergt, den VDR über das Control-Plugin ferngesteuert, wegen der Hin- und Herrennerei.
So wie ich das sehe kriegt er null Daten, fragt sich nur, warum. Wegen dem Timeout: kann man da irgendeinen Wert erhöhen?
Achja, in der Diseqc ist wieder von "v" auf "V" geändert.
scr.conf scheint richtig konfiguriert zu sein:
cat /var/log/syslog | grep SCR
Apr 29 11:38:23 videoserver vdr: [6858] SCR 2 assigned to device 1
Apr 29 11:42:01 videoserver vdr: [6861] SCR 3 assigned to device 2
Habe das hier im syslog gefunden, vielleicht hilft's:
Apr 28 19:51:42 videoserver vdr: [6772] SCR 3 assigned to device 2
Apr 28 19:51:52 videoserver vdr: [6772] frontend 1/0 timed out while tuning to channel 1, tp 111836
D.h. meines Erachtens, das die Karten laufen und ansprechbar sind,
jedoch keine Daten liefern, richtig?
Derjenige, der mir den entscheidenden Tip gibt, der diesen Irrsinn zum Laufen bringt,
bekommt eine Kiste Bier seiner Wahl!
EHRLICH!
Nenn' mir ausser der TBS noch andere!
Das mit dem Kanal 92 ist mein Versehen, habe die Datei erstellt, BEVOR ich bis auf einen Kanal alle aus der Channels.conf gelöscht habe.
Ich denke, das kann man vernachlässigen, da er mit der neuen channels.conf gleich auf Kanal 1 geht.
Mich fasziniert am meisten, das bei der Auswahl des Senders nicht die Meldung "Kanal nicht verfügbar" kommt,
sonder sich der VDR so verhält, als wenn schlicht und ergreifend keine Daten gesendet werden.
Ich habe den Verdacht, das die Skystar-Karten schlicht besch.. sind, leider.
Andere karten für den PCI-Slot, die Unicable beherrschen, habe ich bisher nicht gefunden.
Ich werd' hier noch wahnsinnig! Es geht ums Verrecken nicht!
Was läuft da bloss verkehrt??
Unter Windoof geht es doch!
Ok, hier also meine AKTUELLEN Einstellungen von heute im Anhang. Er bootet gerade... (19:36)
Nix iss... (19:40)
Das steht in /var/log/syslog, wenn ich auf den einen einzigen kanal umschalten will:
Apr 26 19:49:18 videoserver vdr: [855] switching to channel 1
Apr 26 19:49:18 videoserver vdr-sxfe[1438]: [1477] [input_vdr] vdr_flush_engine: playback is paused <0>
Apr 26 19:49:18 videoserver vdr: [1600] TS buffer on device 1 thread ended (pid=855, tid=1600)
Apr 26 19:49:18 videoserver vdr: [1599] buffer stats: 0 (0%) used
Apr 26 19:49:18 videoserver vdr: [1599] receiver on device 1 thread ended (pid=855, tid=1599)
Apr 26 19:49:18 videoserver vdr: [1605] receiver on device 1 thread started (pid=855, tid=1605)
Apr 26 19:49:18 videoserver vdr: [1604] Text2Skin: menu display update thread ended (pid=855, tid=1604)
Apr 26 19:49:18 videoserver vdr: [1606] TS buffer on device 1 thread started (pid=855, tid=1606)
Apr 26 19:49:18 videoserver vdr: [855] [xine..put] OSD bandwidth: 168013 bytes/s (1312 kbit/s)
Apr 26 19:49:18 videoserver vdr-sxfe[1438]: [1478] [demux_vdr] PMT changed, resetting demuxer
Apr 26 19:49:19 videoserver vdr: [1290] frontend 0/0 timed out while tuning to channel 1, tp 111836
Das steht in der scr.conf:
# SCR (Satellite Channel Routing) configuration for VDR
#
# Format:
#
# channel frequency [pin]
#
# channel: SCR channel index (0-7)
# frequency: frequency of the SCR channel ("user band")
# pin: optional pin of the SCR channel (0-255)
#
# A line containing space separated integer numbers, terminated with a ':',
# defines that any following lines apply only to the given list
# of device numbers.
#
# Examples:
# 0 1284
# 1 1400
# 2 1516
# 3 1632
# 4 1748
# 5 1864
# 6 1980
# 7 2096
2 1280
3 1382
Hi Albert!
Alles EXAKT nach Deinen Vorgaben eingerichtet, KEINE Änderung im Verhalten!
Sender lassen sich umschalten, keine Fehlermeldung, aber weder Bild noch Ton noch EPG. Nulll nada niente nichts!
Boote ich von der WindowsXP Platte und starte DVBViewer habe ich sofort ein Bild.
Allerdings stehen die UniCable-Einstellungen dort auf 3 1280 / 4 1382, wie vorgegeben.
Deswegen verstehe ich Deinen Eintrag 0 1284 / 1 1382 nicht so ganz...
Wozu brauch' ich denn den S13.0E Eintrag?
Hallo Gemeinde!
An unserer Inverto-Unicable-Hausanlage betreibe ich YaVDR 0.3.2 (VDR 1.7.22) mit 2 SkyStar S2 Karten (S2-Liplianin)
jede mit einem eigenen Kabel. Adressen (Slots) sind 3 1280 und 4 1382 (so vom Vermieter angegeben und übernommen).
Wirbelscan findet die Karten und scannt das Frequenzband durch, findet jedoch keinen einzigen Sender.
Auch einen händisch in die Channels.conf eingetragenen Sender kann ich nicht sehen.
Es kommt jedoch nicht die Meldung "Kanal nicht verfügbar".
Unter Windows XP mit DVBViewer TE lassen sich die Karten jeweils anstandslos benutzen (nur mal kurz angetestet),
deswegen kann ich wohl generelle Empfangsprobleme ausschliessen.
Eventuell habe ich YaVDR falsch konfiguriert.
Hier meine .conf-Dateien
diseqc.conf:
...
# Eigene Konfiguration
S19.2E 11700 V 9750 t v S0 W10 [E0 10 5A 00 00] W10 v
S19.2E 99999 V 10600 t v S1 W10 [E0 10 5A 00 00] W10 v
S19.2E 11700 H 9750 t v S2 W10 [E0 10 5A 00 00] W10 v
S19.2E 99999 H 10600 t v S3 W10 [E0 10 5A 00 00] W10 v
S13.0E 11700 V 9750 t v S4 W10 [E0 10 5A 00 00] W10 v
S13.0E 99999 V 10600 t v S5 W10 [E0 10 5A 00 00] W10 v
S13.0E 11700 H 9750 t v S6 W10 [E0 10 5A 00 00] W10 v
S13.0E 99999 H 10600 t v S7 W10 [E0 10 5A 00 00] W10 v
#
scr.conf:
# SCR (Satellite Channel Routing) configuration for VDR
#
# Format:
#
# channel frequency [pin]
#
# channel: SCR channel index (0-7)
# frequency: frequency of the SCR channel ("user band")
# pin: optional pin of the SCR channel (0-255)
#
# A line containing space separated integer numbers, terminated with a ':',
# defines that any following lines apply only to the given list
# of device numbers.
#
# Examples:
# 0 1284
# 1 1400
# 2 1516
# 3 1632
# 4 1748
# 5 1864
# 6 1980
# 7 2096
3 1280
4 1382
channels.conf:
ZDF;ZDFvision:11953:hC34M2O0S0:S19.2E:27500:110:120,121=deu;125:130:0:28006:1:1079:0
(ja, ist nur dieser eine Sender drin!)
Irgendwelche Ideen, was ich machen könnte?
ZitatOriginal von cooper
Servus Andre,
Hast du mal einfach alle Plugins deaktiviert? Evtl. fehlt dir ja jetzt mit dem neuen Kernel ein Treiber für irgend was, z.B. gibts ja keine DXR3-Unterstützung uvm.
Viele Grüße, Mirko
Das war der Punkt! Die fehlenden DXR3-Module/Treiber. Kommen die wohl noch? Weiss jemand, ob die Nova-S-Plus mit dem Update endlich erkannt wird und läuft?
Gruss
Andre