OK, I am working on a new replacement patch.<br><br>This time I implemented a callback to track the state of the "can-record" variable. Each time the "can-record" variable value changes, the callback is executed and causes a new "recordable changed" event to be emitted by the media player event manager.<br>
<br>This works in the same way as the existing seekable and pausable implementation that has been in libvlc for some time.<br><br>There is some non-ideal behaviour: if the media player is stopped, or the playback finishes normally, then the recordable state change event does *not* get emitted. Nevertheless, this is the same behaviour as can be observed now with the current "seekable changed" and "pausable changed" implementation.<br>
<br>What this means now is that you can play your media and as soon as you get the recordable changed event you can start recording. You can then track the state by handling the recordable changed, stopped and finished events.<br>
<br>This is tested and working in my own libvlc bindings.<br><br>This should address the previous review comments regarding 1) how the caller knows when to invoke the new is_recordable() method, and 2) how the caller knows when the recordable state has changed.<br>
<br>I also added some more explanation (including what I have described above) to the method declarations in the header file - presumably this is what you mean when you mention the Doxygen documentation?<br><br>Patch to follow...<br>
<br><div class="gmail_quote">On 29 July 2012 15:40, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le dimanche 29 juillet 2012 17:19:03 Mark Lee, vous avez écrit :<br>
<div><div class="h5">> Hello...<br>
><br>
> On 29 July 2012 14:49, Rémi Denis-Courmont <<a href="mailto:remi@remlab.net">remi@remlab.net</a>> wrote:<br>
> > Le dimanche 29 juillet 2012 16:30:15 Mark Lee, vous avez écrit :<br>
> > > +/**<br>
> > > + * Can the media player record the current media?<br>
> > > + *<br>
> > > + * Media must be playing or buffering before it can be recorded.<br>
> > > + *<br>
> > > + * \param p_mi media player<br>
> > > + * \return non-zero if the media player can record, zero if it can not<br>
> > > + * \version LibVLC 2.1.0 or later<br>
> > > + */<br>
> > > +LIBVLC_API int libvlc_media_player_can_record( libvlc_media_player_t<br>
> ><br>
> > *p_mi<br>
> ><br>
> > > );<br>
> ><br>
> > I don't see how that's supposed to work. How does the caller know when to<br>
> > call<br>
> > the function? How does the caller know that the state has not changed<br>
> > since it<br>
> > checked the result of the function? This function seems intrinsically<br>
> > broken<br>
> > by design.<br>
><br>
> As to when: the caller could query this on receipt of a buffering or<br>
> playing event. Similarly if an event like stopped or media changed is<br>
> received then the caller would know the old state was no longer valid. Is<br>
> that approach not acceptable?<br>
<br>
</div></div>I don't know. But whatever the method, it needs to be specified in the Doxygen<br>
documentation.<br>
<div class="im"><br>
> As to the state changing: I did not expect that the state of this variable<br>
> would change whilst the media was playing, but I suppose I don't know<br>
> enough about vlc to be sure.<br>
><br>
> Anyway, do you think it is simply useless to include this function or<br>
> should it be fixed somehow?<br>
<br>
</div>I don't know. But without proper documentation it is useless.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Rémi Denis-Courmont<br>
<a href="http://www.remlab.net/" target="_blank">http://www.remlab.net/</a><br>
<a href="http://fi.linkedin.com/in/remidenis" target="_blank">http://fi.linkedin.com/in/remidenis</a><br>
</div></div></blockquote></div><br>