[gpodder-devel] improvements to handling of last-played position
- From: dovdevel at gmail.com (Dov Feldstern)
- Date: Mon, 13 Jun 2011 19:09:17 +0300
Thanks for the quick responses, Thomas!
>> ?(3) works flawlessly for me with the default media player. I believe
>> ? ? ?that this is acheived by gpodder telling the media player
>> ? ? ?where to resume using mafw's D-Bus API, so this solution is
>> ? ? ?specific to the n900/mafw.
>
> Yes, but if the player provides an API for resuming, we could add this
> (I can also imagine something like using a variable/placeholder like
> $POSITION or __position__, etc.. in the custom command line that would
> then get replaced with the resuming position).
>
Yes, that's exactly what the patch that I've added to
https://bugs.gpodder.org/show_bug.cgi?id=1140 does, except that you
responded before I even got a chance to attach the patch there! ;) But
it's attached now...
>
>> [...] Should I open an issue against the web service for this?
>
> This question is probably something for our resident gpodder.net master
> Stefan Koegl. Stefan: What do you think?
>
Stefan, just to clarify (and so that this section doesn't get lost in
my response now ;) ): the suggestion is that the json documents
returned also return "future" actions, similarly to the fact that
"future" actions are immediately displayed in the web UI.
>> One additional idea I've had, and am interested in hearing feedback, is
>> to create a standalone application which would stand between gpodder
>> and the media players, would talk with gpodder via the Media Player
>> D-Bus API and the command line, and then talk with different media
>> players via their own APIs. That would allow gpodder to have only
>> simple, generic, APIs, and move the complexity of dealing with
>> different media players to a separate, isolated, layer. Any thoughts?
>
> Isn't the Media Player D-Bus API already very simple and generic? I'm not sure
> what additional features the standalone application would provide; maybe you
> have some examples?
>
Certainly what I have in mind would build upon the D-Bus API. But
that's only half the issue, the other half is resuming (which can be
dealt with by adding the command line option).
But the thing is, these APIs require cooperation from the media
players, which may or may not be forthcoming. So what I'm suggesting
is a standalone "glue" application which would talk to gpodder via the
existing APIs (which I agree are good, and, I think, sufficient) on
one side, and with different media players using their preferred APIs
on the other.
I think what I have in mind is very similar to MafwPlaybackMonitor
which already exists in gpodder. If I understand correctly, it
"translates" mafw's native D-Bus API to gpodder's D-Bus API. What I'm
suggesting, I guess, is that such code be moved out of gpodder to a
totally separate application.
Similarly, for example, with VLC: currently, I have my gpodder custom
command setup to enqueue new episodes to an existing instance of VLC
(as explained at
http://wiki.gpodder.org/wiki/User_Manual#Appending_episodes_to_the_current_playlist).
However, the --start_time option does not play nicely with the enqueue
option. (This may be a VLC bug which should be solved there, but
that's beside the point.) Possibly, a better way of interfacing with
VLC is via pipes (again, I'm not familiar enough with VLC development,
but I see there is such an option). If so, it may be useful to have
this go-between application which would still talk to gpodder via
D-Bus / custom command line, and *it* would translate to VLC-pipes or
whatever.
Just throwing this out as an idea to think about, I'm not sure about
it myself, yet...
Again, thanks for the quick responses!
Dov
Other related posts:
