Posts by Razorblade

    Hallo,


    wäre es auch möglich die Struktur (ein System mit DVB-Karten Multicastet ins Netz ein anderes mit dvbloop hat den vdr zu laufen) mit generischer Hardware anstatt dem Netceiver zu betreiben? Oder andesrherum: ist die Software des Netceivers selbst (Kommunikation mit den DVB-Karten, Multicast-Streaming) erhältlich/open-source?


    Hintergrund: ich habe derzeit auf dem Dachboden schon einen "diskless" (nfsroot) VDR, den Storage-Server (selbstgebautes NAS mit 1,5TB) würde ich aus thermischen Gründen lieber im 19" Rack im Keller belassen, die "Sat-Strippen" sind aber nicht durchs ganze Haus gezogen sondern eben nur auf dem Dachboden.
    Da ich den Storage-Server sowieso mittels Xen und mehrerer virtueller Maschinen zum "multi-purpose" Server umbauen möchte kam mir da auch der VDR in den Sinn. Arbeitsersparnis (im Sinne von weniger Wartung) bringt es aber nur, wenn das System auf dem Dachboden wirklich einfach gestrickt ist und nicht noch Disti-Updates etc dazukommen (deswegen scheidet 2xmal vdr gekoppelt mit Streamdev aus). Die Struktur des Streamens bei Bedarf gefällt mir aber sehr gut, zumal sich sicher bei einem "echten PC" auch Methoden wie Wake-on-LAN für den "Tuner PC" implementieren ließen, woran ich mich zur Zeit (hauptsächlich wegen der langen Bootzeit einer vollständigen Distribution) nicht gewagt hatte...
    Ich dachte da an ein einfaches Netboot (nur Kernel und initrd, kein NFS o.ä.) in dem das initrd die DVB-Treiber und den Streaming-Deamon enthält...



    Gruß,
    Razor

    Technotrend S2-3200


    01:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
    Subsystem: Technotrend Systemtechnik GmbH S2-3200
    Flags: bus master, medium devsel, latency 32, IRQ 19
    Memory at e5010000 (32-bit, non-prefetchable) [size=512]
    Kernel driver in use: budget_ci dvb
    Kernel modules: budget-ci


    Class: 0x048000
    Vendor: 0x1131
    Device: 0x7146
    SubVendor: 0x13c2
    SubDevice: 0x1019




    (Das Script hat aber meine auch im System befindliche Skystar nicht erkannt, gibt es da ein Problem mit mehreren aber unterschiedlichen DVB-Karten?)


    Edit: liegt nicht daran, daß es mehrere Karten sind, sondern an der Erkennung:
    Eine Skystar2 hat als class "0x028000" und gibt sich somit als Netzwerkkarte zu erkennen... also wäre es evtl sinnvoll den Suchstring auf "DVB_DEV=$(egrep "0x04[80]0|0x02800" $i/class)"
    abzuändern?

    Nein, keine Fehlermeldung, die Zuordnung der Tonspuren über Dateigrenzen hinweg scheint zu funktionieren, das könnte man doch aber auch per Wrapperscript erledigen oder?
    Ich wollte mir das sowieso etwas basteln, was die bereits vorhandenen Informationen aus der info.vdr (Name der Sendung, Art und Sprache der Tonspuren) mit in die mkv Generierung einfließen läßt.


    Ob ich "defektes" Quellmaterial habe weiß ich nicht, dank der "hervorrangenden" Qualität des TT-3200 Treibers könnte dies durchaus sein ;-) (gerade bei den älteren Aufnahmen mit denen ich teilweise getestet habe).
    Leider fehlt mir eine Gegenprove, da ich die h264-pes vdr-files sonst mit keinem Programm abspielen kann um zu sehen ob der Ton dort auch synchron ist...

    Ich habe eine Skystar und eine TT-3200 an einem aktiven Multischalter an 13° 19,2° 23,5° und 28,2° und bisher keine DiseqC Probleme festgestellt, die TT-3200 verhält sich genauso wie die Skystar und schaltet sauber zwischen den Kanälen.


    Ich benutze den VDR allerdings nicht für liveTV sondern als reinen "Aufnahmeserver", deswegen kann ich nichts zu Umschaltzeiten und locking sagen, mit Aufnahmen gibt es jedenfalls keine Probleme.


    Auch auf 28,2 habe ich bisher noch keine Probleme mit BBC HD festgestellt, zur EM hatte ich (mangels HD Feeds in Deutsch) ausnahmsweise (per Streamdev) auch mal Live geguckt... alles prima.


    Eines sollte man sich aber bewußt sein: multiproto ist eine Baustelle und so wie es aussieht wird sie eher abgebaut, als fertiggestellt.
    Was die aktuelle Situation der DVB devs angeht, so würde ich bei der HVR4000 und/oder NOVA-HD-S2 mittel- bis langfristig mit besserem (mindestens in-kernel) Support rechnen.

    Tolle Sache mit dem mkvmerge, werde ich gleich mal ausprobieren, besonders ob auch die PCH-A110 das dann sauber abspielt :-)


    Anbei schonmal ein gentoo ebuild um den Patch zu integrieren.
    Einfach ins lokale Overlay legen (HOWTO hier: http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds )
    und noch ein Unterverzeichnis "files" anlegen, dort dann den Patch von CBArts als "mkvtoolnix220_PESFIX_0.6.patch" ablegen.
    Dann noch das übliche digest'en des ebuild und schon ist es beim nächsten emerge integriert...

    Ich habe in der Mailingsliste auch schon meinen Kommentar dazu abgegeben, aber meiner Meinung nach ist es der richtige Schritt:
    Auch wenn Multiproto derzeit relativ gut mit vdr 1.7.0 funktioniert brauch man sich nur mal die DVB-S2 bezüglichen Posts auf der DVB-Mailingliste anzuschauen um zu wissen, dass es immer Probleme geben wird, solange manu sein eigenes Süppchen kocht.
    Das ist jetzt nicht gegen Manu gerichtet, seine Arbeit war sozusagen wegweisend für die DVB-S2 Unterstützung, aber leider kommt es nicht nur auf den Inhalt (Code) an, sondern auch das drumherum... und wenn er es nach über einem Jahr nicht geschafft hat seinen Ansatz in den Main-Tree zu bekommen (und auch offensichtlich selbst kein Interesse daran hat), dann ist es Zeit für einen neuen Ansatz.
    Was ich diesbezüglich gut finde, ist die Idee Binärkompatbitlität zu erhalten und es gleich so modular aufzubauen, daß es nicht nur spezifisch für DVB-S2 ist, sondern auch T2 usw (ansonsten haben wir die gleiche Geschichte in ein paar Monaten/Jahren nochmal).


    Ich hoffe nur, kls beißt nicht in die Tischkante und ist offen gegenüber der neuen API, wir als Benutzer sollten ihn jedenfalls bei seiner Entscheidung (wie immer diese aussieht) so gut es unterstützten!

    Das "ICMP unreachable" sieht mir verdächtig nach Firewall-Regeln auf dem Client-System aus. Da könnte sich ja in letzter Zeit dank der DNS Patches (Stichwort RR Cache Poisoning) auch wirklich etwas am Verhalten der Clients geändert haben, so daß evtl (alte) Firewall-Regeln nicht mehr passen...



    Gruß,
    Razor

    Die Händler werden sie sicher aus Belgien, Frankreich, Schweiz oder Italien haben.
    Einige spekulieren sicher auch darauf, daß die Unlock-Software schnell rauskommt und sie dann billige (zB Schweiz Prepaid) Geräte die eigentlich einen Simlock haben als Unlocked verkaufen können.
    So oder so haben mindestens die gewerblichen Händler ein Problem, da die das iPhone in Deutschland gar nicht vertreiben dürfen (schließlich hat T-Mobil die exklusiven Vertriebsrechte)...


    Um wieder (zumindestens teilweise) on-topic zu kommen:
    Ich habe letzte Woche bei Orange Schweiz (die verkaufen neben Swisscom auch das iPhone in CH) und da hieß es, man kann das iPhone ohne Vertrag auch als deutscher ohne weitere Identifizierung kaufen. Allerdings sind die Geräte von Orange auch ohne SIM/Netlock und teuerer als die Prepaid-Geräte von Swisscom.

    Es ist aber sehr wohl ein Unterschied zwischen "nicht erlaubt gemäß AGB" und "illegal".
    Es stellt jedenfalls keinen Straftatbestand dar, wenn man mit einem gültigen Abo und einem lizenzierten CAM (Alphacrypt zB) Premiere mit VDR benutzt.
    Das verstößt zwar gegen die Premiere-Nutzungsbedingungen, aber das schlimmste was passieren kann ist wohl, daß Premiere Dir kündigt.



    Aber wie schon erwähnt, zur Zeit ändert sich einiges, ich würde (mit einem CAM-Kauf) noch abwarten bis die nächste Generation von Nagra online geht...



    Gruß,
    Razor

    Ja ich meinte natürlich DomU, habe es im Beitrag geändert.


    Ich hätte da zwei Theorien:
    1. Die bisher verwendeten DomU Kernel waren entweder zu alt oder es gab 64bit Probleme.
    2. Der shm Treiber mag kein PCI-Passthrough, bzw die benutzen Speicherbereiche werden vom Hypervisor nicht sauber gemapped.


    Habe es gestern übrigens nochmal probiert einen aktuellen pvOps Kernel (also Vanilla mit Xen-Guest Support) zum Laufen zu bringen, klappt: 2.6.25.9.
    Allerdings gibt es woh immernoch kein PCI-Frontend, d.h. Passthrough wird nicht gehen.
    Nimm Dir doch mal die neuesten Ubuntu-Xen-Kernel-Sources und kompilier den als DomU/32bit.



    Gruß,
    Razor

    Quote

    Siehe ersten Beitrag. Das geht IMHO so nicht: Ich habe keine HVM DomU aufgesetzt, d.h. es läuft kein vollständiger getrennter 32-Bit Kernel in der DomU, sondern es wird der 64-Bit Kernel der Dom0 genutzt,was zwingend 64-Bit Module erfordert, die in der Dom0 compiliert werden. Zu diesem Schluß bin ich jedenfalls gekommen. Eine HVM DomU kam für mich aufgrund des Overheads und da dort, soweit ich weiß, das Durchreichen der PCI Devices noch problematischer ist, nicht in Betracht.


    Da ist schlichtweg falsch. Auch bei PV läuft ein eigenständiger Kernel! Egal ob 32bit/64bit. Natürlich *kann* man auch den gleichen Kernel wie für die Dom0 benutzen (vorausgesetzt dieser hat auch die Frontend-Komponenten), man muß aber nicht. Meiner Meinung nach ist dies auch nicht zu empfehlen, da der Dom0 Kernel (eben wegen der Xen-Kompatibilität) stark gepatcht ist und nicht in aktuellen Versionen zur Verfügung steht.
    Meine Empfehlung wäre in der DomU (geändert) mal einen aktuellen 32bit Kernel laufen zu lassen (egal ob Vanilla oder von einer Disitri) und dagegen die HDe-Module zu kompilieren (innerhalb der laufenden DomU)...


    Gruß,
    Razor

    Ok entschuldige, ich dachte Du wolltest mit Xen wirklich nur die 32/64bit Problematik angehen, ok dann gehe ich mal etwas ins Detail:


    Wenn Du die HDe per PCI-Passthrough an die DomU weitergibst, mußt Du natürlich auch das Kernelmodul gegen den DomU (also dann 32bit) Kernel kompilieren.


    Setzt Du selbstkompilierte Kernel ein oder von der Distribution? Welche Disti überhaupt?


    Ich habe gute Erfahrung mit den Dom0 Kerneln von Gentoo (derzeit ein 2.6.21) oder Ubuntu (sogar 2.6.24.3) und "Vanilla"-Kernel (ab 2.6.24) als DomU (allerdings noch nicht mit PCI Passthrough getestet).


    Hast Du denn in der Dom0 das PCI Device auch sauber versteckt?
    "pciback 0000:01:00.0: seizing device" im dmesg zu sehen?



    Und ansonsten zum Thema 8GB RAM:
    Linux unterstützt bis zu 64GB RAM im 32bit mode (mit HIGHMEM64G und PAE) dann werden für Speicher und IO allerdings wieder 64bit Adressen benutzt, was die gleichen 64bit Probleme nach sich ziehen könnte, wie der "echte" 64bit Modus.
    Außerdem kann man auch ein 64bit Xen (also den Hypervisor) mit einer 32bit Dom0 laufen lassen. Die 8GB braucht man ja mit Xen üblicherweise nicht in der Dom0, sondern verteilt sie auf die DomU's.
    D.h. selbst ohne HIGHMEM64G könntest Du ein 64bit Xen, 32bit Dom0 und 32 oder 64bit DomU's laufen lassen -> Keine 64bit Treiberprobleme und trotzdem den ganzen Speicher auf die Dom's verteilen können.




    Gruß,
    Razor

    Ich glaube nicht, daß Xen für Deine Anforderungen wirklich das Richtige ist.
    PCI-Passthrough ist noch recht experimentell und Hauptsächlich mit Netzwerkkarten und RAID-Controllern getestet... weniger mit Grafikkarten oder gar TV-Tunern oder "special purpose" Karten!


    "Nur" um 32/64bit Probleme zu lösenist Xen per-se der falsche Ansatz. Wie wäre es denn mit einem 64bit Kernel und 32bit Userland? Das funktioniert auch ohne jegliche Virtualisierung wunderbar.
    Oder noch einfacher: wenn es Probleme mit 64bit gibt, warum nicht gleich bei 32bit bleiben?


    Gruß,
    Razor