Beiträge von amair

Hi,

Zitat von Copperhead

OK. Es wird immer schlimmer statt besser.

Wie wäre es, wenn ich dir einen Patch vorbereite, der das richtig löst... Mit DESTDIR und PREFIX...

Patches sind immer willkommen.

Gruß
Andreas

Hallo zusammen,

Zitat von _Martin_

Super Dankeschön, ich nutze es fast täglich und für mich die beste Weboberfläche für den VDR!

ich freue mich natürlich über dieses Lob
Aber mich würde interessieren warum ihr VDRAdmin-AM dem Live-Plugin vorzieht?
Ich nutze den VDRAdmin-AM nämlich schon seit langem nicht mehr, sondern eben das Live-Plugin.

Gruß
Andreas

Hallo MegaV0lt,

Zitat von MegaV0lt

Nur das Preview beim Fernsehen müsste auf 16:9 umgestellt werden, da es praktisch ja nur noch dieses Format gibt.

sorry, ich steh' da gerade auf dem Schlauch. Meinst Du die Fenstergröße, die man im Fernseher-Menü bei "Öffne eigenes Fenster" bekommt oder die Größe des Bildes?
Falls es letzteres ist: hierfür wird als Basis 768x576 Pixel verwendet. So das auf 1920x1080 Pixel geändert werden und für das Größe-Auswählfeld dann z.B. HD, SD einführen?

Gruß
Andreas

Hallo Copperhead,

Zitat von Copperhead

Nein. Ich brauche das DESTDIR um das Ziel zu definieren. Also den temporären Pfad, aus dem dann das Paket erzeugt wird. Dieser "Zielpfad" sollte aber nicht in das Perl Skript geschrieben werden.

Einigermaßen verständlich? Ansonsten Versuch' ich es nochmal besser zu erklären.

habe das nun im GIT geändert und DESTDIR in PREFIX umbenannt.

Gruß
Andreas

Hi!

Zitat von Copperhead

Allerdings musste ich deine install.sh etwas umschreiben. https://github.com/VDR4Arch/vd…in-am/fix-install.sh.diff

Warum war das nötig?
Auf den ersten Blick hast Du nur alle $DESTDIR entfernt. Es würde doch genügen, wenn Du "DESTDIR=" (also leer) setzen würdest, oder?

Gruß
Andreas

Mod.: Bitte keine Vollzitate: Richtig zitieren und URLs posten ...

Hi,

Zitat von MegaV0lt

Nur das Preview beim Fernsehen müsste auf 16:9 umgestellt werden, da es praktisch ja nur noch dieses Format gibt.

trage das doch bitte in den BugTracker ein, den Du über die Projektseite erreichst.

Gruß
Andreas

Hi Claus,

Zitat von clausmuus

Und wie das immer so ist, wecken Updates auch immer gleich Begehrlichkeiten
Ich bin seit eh und je mit der Sortierfunktion nicht so richtig glücklich. Die Verzeichnisse werden nun ja immer Oben einsortiert, was schon mal nen guter Anfang ist. Was ich jedoch gerne anders hätte ist, dass Verzeichnisse (immer) und die Alphabetische Sortierung aufsteigend ist, während die Datumssortierung absteigend ist. Optimal wäre natürlich wenn sich beim Umschalten der Sortierart per 0? Taste nicht nur zwischen Datum und Alphabetisch umschalten ließe, sondern auch die Sortierrichtung.

trage das doch bitte in den BugTracker ein, den Du über die Projektseite erreichst.

Gruß
Andreas

Mod.: Bitte keine Vollzitate: Richtig zitieren und URLs posten ...

Hallo zusammen!

Nach einer langen Zeit mal wieder ein Update. Zu finden ist es wie immer hier

Gruß
Andreas

Änderungen seit 3.6.9:

• Improved: Optimized images to reduze their size. (Submitted by Ville Skyttä)
• Improved: Sort recordings secondarily by date when sorting by name. Makes the ordering stabler for multiple recordings with the same name. (Submitted by Olli Lammi)
• Added: streaming of recordings folders (Submitted by Daniel Matzke).
• Added: Hungarian translation (Submitted by István Füley).
• Fixed LSTR when executing recording commands on VDR >= 1.7.21 (Submitted by David Rütti)
• Updated: Italian translation (thanks to Diego Pierotto).
• Updated: Finnish translation.

Hallo,

Zitat von Argus

was mich aber wundert,
laut dem verlinkten Post gab es dazu auch einen Patch "time-warp" aus der ML der das verhindern sollte . Und der soll mittlerweile auch Bestandteil des VDR sein. Anscheinend funktioniert das wohl nicht?

