Beiträge von louis

Zitat von davie2000

Scheint aber an der Implementierung von "Einblenden" zu liegen: wenn ich im OSD (plugin - skindesigner) alle Verzögerungen/Einblendeffekte auf 0 ms stelle,
ist nichts mehr träge.

Ohne OpenGL OSD sind diese Effekte wohl für die Füsse...also entweder Softhddevice mit OpenGL Unterstützung oder die entsprechenden Optionen im Setup abschalten. Falls yavdr das SHD mit OpenGL Osd nicht standardmäßig benutzt, wäre es wohl das beste, die Optionen schon beim installieren (passende Einträge automatisch in der setup.conf vom VDR setzen) abzuschalten.

Ciao Louis

Moin,

wenn deine Hausvisualisierung z.B. Javascript basiert im Browser läuft, könnte libwebsockets was für dich sein. Ich arbeite damit in meinem aktuellen Projekt...Websockets sind schon cool Ist halt ne reine C API, am Anfang muss man sich schon ein bisschen reinfuxen. Aber es sind genügend Beispiele dabei, an denen man sich gut orientieren kann.

Ciao Louis

Zitat von seahawk1986

(jetzt müsste das nur noch jemand mit dem VAAPI/HEVC-Zweig zusammenführen )

Merkst du was? Wie Axel Hacke so schön sagt, der "Herr Jemand" und der "Herr Einer" sind leider meistens stinkfaul. Deshalb wird das wohl nie passieren.

Ciao Louis

Moin,

Zitat von P3F

Ich will hier nicht wieder eine Grundsatzdiskussion lostreten, das haben wir schon oft an anderen Stellen mitlesen konnten. Daher sage ich hier noch einmal vielen Dank für deine bisherige Arbeit und das du den Skindesigner überhaupt ins Leben gerufen hast.
...
So ich hoffe, das hier nun nicht wieder ein OT entsteht, und verabschiede mich aus dem Thema.

ach, das ist ja mein Thread, da kann mir keiner OT verbieten Was mich einfach nervt, ist die Unkoordiniertheit des ganzen "VDR Projekts". Einer fummelt da mal ein bisschen, einer dort mal ein bisschen was anderes. Die Distributoren (wie die MLD) machen dann noch das beste draus, aber für einen Neueinsteiger ist das Thema nicht in den Griff zu bekommen. Neuerungen gehen dann verschüttet, wenn die Distributoren sich nicht selbst darum kümmern. So ging es mir z.B. mit der OpenGL OSD Erweiterung für softhddevice und auch mit der "Zapcockpit" Erweiterung. Softhddevice an sich ist auch ein gutes Beispiel, da sind so viele unterschiedliche Forks, alle mit mehr oder weniger offenen Baustellen, diesen Wust überblickt doch keiner mehr. Plugin Schnitttstelle gut und schön, aber aus meiner Sicht funktioniert dieses Konzept nicht.

Wie man das verbessern könnte, hatte ich an anderer Stelle vor einigen Monaten schon geschrieben, aber das wurde nicht beachtet bzw. abgetan..."es ist doch super so wie es ist"...jaja, man kann sich alles Schönreden

Als Effekt aus dieser ganzen Entwicklung wird meiner Meinung nach der VDR bestenfalls als eines von vielen "Backends" hinter Kodi verschwinden. Deshalb sehe ich es aktuell nicht als sinnvoll, meine Ressourcen in Ausgabethemen rund um den VDR zu stecken. Die Ressourcen sind nach wie vor da, jedoch investiere ich die aktuell aus den genannten Gründen lieber in andere nicht-VDR Themen,

So...just my 2 cent...wollte ich aber mal gesagt haben.

Ciao Louis

PS: wenn Skindesigner ein "must have" ist, sollte es doch sicherlich Leute geben, die dir dabei helfen könnten...aber die "Community" kriegt ja eh nicht den Arsch hoch hier

Ciao Louis

Hi Pit,

