Sky hat etwas an der Laenge der CWs geaendert (und damit passt die Checksummenberechnung nicht mehr). Ich bin mir nicht ganz sicher, aber das duerfte den DVB Standard brechen.
Diverse halblegale Loesungen sind damit abgeklemmt. Die Skyreceiver und auch deren CAM laufen jedoch weiterhin. Wenn nicht, die Hotline kontaktieren.
Eine neue channels.conf hilft Dir also nicht.
Vor dem Kauf der Hardware informieren.
Digital Devices schreibt das sogar im Handbuch, dass es abgeschaltet sein sollte.
Es betraf alle HD Sender, sobald der zweite Tuner aktiv war.
Nach fast einer Nacht Debugsession konnte ich das Problem loesen. Mittels acpi=off war alles in Ordnung. Daher durch die Kernelconfig gehangelt und CONFIG_INTEL_IDLE gefunden, welches aktiv war. N und es ist tatsaechlich gut.
Warum auch immer das erst beim Zweitunerbetrieb zum tragen kam und was da wirklich ausgebremst wird.
Ich halte die Netzwerkleitung auch fuer nicht so toll. Davon ab, macht man sowas ohnehin nicht. Gebauede werden potentialfrei vernetzt.
Und von solchen fancy Zwischensteckern brauchst Du eigentlich genau gar nichts erwarten. Ist wenn ueberhaupt, nur was fuer das eigene Gewissen.
Von Blitzschutz braucht man da aber auch nicht zu reden, wenns dir in die Antenne haut, ist ohnehin alles kaputt. Gegen direkten Blitzschlag kannst du wenig tun.
Ausser den Schaden versuchen zu minimieren, in sofern, dass Dir die Huette nicht abbrennt. Schaeden an Geraeten wirst Du wahrscheinlcih aber auch dann haben, wenn Du mit Fangstange und 50qmm die Hauswand runter schuetzst.
Die meisten Anlagen, die nicht im Schutzbereich sind, haben - sofern sie hoffentlich geerdet sind - dennoch quasi null Blitzschutz. Da laeuft die Erdung dann mit den Coaxkabeln zusammen in einem Rohr vom Dach in den Keller, dort meistens noch sehr nah zu vielen anderen Leitungen.
Ist deine Satanlage denn in den Blitzschutz eingebunden? Sollte sie ja ansich sein, wenn ihr schon Blitzableiter habt.
Du musst aber auch bedenken, dass Dein Nachbar auch jeglichen Schutz haben muesste. Im Zweifelsfall kommt die Gefahr aus dem Netzwerkkabel 
Und Einschlaege in der Naehe kommen Dir meist durch die Telefonleitung ins Haus.
Ich wuerde diesen ganzen Krempel einfach links liegen lassen - es bringt nichts. Ein richtiger Ueberspannungsschutz ist mehrstufig und sehr teuer.
Empfangsanlage ist es definitiv nicht. Habe die kleine Technisat aufgebaut - exakt das selbe Problem.
Werde mich morgen mal an den DD Support wenden. Ansonsten geht der Krempel zurueck.
..egal was du machst, mach ja keinen Kurzschluss.
Hehe, natuerlich nicht
Ich habe bisher nur bei einem Tuner im Leerlauf gemessen (ja, sagt wenig aus) - das passt. Spannung veraendert sich auch, wenn man die Spannung am LNBH25 erhoeht (es gibt dafuer ein Register - der Treiber schreibt da "boost" (ist fest auf 3) und 1 (4) fuer V, 8 (11) fuer H rein.
Zusaetzlich habe ich mal ein paar Ausgaben in den Treiber des lnbh25 eingebaut (der hat 2 Statusregister) - die verhalten sich - was Overload und Co betrifft - unscheinbar.
Um jegliche Empfangsprobleme auszuschliessen (wo ich aber ohnehin nicht dran glaube), werde ich am Wochenende mal im Garten testen. Habe noch eine Technisat Digidish 45 mit Gehwegplatte in der Garage. Die bau ich mal auf. Bei der Gelegenheit kann ich da leicht eine Dose anschliessen und ebenfalls eine Messleitung mit herausfuehren.
Werden denn, wenn man in FEMON auf den zweiten Tuner umschaltet, mehr Daten ueber den PCI Bus geschaufelt? Im Grunde gibts ja nur einen "Abnehmer". Ab da geht das Ruckeln aber los.
Ich habe den zweiten Tuner mit vdr-dynamite mal vom VDR entfernt und auf diesem Dein w_scan laufen lassen. Dabei habe ich nicht so viele Stoerungen gesehen - eher nur ein zwei kleinere, aber das kann ja auch mal woanders herkommen.
Ansonsten habe ich aktuell wirklich keine Idee mehr. Wenn ich die Tests gemacht habe, werde ich mich an den Support von DD wenden.Kann ich sonst noch irgendwas ausprobieren?
Ich koennte vielleicht noch die Kernelsourcen von nst ausprobieren, wo er die Treiber integriert hat. Sehe aber keine wirklichen Aenderungen, die er ma 0.9.29 gemacht hat, die mir helfen koennten.
LNB Spannung hab ich nicht gemessen. Einfach waere nur im Leerlauf, ansonsten muesste ich mir erst was zum Zwischenstecken bauen. Anderseits scheint ja ein Hardwaredefekt der Karte auszuscheiden, da beide dieses Verhalten zeigen.
Theoretisch koennte natuerlich auch hier der Treiber reinspielen.
Vielleicht kann ich auch einfach ein Draht in der Dose mit unter die Seele klemmen zum Messen, muss ich mir morgen mal anschauen.
Ja, ohne zusaetzliche Spannungsversorgung tritt das Problem auch auf (ich habe schon hier und da gelesen, dass eine zusaetzliche Spannungsversorgung da Probleme machen kann). Was ich davon allerdings halten soll, weiss ich nicht.
Hallo,
nach Ableben meiner DVBSky 952 Karte habe ich mir eine Digitial Devices Cine S2 V7A zugelegt. Leider habe ich von Anfang an Probleme gehabt, die ich bisher nicht loesen konnte.
Es gibt - auf jeden Fall bei den HD Sendern, immer wieder Empfangsstoerungen bzw. Kloetzchenbildung. Sowohl beim Live-TV als auch bei Aufnahmen.
Eingrenzen konnte ich das bisher in soweit, dass dieses Problem nur auftritt, wenn beide Tuner aktiv sind, also LOCK haben. Ist also nur einer aktiv, ist es stoerungsfrei.
Dabei ist es egal, welchen von beiden mal ungenutzt laesst.
Beendet man den VDR, ist auf beiden Tunern der LOCK weg (sieht man mit dvb-fe-tool). Startet man den VDR, wird nun auf einem Tuner gelockt. Alles in Ordnung.
Der Fehler ist unabhaengig vom verwendeten Tuner, ob #0 oder #1 allein keine Probleme. Schaltet man in femon auf den anderen Tuner (oder macht parallel einen Stream auf einen anderen Transponder auf) beginnen die Stoerungen.
An der Empfangsanlage liegt es nicht - beide Leitungen sind in Ordnung und die DVBSky lief dort all die Zeit problemlos.
Ich habe schon bei DD den Stromversorgungsadapter bestellt, sogar mit Ferritkern drum. Keine Besserung. Spannungsversorgung ist also auch nicht das Problem (haette mich auch gewundert, da aktiver Multiswitch)
Anderes Netzteil (550W) habe ich auch schon probiert - Probleme bleiben.
Ich habe mir nun auch schon eine zweite V7A bestellt - leider keine Loesung.
Ich habe aktuell keine Idee mehr, was ich noch machen soll.
Treiber verwende ich den 0.9.29 von DD von Github gegen den Kernel 4.9.34.
Die Settings, die DD in ihrer Anleitung erwaehnt habe ich gecheckt. PCI Express Overclock habe ich nicht und ansonsten ist aber auch jeder dynamische Takt seit eh und je inaktiv.
Vielleicht hat jemand von Euch noch eine zuendene Idee, was ich versuchen kann (anderer Treiber, mit irgendwelchen Patches? Der 0.9.29 scheint aber der letzte offizielle im Moment zu sein).
Syslog ist im uebrigen total unauffaellig. Ich habe beim Treiber auch schon die Option msi=0 probiert. IRQ Konflikte liegen laut /proc/interrupts aber ohnehin nicht vor.
Wenn noch Infos fehlen, einfach Bescheid sagen.
PS: Rechner ist ein Fujitsu Celsius W280. BIOS ist das letzte.
Die DVBSky lief auch in dem Rechner - ebenfalls mit beiden Tunern (sogar schon in deutlich schlechterer Hardware).
Danke und Gruss
Ich bin gesundheitlich auch angeschlagen, kann noch nicht versprechen, dass ich komme. Ist aber noch angedacht.
Ich denke ich komme auch - viele altbekannte Leute haben zugesagt oder überlegen es sich noch, die Speisenkarte sieht auch top aus und ich kann mit der Bahn fahren..
TOP Reboot!
Hallo zusammen,
ich habe bis vor kurzem noch VDR 1.6 betrieben mit einer Hauppauge Nexus-S 2.2 sowie einer Tevion Cinergy 1200 (Kabel).
Es war als ein reines SD System; mit der FF hatte ich nie Probleme (auch bei einer Aufnahme von ORF war bis auf träges OSD alles ok, keine Ruckler); die Karte verfügt über keinen Full-TS Mod.
Da ich nun HD-Sender über eine Enigma2 Box schaue, soll der VDR nur noch zur Aufnahme von HD dienen, die ich dann per NFS schaue; ich habe ihn dafür mit VDR 1.7.42 ausgetattet und zusätzlich eine Tevii S470 eingebaut (die hat das Satkabel, die FF dient _NUR_ noch zur Ausgabe von SD (--outputonly) an meinen Schlafzimmerröhrentv). Nur noch mal um sicherzugehen, FULL-TS Mod ist an dieser Stelle nicht nötig, da die Karte den PES bekommt zum Anzeigen?
Nach dem Umschalten hatte ich allgemein immer ziemlich lange ein Ruckeln, was sich allerdings mit Erhöhen der PCI Latenz auf 128 für die FF beseitigen liess. Was jetzt allerdings auftritt, dass ich bei ORF immer wieder Störungen habe, es ruckelt. Signal ist in Ordnung (lief ja vorher mit 1.6er und direkt über die FF auch, FEmon auch OK). Wenn es ruckelt wird meistens TS packet not accepted in Transfer Mode ausgegeben, jedoch nicht immer. Wenn die Meldung nicht erscheint, ruckelt es "schwächer" - greift hier evtl. der Retry?
Die TS meldungen sind mir auf anderen Sendern noch nicht untergekommen, obwohl es dort teilweise auch mal stockt.
Aufnahmen scheinen, soweit ich das jetzt schon sagen kann, nicht betroffen zu sein.
Hat jemand eine Idee, woher das Ruckeln kommt und wie ich das ggf weiter Debuggen kann?
Ich verwende im übrigen Kernel 3.5.7 und die dort integrieren DVB-Treiber. Schaltet man den VDR auf einen HD Sender gibt es kein Bild, nur stockenden Ton. Kann ich daher von der Annahme ausgehen, dass die Änderungen, die UFO durchgeführt hatte dort nicht enthalten sind? Ich habe da noch keinen Blick in die Sourcen geworfen. Allerdings habe ich das Ruckeln auch, wenn ich zuvor nicht auf einem HD Sender war, aber ich weiss auch nicht, inwie fern die Karte (trotz Neustart) irgendwas "defektes" im Speicher halten kann.
PS: Sorry, eigentlich passt es nicht in den Thread, jedoch passt die ganze Diskussion nicht zum Thema Emergency Exit und hier wurde das Problem am ehesten diskutiert. Immerhin kann ich bestätigen, dass Aufnahmen offenbar nicht betroffen sind und der "neue" Mechanismus von kls funktioniert.
Grüße
Hast recht, nächstes Mal.
Hatte das erste eigentlich nur hier hingelegt, weil mich jemand aus dem VDR-Portal IRC fragte.
svn #1165 (keine Ahnung was sich geändert hat) mit scaletext patch von hier für Freetz. Diesmal für MIPS und MIPSEL Boxen.
lcd4linux SVN #1163 mit dpfhack und PNG Imagesupport, sowie scaletext patch von hier für MIPSEL Fritzboxen (Freetz)
BER muss nicht unbedingt 0 sein, UNC schon. UNC != 0 ist Bild/Tonstörung (UNC uncorrectable).
Über Kreuz tauschen wäre ne Idee.
Wandert der Fehler mit, mal genau notieren bei welchen Sendern es Probleme gibt und bei welchen nicht, vielleicht liegen die Probleme wirklich nur auf einem Band.
tv:~# femon -a 1
using '/dev/dvb/adapter1/frontend0'
FE: Conexant CX24123/CX24109 (SAT)
status 1f | signal f000 | snr ffdc | ber 00000027 | unc 00000027 | FE_HAS_LOCK
status 1f | signal f000 | snr ffdc | ber 00000027 | unc 00000027 | FE_HAS_LOCK
status 1f | signal f000 | snr ffdc | ber 00000027 | unc 00000027 | FE_HAS_LOCK
status 1f | signal f100 | snr ffdc | ber 00000000 | unc 00000000 | FE_HAS_LOCKUNC muss für ein fehlerfreies bild 0 sein, geringer Wert auf BER hingegen ist ok. Ein Problem ist also bei genau dieser Karte zu suchen und/oder der Verkabelung dahin.
Der Thread dient wie die Antwort auf den Kommentar mal wieder nur der Selbstproduzierung. Ich finde es jedenfalls ernsthaft lächerlich, wenn es um die Rechtschreibschwäche geht, dass dann direkt die erste Gelegenheit genutzt wird, wieder Werbung für FreeVDR zu machen und sich darzustellen, wie toll man doch für die Community ist.
Das hat damit einfach mal gar nichts zu tun und dann noch einen zweiten Thread aufmachen wegen Diskriminierung?! Wo wirst Du diskriminiert?
Zugegeben, es war etwas ungeschickt von ihm absichtlich so einen Satz falsch zu schreiben, aber das war auch das einzige. Das direkt einem Moderator zu melden, finde ich reichlich überzogen. Er hat dich ja nichtmal wirklich beleidigt, und selbst wenn, passenden Kommentar entgegnen und dann danke, tschüss.
Zum eigentlichen Thema, det, es ist manchmal echt unterirdisch was Du an Rechtschreibung hier ablieferst. Ich unterscheide da aber bewusst zwischen IRC und hier im Portal, allerdings würde ich auch ein Mindestmaß erwarten, wenn man Hilfe zu einem Problem sucht. Im Grunde hat man für das Verfassen im Forum genügend Zeit, um das in Word/Openoffice/Whatever mal vorzuformulieren und die Rechtschreibkorrektur zu bemühen. Keiner erwartet hier von irgendwem die perfekte Rechtschreibung, aber doch ein Mindestmaß. Im IRC ist das etwas anders, da werden Fehler noch eher verziehen, weil es da eine Sache ist, die sage ich mal schneller abläuft, aber auch da fällt auf, dass Du Sachen wie z.B. "Patch" immer wieder auf die gleiche Weise falsch schreibst, auch wenn es vor Dir in zwei Zeilen die Leute richtig schrieben. So eine Rechtschreibschwäche ist sicher ein Handicap, aber man kann damit nicht alles entschuldigen. Da muss man sich leider mal ein bisschen bemühen; bei Scripten oder was Du sonstso erstellst, musst Du dich ja auch an einen gewissen Syntax halten und siehe da, da geht es ja auch.
Just my 2 cents,
devzero
Hallo,
ich hab den Thread durch Google gefunden, weil ich auch Probleme hatte, Xine 1.2 unter Gentoo zu bauen (aus einem ebuild). Zum einen gibt es kaum ebuilds, im flameeyes-overlay bin ich aber letztendlich fündig geworden.
Leider hat dies keine vdpau unterstützung und es baute bei mir nicht, mit einer Fehlermeldung die ich hier fand. Ich habe ein bisschen rumexperiment und eine Lösung gefunden - es wird automake 1.9 benötigt. Ich habe das Ebuild entsprechend angepasst - es baut jetzt durch und kennt vdpau als Useflag.
Die Änderungen gegenüber dem ebuild in flameeyes-overlay sind diese:
vdr ~ # diff -Nur /var/lib/layman/flameeyes-overlay/media-libs/xine-lib/xine-lib-1.2.9999.ebuild /usr/local/portage/media-libs/xine-lib/xine-lib-1.2.9999.ebuild
--- /var/lib/layman/flameeyes-overlay/media-libs/xine-lib/xine-lib-1.2.9999.ebuild 2010-03-26 18:40:12.000000000 +0100
+++ /usr/local/portage/media-libs/xine-lib/xine-lib-1.2.9999.ebuild 2010-03-26 19:28:45.000000000 +0100
@@ -2,6 +2,7 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/media-libs/xine-lib/xine-lib-1.1.8.ebuild,v 1.9 2007/10/08 17:20:23 corsair Exp $
+WANT_AUTOMAKE="1.9"
inherit eutils flag-o-matic toolchain-funcs libtool autotools mercurial
DESCRIPTION="Core libraries for Xine movie player"
@@ -15,7 +16,7 @@
gnome sdl speex theora ipv6 altivec opengl aac fbcon xv xvmc
samba dxr3 vidix mng flac oss v4l xinerama vcd a52 mad imagemagick dts
debug modplug gtk pulseaudio mmap truetype wavpack musepack xcb jack
-real"
+real vdpau"
RDEPEND="X? ( x11-libs/libXext
x11-libs/libX11 )
@@ -70,7 +71,8 @@
v4l? ( virtual/os-headers )
dev-util/pkgconfig
sys-devel/libtool
- nls? ( sys-devel/gettext )"
+ nls? ( sys-devel/gettext )
+ vdpau? ( x11-libs/libvdpau )"
BRANCH="xine-lib-1.2"
EHG_REPO_URI="http://hg.debian.org/hg/xine-lib/${BRANCH}"
@@ -112,6 +114,7 @@
ECONF_SOURCE="${S}" econf \
$(use_enable gnome gnomevfs) \
$(use_enable nls) \
+ $(use_enable vdpau) \
$(use_enable ipv6) \
$(use_enable samba) \
$(use_enable altivec) \
Ich habe es nach /usr/local/portage/media-libs/xine-lib gelegt und entsprechend in PORTDIR_OVERLAY eingetragen.
Es muss natürlich noch Automake 1.9 installiert sein!
Das komplette Ebuild befindet sich im Anhang. Digesten nicht vergessen!
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] media-libs/xine-lib-1.2.9999 USE="X a52 aac aalib alsa nls opengl sdl truetype vdpau xvmc (-altivec) -debug -directfb -dts -dvd -dxr3 -esd -fbcon -flac -gnome -gtk -imagemagick -ipv6 -jack -libcaca -mad -mmap -mng -modplug -musepack -oss -pulseaudio (-real) -samba -speex -theora -v4l -vcd (-vidix) -vorbis -wavpack (-win32codecs) -xcb -xinerama -xv" 0 kB [?=>1]
Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage
[?] indicates that the source repository could not be determinedPS: Die Endung .txt entfernen - das Forum lässt .ebuild nicht zu..
Scheisse wie Outlook 
PN gelesen und Termin im Hinterkopf.
Grüße,
devzero
Nur der vollständigkeithalber: Stecker einlöten reicht, damit geht der 2. IDE port. Ist aber ziemliche fummelei, da dort Lötzinn in den Löchern ist und die Massefläche die Wärme so schlucken.