Beiträge von Razorblade

    Achte bei den Boards darauf, dass sie VT-d unterstützen! Bei der QuadCore Variante ist das mit einem einfachen und preiswerten Q35 Chipsatz erledigt, bei den Xeon's wirds richtig teuer: Die 3x00er Chipsätze können das nämlich nicht, nur die 5x00er und auch da ist es abhängig vom BIOS, also vorsicht!



    Gruß,
    Razor


    Edit: warum eigtl "außer Xen"? ;)

    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?

    Zitat

    Original von Hibbelharry
    wenn kvm läuft würde ich das jedem xen vorziehen. Xen auf neuer Hardware ist ein graus.


    Es gibt einen Ubuntu Dom0 Kernel in Version 2.6.22.9 funktioniert bei mir wunderbar (auf einer Gentoo Kiste). Damit sollte (fast) alle neue Hardware abgedeckt sein.


    Davon abgesehen tut sich gerade mächtig etwas was die Dom0 Integration in den Vanilla Kernel angeht, siehe:
    http://thread.gmane.org/gmane.linux.kernel/730867

    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

    Zitat

    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