die Fehler, die der Compiler auswirft, sind Folgefehler. Im VDR gibt es einige globale Listen wie ein "cChannels Channels", "cTimers timers" usw. Das sind Listen von cChannel bzw cTimer Zeigern. Vor VDR 2.3.x konnte man auf diese Listen "einfach so" zugreifen, im VDR 2.3 wurden diese Listen so angepasst, dass man nicht mehr einfach so darauf ztugreifen kann, sondern vorher über ein MAcro ein Lock setzen muss.

Ich erkläre es dir am besten nochmal an einem Beispiel aus dem Skindesigner Patch für VDR2.3.1 (den DIFF habe ich im letzten Posting verlinkt): coreengine/viewdetail.c, Zeile 356:

Vorher:

const cChannel *channel = Channels.GetByChannelID(event->ChannelID());

Hier wird einfach auf "Channels" zugegriffen. Das ist aber nicht mehr erlaubt, deshalb muss man das nun so machen:

#if defined (APIVERSNUM) && (APIVERSNUM >= 20301)
    LOCK_CHANNELS_READ;
    const cChannels* channels = Channels;
#else
    cChannels* channels = &Channels;
#endif
    const cChannel *channel = channels->GetByChannelID(event->ChannelID());

Es wird also die Versionsnummer des VDR geprüft und für VDR >= 2.3.1 wird das Lock gesetzt und dann auf "Channels" zugegeriffen, für ältere VDR Versionen wirds gemacht wie bisher. Danach kann man wieder auf "Channels" (bzw. channels, ein Zeiger auf Channels) zugreifen.

Das musst du eben für alle Stellen machen, wo auf Channels / Timers / Schedules zugegriffen wird...

Sorry wenn ich dir aktuell nicht mehr helfen kann, ich habe aktuell weder Zeit noch Lust, das anzupassen.

Ciao Louis

Moin P3F,

also irgendwie passt der von dir gepostete Fehler nicht zu dem Codeauszug

Schau dir doch am besten mal die Änderungen für die VDR2.3.1 Kompatibilitätfür den Skindesigner selbst an. In den Änderungen der Datei coreengine/viewdetail.c (das kann man irgendwie nicht verlinken, ca. 1/3 nach unten scrollen) siehst du z.B. die notwendigen Maßnahmen, um auf die Channels zugreifen zu können.

Ciao Louis

Hi,

wie man den Patch auf VDR 2.3.x anpasst, kannst du aus den vielen bereits verfügbaren Beispielen entnehmen. Im Prinzip hat sich nur die Art geändert, wie man auf die globalen Strukturen zugreift. "Früher" konnte man einfach direkt auf Channels zugreifen, ab VDR2.3.1 muss man das über ein Macro machen, das ein entsprechendes Lock setzt.

Zitat von P3F

Weißt Du warum Klaus nur den einen Teil vom Patch in den VDR-Core einfließen lassen hat?

Ich glaube du verwechselst da was. Es gibt zwei Patches: der erste erlaubt, Menüs horizontal auszurichten und dann auch in den Menüs mit der Fernbedienung passend zu navigieren. Dieser Patch ist in VDR 2.3.1 aufgenommen worden. Der Zapcockpit Patch ist notwendig, um das neue "Kanalgruppenhandling" in DisplayChannel (also beim Umschalten) über den Skindesigner zu ermöglichen. Zu diesem Patch hat sich Klaus nie geäußert, ich denke, das ist ihm viel zu viel Bling Bling und viel zu umständlich, ich glaube nicht, dass der jemals im VDR landen wird.

Ciao Louis

Moin,

Zitat von P3F

Für die VDR <=2.2.0 war ja ein Patch notwendig, ist aber obsolete für die VDR 2.3.2 geworden.

der "Zapcockpit Patch" ist auch beim VDR 2.3.2 nocht notwendig...ich habe nicht gesehen, dass Klaus ihn übernommen hätte. Ob der Patch allerdings gegen VDR 2.3.x baut weiß ich nicht. Falls nein sollten die Anpassungen aber überschaubar sein. Müsste sich mal der "Herr Jemand" anschauen

