[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: continuous play
From:       Marcos Dione <mdione () grulic ! org ! ar>
Date:       2013-09-16 16:57:24
Message-ID: 20130916165724.GS4820 () diablo
[Download RAW message or body]

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( "=E92.ogg" )
> > 0:00:02.125529426 15061 0x7f2fa4002c00 WARN                 filesrc gst=
filesrc.c:1141:gst_file_src_uri_set_uri:<source> Invalid URI 'file://%C3%A9=
2.ogg' for filesrc: The URI 'file://%C3%A92.ogg' is invalid
> > 0:00:02.167826528 15061 0x7f2fa4002c00 WARN                 gio_src gst=
giosrc.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 gst=
giosrc.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"
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]