Version 1.2.2 und 1.2.3

louis · 3. März 2017

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:

Code

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:

Code

#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

louis · 3. März 2017

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

P3f · 3. März 2017

Hallo Louis,

vielen Dank für deine ausführlichen Erklärungen, ich werde mal nach dem Wochenende erneut dran machen und versuchen die entsprechenden Stellen so zu erweitern. Scheint ja wirklich erklärbar zu sein (auch wenn man kein C-Programmierer ist).

Das ich den Skindesigner als "must-have" bezeichne liegt daran, das eigentlich jeder Nutzer / Frau (WAF-Faktor) begeistert ist, wenn man im Live-TV mit 2x OK-Taste auf die Filminformationen kommt. Und das Bouquets von rechts eingeblendet werden und dann sehr schön auswählbar sind, brauch nicht extra erwähnt werden. Auch die weitere Übersicht, wie z.B. von Links die Programmübersichten einblenden sind einfach sehr funktionell. Dabei werden keine oder kaum messbare Rechnersourcen benötigt und es funktioniert auch auf schwächeren Boards. Jedem User den ich bisher darauf anspreche findet deine Arbeit großartig.

Auch ich bemerke, das die Community sehr stark auf andere verlässt und da bist Du halt bisher immer ein sehr aktiver gewesen. Klar das immer die Freizeit frisst. Und es schade ist, das die Community an sich nicht mehr gemeinschaftlich daran weiter arbeitet. Daher kann ich deine Reaktion auch nachvollziehen und akzeptieren.

Zitat von 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

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.

Leider bin ich diese Wochenende ohne Computer unterwegs, daher werde ich mir das die kommende Woche anschauen und hoffe das ich die richtigen Stellen finde.

Der Skindesigner an sich funktioniert ja auch mit der VDR 2.3.2 Version, nur halt die Zusatzfunktionen bisher nicht.

So ich hoffe, das hier nun nicht wieder ein OT entsteht, und verabschiede mich aus dem Thema.

Desweiteren hoffe ich das der VDR weiterhin weitergebracht werden wird. So wie es Klaus Schmidiger es ja auch immer schafft den VDR Core weiter voran zu bringen. Danke...

Gruß,

Pit

louis · 3. März 2017

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

seahawk1986 · 3. März 2017

Zitat von louis

So ging es mir z.B. mit der OpenGL OSD Erweiterung für softhddevice

Das funktioniert ja schon sehr schön (jetzt müsste das nur noch jemand mit dem VAAPI/HEVC-Zweig zusammenführen ), sitzt bei yaVDR aber zusammen mit dem aktuellen epgd und vielen anderen Änderungen noch in testing, weil das eine größere Aktion wird das zu mergen und nach stable zu schieben, für die ich mir mal ein WE freiräumen muss.

louis · 3. März 2017

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

rfehr · 3. März 2017

Zitat von louis

Moin,

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

Alles anzeigen

Hi Louis,

da hast vollkommen recht, es ist schon schwierg alle Patches, die es so gibt vernüftig zumsammen zu führen,
aber wir (MLD) geben noch nicht auf

Also 'OpenGL OSD Erweiterung' u. 'softhddevice "Zapcockpit" ist in unsere 5.2 Version schon lange drin.

Und sind froh über jeden Hinweis/Hilfe die wir bekommen

Gruß,
Roland

rfehr · 3. März 2017

Zitat von louis

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

Und da hast du auch wieder recht

Gruß,
Roland

P3f · 9. März 2017

Hallo Zusammen,

um wieder ein wenig zum Thema zu kommen, haben wir um MLD Team uns den ursprünglichen zapcockpit.patch angeschaut und entsprechend für den VDR 2.3.2 umgebaut.

Natürlich haben wir den bereits den PLAIN VDR 2.3.2 gebaut und eingehend getestet.

Nach Rücksprache mit Louis dürfen wir den Patch hier bereitstellen, er wird es mit seinem Repro aufnehmen sobald er wieder an seine Entwicklungsumgebung kommt.

Also, wenn jemand den Patch braucht...Ansonsten kann man ja auch die MLD 5.3 (bald) damit testen.
(Wir sind gerade noch an anderen Kleinigkeiten dran und stellen es dann bereit)

Danke, an Louis für die Erklärungen und "Patch review" damit konnten wir vom MLD Team den Patch für VDR 2.3.2 generieren.

Gruß,

Pit

//edit: Update vom Patch für Zapcockpit, vielen Dank für den Hinweis aus diesem Thread !

obelix · 19. April 2017

Hi,

wenn ein Plugin mit einem klassischen Theme funktioniert aber mit Skindesigner die Funktion nicht so ist wie sie soll, wo soll man da suchen? Liegt das am Plugin oder am Skindesigner? Ich lasse mir per bgprocess den Fortschritt von Handbrake (vdrtranscode) anzeigen. Die Ausgabe ist mit Skindesigner leider sehr gekürzt Ich hänge mal zwei Screenshots an, die das Problem verdeutlichen.

Gruß
Obelix

louis · 19. April 2017

Moin,

in bgprocess.c ab Zeile 324:

Code

