SGS3 stock media player support about gmrender-resurrect HOT 27 OPEN

On 16 October 2012 13:03, MohammadAG [email protected] wrote:

The stock media player on the Samsung Galaxy S3 can act as a UPnP
controller, but when setting output to gmediarenderer, it shows a Loading
dialog that never disappears, but music playback works fine.

So you can play/pause/next/previous and it shows the current status (like
title and position in stream), but just the initial setup does not seem to
work ?
There was a bug about 24h ago where in the setup-phase there was
potentially corrupted response sent; but if you're running a more recent
version, then something else is broken.

I'm not very familiar with UPnP at the moment (coming from an
almost-Apple-ish environment I'm familiar with AirPlay (well, shairport)),
otherwise I would've provided patches.

The stock player works fine with XBMC's UPnP Renderer though.

This might be useful,
https://github.com/xbmc/xbmc/blob/master/xbmc/network/upnp/UPnPRenderer.cpp

Ready to provide logs if needed to help with this.

Thanks. I am as well still trying to comprehend what is going on on the
protocol level; I actually found that of the media controllers I tested,
only BubbleUPnP works well, while other players I tried have various
problems with the current renderer implementation (e.g. they can play
stuff, but they don't seem to understand the message sent back to them that
we're in 'play' mode).

Right now I am reading up the details of the protocol so this hopefully
works soon. As soon as I am further, I'll let you know.

(Unfortunately, I don't have access to the Galaxy S3 media player, so can't
try it with that one).

If you have sample XML logs that go over the network, that might be
helpful. I'll certainly try the xbmc implementation as well to see what the
difference is.

-h

from gmrender-resurrect.

The dialog shown by the player is modal, I'm assuming that I might be able to control everything, but I can't dismiss the dialog and any attempts to kill it cause the player to go into a non-playing state, but the server continues to play the music.

I reported this issue about 10-20 minutes after I cloned and compiled the source, so it's the most recent one.

It's almost 3AM so I might have made some mistakes in the wireshark filters, but this seems to be all the XML data sent to the device (not from), I started monitoring, pressed play, waited for the dialog to disappear, and stopped the capture, all this was done with xbmc (since it's working):
http://pastebin.com/fXU08qpp

The TransportState value changing from STOPPED to TRANSITIONING seems like a hint, but there should be yet another state(?).

I'll redo the capture tomorrow, just in case.

(And off topic, there doesn't seem to be a way to quote on github.com?)

from gmrender-resurrect.

Hi,
I think I found the problem that now makes all my tested UPnP players
happy; there was a response whose content (XML) needed to be escaped.

Does it work better now ? (or at least: different :) )

(And off topic, there doesn't seem to be a way to quote on github.com?)

I was using the email response which did the proper quoting.

from gmrender-resurrect.

Hi,

On 17 Oct 2012 04:35, "Henner Zeller" [email protected] wrote:

Hi,
I think I found the problem that now makes all my tested UPnP players
happy; there was a response whose content (XML) needed to be escaped.

Does it work better now ? (or at least: different :) )

The loading dialog is now dismissed :)

But seeking always seeks to 00:00, and all position values on the device
are 00:00.

I'm guessing you need to push a CurrentPosition (pseudo, didn't look for
the variable name in the xml logs) every second to the device.

(And off topic, there doesn't seem to be a way to quote on github.com?)

I was using the email response which did the proper quoting.

Thanks!

—
Reply to this email directly or view it on GitHub.

from gmrender-resurrect.

I added some printfs to upnp_transport.c

In static int seek(struct action_event event)
char target == 00:00:16
nanos == -1179869184192.168.1.133

The IP address is always at the end of nanos, is this expected behavior?

from gmrender-resurrect.

On 17 October 2012 01:22, MohammadAG [email protected] wrote:

I added some printfs to upnp_transport.c

In static int seek(struct action_event event)
char target == 00:00:16
nanos == -1179869184192.168.1.133

Interesting, so something went wrong with the casting. I now added more
explicit casting of int results to gint64.
Can you try a 'git pull' to see if it goes away ?

The IP address is always at the end of nanos, is this expected behavior?

The IPAddress is printed as part of the "xxx action was a success" message.
Probably you didn't add a '\n' at the end of the printf() so that it looks
a bit confusing.

-h

from gmrender-resurrect.

Hi,

But seeking always seeks to 00:00, and all position values on the device
are 00:00.

I'm guessing you need to push a CurrentPosition (pseudo, didn't look for
the variable name in the xml logs) every second to the device.

No, the UPnP standard says that position information are the only changes
that are not evented (pushed), as they are changing all the time. The
device needs to pull the position info with 'GetPositionInfo'.
You should see 'GetPositionInfo' in the logs of gmrender.

I assume this this was another instance of what we've seen before with some
non-working int64 casting and hence wrong formatting of the time on output.
I am now more explicitly casting the values involved, hopefully this will
fix the display.

In src/upnp_device.c, around line 141, there is a printf() that is now
disabled with "#if 0". If you set this to '#if 1', then you see more
detailed outputs of what variables are pulled by the client-app. Maybe
there is still some formatting error in the time ?

-h

from gmrender-resurrect.

Did it start working for you ?

from gmrender-resurrect.

192.168.1.133: Action 'GetPositionInfo' was a success!

That pops up every second, yep, but the device still shows 00:00 as the current position and the total duration.
Do you want logs from XBMC when the XMLs are sent with the position info?

The rest is the same, but it's a bit quicker now it seems (could be different network conditions though)

Sorry for the late reply, been very busy lately :/

from gmrender-resurrect.

On 22 October 2012 10:17, MohammadAG [email protected] wrote:

192.168.1.133: Action 'GetPositionInfo' was a success!

That pops up every second, yep, but the device still shows 00:00 as the
current position and the total duration.
Do you want logs from XBMC when the XMLs are sent with the position info?

If you have logs from there, that would be helpful. Also, if you change the
#if 0 to an #if 1 as mentioned in one of my previous posts, you can see
what gmrender sends.

-h

from gmrender-resurrect.

Also: does seek now work ?

from gmrender-resurrect.

On Oct 22, 2012 7:45 PM, "Henner Zeller" [email protected] wrote:

Also: does seek now work ?

No, seeking won't work since the slider depends on current/total duration.

I'll check the logs as soon as I'm home.

—
Reply to this email directly or view it on GitHub.

from gmrender-resurrect.

Any update on this one ?

from gmrender-resurrect.

Ping ?

from gmrender-resurrect.

Hey,

On Nov 4, 2012 6:36 PM, "Henner Zeller" [email protected] wrote:

Ping ?

I'm currently out of country with only my phone on me, I'll be back in two
to three days.
Terribly sorry about the hold up.

—
Reply to this email directly or view it on GitHub.

from gmrender-resurrect.

I'm really really sorry about the delay.

Here are the logs as promised.
http://pastebin.com/raw.php?i=mZERQ5zZ

I did turn on debugging and saw the output, but XBMC doesn't show XML logs, so I turned to wireshark and used it for both to give a better 'side-by-side' comparison.

The NOT_IMPLEMENTED AbsTime is the problem I guess? I'll try to send the same value as RelTime for AbsTime to check.

from gmrender-resurrect.

Thanks!
I will have a look, maybe I have to install xbmc.

The NOT_IMPLEMENTED usually should not be a problem as this is the standardized way to describe that, uhm, that is not implemented. The AbsTime usually only makes sense in medias such as tapes where the whole time from the beginning of the tape is remarked; while AbsTime is the value used for the current track, and the only value for Track-based media (which we usually deal with in this context). Almost all renderers I have seen do it this way, so I would be surprised if XBMC is tripping over it. But well, you never know.

The first part in your logs shows a response that has been generated by XBMC while playing some content I presume ? Indeed, there it shows that it fills AbsTime just with the same time than RelTime; maybe it expects similar values for input.

I'll try to just set AbsTime = RelTime and see what is happening; I'll let you know when to 'git pull'.

from gmrender-resurrect.

(didn't mean to close - pressed the wrong button)

from gmrender-resurrect.

On Sun, Dec 2, 2012 at 12:39 AM, Henner Zeller [email protected]:

Thanks!
I will have a look, maybe I have to install xbmc.

The NOT_IMPLEMENTED usually should not be a problem as this is the
standardized way to describe that, uhm, that is not implemented. The
AbsTime usually only makes sense in medias such as tapes where the whole
time from the beginning of the tape is remarked; while AbsTime is the value
used for the current track, and the only value for Track-based media (which
we usually deal with in this context). Almost all renderers I have seen do
it this way, so I would be surprised if XBMC is tripping over it. But well,
you never know.

The first part in your logs shows a response that has been generated by
XBMC while playing some content I presume ? Indeed, there it shows that it
fills AbsTime just with the same time than RelTime; maybe it expects
similar values for input.

Yes, both logs are during successful playback (XBMC always works,
gmrenderer is a hit and miss, sometimes playback doesn't start at all).

I'll try to just set AbsTime = RelTime and see what is happening; I'll let
you know when to 'git pull'.

I actually tried that, and it seems like nothing changed.
I did some poking around and noticed you're setting the ID sometimes as
gmr-$RANDOM, while XBMC uses the media URI(?), e.g http://IP:port/mediaID,
so it's using TrackURI as the id, but since I'm still not familiar with the
codebase I failed to see how I could get TrackURI in output.c.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-10923219.

Regards,
Mohammad Abu-Garbeyyeh

from gmrender-resurrect.

I'll try to just set AbsTime = RelTime and see what is happening; I'll
let
you know when to 'git pull'.

I actually tried that, and it seems like nothing changed.

Ok, so will not try this now.

I did some poking around and noticed you're setting the ID sometimes as
gmr-$RANDOM, while XBMC uses the media URI(?), e.g http://IP:port/mediaID,

so it's using TrackURI as the id, but since I'm still not familiar with
the
codebase I failed to see how I could get TrackURI in output.c.

The random number thing is only happening when we have to make up a media
ID, e.g. when we're playing
internet radio and we get the new title/artist in the stream data and don't
have any meta data yet - in that case we send back the changed meta-data to
the stream.
So this only happens if there is no mediaID initially - it should not be
triggered in 'normal' circumstances.

At this point, I assume some mismatch of XML escaping/unescaping, something
I have observed before. I hope I can find some time to install XBMC on some
machine tomorrow
to see how it interacts with gmrender.

gmrenderer is a hit and miss, sometimes playback doesn't start at all

If you can, can you (wireshark-)record a full failing conversation between
gmrender and the controller (do you use XBMC as well or as well other tools
?), that leads to a non-starting playback ?
Even a raw capture file that I then can open with wireshark would be useful.

Thanks
-h

from gmrender-resurrect.

The random number thing is only happening when we have to make up a media
ID, e.g. when we're playing
internet radio and we get the new title/artist in the stream data and
don't have any meta data yet - in that case we send back the changed
meta-data to the stream.
So this only happens if there is no mediaID initially - it should not be
triggered in 'normal' circumstances.

Oh, I see, that I indeed replace the ID - this was to make sure that it is
always unique (originally, this was only enabled for internet radio
transmissions, but I widened that earlier). Feel free to comment out the
line:
result = replace_range(result, "id="", """, unique_id);
.. to see if it makes any difference. But this has been added after your
original troubles with the display time, so it is probably not related.

-h

from gmrender-resurrect.

On Sun, Dec 2, 2012 at 1:31 AM, Henner Zeller [email protected]:

The random number thing is only happening when we have to make up a media
ID, e.g. when we're playing
internet radio and we get the new title/artist in the stream data and
don't have any meta data yet - in that case we send back the changed
meta-data to the stream.
So this only happens if there is no mediaID initially - it should not
be
triggered in 'normal' circumstances.

Oh, I see, that I indeed replace the ID - this was to make sure that it is
always unique (originally, this was only enabled for internet radio
transmissions, but I widened that earlier). Feel free to comment out the
line:
result = replace_range(result, "id="", """, unique_id);
.. to see if it makes any difference. But this has been added after your
original troubles with the display time, so it is probably not related.

I commented out the line, but it still shows up as gmr-etc, so I guess the
SGS3 sends an invalid ID?
In any case, wouldn't it be better to do what XBMC does and use the
TrackURI?
I couldn't playback to not work on my laptop btw (and playback doesn't seem
to take time to start now), it seems to be always working now for some
reason, I'll try with my desktop tomorrow.

-h

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-10923736.

Regards,
Mohammad Abu-Garbeyyeh

from gmrender-resurrect.

Err, my mistake, I forgot to comment out the line after a git reset --hard.
It shows the media ID now, but without the IP address and port as with XBMC.

from gmrender-resurrect.

On 1 December 2012 16:09, MohammadAG [email protected] wrote:

On Sun, Dec 2, 2012 at 1:31 AM, Henner Zeller [email protected]:

The random number thing is only happening when we have to make up a
media
ID, e.g. when we're playing
internet radio and we get the new title/artist in the stream data and
don't have any meta data yet - in that case we send back the changed
meta-data to the stream.
So this only happens if there is no mediaID initially - it should
not
be
triggered in 'normal' circumstances.

Oh, I see, that I indeed replace the ID - this was to make sure that it
is
always unique (originally, this was only enabled for internet radio
transmissions, but I widened that earlier). Feel free to comment out the
line:
result = replace_range(result, "id="", """, unique_id);
.. to see if it makes any difference. But this has been added after your
original troubles with the display time, so it is probably not related.

I commented out the line, but it still shows up as gmr-etc, so I guess the
SGS3 sends an invalid ID?

Interesting. This would mean, that there is no Track Meta Data sent by the
client. In that case, gmrender
makes up something.
There are two pieces of information sent by the client: TrackURI - which is
the url to the stream and TransportURIMetaData which
is the meta data such as title, artist etc. The renderer usually does
nothing with the meta data, but sends it back when requested so
that controllers can display the information in their display when
connecting to a new renderer to show the current piece of music playing.

In any case, wouldn't it be better to do what XBMC does and use the

TrackURI?

Using the track URI would probably be a good idea. The gmr-XXX stuff was
mostly done for experimenting
with radio streams; in which case the meta data actually changes while the
URI stays the same. The idea
is that when the music changes in the stream, the display changes in the
controller.
This is not complete yet as I found out that renderers usually don't show
changed meta data sent back to them, so this effort
is not working out yet :/

from gmrender-resurrect.

On 1 December 2012 16:11, MohammadAG [email protected] wrote:

Err, my mistake, I forgot to comment out the line after a git reset --hard.
It shows the media ID now, but without the IP address and port as with
XBMC.

Where is the media ID shown ? Is it part of the display in your client ?
Usually, the ID should be just an internal unique identifier for the meta
data, but displayed should be the content such
as title and artist. In the case of the minimserver, for instance, the ID
looks something like "0$Composer$1$albums$2$0" - it does not need to be a
URI or anything.

from gmrender-resurrect.

On 12/02/2012 02:23 AM, Henner Zeller wrote:

On 1 December 2012 16:11, MohammadAG [email protected] wrote:

Err, my mistake, I forgot to comment out the line after a git reset
--hard.
It shows the media ID now, but without the IP address and port as with
XBMC.

Where is the media ID shown ? Is it part of the display in your client ?
Usually, the ID should be just an internal unique identifier for the meta
data, but displayed should be the content such
as title and artist. In the case of the minimserver, for instance, the ID
looks something like "0$Composer$1$albums$2$0" - it does not need to be a
URI or anything.
It isn't shown actually, but I'm thinking maybe Samsung did something
like if (instanceID == TrackURI) to listen to changes.
I could be wrong, I tried to disassemble the player but couldn't find
any reference to UPnP code (mainly AbsTime and RelTime, it must be using
some shared library to do the playback so I'll look into that later.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Regards,
Mohammad Abu-Garbeyyeh

from gmrender-resurrect.

In the meantime, I have updated the way variables are exchanged in events, this should make things more robust. Can you try again with a fresh version of gmrender-resurrect and your player ?

from gmrender-resurrect.