Beiträge von kamel5

Zitat von gggggg

Ich bekomme es nicht hin dass die Aufnahmen zeitlich sortiert werden...

In den Einstellungen des OSD habe ich "nach Zeit" und "descending". Stelle ich auf ascending is es immer noch "nach Namen" u halt aufsteigend aber nie nach Zeit .

Das funktioniert hier schon länger ohne Probleme.

Man muss allerdings die Zusammenhänge richtig verstehen.

- den Im Setup->OSD vorhandenen Eintrag "Standard Sortierreihenfolge für Aufnahmen" würde ich ignorieren.

- der Im Setup->OSD vorhandene Eintrag "Sortierreihenfolge für Aufnahmen" legt fest, ob aufsteigend oder absteigend sortiert wird.

- das Umschalten zwischen Sortierung nach Name oder Zeit erfolgt dann bei geöffnetem Aufzeichnungsmenü mit der "0"

Das Gleiche gilt auch für das extrecmenung, da dort die VDR-internen Funktionen benutzt werden.

Grüße

kamel5

Neue Version 1.3.6 im git:

- Fix segfault when tvscraper returns "call->type = tNone"

- In menu "Search Recordins" get ChannelName from 'RecInfo'

- Display errors in search recordings

- Fixed possible segfault when showing scrollbar in search result lists

- Adapt epgsearch "allow empty" for searchtimer

- some rework

- optical optimization

Grüße

kamel5

Neue Version 1.1.12 im git:

- Add display volume to DisplayMenu, DisplayChannel and DisplayReplay

- Display number of recordings in recordings main menu

- Some optical optimitation

- Fix segfault when tvscraper returns "call->type = tNone"

- Fix segfault when selecting invisibile menu items

Grüße

kamel5

MarkusE , das gefällt mir auch nicht so richtig.

In diesem Bereich hatte ich mir sowieso für den Herbst mal eine Überarbeitung vorgenommen, es gibt da noch redundanten Code zwischen tabbed und nicht tabbed Anzeige. Bei der Gelegenheit werde ich mir das mit den Schauspielern auch mit ansehen.

Ich werde dann die Schauspieler ohne Bild einfach weglassen, da dieser Reiter ja hauptsächlich die Bilder anzeigen soll. Außerdem gibt es eh nie aller "Teilnehmer".

Grüße

kamel5

Ich habe die Plugins mal mit gepatchtem tvscraper getestet und es scheint soweit zu funktionieren.

Für skinnopacity und tvguide werde ich am kommenden Wochenende neue Versionen machen, die die Fixe enthalten.

Grüße

kamel5

Ich nehme das mal mit auf meine Liste. Vorher muss ich mir aber noch einen Testfall ausdenken, der auch mit ungepatchem VDR zum Absturz führt.

Grüße

kamel5

M-Reimer,

Danke für Deine Mühen.

Das Ganze sieht schon mal sehr gut aus. Wenn ich mal wieder mehr Zeit habe, muss ich mal schauen, ob das alles noch gültig ist.

Grüße

kamel5

Zitat von M-Reimer

Edit: Hast ein Issue dazu. Leider kennt gitlab, anders als GitHub, kein "offen editierbares Wiki" und in dem Issue, in dem das behandelt wird, haben die sich verkünstelt mit einem Berechtigungs-Konzept.

Ich habe Dir für skindesigner, tvguide, tvguideng und skinnopacity developer-Rechte eingetragen. Für die 4 gibt es ein Wiki.

Für tvguide habe ich händisch schon mal ein Wiki angelegt, das war doch recht großer Aufwand.

Ich sehe gerade, Du hast schon etwas hochgeladen, da scheint es zu funktionieren.

Grüße

kamel5

Ich habe meine Projekte ja schon auch auf gitlab, allerdings ist es mir bisher nicht gelungen, die Wiki-Einträge der Projekte komplett zu sichern.

Wenn da jemand eine Idee hat, wie das gehen könnte, würde ich das auch noch machen.

