Posts by Telperiar

    Also die Variante die am wenigsten Stress und Arbeit macht dürfte über das AudioPodCatcher Plugin sein. Der sucht seine Quellen über eine OPML Datei, hier mal mein Beispiel für den CC2



    Auch wenn das Addon unter Audio zu finden ist, klappt es auch mit dem Video-Podcast. Beschreibungen hat er leider keine, aber die sind beim CC2 sowieso immer etwas halbherzig ;-)

    Ich denke besonders der Kernel-Update von 3.0 auf 3.2.12 wird für PVR einige Vorteile bringen. Da ist ja in Richtung DVB so einiges passiert, das den Einsatz von media-build Treibern reduzieren sollte.

    Was mich noch interessieren würde: Wie lange hält eine Autobatterie durch, wenn sie eine ARM-Box + USB-DVB-S2-Device + Notebookfestplatte versorgen muss. Kann man eventuell auch schon mit einem kleineren Akku eine mehrstündige Stromversorgung sicherstellen? Dockstar und DVB-S2-Device sollten doch deutlich unter 10 Watt ziehen.


    Gruß
    hepi


    Mit einer Autobatterie eine ganze Zeit, die haben gerne mal um die 500Wh. Ein Raspberry braucht ~ 3.5W, eine 2,5er Platte so um 4W, im Leerlauf eher 1W, dazu was für dein DVB-Device brauchst und ein bisserl Konvertierungsverlust - deutlich unter 20W.

    ... dass The Pirate Bay erwägt, ihre Server in Drohnen vor der Polizei wegfliegen zu lassen ...


    Das gibt dem Wort Serverabsturz eine ganz neuen Bedeutung :rolleyes:


    Wieso eigentlich Windkraft und Atom-Prozessor? Wie stehen die Chancen VDR für einen Raspberry Pi auf ARM zu portieren? Die Plattform ist winzig, und locker mit einer Solarzelle und einem kleinen Puffer-Akku zu betreiben.

    Haben wir überhaupt die Möglichkeit am EPG zu erkennen ob eine Sendung auf einem HD-Sender wirklich HD ist? Ich würde dem Timer gerne selber sagen welche Qualitätsstufe ich bevorzuge.


    So nehme ich trotz HD, viele Sendungen bevorzugt über SD auf, denn ich habe mir eine halbautomatische Verarbeitung gebastelt. Mit einer modifizierten Version von Project-X, welche MarkAd und Titeldaten als Batch direkt aus dem VDR-Verzeichnis liest. Dort muss ich lediglich die Schnittmarken kontrollieren, und der Rest läuft Automatisch. Leider gibts immer noch nichts vergleichbares natives für HD unter Linux, und so mache ich mir den Aufwand dort nur wo es für mich lohnt.

    Bisher haben wir immer vom Sendernamen her gedacht: "ZDF" und "ZDF HD" gehören zusammen, weil sie offensichtlich den gleichen Namen haben. Wir haben aber kein Tool, um zu sehen, ob das EPG tatsächlich auch bis ins Detail übereinstimmt. Was hilft uns ein Kanalnamenmatching, wenn das EPG nur zu 80% übereinstimmt? Nehmen wir zum Beispiel mal an, "Wetten Dass..." würde nur auf ZDF überziehen dürfen, bei ZDF HD würde aber hart abgeschnitten werden zum planmäßigen Ende der Sendung.


    Ich denke das würde die Sender ins totale Chaos stürzen, weil dann die Nachfolgesendungen nicht mehr synchron laufen würden. Spätestens mit der nächsten Live-Sendung müsste so eine Differenz wieder korrigiert werden, was im Normalfall die Nachrichten sein dürften. Auch vom Aufwand her bräuchte man dauernd zwei Sendezentren, und mir ist auch noch keine Fernsehzeitung begegnet die HD und SD trennt.


    Ich nutze aktuell auch einen Mischbetrieb aus DVB-T und DVB-C. Schon weil mir die Grundverschlüsselung gestohlen bleiben kann. Antenne ist natürlich Störanfälliger, wobei Ich bevorzugt über ÖR und Kabel aufzeichne. Da wäre es schon hilfreich die Antennen-Transponder als Fallback nutzen zu können, ohne drei Identische Sender in der Liste zu haben.


    Würde das denn etwas verbessern? Allenfalls marginal, weil der Sender vielleicht etwas
    besser hochskalieren kann, als die Geräte beim Zuschauer, oder?


    Kommt darauf an wie das Material an der Quelle vorliegt. Wenn man etwa vergleicht wie hochskaliertes SD auf eine HD Sender aussieht und die selbe Sendung auf dessen SD sieht, könnte es durchaus etwas bringen.


    Ein Beispiel das mir im Gedächtnis blieb war die Serie Eureka auf Pro7. Die ist recht neu und natürlich voll in 16:9 HD gedreht, entsprechend sollte sie dem Sender auch vorliegen. Übertragen wurde aber in 4:3 mit Trauerrahmen. Da kann man mir nicht erzählen die hätten für den einen Sendeweg eine HD-Videodatei und für den anderen eine staubige VHS-Kassette.

    Hallo,


    schafft man es Festplatten mit RAID 5 schlafen zu legen?
    Wenn nein, halten die normalen Konsumerplatten meiner Erfahrung nach max. 1 Jahr bei 24/7 Std Dauerbetrieb.


    Das würde ich bleiben lassen, RAID-Platten schlafen zu legen kann dazu führen das es die Integrität zerlegt.


    Auch Consumer-Platten halten prächtig, der größte Stress ist das anfahren wenn man sie schlafen legt. Du solltest aber dringend auf gute Kühlung achten, bei 30° halten die Dinger ewig.


    Benutzt XBMC nicht FFmpeg? Vielleich mal dort ein wenig rumschrauben.


    Albert


    Wenn die Restauflösung des Bildes noch knapp 700x250 Pixel, abzüglich Senderlogo, ist und dann noch Interlaced daherkommt hilft dir auch der beste Decoder nichts. Damit kannst du etwas die Ecken abschleifen, schwammig bleibt das Bild trotzdem.


    Besonders witzig ist, wenn uralte 4:3 Fernsehserien auf dem selben Sender besser aussehen, als Cinemascope Trauerrand-Spielfilme mit gefühlt 80% Werbeanteil, und Werbung geht sowieso immer perfekt codiert über die Leitung, da kann der Transponder noch so schmal sein.

    LVM und RAID ist schon eine prima Sache, wenn man es richtig einrichtet. Mein Heimserver nutzt RAID5 auf einem Hardware-Controller, darauf baut ein LVM auf in denen Zentral alle Dateien verwaltet werden. Alles Relevante wird zusätzlich täglich auf eine Sicherungsplatte gesichert. Da passiert also gar nichts wenn eine Platte ausfällt.


    Aber Keine_Ahnung hat natürlich recht, LVM und der Umgang mit Volumes will einstudiert sein. Mal eben eine Partiton per dd "umzuziehen" führt garantiert zum Totalverlust.


    Wie, bzw. mit was zoomst Du denn? Ich meine nur, bei mir ist die Qualität akzeptabel.


    Albert


    Primär mit XBMC, weil ich das als Frontend nutze, wobei das relativ egal ist. Wenn die native Auflösung PAL ist und Cinemascope in Letterbox läuft, dann bleibt recht wenig übrig. Das ganze Übertragen in der üblichen Spar-Datenraten sieht einfach nur grausam aus. Da hat man gar keine Lust mehr auch nur ans Aufnehmen zu denken, da sehen oft Webstreams besser aus.


    Ich denke ja auch das die Filme im Videoarchiv oft noch in Letterbox "rumliegen", aber die anderen Sender schaffen es auch wahlweise die Kassette/Datei zu wechseln oder es zurecht zuschneiden bevor das ganze auf Sendung geht.

    Immer wenn ich beim zappen über Privatsender stolpere, gerade solche der Pro7-Gruppe, fallen mir immer wieder Breitwand-Filme auf die erst in Letterbox für 4:3 umgerechnet um dann auf 16:9 Geräten mit Trauerrand an allen vier Seiten dargestellt zu werden. Zoomt man Ränder weg ist das Bild mangels Auflösung und Datenrate eine reine Klötzchensammlung. Bei Analog-TV könnte ich das ja noch einigermaßen nachvollziehen, besteht ja das Restrisiko einen der 80er Jahre Fernseher zu erwischen der keine Taste für das Seitenverhältnis kennt, aber bei DVB? Selbst wenn das Material am Sender nur in Letterbox vorliegt, wie groß ist der Aufwand die Trauerränder abzuschneiden und das Seitenverhältnis zu korrigieren. Bei den Senderlogos bekommen Sie es ja auch gebacken.


    Die Frage die ich mir dann immer stelle, machen die das mit Absicht oder aus Unfähigkeit? Will man mit künstlich schlechtem SD die Leute zu kostenpflichtigem HD treiben, oder bekommen die Sender das da auch nicht gebacken? Wie sind eure Erfahrungen zu dem Thema?

    Hallo,


    das nachfolgenden Problem hat mich die letzten zwei Wochen generft, und war wahrhaftig schwer einzugrenzen. Ich nutze ein Point-of-View ION Board der 1. Generation, und das ist für HTPC-Systeme ja immer noch geläufig. Möglicherweise trifft das Problem auch auf andere ION-Boards der 1. Generation zu.


    Symptome: Man nutzt USB-Tuner und es kommt in unregelmäßigen Abständen zu anhaltenden Empfangsstörungen, die sich mehrere Minuten ziehen. Umschalten hilft genau so wenig, wie der Neustart von VDR. Es gibt keine Auffälligkeiten im Log, und auch sonst keine Hinweise die auf etwas anderes als "schlechten Empfang" hindeuten. Nutzt man mehrere USB-Empfänger, tritt das Problem an allen gleichzeitig auf, selbst wenn einer Terrestrisch und einer Kabel hat.


    Nachdem ich in zahllosen Experimenten, den Empfang, die Kabel, die TV-Karten, VDR, Kernel und Betriebssystem als Ursache ausgeschlossen hatte, war ich kurz davor ein neues Board anzuschaffen. Irgendetwas brachte das Timing der USB-Datenübertragung durcheinander, war aber nicht zu fassen. Am Durchsatz lag es nicht, der war einwandfrei. Den ersten Erfolg brachte der Kernel-Parameter ACPI=off, macht das doch gerne mal Probleme. Einige Tests später war klar ACPI=noirq reicht aus.


    Wem das Problem bekannt vorkommt, versuchts mal mit:


    Code
    1. # sudo nano /etc/default/grub


    Erweitern der Startparameter um diesen Eintrag:

    Code
    1. GRUB_CMDLINE_LINUX_DEFAULT="... acpi=noirq ..."


    Gefolgt vom Befehl ...

    Code
    1. # update-grub2


    ... und einem Reboot.

    Kann man Openelec eigentlich auch auf mehreren Kernen bauen? Das baut ja schließlich ein komplettes System, klar das sowas dauert. Das anhängen eines handelsüblichen "-j4" ans make wird jedenfalls nicht weitergegeben.

    Das klingt für mich als sollte man beim "Eigenbau" voll auf die Repos von Pippelka setzen, weil man dann sicher geht das die Teile zusammenpassen. Mein letzter Opdenkamp-Build hatte ein wunderliche "Stottern" im Bild, das jede Sekunde einen kurzen Hüpfer verursachte.

    Zentyal ist ganz nett als Server-Distri, was mir daran abgeht ist eine Unterstützung für NFS-Mounts, und die GUI ist reichlich träge, besonders beim Anmelden.


    Wenn du ernsthaft KVM machen willst, versuchs mal mit Proxmox, die 2.0er ist jetzt RC1, und hat das letzte mal als ich sie sah einen guten Eindruck gemacht.

    Wie steht es denn aktuell mit Pipelka va. Opdenkamp? Ich nutze ja schon lange Opdekamps Fork in Kombination mit Pipelkas XVDR Addons, und das läuft auch ganz gut.


    Irgendwie scheint mir das wenig Zielführend wenn die beiden Forks sich auseinander entwickeln, wenn am Ende ein UNIFIED PVR Frontend mit Addons-Clients rauskommen soll.