SGS3 stock media player support

[MohammadAG]

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.

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 for the forked version! :)

[hzeller]

On 16 October 2012 13:03, MohammadAG notifications@github.com 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

[MohammadAG]

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?)

[hzeller]

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.

[MohammadAG]

Hi,

On 17 Oct 2012 04:35, "Henner Zeller" notifications@github.com 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.

[MohammadAG]

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?

[hzeller]

On 17 October 2012 01:22, MohammadAG notifications@github.com 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

[hzeller]

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

[hzeller]

Did it start working for you ?

[MohammadAG]

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 :/

[hzeller]

On 22 October 2012 10:17, MohammadAG notifications@github.com 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

[hzeller]

Also: does seek now work ?

[MohammadAG]

On Oct 22, 2012 7:45 PM, "Henner Zeller" notifications@github.com 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.

[hzeller]

Any update on this one ?

[hzeller]

Ping ?

[MohammadAG]

Hey,

On Nov 4, 2012 6:36 PM, "Henner Zeller" notifications@github.com 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.

[MohammadAG]

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.

[hzeller]

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

[hzeller]

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

[MohammadAG]

On Sun, Dec 2, 2012 at 12:39 AM, Henner Zeller notifications@github.comwrote:

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/hzeller/gmrender-resurrect/issues/1#issuecomment-10923219.

Regards, Mohammad Abu-Garbeyyeh

[hzeller]

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

[hzeller]

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

[MohammadAG]

On Sun, Dec 2, 2012 at 1:31 AM, Henner Zeller notifications@github.comwrote:

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/hzeller/gmrender-resurrect/issues/1#issuecomment-10923736.

Regards, Mohammad Abu-Garbeyyeh

[MohammadAG]

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.

[hzeller]

On 1 December 2012 16:09, MohammadAG notifications@github.com wrote:

On Sun, Dec 2, 2012 at 1:31 AM, Henner Zeller notifications@github.comwrote:

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 :/

[hzeller]

On 1 December 2012 16:11, MohammadAG notifications@github.com 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.

[MohammadAG]

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

On 1 December 2012 16:11, MohammadAG notifications@github.com 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 https://github.com/hzeller/gmrender-resurrect/issues/1#issuecomment-10924156.

Regards, Mohammad Abu-Garbeyyeh

[hzeller]

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 ?