Ein Plugin das mal geladen werden kann und mal nicht ist per se instabil und sollte gefixt werden.
Wenn du mit dem Patch gut leben kannst, ist das schön. In den offiziellen VR möchte ich das aber nicht aufnehmen.
Posts by kls
-
-
Wenn wegen so etwas eine Aufnahme ausfällt, findet man das in der Regel nicht lustig…
Der VDR wurde ja wohl schon mindestens einmal erfolgreich mit dieser Kombination von Plugins gestartet. Wieso sollte es dann bei einem Neustart (mit unveränderter Konfiguration) dazu kommen, dass ein Plugin nicht mehr geladen werden kann?
-
Wie wäre es wenn man das einstellbar macht, so wie es ja auch beim Video Data Stream Broken ist?
VDSB kann irgendwann mal auftreten (sei es wegen Wetter oder sonstigen Problemen). Wenn ein Plugin bereits beim ersten Start nicht geladen werden kann, dann sollte man wirklich den Fehler gleich beheben.
-
Eventuell könnte kls das in den VDR übernehmen
Wenn ein angefordertes Plugin nicht geladen werden kann halte ich es nicht für sinnvoll, den VDR zu starten. Es könnte ja ein Plugin sein, dessen Fehlen zunächst gar nicht auffällt, aber das zu einem späteren Zeitpunkt wichtig ist. Dann lieber gleich gar nicht starten und den Benutzer dazu "zwingen", das Problem zu beheben.
-
Recording->numFrames = -1 zu setzen bewirkt lediglich, dass in cRecording::NumFrames() die Länge der Index-Datei neu eingelesen wird und, falls die Aufnahme noch läuft, dies auch weiterhin getan wird, bis die Aufnahme endet. Sollte also keine negativen Auswirkungen haben..
-
Würde es gehen, wenn du auch noch das hier machst?
Diff
Display More--- recording.c 2025/04/16 09:14:20 5.41 +++ recording.c 2025/04/18 19:54:23 @@ -1728,8 +1728,10 @@ void cRecordings::UpdateByName(const char *FileName) { - if (cRecording *Recording = GetByName(FileName)) + if (cRecording *Recording = GetByName(FileName)) { + Recording->numFrames = -1; Recording->ReadInfo(true); + } } -
FireFly DelByName() erscheint mir hier in der Tat etwas zu invasiv. Würde vielleicht ein UpdateByName() auch genügen (mit dem Patch aus #25)?
-
Ehrlich gesagt habe ich mich gewundert, dass Infos wie FramesPerSecond indirekt über die info-Datei an die Aufnahmeliste übergeben werden.
Da hast du natürlich grundsätzlich recht. Aber ausser priority, lifetime und framesPerSecond geht es ja auch noch um die ganzen Frame-Parameter (in cRecorder::Action()). Um alle erdenklichen (und evtl. künftigen) Fälle abzudecken müsste man also die Info komplett kopieren - da erscheint es mir einfacher, die Datei neu einzulesen.
-
"Sekundengenau" - oh Mann, da hätte ich aber auch draufkommen können! Danke FireFly!
-
FireFly Der Ablauf ist aber doch
CoderecordingInfo->Write(); LOCK_RECORDINGS_WRITE; Recordings->UpdateByName(recordingName);Kann es vielleicht sein, dass st.st_mtime in cRecordingInfo::Read(FILE *f) noch den "alten" Timestamp liefert?
Kannst du mal diesen Patch ausprobieren? (nur compiliert, nicht getestet)
Diff
Display More--- recording.c 2025/04/15 19:38:46 5.40 +++ recording.c 2025/04/15 20:23:11 @@ -497,13 +497,13 @@ errors = Errors; } -bool cRecordingInfo::Read(FILE *f) +bool cRecordingInfo::Read(FILE *f, bool Force) { if (ownEvent) { struct stat st; if (fstat(fileno(f), &st)) return false; - if (modified == st.st_mtime) + if (modified == st.st_mtime && !Force) return true; if (modified) { delete ownEvent; @@ -614,13 +614,13 @@ return true; } -bool cRecordingInfo::Read(void) +bool cRecordingInfo::Read(bool Force) { bool Result = false; if (fileName) { FILE *f = fopen(fileName, "r"); if (f) { - if (Read(f)) + if (Read(f, Force)) Result = true; else esyslog("ERROR: EPG data problem in file %s", fileName); @@ -1281,9 +1281,9 @@ return cMarks::DeleteMarksFile(this); } -void cRecording::ReadInfo(void) +void cRecording::ReadInfo(bool Force) { - info->Read(); + info->Read(Force); } bool cRecording::WriteInfo(const char *OtherFileName) @@ -1729,7 +1729,7 @@ void cRecordings::UpdateByName(const char *FileName) { if (cRecording *Recording = GetByName(FileName)) - Recording->ReadInfo(); + Recording->ReadInfo(true); } int cRecordings::TotalFileSizeMB(void) const --- recording.h 2025/04/15 19:38:46 5.14 +++ recording.h 2025/04/15 20:17:50 @@ -80,7 +80,7 @@ char *fileName; int errors; cRecordingInfo(const cChannel *Channel = NULL, const cEvent *Event = NULL); - bool Read(FILE *f); + bool Read(FILE *f, bool Force = false); public: cRecordingInfo(const char *FileName); ~cRecordingInfo(); @@ -110,7 +110,7 @@ int Errors(void) const { return errors; } // returns -1 if undefined void SetErrors(int Errors); bool Write(FILE *f, const char *Prefix = "") const; - bool Read(void); + bool Read(bool Force = false); bool Write(void) const; void SetData(const char *Title, const char *ShortText, const char *Description); void SetAux(const char *Aux); @@ -201,7 +201,7 @@ ///< Deletes the editing marks from this recording (if any). ///< Returns true if the operation was successful. If there is no marks file ///< for this recording, it also returns true. - void ReadInfo(void); + void ReadInfo(bool Force = false); bool WriteInfo(const char *OtherFileName = NULL); ///< Writes in info file of this recording. If OtherFileName is given, the info ///< file will be written under that recording file name instead of this -
Hier mal ein Patch, der das doppelte Speichern von priority, lifetime und framesPerSecond entfernt.
Das ist auf jeden Fall schon mal sinnvoll, denn eine Information, die an zwei Stellen gespeichert ist, wird früher oder später an mindestens einer Stelle falsch sein ;-).
Ob das den eigentlichen Fehler auch behebt, muss sich erst noch zeigen...
-
FireFly Das hab ich in letzter Zeit auch ein paarmal beobachtet. Danke für den Hinweis, schau ich mir an.
-
Kann es sein, dass da noch Anpassungen an den Plugins nötig sind?
Sorry, ich hatte die Änderungen per sed automatisch durchgeführt, aber leider übersehen, dass hello und skincurses nicht neu compiliert wurden. Werde das in meinen Testablauf integrieren.
-
Code
Display MoreVDR version 2.7.5 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.4: - Added the "override" keyword to virtual functions reimplemented in derived classes. Plugins may want to do the same, but don't have to. - Removed -Werror=overloaded-virtual from Makefile and Make.config(.template). Plugins may want to do the same, but don't have to. - Renamed cStatus::Osd*2() to cStatus::Osd*(). Plugins that use these recently introduced functions need to remove the '2' from the name. - The new virtual function cSkinDisplayMenu::SetItemEvent(..., const cTimer *Timer) can be used to get full access to the timer (if any) defined for this event. - Added mutex locks to protect creating/deleting cStatus and cEpgHandler objects (suggested by Markus Ehrnsperger). - Making absolutely sure cEvent::Title() never returns NULL. APIVERSNUM is now 30007. - Improved subtitle handling: + Subtitles now disappear as signaled in the data stream. + Subtitles are now kept in memory for at least 120 seconds, to have them readily available after a short rewind during replay. - Subtitles can now be temporarily displayed after a fast rewind: + The setup option "DVB/Display subtitles" now has three settings: "no" and "always" behave like before, the new "after rewind" turns on subtitles after a fast rewind during replay, and off again when the point where the rewind was started is reached. - Removed an unnecessary call to cDevice::GetVideoSize(). - Moved the call to Empty() back into the pmSlow case (thanks to Andreas Baierl). - Fixed spurious times shown in the progress display when switching from "play" to "fast forward". - Now deleting old recording info before reading modified info file (suggested by Stefan Hofmann). - Plugins need to be rebuilt. Homepage: http://www.tvdr.de Facebook: https://www.facebook.com/VideoDiskRecorder Have fun! Klaus -
Ich bin jetzt nochmal alle möglichen Umschaltungen während der Wiedergabe durchgegangen und komme zu beiliegendem Fazit (Patch gegen Version 2.7.4). Einzig alle Umschaltungen nach "backward" springen auf dem rpihddevice zunächst ca. 6 Sekunden rückwärts, bevor sie wie erwartet laufen. Mit softhddevice passiert das nicht. Ich konnte im VDR selber keinen Grund hierfür finden, liegt vielleicht am rpihddevice.
Bitte ausführlich testen. Ich würde gerne noch vor Ostern die Version 2.7.5 freigeben.
-
Die Funktion
Codebool cOmxDevice::HasIBPTrickSpeed(void) { return !m_hasVideo; }soll anscheinend im Falle von reiner Audio-Wiedergabe true liefern, bei Video false. So wie es implementiert ist passiert es aber, dass bei Video-Wiedergabe beim Umschalten von z.B. Play auf FFWD kurzzeitig true geliefert wird, wodurch cDvbPlayer::Action() in den falschen Zweig kommt und erst noch einige non-I-Frames schickt, befor es auf I-Frames umschaltet. Ich habe das hier jetzt mal auf "return false;" geändert, damit tritt der Fehler nicht mehr auf. Sollte evtl. im Plugin so gelöst werden, dass nur bei wirklich reiner Audio-Wiedergabe true geliefert wird.
Ist mir beim Debuggen hiervon aufgefallen. Hatte dann zwar nichts mit dem eigentlichen Problem zu tun, hat mich aber einige Zeit gekostet, das auszuschließen ;-).
-
rell Kannst du bitte ganz genau beschreiben, welche Tasten du drückst und wann genau das Bild wie springt? "pmPause nach pmSlow forward" könnte zweierlei bedeuten...
-
Dem muss ich widersprechen.
OK, ich entferne dann nur den Aufruf in cDvbSubtitleConverter::SetOsdData().
-
rell war schneller als ich ;-). Also nur der Aufruf in cDvbSubtitleConverter::SetOsdData() kann definitiv entfallen. Falls es Plugins gibt, die GetVideoSize() aufrufen, muss es natürlich in device.[hc] bleiben.
-
Soweit ich sehe werden die Daten, die GetVideoSize() in dem einzigen Aufruf in cDvbSubtitleConverter::SetOsdData() liefert, seit Version 1.7.24 nicht mehr benutzt. Man könnte also die Zeile
cDevice::PrimaryDevice()->GetVideoSize(VideoWidth, VideoHeight, VideoAspect);
sowie die Deklarationen der Variablen komplett löschen und es würde sich nichts ändern.
Interessant ist auch, dass es bei der Beschreibung von GetVideoSize() mal hießCodevirtual void GetVideoSize(int &Width, int &Height, eVideoAspect &Aspect); ///< Returns the With, Height and Aspect ratio of the currently ///< displayed material. The data returned by this function is ///< only used for informational purposes (if any). ///< The default implementation returns 0 for Width and Height.Mein Fazit: GetVideoSize() kann komplett entfallen, nur GetOsdSize() ist von Bedeutung.
