Concerns about changing the API-definition of 'cStatus::Replaying()' and 'cStatus::Recording()' of VDR?
Hi list!
I've a problem to check which recording is currently replayed in VDR. I know, that there is a the function 'cStatus::Replaying()', which delivers the 'Name' of the recording, but unfortunatly this is only a short version and not the full FileName. So there is no (secure) way to check which of several recordings which have the same name is actually replayed. I tried to use 'cReplayControl::LastReplayed()' but I have some problems with that and Klaus told me that this is a bad idea to call it out of a thread. So he considers changing the API of 'cStatus::Replaying()' and 'cStatus::Recording()' so it returns the full FileName (Name incl. the path to the recording) instead of the Name. He told me that I should ask the list if anybody would have a problem with that (plugins, scripts and so on) ... so here it is ... what do you all think about that? Any concerns?
Bye, Andreas Brugger
2005/12/15, Andreas Brugger brougs78@gmx.net:
Hi list!
So he considers changing the API of 'cStatus::Replaying()' and 'cStatus::Recording()' so it returns the full FileName (Name incl. the path to the recording) instead of the Name. He told me that I should ask the list if anybody would have a problem with that (plugins, scripts and so on) ... so here it is ... what do you all think about that? Any concerns?
As the LCDproc-Plugin displays the name of the recording that is currentyl replayed I think the LCDproc-Plugin will have "problems" with that. At least it must be adapted to this API-change.
Regards, Matthias
Hi Andreas,
I use cStatus::Recording() in epgsearch, but changing the name would be no problem, at least not for me, since I don't evaluate its content ;-) Perhaps it would even be better to change the whole thing in:
virtual void Recording(const cDevice *Device, const cRecording* Recording)
But this would result in a big plugin patch list after the next vdr release ;-)
BR,
Christian
The screenshot-plugin uses cStatus::Replaying() to name the screenshot-files. If the behaviour of this method is changed, i would wish to change it in a compatible way. For example adding a new parameter without changing the existent ones.
Regards, Joachim.
On Thursday 15 December 2005 18:09, Andreas Brugger wrote:
Hi list!
I've a problem to check which recording is currently replayed in VDR. I know, that there is a the function 'cStatus::Replaying()', which delivers the 'Name' of the recording, but unfortunatly this is only a short version and not the full FileName. So there is no (secure) way to check which of several recordings which have the same name is actually replayed. I tried to use 'cReplayControl::LastReplayed()' but I have some problems with that and Klaus told me that this is a bad idea to call it out of a thread. So he considers changing the API of 'cStatus::Replaying()' and 'cStatus::Recording()' so it returns the full FileName (Name incl. the path to the recording) instead of the Name. He told me that I should ask the list if anybody would have a problem with that (plugins, scripts and so on) ... so here it is ... what do you all think about that? Any concerns?
No problem in general but if this is worked on, maybe we should think of defining a name scheme for all kinds of replays and to have these interfaces return those names, too.
Currently, there are large problems wanting to identify where a replay comes from, especially if the replay doesn't have a filename in that sense. I could imagine that a DVD replay announces itself as "dvd://1", so we could use common URI naming schemes instead of defining one ourselves for things other as normal files.
Example application: An extension to the trayopen plugin shall open the tray when the drive's button is pressed. Unfortunately, for this to happen, a replay from that drive must be stopped and the disk must be unmounted prior to ejecting. On the other hand, a replay from any other source must continue. Currently, this is hardly to implement reliably.
Greetings, Sascha
Sascha Volkenandt wrote:
Currently, there are large problems wanting to identify where a replay comes from, especially if the replay doesn't have a filename in that sense. I could imagine that a DVD replay announces itself as "dvd://1", so we could use common URI naming schemes instead of defining one ourselves for things other as normal files.
Well, on a very long term. This could even go that far to start playing an URI, and VDR checks which plugin can play it back. Different plugins could use one generic VDR playback sources dialog, instead of each having its own file selector.
Example application: An extension to the trayopen plugin shall open the tray when the drive's button is pressed. Unfortunately, for this to happen, a replay from that drive must be stopped and the disk must be unmounted prior to ejecting.
DVD plugin and trayopen plugin could agree on a protocol using the Service() interface. Something like 'DVD plugin, are you replaying?' or 'could all players stop using /dev/dvd please?'
Cheers,
Udo
On Friday 16 December 2005 01:27, Udo Richter wrote:
Well, on a very long term. This could even go that far to start playing an URI, and VDR checks which plugin can play it back. Different plugins could use one generic VDR playback sources dialog, instead of each having its own file selector.
Yes, that was my (and some others') initial thought, too, but I'd not dare suggesting that before 1.5 :-D
DVD plugin and trayopen plugin could agree on a protocol using the Service() interface. Something like 'DVD plugin, are you replaying?' or 'could all players stop using /dev/dvd please?'
In the meantime yes, but this goes for VCD and PhotoCD, too (their developer seems to be inactive currently), and the mp3 plugin drops ID3 information into that interface instead of the filename, if I recall correctly :-( (BTW, the second "service phrase" of yours sounds a little desperate *g*)
Greetings, Sascha
Sascha Volkenandt schrieb:
On Friday 16 December 2005 01:27, Udo Richter wrote:
Well, on a very long term. This could even go that far to start playing an URI, and VDR checks which plugin can play it back. Different plugins could use one generic VDR playback sources dialog, instead of each having its own file selector.
Yes, that was my (and some others') initial thought, too, but I'd not dare suggesting that before 1.5 :-D
Now it would be interesting to see what Klaus thinks about the proposed changes for vdr-1.4 ... Klaus? ;-)
Bye, Andreas Brugger
Andreas Brugger wrote:
Sascha Volkenandt schrieb:
On Friday 16 December 2005 01:27, Udo Richter wrote:
Well, on a very long term. This could even go that far to start playing an URI, and VDR checks which plugin can play it back. Different plugins could use one generic VDR playback sources dialog, instead of each having its own file selector.
Yes, that was my (and some others') initial thought, too, but I'd not dare suggesting that before 1.5 :-D
Now it would be interesting to see what Klaus thinks about the proposed changes for vdr-1.4 ... Klaus? ;-)
Well, switching from
void Recording(const cDevice *Device, const char *Name)
to
void Recording(const cDevice *Device, const cRecording* Recording)
would only allow actual VDR recordings to work with this, so that's out of the question.
So it's either
void Recording(const cDevice *Device, const char *FileName)
which would be code compatible but might break plugins at runtime that rely on the string being a pure name, or
void Recording(const cDevice *Device, const char *Name, const char *FileName)
which extends the interface to hold a second parameter that contains the actual file name (or NULL, if there is none), but would break plugins st compile time.
Same goes for Replaying(), of course.
To me it's all the same, so let's here the votes.
Klaus
On Sonntag 18 Dezember 2005 17:40, Klaus Schmidinger wrote:
void Recording(const cDevice *Device, const char *Name, const char *FileName)
which extends the interface to hold a second parameter that contains the actual file name (or NULL, if there is none), but would break plugins st compile time.
maybe
void Recording(const cDevice *Device, const char *Name, const char *FileName=0)
would reduce the needed plugin changes?
Wolfgang Rohdewald wrote:
On Sonntag 18 Dezember 2005 17:40, Klaus Schmidinger wrote:
void Recording(const cDevice *Device, const char *Name, const char *FileName)
which extends the interface to hold a second parameter that contains the actual file name (or NULL, if there is none), but would break plugins st compile time.
maybe
void Recording(const cDevice *Device, const char *Name, const char *FileName=0)
would reduce the needed plugin changes?
No, because this is a virtual function the plugin must actually _implement_.
The related functions
static void MsgRecording(const cDevice *Device, const char *Name); static void MsgReplaying(const cControl *Control, const char *Name);
can, of course, have a default value for FileName.
Klaus
Hi
Am Sonntag, den 18.12.2005, 17:50 +0100 schrieb Wolfgang Rohdewald:
maybe
void Recording(const cDevice *Device, const char *Name, const char *FileName=0)
would reduce the needed plugin changes?
Please don't used parameter completion. Remember a virtual function of a Plugin must always adjusted.
A Plugin could only use a #ifdef for downward compatibility.
Maybe could a pure virtual / abstact interface help to enforce a compatibility at build time.
virtual void Recording(const cDevice *Device, const char *Name, const char *FileName) = 0;
with kind regards, Andreas
Klaus Schmidinger wrote:
void Recording(const cDevice *Device, const char *Name) void Recording(const cDevice *Device, const cRecording* Recording) void Recording(const cDevice *Device, const char *FileName) void Recording(const cDevice *Device, const char *Name, const char *FileName)
Same goes for Replaying(), of course.
To me it's all the same, so let's here the votes.
I'll start backwards, because I think its easier for Replaying():
void Replaying(const cControl *Control, const char *Name);
There we have a nice cControl passed, which is a cReplayControl in the VDR case, with things like cReplayControl::fileName etc. Without changes, we could mess with dynamic_cast<> to get back cReplayControl. More elegant would be to add virtual const char* cControl::FileName() and maybe cControl::URI() and cControl::Title() and similar, so any control implementation can give away more information about itself.
For recordings, only a cDevice is passed. The logical counterpart would be to pass a pointer to cRecordControl, cRecorder or cReceiver - and extend its interface too. There is no generic cRecordControl class, the actual cRecordControl directly implements VDR's own recorder. Question is, do we have other recordings, except VDR's own ones?
For compatibility, what about something like this:
virtual void Recording_V2(const cRecordControl *Control) { Recording(Control->Device(),Control->Name()); } virtual void Recording(const cDevice *Device, const char *Name) {}
That way compatibility is kept unless Recording_V2 is replaced with an own implementation. (names and parameters are just an example)
Cheers,
Udo
Klaus Schmidinger wrote:
So it's either
void Recording(const cDevice *Device, const char *FileName)
which would be code compatible but might break plugins at runtime that rely on the string being a pure name, or
void Recording(const cDevice *Device, const char *Name, const char *FileName)
which extends the interface to hold a second parameter that contains the actual file name (or NULL, if there is none), but would break plugins st compile time.
Same goes for Replaying(), of course.
To me it's all the same, so let's here the votes.
Imho it is far more dangerous to break a plugin at run-time because changes are not obvious. Incompatible changes of an interface should always break compilation. I have no problems to release a new version of the remote plugin...
Recording/Replaying should pass the _same_ file name (short name, full name or whatever).
If a recording has been stopped, Recording() should also pass the file name. Otherwise you never know which recording has stopped. ;-(
For example: void Recording(const cDevice *Device, const char *FileName, bool On)
The same should be done for Replaying(). void Replaying(const cControl *Control, const char *FileName, bool On)
Just my 2 cents.
Oliver
In the new year, Oliver Endriss wrote:
Klaus Schmidinger wrote:
Imho it is far more dangerous to break a plugin at run-time because changes are not obvious. Incompatible changes of an interface should always break compilation. I have no problems to release a new version of the remote plugin...
Recording/Replaying should pass the _same_ file name (short name, full name or whatever).
If a recording has been stopped, Recording() should also pass the file name. Otherwise you never know which recording has stopped. ;-(
For example: void Recording(const cDevice *Device, const char *FileName, bool On)
The same should be done for Replaying(). void Replaying(const cControl *Control, const char *FileName, bool On)
Just my 2 cents.
What about an object-oriented approach, where the recording knows whether it is playing or not and on which device. What about attaching signals to the callbacks and when the recording is stopped, a signal can be emitted.
_J
Oliver
--
VDR Remote Plugin available at http://www.escape-edv.de/endriss/vdr/
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Jeremy Hall wrote:
In the new year, Oliver Endriss wrote:
Recording/Replaying should pass the _same_ file name (short name, full name or whatever).
If a recording has been stopped, Recording() should also pass the file name. Otherwise you never know which recording has stopped. ;-(
For example: void Recording(const cDevice *Device, const char *FileName, bool On)
The same should be done for Replaying(). void Replaying(const cControl *Control, const char *FileName, bool On)
Just my 2 cents.
What about an object-oriented approach, where the recording knows whether it is playing or not and on which device. What about attaching signals to the callbacks and when the recording is stopped, a signal can be emitted.
Fine if Klaus chooses to implement it that way. I simply need the information, and I don't care how it is passed to the plugin. ;-)
Oliver
Klaus Schmidinger schrieb:
To me it's all the same, so let's here the votes.
Thanks for all the comments. First off I thought this would be much easier but there is more to consider than I was aware off.
I would prefer void Recording(const cDevice *Device, const char *Name, const char *FileName) and its Replaying-counterpart.
con: - plugins would have to adopt once
pros: - easy to implement and little changes on the VDR- and plugins-side - delivers everything like bevore plus detailed info can be gatheredby loading the corresponding recording using the FileName
Bye, Andreas Brugger
Andreas Brugger wrote:
Klaus Schmidinger schrieb:
To me it's all the same, so let's here the votes.
Thanks for all the comments. First off I thought this would be much easier but there is more to consider than I was aware off.
I would prefer void Recording(const cDevice *Device, const char *Name, const char *FileName) and its Replaying-counterpart.
con:
- plugins would have to adopt once
pros:
- easy to implement and little changes on the VDR- and plugins-side
- delivers everything like bevore plus detailed info can be gatheredby
loading the corresponding recording using the FileName
Here's how it's going to be in VDR 1.3.38:
virtual void Recording(const cDevice *Device, const char *Name, const char *FileName, bool On) {} // The given DVB device has started (On = true) or stopped (On = false) recording Name. // Name is the name of the recording, without any directory path. The full file name // of the recording is given in FileName, which may be NULL in case there is no // actual file involved. If On is false, Name may be NULL. virtual void Replaying(const cControl *Control, const char *Name, const char *FileName, bool On) {} // The given player control has started (On = true) or stopped (On = false) replaying Name. // Name is the name of the recording, without any directory path. In case of a player that can't provide // a name, Name can be a string that identifies the player type (like, e.g., "DVD"). // The full file name of the recording is given in FileName, which may be NULL in case there is no // actual file involved. If On is false, Name may be NULL.
Klaus
-
Andreas Brachold -
Andreas Brugger -
Christian Wieninger -
Jeremy Hall -
Joachim Wilke -
Klaus Schmidinger -
Matthias Becker -
Oliver Endriss -
Sascha Volkenandt -
Udo Richter -
Wolfgang Rohdewald