sollte ich mich angesichts der frühen Morgenstunde nicht im Sourcecode verlesen, dann scheint der Patch, der verhindert, dass Differenzen über 90 Minuten gesetzt werden, NICHT übernommen worden zu sein. Zumindest bei VDR 2.0.6.

Gruß
Andreas

Hallo Christian,

Zitat von CKone

ich habe den Einschaltkanal auf "das Erste" fixiert und lasse nur da den Zeitsync zu - funktioniert seit Jahren problemlos

Christian

ja, hat bei mir auch ca. 10 Jahre funktioniert, aber jetzt ist es mir in vier Wochen zweimal passiert.

Gruß
Andreas

Hallo Argus,

Zitat von Argus

VDR löscht selbständig timer!

auch unser VDR hat ein Recht auf Vergessen

danke für den Link! Hatte ich bei meinen Suchanfragen leider nicht gefunden.

Gruß
Andreas

Hi Lars,

Zitat von mini73

Das kannst du in den vdr-Einstellungen überprüfen. Wenn der vdr die Zeit nicht stellen soll, kommt sie nicht über DVB. Wenn er es darf und du keinen ntp-Daemon laufen hast, dann kommt sie über DVB.
Und es wäre ja nicht das erste mal, dass ein Sender Müll sendet.

Deshalb benutze ich lieber ntp, da hatte ich bisher noch nie solche Sprünge.

Lars.

ja, VDR darf die Zeit von "Das Erste" nehmen und setzen. Hatte auch noch nie Probleme gegeben und ich habe jetzt schon seit ca. 10 Jahren VDR am Laufen.
Eventuell stelle ich doch auf ntp um. Danke für den Schubser in diese Richtung, manchmal sieht man das Naheliegende nicht.

Gruß
Andreas

Hallo,

ich hatte jetzt schon zum zweiten Mal den Fall, dass das Datum im Betrieb sehr weit in die Zukunft gestellt wird:

[vdr] [1002] system time changed from Sun Aug  3 21:01:40 2014 (1407092500) to Wed Sep 24 20:57:41 2014 (1411585061)

VDR macht dann einen Neustart und löscht daraufhin alle Timer, die dann in der Vergangenheit liegen. Das ist natürlich nicht schön.

Meine Frage ist nun: wieso will der VDR das Datum, so weit in die Zukunft stellen?
Ich vermute mal, dass die neu zu stellende Zeit über DVB kommt. Bedeutet das dann, dass der Sender Mist schickt?
Habe momentan jedenfalls keine Idee, wo ich mit der Suche anfangen soll

Hatte das schon mal jemand von Euch?

Gruß
Andreas

Hallo!

Nach einer langen Zeit mal wieder ein Update. Zu finden ist es wie immer hier.

Viel Spaß damit!

Gruß
Andreas

Änderungen seit Version 1.2.2:

• [amair] Fixed crashes that happened if a skin used the "menu category" feature. (Submitted by The Chief @vdr-portal.de).
• [amair] GoLastReplayed and ReturnToPlugin now work as expected.
• [amair] Add support for VDR v2.1.2+ (Submitted by TheChief @vdrportal.de).
• [amair] Fixed "level" for menu items (Patch by TomJoad @vdrportal.de).
• [amair] Display folders on top of recordings list when using descending sorting.
• [amair] Display the root video folder again when opening ExtRecMenu (closes #1447).
• [karim.afifi] Updated French translation.
• [amair] Fix recording list problems with some recording names.
• [amair] Set menu category in VDR >= 1.7.28 (Closes #1110).
• [amair] Close replay OSD before starting cutter so that marks are saved to disk (submitted by mini73 @vdr-portal.de).
• [amair] Always use VDR's cutting feature in VDR >=1.7.32.
• [amair] Reduced calls to get the free disk space.
• [amair] Use new MBperMinute() function in VDR >=1.7.27.
• [amair] Fixed compiling with VDR 1.7.28.

Hi,

Zitat von TheChief

OK, ich nutze softhddevice und hab mit skinnopacity eigentlich keine Probleme. Ist jetzt halt die Frage, ob das ganze an xineliboutput oder Deinen Plugin liegt, denn ich kann momentan keine Probleme feststellen. Vielleicht kannst Du ja mal ein backtrace erstellen und schauen, wo es hängt.

nachdem ich die Abstürze nicht mehr reproduzieren konnte, habe ich den Patch übernommen. Danke!

Gruß
Andreas

Hi,

Zitat von TheChief

Ich habe mehrfach getestet und bei mir ist der VDR nie abgestürzt. Sicher, dass der Patch beim ersten Versuch schon aktiv war? Ansonsten scheinen ja nicht mehr so viele Leute extrecmenu zu nutzen, den die Resonanz geht nahezu gegen null.

ja, bin mir sicher, dass der Patch schon drinnen war, da ich dazwischen nicht neu kompiliert habe.
Allerdings läuft auf meinen Testsystem nOpacity sowieso recht bescheiden (mit libxineoutput). OSD-Menü oft nicht zu sehen, die einzelnen Zeilen werden erst angezeigt wenn ich mit den Cursortasten das aktuelle Item ändere. Auch reagiert der VDR nicht mehr, wenn ich "bestimmte Tasten zum falschen Zeitpunkt" drücke, dann hilft nur noch ein "kill -9". Keine Ahnung, wer Schuld ist (libxineoutput?).

Aber egal. Ich warte noch ein paar Tage und teste zwischendurch nochmal. Wenn es bis dahin keine Einwände gibt, dann übernehme ich den Patch.

Gruß
Andreas

Hi,

Zitat von TheChief

Mein VDR scheint nicht mehr abzustürzen nach verschieben/umbenennen. Da sich sonst keiner meldet, würd ich den Patch mal so amair vorschlagen.

auf meinem Testsystem konnte ich keine Veränderung durch den Patch feststellen. Der VDR stürzt beim Verschieben immer noch ab (mehrmals!).
Beim nächsten Test konnte ich mehrmals verschieben ohne dass VDR abgestürzt ist. Merkwürdig.

Etwas mehr Feedback von anderen, die das Problem haben, wäre schon schön...

Gruß
Andreas

Hallo!

Zitat von TheChief

Eben...aber scheint doch nicht zu gehen. Hatte gerade einen Absturz beim Testen.

Ist leider immer noch nicht gefixt, da ich einfach keine Zeit dafür finde. Sorry!
Das Problem ist, dass Verschieben als Hintergrund-Prozeß läuft und, wenn der Vorgang abgeschlossen ist, das alte Recording-Objekt gelöscht und an der neuen Stelle neu angelegt werden muss. Wenn die Menü-Kategorie Option aktiv ist, dann wird aber eben wieder auf dieses Recording-Objekt zugegriffen, da im *offenen Menü* nicht bekannt ist, dass das Objekt schon gelöscht wurde. Bei deaktivierter Menü-Kategorie Option wird eben nicht auf das Recording-Objekt zugegriffen, sondern nur auf den (kopierten) Text.

In VDR 2.1.x könnte man das vermutlich mit der neuen ChangeName() Methode lösen, versucht habe ich es aber noch nicht.

Vielleicht findet ja von euch jemand eine Lösung? Patches werden gerne angenommen!

Gruß
Andreas

Hi,

habe' mal kurz in den Quelltext geschaut, hab's aber nicht getestet.
Den VDR-Parameter "-r" kennst Du? Dieser wird im ExtRecMenu auch mit den Actions "move" und "rename" aufgerufen. Du müsstest also nur ein eventuell schon existierendes Skript diesbezüglich anpassen.

Gruß
Andreas

Hi,

Zitat von Ramirez

Nach dem Update ist da nun folgender Code:

Code

if(mysetup.GoLastReplayed && mysetup.ReturnToRec && myReplayControl::LastReplayed())
	Open();
  mysetup.ReturnToRec = false;

Damit ist eigentlich auch klar, dass man GoLastReplayed of true setzen kann, so viel man will. Nach dem ersten Aufruf ist ReturnToRec false und die Zeile mit dem Open wird nie aufgerufen.

Ich habe mal testweise dort den alten Code eingebaut und siehe da, alles funktioniert wieder. Was für Auswirkungen an anderen Stellen dadurch sind, kann ich natürlich nicht sagen. Ich weiß ja nicht, warum diese Änderung überhaupt reinkam.
Ich kann nur sagen, dass danach dieses, für mich wichtige, Feature wieder geht.

Sorry, da hatte ich einen kleinen Vertipper. Im aktuellen GIT ist das nun behoben.

@all
Ich würde gerne demnächst eine neue Version veröffentlichen.
Es geistert aber noch ein "Absturz beim Verschieben mit dem Skin nOpacity" herum. Leider habe ich bis jetzt noch keinen Backtrace bekommen.
Wenn das also noch immer der Fall ist, dann mir bitte *jetzt* einen Backtrace schicken, dann versuche ich das noch in die nächste Version einzubauen.

Gruß
Andreas