void BgProcessMenu::ShowBgProcesses()
{
  SetCols(4,10,13,7);
  ...

Hier würde ich mal versuchen, die 5. Spalte mit anzugeben.

Ciao Louis

obelix · 19. April 2017

Zitat von louis
Moin,

in bgprocess.c ab Zeile 324:
Code
void BgProcessMenu::ShowBgProcesses()
{
  SetCols(4,10,13,7);
  ...
Hier würde ich mal versuchen, die 5. Spalte mit anzugeben.

Ciao Louis
Alles anzeigen

Ich teste das mal und melde mich. Danke.

Gruß
Obelix

obelix · 20. April 2017

Hallo Louis,

ich habe mir das gerade mal angeschaut. Allerdings verstehe ich nicht was du mit "die 5. Spalte mit anzugeben" meinst. Kannst du mir mal auf die Sprünge helfen?

Danke und Gruß

Obelix

louis · 20. April 2017

Hm...wie lange hat denn dein "anschauen" gedauert?

In Zeile 353 von "bgprocess.c" werden die Zeilen des OSD Menüs ausgegeben, \t ist der Spaltentrenner. Wenn du nun mal die ausgegebenen Spalten zählst, kommst du auf 5. Und jetzt darfst du noch überlegen, was "Spalten" auf Englisch heisst und dann den oben geposteten Codeschnipsel nochmal anschauen...vielleicht klingelts dann

3PO · 21. April 2017

Zitat von obelix

[...] Die Ausgabe ist mit Skindesigner leider sehr gekürzt ...

Das betrifft nicht nur bgprocess, sondern auch noch diverse andere Plugins und auch den VDR selbst.

tomas · 23. April 2017

Hallo,

Zitat von louis
in bgprocess.c ab Zeile 324:
Code
void BgProcessMenu::ShowBgProcesses()
{
  SetCols(4,10,13,7);
  ...
Hier würde ich mal versuchen, die 5. Spalte mit anzugeben.

das bringt nichts.

Der Knackpunkt ist, dass die Zeilen mit den laufenden Prozessen vom bgprocess als Separatoren ausgegeben werden. (alle?) Skindesignerskins zeigen bei Separatoren aber nur die erste Spalte an.

obelix: den shady, der in deinem zweiten Screenshot zu sehen ist, habe ich zum Testen (git) incl. graphischer Prozessbalken angepasst, den KISS mache ich wohl noch. Wenn du einen anderen Skindesignerskin verwendest, musst du entweder selbst aktiv werden oder den entsprechenden Entwickler bitten.

Gruß,
Tomas

obelix · 23. April 2017

Zitat von tomas

Hallo,

das bringt nichts.

Der Knackpunkt ist, dass die Zeilen mit den laufenden Prozessen vom bgprocess als Separatoren ausgegeben werden. (alle?) Skindesignerskins zeigen bei Separatoren aber nur die erste Spalte an.

obelix: den shady, der in deinem zweiten Screenshot zu sehen ist, habe ich zum Testen (git) incl. graphischer Prozessbalken angepasst, den KISS mache ich wohl noch. Wenn du einen anderen Skindesignerskin verwendest, musst du entweder selbst aktiv werden oder den entsprechenden Entwickler bitten.

Gruß,
Tomas

Alles anzeigen

Hallo Tomas,

vielen, vielen Dank

Gruß
Obelix

louis · 24. April 2017

Ja den Tomas gibts ja auch noch...sei gegrüßt

tomas · 24. April 2017

Zitat von louis

Ja den Tomas gibts ja auch noch...sei gegrüßt

Ajooo, salve Louis

CKone · 28. April 2017

Zitat von P3F

Hallo Zusammen,

um wieder ein wenig zum Thema zu kommen, haben wir um MLD Team uns den ursprünglichen zapcockpit.patch angeschaut und entsprechend für den VDR 2.3.2 umgebaut.

Natürlich haben wir den bereits den PLAIN VDR 2.3.2 gebaut und eingehend getestet.

Nach Rücksprache mit Louis dürfen wir den Patch hier bereitstellen, er wird es mit seinem Repro aufnehmen sobald er wieder an seine Entwicklungsumgebung kommt.

Also, wenn jemand den Patch braucht...Ansonsten kann man ja auch die MLD 5.3 (bald) damit testen.
(Wir sind gerade noch an anderen Kleinigkeiten dran und stellen es dann bereit)

Danke, an Louis für die Erklärungen und "Patch review" damit konnten wir vom MLD Team den Patch für VDR 2.3.2 generieren.

Gruß,

Pit

Alles anzeigen

Mal zu dem Patch: sieht auf den ersten Blick sehr gut aus, eine Sache ist mit aber aufgefallen:

wenn ich mit "links" das Menu für die Kanalgruppen aufmachen, eine andere Kanalgruppe wähle und mit "links" die andere Kanalgruppe öffne, dort dann gleich ohne vorher mit rauf/runter den ersten Kanal dieser Gruppe mit ok bestätige, dann schaltet er nicht auf den ersten Kanal dieser Gruppe sondern bleibt auf dem ersten Kanal der aktuellen Gruppe stehen.

ist sehr merkwürdig, so als wäre da beim Start eine Variable nicht richtig gefüllt. Auf dem 2.2.0 macht er das nicht, gerade gegen getestet.

Ansonsten super!

Christian

Version 1.2.2 und 1.2.3

Jetzt mitmachen!

Teilen