-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I am trying to write a recmenu plugin, that implements archive-hdd
functions.
It is very hard to derive from VDRs original classes, because Klaus has set
most class members private, instead of protected. So I have to implement
everything myself, w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Klaus!
Some class declarations, for example the class cMenuRecording are
declared in the
sourcefile. So plugin developers cannot use them easily. Why don't you
move this
declarations to the headerfiles?
There are also most class members declared as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wanna write a recmenu plugin similar to extrecmenu. And when I look
into the code
of extrecmenu, the developer had to implement everything himself, even
calling a
recording's info screen. Also functions as play, rewind, delete etc.
I want to implem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
When pressing the back key during replay, the replay is not really stopped
immediately. It has another behaviour than pressing stop or blue.
When pressing back, the replay stops, and I get back to the menu. But the
recording seems to be still open
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
My plugin should work with an unpatched VDR.
I added a
cReplayControl::Stop();
as first command to the destructor of cMyReplayControl.
This works, but is that the way to go?
Can you suggest a better place to do the unlinking and
unmounting?
Thomas
-
Hi!
I like the new editing functions coming with version 2.1.2.
Thank you for that Klaus!
It would be nice, if VDR could recognize existing subfolders
and add them to folders.conf automatically.
Sometimes I edited my videodir manually, created some
subfolders to sort some recordings. VDR does not k
Hi!
I think, VDR should implement something like an editing lock,
that prevents deleting, renaming, moving or cutting the
recording. It would make something more safe. For example
renaming or moving while cutting is active, a plugin should
not alter anything. And VDR should also be prevented, when