Zum Teil, wie z.B. beim skindesigner gibt es ja umfangreiche Wiki-Einträge, und die alle einzeln per Hand zu sichern, wäre mir dann doch zu aufwändig.

Grüße

kamel5

Danke für die Rückmeldung.

Zitat von shofmann

Einen Absturz kann man vermutlich auch mit dem Standard-VDR ganz leicht produzieren: Einfach die Zahl der Hauptmenü-Elemente so einstellen, dass sie nicht mehr auf eine Seite passen und einen Eintrag auf einer nicht angezeigten Folgeseite auswählen.

Ja, das dürfte die gleichen Abstürze verursachen.

Zitat von shofmann

Beides deutet darauf hin, dass nicht der Menu-Selection-Patch ursächlich ist, sondern nur die Tatsache, dass man ein nicht angezeigtes Element auf einer anderen Seite als Seite 1 direkt auswählt. Mit dem Patch war aber auch in diesen Szenarien alles gut.

Genau so ist es, der Menu-Selection-Patch hat es nur zum Vorschein gebracht.

Zitat von shofmann

PS: Die andern von mir genutzten Skins haben, wie bereits weiter oben erwähnt, ein solches Verhalten bislang nicht gezeigt. Vor SkinNopacity habe ich meist SkinEnigmaNG genutzt und mir auch mal SkinElchi, LCars oder LCarsNG angesehen.

Wie das andere Skins gemacht haben, habe ich mir nicht angesehen, es ist aber so, das Skins, die keine eigene Verwaltung von Menüelementen implementiert haben, wie z.B. LCARS, von diesem Problem grundsätzlich nicht betroffen sind.

Im Endeffekt könnte man diesen Absturz sicher auch im Core-VDR beheben und vielleicht wäre das sogar die bessere Lösung. Da wir hier aber jetzt einen Fix haben, sehe ich da im Moment keinen Handlungsdruck.

Grüße

kamel5

Zitat von MarkusE

"GetEventType": Das gibt "false" zurück, wenn das Ereignis nicht gefunden wird. . Das kann ich (noch) nicht fixen, da es Plugins gibt, die sich auf den Fehler in tvscraper verlassen .

Ich habe jetzt Fixe für skinnopacity im devel-Branch, tvguide im master-Branch eingespielt.

Für tvguideng und skindesigner sind auf den ersten Blick keine Fixe nötig.

Ich würde das aber gerne nochmal testen. Kannst Du mir dazu mal eine Version mit geändertem "GetEventType" liefern.

Grüße

kamel5

Zitat von S:oren

Mir ging es nicht darum, was man aufrufen kann oder nicht. Ich wollte wissen, ob man beim Standard-VDR ohne Patches auch so einen Absturz provozieren kann.

Ah, OK. Ohne Patches kann man so einen Absturz nicht provozieren, es ist mir bisher zumindest nicht gelungen.

Zitat von S:oren

Das scheint mir eigentlich ein Problem des Core-VDR zu sein. Warum sollte man einen Menueeintrag (sichtbar oder nicht) updaten (die Darstellung auf ausgewaehlt aendern), wenn das Menue sowieso durch die Auswahl geschlossen wird? So ein Update verlangt aber der VDR-Core. Und das ist eigntlich nur sinnvoll, wenn gescrollt werden soll, nicht bei einer Auswahl mit Zifferntasten.

Das Updaten der Menüeinträge hat folgenden Grund:

Wenn man z.B. den Eintrag 10 aktiv hat und sich dann mit der 4 die Aufzeichnungen anzeigen läßt und dann mit der Zurück-Taste wieder in das Hauptmenü zurück springt, ist dann der Menüeintrag 4 aktiv (das ist auch die Erwartungshaltung).

Es kann aber durchaus sein, das sich da noch einiges optimieren ließe. Bei den Standard-Skins ist das bisher wahrscheinlich nicht aufgefallen, weil dort die Menüeinträge nicht separat behandelt werden, es wird also nur das angezeigt, was der VDR selbst liefert.

