Posts by balta

    Seit Java 7 sollte es eigentlich keinen Unterschied mehr zwischen Oracle JDK und OpenJDK geben, genauer gesagt basiert das Oracle JDK auf OpenJDK. Einzig einige Pakete aus den com.sun.* Paketen können fehlen, aber die waren eh nie Bestandteil der offiziellen API und wer die benutzt musste immer Angst haben dass die Anwendung irgendwann nicht mehr läuft. Ich würde mal die Java-Konsole für Applets aktivieren:

    • itweb-settings ausführen. (Gehört zu java-1_8_0-openjdk-plugin, ich musste es unter openSUSE Tumbleweed nach der Installation noch mit update-alternatives aktivieren)
    • Links Fehlerbeseitigung auswählen, dann Javakonsole "Beim Start des Plug-ins anzeigen" bzw "Beim Start von javaws anzeigen", je nachdem ob es ein Applet oder Java WebStart ist.
    • Anwenden

    Wenn jetzt ein Java-Applet gestartet wird erscheint eine Konsole mit allen Meldungen des Applets und somit auch allen evtl. auftretenden Fehlern.

    Hi,

    habe mir hier jetzt alle 44 Seiten am Stück durchgelesen und finde das generell eine interessante Idee... meine Frage wäre aber, hat das schon jemand auf einem "Internet-Server" getestet? Ich habe zuhause nichts dauerhaft laufen und will das nicht mit auf den VDR hauen. Außerdem könnte ich dann gleich drei VDR-Systeme mit versorgen. Zugriff natürlich nur mit VPN, werde den MySQL-Port nicht öffnen. (Wobei eine Rest-API o.ä. in epgd schon was tolles wäre... wenn mehrere Anwendungen direkt über die Datenbank kommunizieren da kriege ich als Webanwendungsentwickler schon etwas Bauchschmerzen ;) )

    Wie wird sich das auf die Performance auswirken? Da hier viele schon von Gigabit-LAN usw schreiben... Entsteht da wirklich so viel und so häufig Traffic? Wenn sich der VDR direkt die "aufbereiteten Daten" laden kann sollte das doch eig. weniger sein als die ganzen Rohdaten quer aus dem Internet zu ziehen oder?


    Hey sry dass ich erst jetzt antworte, die Woche war irgendwie voll... nein auch ImageMagick wurde aktualisiert, von 6.7.8.8 auf 6.8.6.9, aber ich habe das so verstanden dass dies eine Meldung von libpng ist.

    Die 1.0.2 werde ich morgen mal testen, hast du denn auch was an den Bildern gemacht oder muss ich mir die wieder konvertieren?

    Hey, danke für eure Ideen, sie haben mir nicht direkt geholfen aber darüber habe ich dann den Bug gefunden. Ich hatte gestern früher auch auf openSUSE 13.1 aktualisiert, ich dachte aber nicht dass das damit zusammenhängt. Hier wird jetzt aber libpng 1.6 mitgeliefert, was eine neue Warnung mitbringt:

    Code
    Warning: vdr: iCCP: known incorrect sRGB profile `/usr/share/vdr/plugins/skinnopacity/icons/darkblue/skinElements/channellogoback.png' @ warning/png.c/MagickPNGWarningHandler/1830

    nOpacity wertet aber auch Warnungen beim Laden der Bilder als Fehler und meint dass das Bild nicht geladen werden kann. Im angehängten Patch habe ich das korrigiert und außerdem die Fehlerausgabe verbessert. Leider reicht das hier noch nicht, libpng 1.6 will diese Datei nicht korrekt laden. Nachdem ich sie einfach nochmal durch convert gejagt habe funktioniert der Hintergrund bei mir wieder wie gewohnt.

    hey, ich habe etwas an den Einstellungen rumgespielt, und plötzlich bekomme ich es nicht mehr hin dass ein Hindergrund hinter den Kanallogos beim Kanalwechsel ist. Die Option "Hintergrund für Kalallogos benutzen" habe ich natürlich schon aktiviert. Im Log kann ich keine Fehler dass das Bild nicht gefunden werden kann o.ä. finden, und die ganze Konfiguration und von nOpacity habe ich schon einmal gelöscht.

    Hast du eine Idee woran das liegen kann? Das Problem habe ich bei allen "alten" Themes

    so mal auf meiner AMD APU getestet... und es ist deutlich schneller :) das einzige was jetzt noch langsam ist ist das Aufnahme-Menü mit TVScraper-Bildern... da kann man wohl mit Caching auch nicht mehr viel rausholen oder? Sogar das seitenweise durchscrollen ist sehr langsam... wenn man mal ans Ende muss ist das ne laaaange Aufgabe... :D

    Wie sehen das denn die anderen? Für mich wäre es so natürlich am einfachsten...

    Die bösen "Kaufreceiver" machen das ja schon anders und stellen dar, was gerade wiedergegeben wird, falls ich da richtig informiert bin.

    Ciao Louis

    Wie sehen das denn die anderen? Für mich wäre es so natürlich am einfachsten...

    Die bösen "Kaufreceiver" machen das ja schon anders und stellen dar, was gerade wiedergegeben wird, falls ich da richtig informiert bin.

    Ciao Louis


    wieso wollen alle den Codec sehen? Entscheidend sind doch die Kanäle, ob es sich lohnt die 5.1-Anlage anzuschmeißen... ob der Sound als Dolby, MPEG oder von mir aus Rauchzeichen übertragen wird ist zumindest meinen Ohren egal ;) Und bei HD Sendern steht da dann eh immer Dolby.

    Diese info wäre übrigens auch bei Aufnahmen interessant.

    Tja...shit in, shit out :D

    Ich habe doch im Readme und im Wiki geschrieben, dass man erst sein Hirn einschalten soll und dann die zum scrapen sinnvollen Sender konfigurieren soll. Eurosport und CC sind definitiv keine Kandidaten dafür...da werden die Server von themoviedb und thetvdb mit völlig unnötigen Schrottanfragen belastet, das muss nicht sein.

    Ciao Louis

    Bei Eurosport gebe ich dir recht, aber ich denke CC als "Seriensender" ist schon ein sinnvoller Kandidat. Und viele Anfragen sind das ja nicht, da dort nicht viele verschiedene Sendungen laufen. Allerdings liegt es hier am kaputten EPG von Viacom, auf die EventIDs kann man sich hier überhaupt nicht verlassen.

    Das Format der Blacklist sollte aber einfach per Skripting bearbeitbar sein, dann kann man sich sein eigenes "Sharing"-Skript schreiben ;) Natürlich samt SVDRP-Kommando zum reload.

    Ob es dann sinnvoll ist eine gemeinsame Blacklist-Datei auf vdr-developer oder so zu legen kann man dann ja immer noch sehen... Oder es wird eine im git gepflegt, die könnte man sich ja auch per Skript regelmäßig laden.

    Generell fände ich persönlich eine solche gemeinsame Datei aber sinnvoll, da man ansonsten nur die paar Sendungen dadrin haben wird die man selber auch schaut, beim "Durchzappen" aber immer noch regelmäßig Fehlinformationen erhalten wird.

    Das jedesmal neu zu berechnen wäre ziemlich unperformant, das stimmt. Aber wie wäre es wenn das nur bei der ersten Anzeige vom Skin (per Skript oder was auch immer) erstellt wird und dann im Cache-Ordner abgelegt wird? So müsste man neue Logos nur einmal ins Verzeichnis legen und nicht für jedes Theme einzeln...

    Und es würde auch das Paketieren vereinfachen, man bräuchte nicht ein Logo-Paket für jedes Theme die sich auch noch gegenseitig ausschließen müssten bzw. die in Theme-spezifischen Ordnern liegen (und man so den Logo-Pfad beim Skin-Wechsel ändern müsste)

    Außerdem könnte der Skin die Logos dann perfekt für alle Einstellungen (OSD-Höhe, Theme, abgerundet/eckig etc...) erstellen.

    danke für die neue Version und den scraper... ich bin gerade fleißig am scrapen und in mein SUSE-Repository habe ich es auch schon aufgenommen ;)

    meinen deadlock-Patch hast du aber wieder vergessen oder? :( Ich habe nochmal eine Version für 0.1.4 angehängt. Ich verstehe echt nicht wieso das Problem sonst niemand hat, prüft softhddevice den Mutex der Pixmap nicht vorm zeichnen? genau dafür ist der doch eigentlich gedacht, damit er nicht gezeichnet werden kann während noch an ihm gearbeitet wird. Zumindest habe ich das so verstanden...

    Und wie versprochen... hier die Unterstützung für die Videoskalierung in xineliboutput. Ich weiß aber nicht ob ich die yaepghd-Unterstützung damit kaputtmache, da ich das Plugin nicht verwende.

    DrSat: Ich denke dein Problem liegt daran, dass vdr-xine kein TrueColor-OSD erstellen kann wenn kein Client verbunden ist, und das ist etwas was nOpacity zum Absturz bringt. Das war bei xineliboutput dasselbe Problem und daher auch mein Patch. Vielleicht sollte nOpacity vor jeder Aktion prüfen ob das OSD erstellt werden konnte bevor es es verwendet, aber das wäre echt viel Fleißarbeit ;)

    Ich habe endlich die Zeit gefunden um es mit xineliboutput stabil zum laufen zu kriegen. Vielleicht interessiert das hier ja noch jemanden... :)

    Der xineliboutput-Patch gibt dem Plugin einen neuen Parameter:

    Code
    -t        --truecolor    Support True Color OSD if no client is connected

    Wenn dieser verwendet wird dann behauptet xineliboutput immer dass es Truecolor beherrscht, auch wenn kein Client mit "--hud" verbunden ist. Allerdings crasht der VDR dann wenn man versucht sich ohne "--hud" zu verbinden und ein OSD wird angezeigt. Daher habe ich das als Parameter umgesetzt anstatt als Standard-Verhalten.

    Der nOpacity-Patch behebt ein Deadlock-Problem, wo ich mich wundere dass dieser nicht mit anderen Ausgabeplugins auch schon aufgefallen ist.

    Als nächstes werde ich mich dann bald mal dem Scaling-Support widmen. Ich hoffe das ist nicht allzuschwer da xineliboutput das für den alten yaepg-Patch schon beherrscht.

    Moin,


    na dann liefere doch einen Patch, der das Problem behebt. Ich habe das ganze Xine gedöns nicht mehr am laufen und werde es auch nicht mehr zum laufen bringen...deshalb bin ich da auf Input angewiesen.

    Prinzipiell musst du eigentlich nur konsequent in allen public Methoden der jeweiligen Skin Klassen (inklusive der Konstruktoren / Destruktoren), die vom VDR aufgerufen werden, prüfen, ob das osd Objekt NULL ist und falls ja, direkt ein return einbauen. Hier findest du eine ganz gute Übersicht, wie ein Skin aufgebaut ist. Dann sollte der VDR auf jeden Fall nicht abstürzen. Ich denke, wenn du das in displaychannel, displaymessage und displaymenu anwendest, sollte es passen.

    Ciao Louis

    Das werde ich mir die Tage mal anschauen, sollte dann ja nicht so aufwendig sein


    Probier mal als workaround softhddevice im "suspended + detached" mode mit in die gestarteten Plugins aufzunehmen (-s -D), ich denke dann laesst sich nOpacity dazu ueberreden, keine Probleme mehr zu machen. Ich glaube mich zu erinnern, als ich versuchte, fuer xineliboutput das neue Scaling-API zu patchen (habe es letztendlich wegen der komplizierten client/server Implementierung aufgegeben, weil es nicht rund lief) das so hinbekommen zu haben, also softhddevice inaktiv geladen und trotzdem xineliboutput (mit vdr-sxfe) genutzt.

    Danke für den Tipp, das werde ich morgen mal ausprobieren, auch wenn das mehr als ein Workaround ist :D

    [Schon wieder OT]

    [Noch ein bisschen weiter mit OT]

    Willst Du keinen Dekoder im VDR-Kern aus irgend einem praktischen, oder bloss ideologischen Grund?

    Zum einen finde ich Software sollte immer soweit getrennt und modularisiert werden wie es einfach möglich ist, vor allem aber gehört immer Frontend und Backend getrennt (da das Frontend immer fehleranfälliger und schwieriger zu testen ist), aber da denke ich vermutlich auch zu stark als Java-Webentwickler... (Ich überlege immer noch ob ein REST-Plugin für VDR Sinn macht ;))

    Aber davon abgesehen ist meine Erfahrung dass vdr-sxfe deutlich öfter abstürzt als der VDR selber... und wenn ich überlege dass jedes mal eine Aufnahme kaputt gehen könnte weil mal ein Stream nicht in Ordnung ist oder der Grafikkarten-Treiber spinnt oder so... der VDR-Prozess sollte sich auf das konzentrieren wofür er da ist: Aufnehmen und Streams rausgeben.

    Ich z.B. waere auch Freund von open source Treibern, aber wenn es die nicht "in brauchbar" gibt, nutze ich halt nVidia und deren wirklich gute closed-source Treiber ohne das es mich weiter juckt. Genauso habe ich mich mal dazu entschlossen (nutzte frueher auch vdr-sxfe weil ich das Frontend auschalten konnte um XBMC bei fortlaufendem VDR starten konnte), trotz fehlender expliziter Client/Server Unterstuetzung in Softhddevice, dieses auszuprobieren als es reifer wurde und seither brauche ich kein anderes natives VDR-Frontend, alles vernetzte kann an Streamdev oder den XBMC-spezifischen Protokollen des VDR-Servers connecten. Ich bin auch fuer die Trennung der VDR-Instanz die fast immer laueft, weil sie auch dann wenn man nicht live guckt fuer Aufnahmen zustaendig ist und auf keinen Fall unnoetige Energie mit Dekodieren verbraten soll (und ganz nebensaechlich, zufaelligerweise oft Server genannt wird), und das Frontend zum gucken (ob nun ein tatsaechlicher Client, oder auch "nur" Softhddevice aktiviert bloss wenn man es braucht. Es kommt also vielmehr auf das Ergebnis als soches an, und mit Softhddevice kann man das auch erzielen.


    Wie meinst Du das, was an den Moeglichkeiten die Softhddevice alleine bietet, stellt Dicht nicht zufrieden in deinem Anwendungsszenario (welches wenn ich es richtig verstehe, nicht weit von meinem sein kann)

    [/Noch ein bisschen weiter mit OT]

    Ob die Treiber Open Source oder Closed sind ist mir auch egal, wie gesagt ich verwende fglrx... Ich sehe es nur nicht ein wenn ich Hardware besitze die das kann mir neue zu kaufen, nur weil die Software nicht passt... und mein VDR läuft mit xineliboutput und Xv ja auch zufriedenstellend, nur halt nicht mit diesem Skin ;) und die Probleme des Skins hier sind auf jeden Fall reine Software-Probleme...

    Und was mir softhddevice nicht bietet sind halt die oben angesprochene strikte Prozesstrennung und evtl. auch die Netzwerkfähigkeit... Ich finde es schon praktisch auch in der Küche oder auf dem Balkon mit dem Laptop rumzappen zu können... Und seit ich ein Tablet habe überlege ich auch schon mir dafür was zu basteln... nur zur komfortablen Nutzung brauche ich das OSD, und da reicht dann streamdev schon nicht mehr... und die PVR-Unterstützung in XBMC habe ich ehrlich gesagt noch nie wirklich gemocht, zu wenig intuitiv zu benutzen, zu eingeschränkt und zu viele Kinderkrankheiten als ich sie das letzte mal testete...

    [/Schon wieder OT]


    [OT on] AMD und softhddevice unterstützen mittlerweile vdpau. [OT off]


    [OT on] Danke für die Erinnerung, ich hatte davon gelesen und wollte es mir mal anschauen, bin ich bisher aber leider noch nicht zu gekommen... aber bisher nur mit devel-Mesa und devel-X und neuestem Kernel nehme ich an? Und außerdem müsste ich dafür endlich mal HDMI-Audio in Gang kriegen mit dem Open Source Treiber, nutze zur Zeit fglrx... :( aber ich habe eben entdeckt dass es dazu hier sogar einen eigenen belebten Thread gibt :) Fehlt dann nur noch die Client-Server-Unterstützung in SoftHDDevice, ich will keinen Dekoder im VDR-Kern [OT off]

    Heute habe ich es endlich mal geschafft deinen Skin zu testen, und ich muss sagen er gefällt mir sehr :)

    Allerdings habe ich ein riesengroßes Problem bei der Verwendung mit xineliboutput... Bei mir läuft der VDR im Hindergrund als Service, und wenn ich Fernsehen will starte ich vdr-sxfe. Das Problem hierbei ist dass der VDR nicht einmal startet wenn kein vdr-xfe verbunden ist, da dann kein TrueColor-OSD vorhanden ist. Dieses Problem lässt sich zwar einfach durch das Auskommentieren des "return false" in der entsprechenden Methode beheben, allerdings crasht der gesamte VDR dann wenn irgendetwas auf dem OSD ausgegeben werden soll während kein vdr-sxfe läuft. Der Stacktrace dazu sieht dann wie dieser aus:

    Code
    #0  0x00007ffff1744b59 in cNopacityDisplayMenuView::CreatePixmaps() () from /usr/lib64/vdr/libvdr-skinnopacity.so.2.0.0
    #1  0x00007ffff1751183 in cNopacityDisplayMenu::cNopacityDisplayMenu() () from /usr/lib64/vdr/libvdr-skinnopacity.so.2.0.0
    #2  0x00007ffff1751407 in cNopacity::DisplayMenu() () from /usr/lib64/vdr/libvdr-skinnopacity.so.2.0.0

    Meine Meinung dazu ist dass ein Skin den VDR nicht am Start hindern darf, aber das wurde wohl schon des öfteren diskutiert... aber dass er dann den VDR später crasht sehe ich schon als Bug an ;) Hat denn jemand diesen Skin erfolgreich mit xineliboutput (im Remote-Zugriff) am laufen? SoftHDDevice ist für mich aus zwei Gründen keine Option, zum einen habe ich als AMD-Nutzer kein VDPAU, zum anderen finde ich müssen VDR und Oberfläche wie oben beschrieben getrennt sein, damit Aufnahmen z.B. laufen können während ich xbmc o.ä. am Laufen habe. Und das ist mit softhddevice nicht zufriedenstellend möglich.

    Nchdem hier und vor allem in der Mailinglist soviel über das neue Makefile-System gemeckert wird, muss ich einmal schreiben dass ich das gut finde da es vieles vereinfacht. Man braucht keinen VDRSRCDIR o.ä. mehr um einfach ein Plugin zu bauen, man macht einfach nur noch im Plugin-Ordner make && make install. Dieses ganze Make.global und Make.config fand ich schon immer Mist. Generell sind solche compile-time Einstellungen mit ifdefs etc blöd, da hier dem Benutzer Entscheidungen vorweggenommen werden. Nicht jeder kompiliert selber, die meisten wollen einfach nur ein Paket installieren und das Programm starten.

    Ich würde sogar noch weitergehen, wieso soll der Benutzer noch die runvdr oder eine runvdr.conf anpassen nachdem er ein Plugin installiert hat? Wieso lädt der VDR nicht einfach alle Plugins die installiert sind? Wieso brauchen viele Plugins wieder Parameter? Wieso kann man das alles nicht über das OSD einfach einstellen? Der Idealfall wäre doch: Ein Paket VDR und ein paar Plugin-Pakete installieren, dann den VDR-Service starten und im OSD alles einstellen können.