Beiträge von löwe

  • Puls 4 Austria - Empfangsprobleme

    Hallo!


    Vor ein paar Tagen hab ich meinen Fernseher (VDR) wieder mal angeworfen und musste beim Durchzappen feststellen, dass Puls Austria (der ganz normale Kanal, also SD-Version) einfach nicht laufe will.


    Der Sender bleibt schwarz, in der /var/log/syslog steht etwas von Timeouts beim Tuning für den Kanal.


    Als Hardware verwende ich ein Technisat Skystar HD (nicht HD2) mit CI-Slot, Cryptoworks CI-Modul und ORF-Karte.



    Zuerst dachte ich, dass das CI-Modul die Probleme verursacht, gestern dann aber gelangt es mir Puls 4 zu sehen, und zwar immer wieder mit Bild-Artefakten und kurzzeitigen Aussetzern. Der Empfang bei diesem Sender liegt also scheinbar am Limit, sodass er eben nur schwer empfangbar ist.


    Weiß jemand was man in meinem Fall dagegen machen könnte?
    Der Empfang an sich war in meinem Fall noch nie ein Problem (alle anderen Kanäle funktionieren einwandfrei), ich vermute deshalb eher ein verflixtes Software-Problem das mir die Empfangsprobleme bei genau diesem einen Sender bereitet ...

  • [gelöst] HTTP Streaming Port nicht erreichbar

    Ich hab gerade meinen VDR upgedated und das selbe Problem:


    Der Server ist über das Netzwerk von vdr-sxfe aus nicht erreichbar.


    Im server.log siehts dann so aus:

    Code
    Jul 18 22:20:47 htpc kernel: [  340.802170] vdr[5067]: segfault at 0 ip 00007f5b1d355bad sp 00007fff1f64c5f0 error 4 in libvdr-text2skin.so.1.7.27[7f5b1d31f000+63000]


    Das text2skin Plugin ist in meinem Fall kaputt. Ich werde mal versuchen wieder auf die Vorgänger-Version downzugraden ...

  • Kein Ton beim Umschalten auf ZDF HD

    Hallo!


    Ich habe das Problem auch - leider schon unverändert seit 2010.


    Aufgrund von Empfehlungen für die Buffer-Einstellungen in der config_xineliboutput in der aktuellen c't habe ich mir die Thematik gestern nochmals genau angesehen.


    Leider ohne Erfolg: Ein Herumschrauben an den verschiedenen Buffer-Werten erhöht zwar allgemein die Umschaltzeit - speziell zu HD-Kanälen - die Tonaussetzer treten aber gelegentlich immer noch auf.


    Die Probleme existieren nur bei öffentlichen deutschen HD-Sendern wie zB ZDF HD, 3sat HD, arte HD, ZDFneo HD.


    Bemerkbar machen sie sich so, dass beim Umschalten auf einen betroffenen Kanal entweder gar kein Ton wiedergegeben wird, oder dieser stark zerhackt ist.


    Für mich sieht das Ganze so aus, als wären nur bestimmte Sender (die aus der ZDF-Reihe betroffen) - bei Sendern wie Das Erste HD zB waren die Tonprobleme bisher noch kein Thema.



    Meine Konfiguration sieht so aus:


    Hardware:
    * Mainboard POV ION 330-1 mit Nvidia/VDPAU-Lösung onboard
    * TechnoTrend TT-budget S2-3200


    Software:
    * Ubuntu 12.04
    * VDR aus dem yaVDR-Testing Repository
    * Wiedergabe über xineliboutput und vdr-sxfe am selben Rechner



    Gibt es zu den Tonaussetzern schon eine Lösung?

  • linux-media-dkms: Module werden bei Kernel-Update nicht automatisch kompiliert

    Hallo!


    Ich nutze als TV-Box ein Ubuntu 11.10 System (Oneiric), bei welchem ich die yavdr-Quellen als Basis für die TV-Teile eingebunden habe. Insbesondere setze ich auf das dortige Paket linux-media-dkms, da dort wichtige Bugfixes für den Treiber meiner TT-S2 3200 vorhanden sind, die im normalen Kernel so nicht existieren.


    Zwar weiß ich, dass von Seiten yavdrs die Oneiric-Quellen nicht unbedingt die am besten gewarteten Pakete sind (die Entwicklung geschieht ja woanders), trotzdem aber möchte ich von einem seltsamen Problem berichten.


    Immer dann, wenn ich über apt-get upgrade eine neue Kernel-Version aus den Ubuntu-Quellen erhalte, wäre es so weit, dass die DVB-s Treiber aus dem Paket linux-media-dkms neu zu kompilieren wären. Dafür wird dkms verwendet, welches sich bei einer Kernel-Installation auch brav meldet.


    Allerdings geschieht Folgendes:

    Code
    linux-headers-3.0.0-19-generic (3.0.0-19.33) wird eingerichtet ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.0.0-19-generic /boot/vmlinuz-3.0.0-19-generic
