Leider finde ich kein WOW-Smiley ;-).
Posts by kls
-
-
Hier der Fix:
Diff--- remux.c 2024/10/08 08:46:38 5.14 +++ remux.c 2024/10/13 13:34:32 @@ -2274,6 +2274,7 @@ } else // audio framesPerSecond = double(PTSTICKS) / Delta; // PTS of audio frames is always increasing + frameChecker->SetFrameDelta(Delta); dbgframes("\nDelta = %d FPS = %5.2f FPPU = %d NF = %d TRO = %d\n", Delta, framesPerSecond, framesPerPayloadUnit, numPtsValues + 1, parser->IFrameTemporalReferenceOffset()); synced = true; parser->SetDebug(false);johol Nicht schlecht für den ersten Post
. Falls du in der CONTRIBUTORS-Datei genannt werden möchtest schick mir bitte eine Email mit deinem Realnamen an vdr@tvdr.de. -
Hab den Fehler gefunden, muss ihn nur noch fixen - ohne was anderes kaputtzumachen ;-).
-
MarkusE Stimmt! Dafür sorgt ja der bei cControl::Control() mitgegebene cMutexLock. Da hatte ich wohl momentan Tomaten auf den Augen ;-).
-
Sowas hab ich auch: http://www.tvdr.de/geotagger. Hab ich auch erstmal nur für mich selber geschrieben, weil es nichts gab, das meinen Vorstellungen entsprach. Da hab ich auch so gut wie kein Feedback bekommen. Macht aber nichts, ich hab's ja nur für mich geschrieben, und wenn es wirklich noch jemand anderes brauchen kann, um so besser. GeoTagger ist halt aber auch mehr oder weniger ein abgeschlossenes Projekt. An VDR dagegen wird ständig gearbeitet und es gibt wohl doch eine Menge Anwender. Da wäre es natürlich schon interessant, für wie viele Leute ich da Zeit investiere. So als "Ansporn" ;-). Genau genommen hab ich die letzten Monate eh schon wieder viel zuviel Zeit in VDR gesteckt, ich sollte mich mal wieder meinem anderen Hobby zuwenden...
-
wmautner Meine Frage bezog sich darauf, wieso Version 2.7.1/2 nur mehr für höhere Ubuntu-Versionen gehen.
-
Wer mit den Warnungen wegen der DEPRECATED-Macros Probleme hat, könnte mal beiliegenden Patch probieren. Damit werden diese Codeteile komplett entfernt, und das kommt auch in die nächste Version so rein.
Bei der Stelle in cControl::Launch() steht zwar ein "TODO obsolete once DEPRECATED_CCONTROL is gone", aber das fasse ich lieber nicht an, daher habe ich hier nur das TODO entfernt. Falls jemand mehr dazu sagen kann, bitte melden.
-
Wird jetzt der Zähler geändert, werden jedenfalls nur die allerneuesten VDR-Versionen gezählt, und das werden nicht sehr viele sein ...
Klar würde ein neuer Zähler wieder bei Null anfangen. Aber ich könnte auch einen Patch für ältere VDR-Versionen machen, wenn daran Interesse besteht.
-
dann kam schon 2.7.1/2, die nur mehr für höhere Ubuntu-Versionen gehen
Wieso das denn?
-
Könnte man da noch mit zählen, welche Plugins verwendet werden?
Damit würden aber dann doch wieder Daten vom VDR zum Server übertragen (mit meinem jüngsten Vorschlag würden eben genau keine Daten übertragen). Sicher wäre auch diese Info interessant, und ich persönlich hätte kein Problem damit. Auch könnte das natürlich separat abschaltbar sein. Aber ich fürchte, das fliegt uns vom Datenschutz her wieder um die Ohren...
-
Auf diesem Rechner lief bisher die Version 2.6.9 - und da trat der Fehler noch nicht auf.
Ich wüsste jetzt nicht, welche Änderung diesen Effekt haben sollte.
Kannst du mal mit Version 2.7.1 und 2.7.2 testen, um das näher einzugrenzen?
-
wirbel Ich gehe mal davon aus, dass diese Warnungen bei dir nicht aufgetreten sind, sonst hättest du diese Änderung ja nicht vorgeschlagen, oder? Ich habe mich da wohl zu sehr darauf verlassen, dass es damit kein Problem gibt, sonst hätte ich sie auf jeden Fall nicht gemacht.
@alle Ich werde das jetzt nicht nach #ifdef ändern, sondern in der nächsten Version diesen Code ganz entfernen.
-
hat jemand einen Patch für graphtftng mit VDR 2.7.3?
Ist der Fehler neu in 2.7.3? Gab es den mit der vorherigen Version nicht?
-
Nein, nicht VDR ist das Problem. live ist das Problem
Da bin ich mir nicht so sicher. Live wäre nur dann das Problem, wenn es DEPRECATED_SECTIONSYNCER_SYNC_REPEAT=1 definieren würde, was es aber offensichtlich nicht tut.
-
Solche Sachen wurden ganz früher mal mit #ifdef gemacht, wurde dann aber auf #if umgestellt, um es von aussen überschreiben zu können. Dass das jetzt solche Meldungen verursacht, wusste ich nicht (bei mir kommen die nicht). In der nächsten Version werde ich diese Codeteile eh ganz entfernen und dann nur noch [[deprecated]] verwenden.
-
VDR version 2.7.3 is now available at the official VDR GIT archive
git://git.tvdr.de
You can also get the latest stable version with
git clone --branch stable/latest git://git.tvdr.de/vdr.git
or as a tar archive with
http://git.tvdr.de/?p=vdr.git;a=snapshot;h=stable/latest;sf=tbz2
The changes since version 2.7.2:
- Removed defining DEPRECATED_* macros with value 0, because this is the preprocessor's
default (suggested by Winfried Köhler).
- Fixed error checking in case of large PTS discontinuities (reported by Matthias Senzel).
- Fixed handling negative values in cSource::Position() on systems where 'int' is 64 bit
(reported by Markus Ehrnsperger, fix suggested by Winfried Köhler).
- Fixed expiring of one-time VPS timers in case there is more than one event with the
same VPS time (suggested by Markus Ehrnsperger).
- The Channel+/- keys can now be used to jump between errors while replaying a recording
(suggested by Stefan Hofmann).
- Added vdrrootdir and incdir to vdr.pc (thanks to Stefan Hofmann).
- Plugins that have been built with API version 5 do not need to be rebuilt.
Homepage: http://www.tvdr.de
Facebook: https://www.facebook.com/VideoDiskRecorder
Have fun!
Klaus
-
Was würde der VDR denn mit der ermittelten Versionsnummer machen, wenn es denn eine neue gäbe? Im Menü anzeigen, dass es was Neues gibt?
Ja, so wie andere Programme halt auch.
-
Eine Möglichkeit wäre mir noch eingefallen:
Viele Programme fragen beim Hersteller automatisch nach, ob es eine neue Version gibt, warum also nicht auch VDR.
Also:
- Der VDR ruft einmal am Tag (auch wenn er mehrfach gestartet und gestoppt wird wirklich nur alle 24 Stunden) eine Seite auf, deren einziger Inhalt die aktuelle Versionsnummer ist (und evtl. die Zahl der Benutzer, die in den letzten 24 Stunden aktiv waren).
- Mit jedem solchen Aufruf wird ein Zähler für 24 Stunden inkrementiert.
- Es wird kein Token, Cookie oder sonst irgend etwas übertragen, worüber der einzelne VDR identifizierbar wäre.
- Die IP-Nummer wird natürlich, wie bei jedem Web-Zugriff übertragen (das ist technisch bedingt). Aus dieser wird per GeoLocation der Standort des Providers ermittelt und danach wird die IP-Nummer gelöscht. Dies erfolgt alle 5 Minuten, so lange ist die IP-Nummer also maximal auf dem Server gespeichert.
- Aus den auf dem Server längerfristig gespeicherten Daten ist somit kein Rückschluss auf einen einzelnen VDR oder Benutzer möglich.
- Damit das Sinn macht, müsste es aber defaultmäßig aktiviert sein. Wer es nicht möchte, kann es im Setup abschalten. VDR wartet zur Sicherheit mit der ersten Anfrage einige Zeit, so dass der Benutzer genügend Zeit hat, die Funktion im Setup zu deaktivieren, ohne dass eine einzige Anfrage erfolgt.
-
Und ein Token auf dem Rechner zu hinterlassen, um ihn zukünftig eindeutig zu identifizieren, ist das auch
<spitzfindig>Und was, wenn nicht der Server ein Token auf dem Client "hinterlässt", sondern der Client das Token generiert und es dem Server "überlässt"?</spitzfindig>
Ich sehe schon, das wird nichts.
Also bleiben wir bei dem bisherigen, wenig aussagekräftigen Counter, bei dem die User deutlich mehr Informationen presigeben, als es ein einfaches Token wäre. Und genau genommen erhalten Sie auch hier ein "Cookie", nämlich ihre Benutzernummer und ein Passwort!
Falls jemand helfen kann, die Karte von Google Maps auf OSM (oder ein anderes, offenes System) umzustellen, würde ich das gerne annehmen. Ansonsten bleibt alles, wie es ist...
-
zillerbaer Die Frage war auch eher rethorischer Natur ;-).