Ciao Louis

Moin,

naja, noch ist der Leidensdruck nicht so hoch als dass ich was unternommen hätte...bzgl. Verstärker: meine DD Karte hat ja nur einen Eingang und verteilt das Signal intern auf den zweiten Tuner.

Ich denke, die benutzen da seit der Kanalumstellung irgendwelche grenzwertigen Frequenzen, die bei kleinsten Störungen anfällig sind. Anscheinend kommt da die DD Hardware nicht so ganz mit zurecht. Blöd...

Ciao Louis

Moin,

hm, das kenne ich Die Frage ist nur...was tun?! Bei Unitymedia beschweren scheint ja nichts zu bringen, mit den offiziellen Receivern scheint das Problem ja nicht aufzutreten...

Ciao Louis

Hi,

ist das zufällig bei Pro7 HD und Co? Ich habe das nämlich auch (Unitymedia Mannheim), auch sporadisch. Mal ist es Tage gut und dann kackt es, insbesondere zur Primetime, ein paar Stunden ab. Manchmal sind sogar auch die entsprechenden SD Kanäle gestört. Ich habe den Eindruck, das Problem besteht, seitdem Unitymedia vor ein paar Monaten die Sender so heftig umsortiert hat...vielleicht haben die die Transponder zu voll gepackt?!

Ciao Louis

Ich würde das Paket "Eigeninitiative" vorschlagen

Ciao Louis

Zitat von fnu

Ist auch so, der Octopus hängt direkt an dem 5-Port Switch, hat keine mehreren Ethernet Karten.

Das habe ich doch gemeint...Karten oder Ports kommt hier ja aufs gleiche raus

Ciao Louis

Hi,

die OctopusNet hat doch mehrere Netzwerkkarten oder? Kannst du die nicht einfach in beide Netze hängen? Dazu müsste man die Netzwerkkarten allerdings an verschiedene IPs binden können...auf der Produktseite sprechen sie aber nur von "5 Port Switch"

Ciao Louis

Moin,

der Unterschied zwischen blackhole und metrixhd ist, dass blackhole an den von dir genannten Stellen SVG Graphiken verwendet (z.B. diese hier für den Hintergrund beim Umschalten), metrixhd füllt die Flächen einfach mit Farbe. Es scheint so, als werden die Graphiken in deiner Auflösung nicht angezeigt. Möglicherweise hat die librsvg ein Problem, die SVGs auf diese Größe zu zoomen. Ggf. hilft ein Upgrade auf eine neuere librsvg Version?

Ciao Louis

Moin,

du glaubst doch nicht etwa, dass sich jemand durch diesen beschissen formatierten Code quält?

Generell muss jeder Speicher, der mit malloc und Konsorten angelegt wird, auch per free wieder explizit freigegeben werden. Wenn du externe Libs verwendest, musst du bei Verwendung der API entsprechend in der Doku der API nachlesen, ob du dich selbst um das Aufräumen des Speichers kümmern musst oder ob das die Lib für dich übernimmt. Bei z.B. "png_malloc" wäre das empfehlenswert

Ciao Louis

Moin,

originär ist das vom epgsearch Plugin (bzw. dem Schedules Menü aus dem epgsearch Plugin), das epg2vdr Plugin kann das aber auch...

Ciao Louis

Moin,

der Skin ist jetzt auch per Skindesigner installierbar...wer mag kanns mal testen

Ciao Louis

Zitat von seahawk1986

Dann schmiert der VDR beim Attachen des softhddevice-Frontend ab:

Ok, dann wissen wir jetzt zumindest, wozu die if Abfrage gut ist Da kackt dann VdpauOutputSurfacePutBitsNative ab, wenn es mit zu großen Werten aufgerufen wird. Das Plugin müsste wohl generell für 4K überholt werden.

Das Problem ist, dass die VdpauOsdClear() Methode wegen dem obigen if abgebrochen wird, deshalb bleibt das OSD stehen...

CIao Louis