Zitat von S:oren

Aber mein Workaround sollte den Absturz auch fixen.

Da die anderen von mir getesteten Skins (ich habe nicht alle getestet) das Problem nicht haben, ist ein Workaround für mich mehr als OK.

Grüße

kamel5

S:oren , danke für den Patch.

Ein erster Test bei mir war erfolgreich.

Ich habe den Patch in meinen devel-Branch übernommen.

shofmann , bitte testen, ob das bei Dir auch funktioniert.

Grüße

kamel5

Zitat von S:oren

Meine Frage war, ob das auch bei Standard-Skins ohne Patches so ist.

Ich dachte, ich hatte das geschrieben:

Zitat von kamel5

Ja, mit Menu-Selection-Patch, sowohl mit LCARS, als auch mit z.B. skindesigner.

Ohne Menu-Selection-Patch kann man 2-stellige Menüpunkte nicht eingeben.

Also, bei Standard-Skins funktioniert es sowohl mit, als auch ohne Patch. Ohne Patch kann man aber keinen 2-stelligen Menüpunkt auswählen (hier wird jede Ziffer einzeln ausgewertet). Man kann aber von der 2. Seite einen einstelligen Menüpunkt auf der ersten Seite auswählen. Ohne Patch funktionierte das letzte auch mit skinnopacity.

Test mache ich im Anschluss.

Grüße

kamel5

Zitat von S:oren

Funktioniert das mit den "Standard-Skins"?

Ja, mit Menu-Selection-Patch, sowohl mit LCARS, als auch mit z.B. skindesigner.

Ohne Menu-Selection-Patch kann man 2-stellige Menüpunkte nicht eingeben.

Zitat von S:oren

Und ohne Menu-Selection-Patch (auf zweite Seite gehen und dann per Zahl einen Eintrag der ersten Seite aufrufen)?

Das funktioniert, solange der Menüpunkt einstellig ist.

Es scheint so, das das Auswählen eines Menüeintrages, der gerade nicht angezeigt wird, zum Absturz führt.

Anbei auch:

Backtrace-1: angezeigt wird Menüeintrag 11-20 (2. Seite) und Menüeintrag 4 soll aufgerufen werden.

Backtrace-2, angezeigt wird Menüeintrag 1-10 und Menüeintrag 18 soll aufgerufen werden.

Grüße

kamel5

shofmann ,

ich habe mir das gerade mal angesehen und es ist bei mir auch so.

S:oren , Du hast ja damals die Behandlung der Menü-Einträge überarbeitet (commit: Convert menuItems from cList to std::vector),

es wäre schön, wenn Du Dir das mal anschauen könntest.

Grüße

kamel5

OK, ich schaue es mir an. Es betrifft bei mir außer skinnopacity:

- skindesigner, (den hast Du schon getestet)

- tvguide, tvguideng (hier wird der gleiche Code benutzt, wie bei skinnopacity, also auch ein Fix nötig)

Das wird aber vorausichtlich erst am Wochenende.

Grüße

kamel5

Zitat von MarkusE

Es ist noch nicht aufgefallen, weil tvscraper sich nicht an die Vorgaben von Klaus gehalten hat .

Das ist zwar nicht i.O. Die Frage ist dann aber, ist es klug, es jetzt noch zu ändern.

Ich habe da noch 3 Plugins, die davon auch betroffen sind. Und möglicherweise gibt es auch noch andere.

Grüße

kamel5

MarkusE , ich sehe das Problem, wobei es mich wundert, das es bisher noch nicht aufgefallen ist.

Ich habe mal einen schnellen Fix im Branch devel hinzugefügt.

Es wäre schön, wenn Du das mal testen könntest.

Grüße

kamel5

Zitat von S:oren

Finde ich prinzipiell gut, aber "remotes/origin/Devel-Light" gibt's noch

Das stimmt, den hatte ich schon aus meinem Gehirn verdrängt.

Ich werde ihn auch noch umbenennen...

Grüße

kamel5