Error! Could not locate dkms.conf file.
File:  does not exist.


    Die Kernel-Module aus linux-media-dkms werden bei einem Kernel-Update NICHT kompiliert, weshalb man nach einem Reboot plötzlich die Original-Treiber aus dem Kernel nutzt (die bei mir teils wesentlich längere Umschaltzeiten mit sich bringen)


    Abhilfe schafft folgender Befehl (der die Module neu kompiliert, für den neuen Kernel):

    Code
    sudo apt-get install --reinstall linux-media-dkms



    Liegt hier ein Problem an meinem System vor?
    (Das System schleppe ich in seiner Grund-Konfiguration seit Herbst 2009 mit - es wurde nur immer wieder hochgezogen, weshalb ich mir wirklich nicht sicher bin ob damit noch alles passt)


    Oder ist das Problem im Paket linux-media-dkms zu suchen (ist dort die dkms-Konfiguration "ungünstig" hinterlegt)?

  • XBMC crashed sehr häufig und landet im VDR

    Dachte ich mir, dass so etwas kommt :)


    Aber es ist meine Rede dass es ein Problem von Intel ist, denn auf der kommerziellen Schiene bei einem verbreiteten und kostenpflichtigen Betriebssytsem könnten sie es sich niemals erlauben etwas so lange so miserable bestehen zu lassen.


    Das war das Problem:


    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575965




    Und über die Behebung war sogar auf heise.de und anderen IT-Branchen-Portalen zu lesen. Ein Fehler der seit Jahren in diveren Bugtracking-Tools (freedesktop.org, Ubuntu, Gnome, Intel) herumgeistert sei endlich behoben, hieß es einhellig :)




    Seit 2006 schon nutze ich privat ausschließlich Linux. Ich könnte dir aber - wahrscheinlich gerade deshalb - eine ganze Liste an Punkten zusammenstellen, was an diesem ganzen Gebilde so richtig mistig ist.



    Inzwischen ist es mir nur teilweise zu blöd zu Problemen Threads hier zu erstellen - ich kann ohnehin nur einen Workaround beschreiben und nicht v4l-Treiber-Pakete aus dem yaVDR-Repository neu bauen, die ein Ubuntu-System in bestimmten Situationen zerschießen, obwohl sie dafür gemacht sind ...



    Inzwischen denke ich ganz offen und ehrlich, dass man mit einem sauber aufgesetzten Embedded Windows System für Zwecke wie xbmc oder eine TV-Lösung wie VDR wohl besser aufgehoben ist.


    Eine Lizenz dafür kostet ein paar Euro - schwierig wird es nur jemanden mit dem entsprechenden Know-How zu finden so ein System ordentlich aufzusetzen (Embedded Windows != Windows)



    Du hast aber recht: Ein generelles Open-Source-Problem sind diese Missstände wohl nicht - schon eher der fehlende kommerzielle Druck, den Produkte die nicht gegen Geld verkauft werden unweigerlich mit sich bringen.



    Ich bin aber trotzdem zufrieden mit meinem VDR und der Software insgesamt; die VDR-Software und die Bewegung dahinter sind eine tolle Sache, das kann man wohl sagen :]

  • XBMC crashed sehr häufig und landet im VDR

    Das Problem mit Crashes bei aktivierter Bildwiederholfrequenz-Anpassung kenne ich seit ich Xbmc bei meinem aktuellen Setup nutze - und das ist seit Ende 2009.


    Unglaublich wie wenig in dem Bereich weiter geht und scheinbar niemand in der Lage ist dieses immer wieder auftretende Problem zu beheben (dürfte ein Open-Source-Problem sein: auf meinen privaten Rechnern verwende ich nur Linux und musste mal eineinhalb Jahre auf einen Bugfix im offiziellen Intel-GMA-Treiber warten, bis endlich mit System-Freezes auf meinem Notebook Schluss war - das ist aber eine andere Geschichte :) )


    Ein Deaktivierung der Bildwiederholfrequenz-Anpassung hilft gegen die Xbmc-Abstürze, ich hab aber einen noch besseren Workaround anzubieten:


    • Frequenz-Anpassung aktiviert lassen
    • Audio-Video-Sync aktivieren, und zwar die Anpassung des Audio-Signals an den Video-Takt
    • Wartezeit für die Bildwiederholfrequenz-Anpassung aktivieren. (bei mir: 10 Sekunden, da mein Beamer so lange zur Umschaltung braucht. Bei einem TV-Gerät würde ich es mit 3 Sekunden versuchen)

    Seit ich diese Einstellungen vorgenommen habe (ich hab mehr als 2 Jahre dafür gebraucht :) ) ist Schluss mit den Abstürzen beim Start einer Videowiedergabe :)

  • yaVDR 0.4 - bereits lauffähig?

    Und das mit eurer Version 0.4 soll tatsächlich etwas werden, wenn ihr keinerlei Erfahrung dazu habt, wenn es um euren eigenen Paketbau in eurem eigenen Repository geht? :rolleyes:


    Ich sehe gerade:
    Das aktuelle Paket "vdr" für Ubuntu 11.04 Natty hast sogar du selber im Repository gebaut - 2 Wochen ists her.



    Was soll das nun heißen: Keine Erfahrung damit? Keine Ahnung was man tut? Ein großes Blackout?



    Bitte nicht als Vorwurf verstehen, aber genau so kommt deine Antwort rüber ?(

  • yaVDR 0.4 - bereits lauffähig?

    Hallo!


    Ich nutze auf meinem HTPC derzeit Ubuntu 10.04, in welchem ich die VDR-Pakete aus dem yaVDR-Repository installiert habe (testing-Repository)


    Schon länger sehe ich, dass sich darin bereits Pakete für Ubuntu Natty (11.04) befinden, welche später wohl einmal die Grundlage für yaVDR 0.4 darstellen werden. Regelmäßig aktualisiert werden diese Pakete wohl auch.


    Hat diese Pakete (vdr unter Ubuntu 11.04 Natty) schon jemand im Einsatz?


    Kann man bereits einen Test wagen, oder sollte man sich noch überhaupt keine Lauffähigkeit der neuen Pakete erwarten?

  • [yavdr-testing] vdr-sxfe stürzt seit Update von libxine2 ab

    Als Workaround bietet sich an, das Paket libxine2 manuell aus dem vdr-stable Repository downlzuloaden und mittels dpkg -i zu installieren.


    Code
    wget 'https://launchpad.net/~yavdr/+archive/stable-vdr/+build/2250391/+files/libxine2_1.2.0%7Ehg20110207-1yavdr1_amd64.deb'
sudo dpkg -i libxine2_1.2.0~hg20110207-1yavdr1_amd64.deb

  • [yavdr-testing] vdr-sxfe stürzt seit Update von libxine2 ab

    Hallo!


    Ich verwende einen HTPC mit Ubuntu 10.04 und yaVDR, welches ich aus dem vdr-testing repository installiert habe.


    Bei einem apt-get upgrade wurde gestern das Paket libxine2 auf die Version 1.2.0~hg20110415.1930-1yavdr2~lucid upgegraded (andere Pakete wurden nicht erneuert - libxine2 war das einzige)


    Seit dem Update startet auf meinem Rechner vdr-sxfe nicht mehr - der Prozess stürzt sofort nach dem Starten wieder ab.


    Im File ~/.xsession-errors ist nach einem Aufruf von vdr-sxfe der folgende Fehler zu sehen


    Code
    2139 Speicherzugriffsfehler


    2139 steht in diesem Fall für die PID von vdr-sxfe


    Hier noch - falls der Inhalt von Interesse ist; ich bin mir in diesem Fall nicht sicher - die Log-Ausgaben von vdr-sxfe vom Start an bis zum Absturz:


  • XMBC: Kanal kann nicht wiedergegeben werden

    Im .xbmc-Ornder im Home-Ordner gibts eine MyTV.db (in einem Unterordner, ich denke data)


    Du kannst mal versuchen, während Xbmc beendet ist, diese Datei zu löschen.


    Beim nächsten Start von Xbmc weren dann alle Einträge der Kanal-Liste neu von VDR in Xbmc rein geladen.



    Allgemein kann man zu Xbmc jedoch sagen, dass die bei yaVDR inkludierte Version leider nicht die neueste ist.
    Obwohl die TV-Unterstützung in Xbmc zwar generell schlecht funktioniert, tut sich doch hin und wieder die eine oder andere Änderung die eine Verbesserung mit sich bringt.


    Evtl. hilft es bei dir, in deinem System ein xbmc-Paket von Lars Op den Kamp zu installieren. Ich denke seine Pakete liegen auch im xbmc-unstable Repository des yaVDR-Teams.


    https://launchpad.net/~yavdr/+archive/unstable-xbmc


    Durch Einbinden dieses Repositories in dein System solltest du einfach auf diese neue Xbmc-Version updaten können.

  • xineliboutput: OSD zu groß bzw. nach Scaling pixelig (Full-HD)

    Lösung: Blending-Method (bei den Optionen des xineliboutput-Plugins) auf Hardware stellen


    --> und das OSD ist gestochen scharf beim aktivierten Scaling


    Ich fasse es nicht - eine halbe Woche lang hatte ich Probleme damit


    Edit:
    Verwirrend war für mich, dass VDR mit meinen Einstellungen (kein Scaling, HW-Blending) mit einer Version aus dem testing-Repository wochenlang funktionierte --> das OSD war immer so groß wie das angezeigte Fernsehbild (also bei 4:3 Inhalten wurde die Mitte des Bildschirms ausgefüllt wo das Bild war, und bei 16:9 Inhalten das gesamte Bild)


    Das war wohl ein "Fehler", der mit einem Update behoben wurde

  • xineliboutput: OSD zu groß bzw. nach Scaling pixelig (Full-HD)

    Hallo!


    Ich nutze VDR aus dem vdr-testing Repository und habe im Moment ein Problem mit dem OSD (unabhängig vom Skin)


    Zur Ausgabe nutze ich das xineliboutput-Plugin mit vdr-sxfe.
    Mein Bildschirm hat eine Auflösung von 1920x1080 - also Full-HD


    Bei Aufruf des OSD (PearlHD) passt dies eigentlich nur bei der Wiedergabe von Full-HD Sendern auf dem Bildschirm (zB Servus TV HD) - bei allen anderen Sendern ist es jeweils immer abgeschnitten; ein kleiner Teil des OSDs wird viel zu groß dargestellt und füllt den gesamten Bildschirm.


    HD-Sender wie Das Erste HD schneiden das OSD also ab - und SD-Sender erst recht.


    Scheinbar wird immer nur jener Teil des OSDs angezeigt, dessen Pixel in das gerade wiedergegebene TV-Bild passen (Bei SD ist das Bild natürlich am kleinsten)



    In den Einstellungen des xineliboutput-Plugins habe ich für das OSD eine Größe von 1920x1080 eingestellt.
    Aktiviere ich hier zusätzlich Scaling, so passt das OSD zwar immer ins Bild, bei Sendern mit kleinerer Auflösung als Full-HD ist das OSD dann aber pixelig und vor allem Buchstaben sind nicht immer lesbar.



    Das Problem tritt auf, seit ich vor ein paar Tagen mal ein apt-get upgrade durchgeführt hatte (das letzte update zuvor war einige Wochen her)


    Zuvor wurde das OSD immer ganz am Bildschirm angezeigt - ohne beschnitten zu sein; bei deaktiviertem Scaling.



    Was kann ich dagegen tun?
    Ich bin echt ratlos .... (sogar bei einem Wechsel zu vdr-stable und Neuinstallation aller dort vorhandenen Pakete tritt mein Problem weiter auf)

  • Aktuelles v4l-dvb-dkms funktioniert nicht?

    Hallo!


    Es funktioniert leider noch immer nicht - diesmal scheint es ein Problem beim Kompilieren zu geben.


    apt-get Ausgabe:


    Aus der make.log, auf die verwiesen wird, werde ich leider nicht schlau - scheinbar ist lt. den Einträgen dort alles so weit in Ordnung. Das oben genannte radio-gemtek.ko Modul wird dort erst gar nicht gelistet:


    http://pastebin.com/Lz9QxAWk