Beiträge von TesaFilm

    Gut, dass ich von Netzwerk keine Ahnung habe.


    Was heißt das jetzt für mich? Alles bleibt beim Alten, oder muss ich irgendwo etwas ändern?


    Von meiner Seite aus nicht, alles gut.


    Natürlich bleibt alles beim alten. Wenn jemand auf's Netzwerk warten will, dann geht das über ein Dropin und ist damit ein individuelles Konfigurationsthema.


    Im hier vorliegenden Fall halte ich es aber für sinniger direkt auf 0.0.0.0 zu binden und ggf. mit Iptables den Zugang von IPv6 zu sperren.


    Wobei nach wie vor nicht geklärt ist, warum der Port auf IPv6 nicht offen sein darf. Wenn der schlimmstmögliche Fall vorliegt (IPv6-Adressen ungefiltert von außen erreichbar), dann sollte dieses Problem bereits auf Router-Seite erschlagen werden!


    Komm mal wieder runter. Ich hab den Fehler selber eingesehen und behoben und auch nicht verlangt das Netzwerk-Verhalten, bzw. die Startreihenfolge zu ändern.


    Thema für mich erledigt.

    Warum gibst du auf dem Server überhaupt eine IP an streamdev? Wenn man hier wirklich eine IP angeben muss, dann nimm "0.0.0.0". Auf die kann er dann sofort ein "Listen" machen und da "0.0.0.0" nichts anderes bedeutet wie "alle IPs" ist der Port dann auf später dazukommenden Netzwerkverbindungen sofort offen.


    Hatte ich oben schon geschrieben, wegen meinem IPv6-Netz. Ich wollte nicht, das er sich daran bindet und daher die IP eingetragen. Da ich die setup.conf zum grossen Teil übernommen hatte, bin ich da erst heute drauf gekommen, hab ja auch nicht je änderung aus den letzten Jahren im Kopf :)

    Moin,


    Ich teste es gerade auf dem Server, ob es nicht einfach nur mein Problem war. Ich hatte unter YaVDR dem streamdev-server die IP mitgegeben auf die er hören sollte, wegen IPv6. Da ich jetzt IPv6 ausgeknipst hab, kann ich netürlich auch wieder die 0.0.0.0 eintragen, was funktionieren sollte.
    Die frage ob er dann auch auf der richtigen IP horcht und Verbindungen annimt kann ich aber erst heute abend prüfen.


    Da ich aber auch kein DHCP verwende, sondern primär feste IPs, ist meine Netz innerhalb 2 sekunden oben als per dhcp von der Fritz.


    'schulligung für die Verwirrung ;)


    Edit:
    Sieht bisher gut aus, streamdev (VTP) mosert zumindest nicht rum wenn das Netz noch nicht oben is, so wie es sein sollte:

    Code
    Nov 26 10:36:44 nas-mopped vdr[304]: [353] streamdev server thread started (pid=304, tid=353, prio=high)
    Nov 26 10:36:44 nas-mopped vdr[304]: [353] Streamdev: Listening (VTP) on port 2004
    Nov 26 10:36:44 nas-mopped vdr[304]: [304] EPGSearch: loading /var/lib/vdr/plugins/epgsearch/epgsearch.conf
    Nov 26 10:36:44 nas-mopped vdr[304]: [304] EPGSearch: loading /var/lib/vdr/plugins/epgsearch/epgsearchdone.data
    Nov 26 10:36:44 nas-mopped vdr[304]: [353] Streamdev: Couldn't listen (HTTP) 192.168.178.12:3000: Die angeforderte Adresse kann nicht zugewiesen werden
    Nov 26 10:36:44 nas-mopped vdr[304]: [304] loading /var/lib/vdr/plugins/epgsearch/epgsearchswitchtimers.conf

    Moin,


    ich hatte letzte Woche ähnlich Probleme mit der 6.5 und den media-build-experimentral. Karte zeigte an zwei SAT-Anlagen das problem schlechter Empfang, abfallendes SNR, speziel nach'm resume.
    Ich hab dann kurz entschlossen die Treiber aus den aktuellen sourcen selber gebaut und das Problem war Geschichte.

    Ich nochmal..


    Zitat


    Probleme sehe ich eher beim Client. Ich weiß nicht, wie Streamdev auf ein nicht vorhandenes Netzwerk reagiert. Das ist in Standardeinstellung nämlich beim VDR-Start noch nicht initialisiert. Im Wiki habe ich aber einen Lösung dafür geschrieben, die angeblich funktionieren soll. (von mir nicht gestestet)


    Spricht etwas dagegen das nicht direkt mit ein zu bauen? Streamdev-server spielt nach nem reboot nämlich wirklich toter Mann. OK, momentan boote ich den Server öfter aber eigentlich rennt der 24/7.


    ein anderes 'problem' bin ich leider nicht los geworden, ich vermute da aber eher, das die Karte das problem ist:



    Das hatte ich unter YaVDR nachvollziehbar wenn viel last auf dem System war und vdr gleichzeitg streamte. Mal Digital Device anschreiben, ob die das eher eingrenzen können, Treiber schliess ich momentan aus :)
    Kann aber auch sein, das der N40L nach zwei Jahren Dauerbeteib die weisse Flagge hisst ;)


    Ansonsten läuft der Server 1a :)

    So liebe Leute, heute war es soweit, Server platt machen und VDR4Arch drauf. Freitag und gestern hab ich, weil ich 'unbedingt' noch ne neue Platte brauchte Daten umgezogen. Weil ich gute Erfahrung damit gemacht habe kam BTRFS zum einsatz, mit 2 Devices als single (ich weiss selber das das kein RAID ist und evtl. Datenverlust droht) um mhddfs abzulösen. Das aber nur vorweg.


    Heute morgen dann noch Daten für den direkt zugriff kopiert, von USB gebootet, grundinstallaton gemacht, neu gestartet und der Server bringt kein Grub-Menü, startet aber fröhlich neu..
    Also wieder von USB, mit parted und im chroot alles nochmal kontrolliert.. alles i.O.. nach mehreren versuchen dann die Lösung: MBR-Partitionstabelle.. Irgendwie kommt das BIOS wohl mit GPT nicht klar, was ich aus alter Gewohnheit genommen hab..
    Danach das VDR-Geraffel installiert, ein teil meiner alten Konfig übernommen und reboot..


    VDR beschwert sich im log das es keine Channels findet, was OK ist, rechner hängt nich an den Kabeln. Fix feste IP vergeben (schön das die seiten auf netcfg basieren, was aber nicht funktioniert), ssh installiert, kontrolliert, rüber geschleppt, verkabelt (Protipp: Ein Server Served besser, wenn man das Netwerkkabel auch anschliesst ;) ), angerissen und dann der grosse moment: Client angeworfen und sofort Bild! :tup


    Ich meine das das Zappen schneller ist, meine regelmässigen kurzen Tonaussetzer sind weg, ich bin zufrieden :)
    Fehlen nur noch die restlichen Klamotten (NFS, MySQL... und Anpassungen


    Für mich hat sich der Umstieg gelohnt, der im grossen und ganzen Stressfrei war..

    Code
    Nov 24 17:55:48 nas-mopped vdr[1079]: [1103] Streamdev: Accepted new client (VTP) 192.168.178.2:56203
    Nov 24 17:55:48 nas-mopped vdr[1079]: [1103] Streamdev: Setting data connection to 192.168.178.2:42319
    Nov 24 17:55:48 nas-mopped vdr[1079]: [1375] streamdev-writer thread started (pid=1079, tid=1375, prio=high)
    Nov 24 17:55:48 nas-mopped vdr[1079]: [1376] streamdev-livestreaming thread started (pid=1079, tid=1376, prio=high)
    Nov 24 17:55:48 nas-mopped vdr[1079]: [1377] receiver on device 1 thread started (pid=1079, tid=1377, prio=high)
    Nov 24 17:55:48 nas-mopped vdr[1079]: [1378] TS buffer on device 1 thread started (pid=1079, tid=1378, prio=high)
    Nov 24 17:55:49 nas-mopped vdr[1079]: [1079] connect from 192.168.178.2, port 42048 - accepted
    Nov 24 17:55:58 nas-mopped vdr[1079]: [1079] closing SVDRP connection

    Ja, der Server ist 64Bit, das ist weniger das problem. Ich sehe da auch keine grossen probleme, mal davon abgesehen die verstreuten Daten zu sichern und 'wie hab ich das $DAMALS noch gemacht??' 's beste wird wohl sein das installierte System einmal mit FSArchiver zu sichern und als cheat-sheet das gerümpel mit rsync auf eine der Platten zu sichern :)
    Dann weiss ich ja, was ich Freitag/Sonnabend zu tun habe.
    Der Client sollte sich ja davon unbeeindruckt zeigen..


    Wegen dem Client: wenn ich da was finde wie man es machen könnte oder wie es geht, geb ich laut :) Ebenso wie das mit'm Nyxboard klappt, AFAIK meldet die sich als Tastatur..


    Arch ist schon nen ziemlicher umstieg, selbst wenn man CentOS/Debian/FreeBSD recht gut kennt, aber genial :)

    Moin,


    momentan habe ich mein VDR-Setup wie in der Signatur laufen. Da sowas aber für mich den Charakter einer Modelleisenbahn hat (wenn fertig aufgebaut isses langweilig) spiele ich damit erstmal meinen Server auf Arch umzustellen. Der Server befeuert den Client-VDR über Streamdev, stellt Filme/Serien über NFS zu Verfügung, XBMC's Datenbank liegt in MYSQL und macht noch ein paar dinge über die man hier nichts schreiben darf.
    Anyway, wird ein Projekt für's Wochenende :)
    Auf was für Schwiriegkeiten könnte ich denn stossen? Der Server hat nur nen popeligen VGA-Ausgang, braucht also kein X, was man ja in der runvdr.conf dann auch nicht starten braucht..
    Was später geplant ist: mhddfs abzulösen durch btrfs, wieder ein Wochenende weg ;)



    Zum Client:
    Wie ist es dort gelösst mit dem 'umschalten' von yaVDR zu xbmc? Ich werde mit PVR über xbmc irgendwie nicht warm.



    Arch ist für mich nicht völlig fremd, ich hatte auf Arbeit damit mal nen Samba-Server laufen, das ist aber SEHR lange her ;)


    Schönen dank für die Arbeit an VDR4Arch :)

    Moin,


    ich hae gestern den yaVDR-05 bei meiner Mutter auf aktellen stand gebracht, einmal im Jahr muss das sein. dist-upgrade lief einwandfrei durch, nach neu-kompilieren der TBS-6981-Treiber hatte ich auch wieder Bild.
    Das einzige Probelm wo ich keine Lösung für finde: Ich programmiere einen Timer, schicke VDR schlafen und warte das er 5 minuten vor Aufnahmezeitpunkt, wie vor dem Update, aufwacht. Das passiert aber nicht:





    BIOS-Zeit, wie vorher auf UTC, /etc/default/rcS ebenso


    um 12:55 passierte nix, erst als ich den PC von Hand startete:



    was habe ich übersehen? :)



    Hardware: FOXCON A88GMV, NVIDIA GF119, 4GB Ram, TBS-6981 DVB-S2-Karte, SoftHD, HDMI Out

    ja, lass ich, steht auf 5 und:

    Code
    Oct 28 10:01:21 nas-mopped vdr: [4235] changing transponder data of channel 749 from 11582:hC23M5O35S1:S19.2E:22000 to 11582:HC23M5O35P0S1:S19.2E:22000
    Oct 28 10:04:05 nas-mopped vdr: [1492] changing pids of channel 749 from 5241+5241=27:5242=deu@3,5243=deu@4;5246=@106:5225:5244 to 5221+5221=27:5222=deu@3,5223=mis@3;5226=deu@106:5225=deu:5224


    nur schlägt sich das nicht auf den Client durch, welcher aber auch so eingestellt ist. Ich bin mir aber auch nicht 100% sicher wie der Client beim Server den entspr. Stream anfordert :)

    Moin,


    ich habe seit ein paar tagen das problem das speziell mein Heimatsender über SAT probleme macht. Irgendwann stopt das Bild und kommt auch durch Umschalten nicht wieder. Phoenix HD, auf dem selben Transponder, läuft 1a und auch über Stunden problemlos.
    Ich habe dann mal spasseshalber XBMC über VNSI probiert, hier läuft NDR auch 1a.


    Neu starten von VDR auf Client & Server und rebooten bringt nix.
    Ich habe dann mit w_scan ne neue channels.conf erstellen lassen, daraus die Zeile für NDR rauskopiert und auf client/server neu eingefügt, ohne erfolg.


    Die Zeilen vom Server beim Umschalten auf NDR über VNSI:


    Server beim Umschalten auf NDR:


    der Client:


    Das ganze nochmal auf Phoenix HD, Server:


    Client:


    Die Zeile aus channels.conf:

    Code
    NDR FS NDS HD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3;5226=deu@106:5224;5225=deu:0:10327:1:1025:0


    Server und Client sind auf aktuellem Stand.


    Ich bin mit meinem Latein so ziemlich am Ende :)

    Versuch's mal damit:


    Code
    vi /etc/default/grub
    GRUB_CMDLINE_LINUX_DEFAULT="vmalloc=256m quiet splash vga=792 noresume acpi_enforce_resources=lax pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1"
    update-grub2


    Wenn's nicht hilft dann alternativ:


    Code
    GRUB_CMDLINE_LINUX_DEFAULT="vmalloc=256m quiet splash vga=792 noresume pci=nomsi,noaer"


    Albert


    Moin,
    Die erste alternative bezieht sich ja eher auf powersaving. Da der Server, wo die Karten drin sind, 24/7 rennt, scheint mir die 2. Option mehr Erfolg zu haben.
    Ich teste das mal. Bisher rennt der Server aber mit den älteren linux-media-dkms stabiler :)

    Moin,


    ich hab seit dem letzten dist-upgrade vor ein paar tagen das problem das mir das Bild von jetzt auf eben einfriert, andere Programme laufen aber noch einwandfrei. Öfter kommt es auch vor das ich beim Umschalten nur ein schwarzes Bild bekomme.. Z.B heute abend. Client aus dem Suspend geholt, schalte auf das Erste HD: schwarz, umschalten auf ZDF: Bild, zurück auf ARD: schwarz. Femon aufgerufen, auf das erste geschaltet: Bild. Beide kommen per SAT rein.
    Später dann DMAX geschaut (DVB-C), Bild bleibt hängen und kommt auch nicht wieder.


    Zur selben Zeit finde ich das im syslog:


    Code
    Dec 28 20:51:05 nas-mopped vdr: [5990] read incomplete section - len = 18, r = 167
    Dec 28 20:51:06 nas-mopped kernel: [ 3462.874364] do_IRQ: 0.131 No irq handler for vector (irq -1)
    Dec 28 20:51:08 nas-mopped kernel: [ 3464.208051] I2C timeout
    Dec 28 20:51:08 nas-mopped kernel: [ 3464.208117] IRS 00000f02
    Dec 28 20:52:45 nas-mopped vdr: [6920] streamdev-livestreaming thread ended (pid=5926, tid=6920)
    Dec 28 20:52:45 nas-mopped vdr: [6919] streamdev-writer thread ended (pid=5926, tid=6919)


    Die I2C-Fehler finde ich erst seit dem Update, in den syslogs vorher ist davon nichts zu finden:

    Code
    root@nas-mopped:~# zgrep I2C /var/log/syslog.* 
    /var/log/syslog.1:Dec 26 17:11:03 nas-mopped kernel: [453910.476106] I2C timeout
    /var/log/syslog.1:Dec 26 17:11:04 nas-mopped kernel: [453911.272105] I2C timeout
    /var/log/syslog.1:Dec 26 21:55:03 nas-mopped kernel: [470950.608164] I2C timeout
    /var/log/syslog.1:Dec 26 23:08:40 nas-mopped kernel: [475367.508153] I2C timeout
    /var/log/syslog.1:Dec 27 08:36:00 nas-mopped kernel: [  221.248104] I2C timeout
    /var/log/syslog.1:Dec 27 20:20:14 nas-mopped kernel: [42475.068167] I2C timeout
    /var/log/syslog.1:Dec 27 20:20:15 nas-mopped kernel: [42476.044086] I2C timeout
    /var/log/syslog.5.gz:Dec 22 18:08:03 nas-mopped kernel: [111730.288040] I2C timeout


    Hier noch ne grösserer Ausschnit, inkl. sterbenden vdr:



    Ich gehe erst mal auf den Stand vom Oktober zurück


    Achja: 1x DD Cine C/T und daran angeschlossen ne DuoFlex S2 (signatur überarbeite ich noch)


    Ich hätte hier noch ne ältere TeVii S480 rumgammeln, war in nem N40L verbaut. Nach außen stellt die sich als 2 USB-Devices dar.. Die könnte ich für kleines Geld abtreten, bevor die hier verstaubt..
    Ich hab aber keine Ahnung wie sich die virtualisierten Umgebungen verhält.