continuous play

[Marcos Dione]

On Mon, Sep 16, 2013 at 01:52:40PM +0200, Harald Sitter wrote:
> >     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.

    well, from Python2's side, I know that what I get from sys.arg
is whatever I gave to the script, with no attempt for dencoding it (that
is, to transform from the bytes [in py3's speak] to a unicode 
representation); and in any case that would fail because the string is 
not valid utf8. in the other hand, it's possible that PyQt4 is doing 
something there.

> 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.

    ok.

> 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.

    ok, good point.

-- 
(Not so) Random fortune:
Scheme code is not meant to be written by humans, it is intended to be
written automatically by macros.
	    -- Michele Simionato, "The adventures of a Pythonista in Schemeland"