continuous play

[Harald Sitter]

On Sun, Sep 15, 2013 at 1:12 PM, Marcos Dione <mdione at grulic.org.ar> wrote:
> On Wed, Sep 11, 2013 at 11:16:38AM +0200, Harald Sitter wrote:
>> what you want to do is hold on to the finished() signal or the state
>> transitions and write all your handling around that. then to
>> complement that you write code acting on aboutToFinish. iff you get
>> abouttofinish and tried setnextsource and still you get the finished
>> signal after that, then there was no transition opportunity for the
>> backend and you simply do your completely generic finished() handling
>> (e.g. check currentSource is the right one or set the right one and
>> simply call play()), otherwise transition from source 1 to 2 worked
>> just fine and everythign will continue playing.
>
>     ok, this paragraph took me a while to unravel, and this is what I
> understood: I should do business as usual trying to set the new source
> on aboutToFinish() (all this assuming the GST backend) but keeping an
> eye in finished() to see if it suceeded; if not, set a new source and
> carry on.
>
>     attached you will find a simple python/pyqt4/python-dbus script that
> works  exactly how my player does, and that introduces the things you
> mention. I run this scritps with 3 files I generated the following way:
>
>     cp /usr/share/sounds/KDE-Sys-Log-In-Short.ogg 01.ogg
>     cp /usr/share/sounds/KDE-Sys-Log-In-Short.ogg $(echo -e '\xe92.ogg')
>     cp /usr/share/sounds/KDE-Sys-Log-In-Short.ogg 03.ogg
>
>     notice that '\xe9' if tha latin1 representation of 'é', and it's not
> the utf8 one, which is the encoding in my system. I ran that python script
> with those files as parameters:
>
>     python phonon.py 01.ogg $(echo -e '\xe92.ogg') 03.ogg
>
>     also attached there is an edit version of the output, weeding out
> anything that was definetely not important. there are sevral things to
> notice:
>
>     when the aboutToFinish signal is emited, I enqueue the new source:
>
> next! >'\xe92.ogg'<
>
>     but what reaches phonon is something completely different:
>
> PHONON-GST     New source:  QUrl( "é2.ogg" )
> 0:00:02.125529426 15061 0x7f2fa4002c00 WARN                 filesrc gstfilesrc.c:1141:gst_file_src_uri_set_uri:<source> Invalid URI 'file://%C3%A92.ogg' for filesrc: The URI 'file://%C3%A92.ogg' is invalid
> 0:00:02.167826528 15061 0x7f2fa4002c00 WARN                 gio_src gstgiosrc.c:324:gst_gio_src_get_stream:<source> error: Could not open location file://%C3%A92.ogg for reading: Operation not supported
> 0:00:02.167953267 15061 0x7f2fa4002c00 WARN                 gio_src gstgiosrc.c:324:gst_gio_src_get_stream:<source> error: Could not open location file://%C3%A92.ogg for reading: Operation not supported

^ that is most likely because of python, or pyqt, or both. phonon
always ever expects utf8 which seems not to be the case with your
python application. In particular I seem to recall python2 not
defaulting to unicode strings or something like that. perhaps using
the MediaSource(QUrl) constructor works around that, but I wouldn't
bet on it. Otherwise a web search surely would yield more information
on unicode strings in python2.

>     then there is an attempt to transition to state 5, Error:
>
> PHONON-GST BEGIN: void Phonon::Gstreamer::MediaObject::requestState(Phonon::State)
> PHONON-GST   5
> PHONON-GST   BEGIN: GstStateChangeReturn Phonon::Gstreamer::Pipeline::setState(GstState)
>
>     but somehow gets lost in its way:
>
> PHONON-GST     Transitioning to state "null"
> PHONON-GST     State change
> PHONON-GST     BEGIN: void Phonon::Gstreamer::MediaObject::handleStateChange(GstState, GstState)
> PHONON-GST       Moving from "playing" 2 to "paused" 4
> PHONON-GST     END__: void Phonon::Gstreamer::MediaObject::handleStateChange(GstState, GstState) [Took: 0s]
> PHONON-GST     State change
> PHONON-GST     BEGIN: void Phonon::Gstreamer::MediaObject::handleStateChange(GstState, GstState)
> PHONON-GST       Moving from "paused" 4 to "ready" 1
> PHONON-GST     END__: void Phonon::Gstreamer::MediaObject::handleStateChange(GstState, GstState) [Took: 0s]
>
>     there are more messages about state 5, but at the end all I got is:
>
> State changed from 2 to 4 -> sending to zeitgeist.
> Player.stateChanged(): 2-> 4
> State changed from 4 to 1 -> sending to zeitgeist.
> Player.stateChanged(): 4-> 1

I can reproduce this. It appears phonon gstreamer swollows the error
state, kind of.

What you get is the legit state changes paused to playing and then
(due to error) playing to stopped. What you do not get is stopped to
error as phonon gstreamer actually doesn't emit that state change *at
all*, it does however force the pipeline into null state. Null state
should as far as I know simply reset all elements so they become
usable again. Why they are not, I do not know.

>     So I thing I didn't quite understood what you meant in that paragraph,
> but at the same time now I know the reason why that file is unplayable,
> and I think thereś a bug there where the error state is never reached. for
> clarification, my original code handles that:
>
>     def stateChanged (self, new, old):
>         if new==Phonon.ErrorState:
>             logger.warning ("ERROR: %d: %s", self.media.errorType (), self.media.errorString ())
>             # just skip it
>             self.next ()
>         elif old==Phonon.StoppedState and new==Phonon.PlayingState:
>             self.sourceChanged (self.media.currentSource ())
>             pass
>         else:
>             logger.debug ("Player.stateChanged(): %s-> %s", old, new)

self.next () <- that wouldn't actually handle it. you'd have to check
the error type and if it is fatal you should trow away all phonon
objects and reconstruct them. generally speaking recovery from fatal
errors is not supported.

HS
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia