Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TreeFrog77]

Without going into a ton of detail, I have a small little thing I was wondering could be glanced at in the library server.  To make a long story short, I've recently returned to developing a custom Flash interface to my home automation / media control.  Data regarding Playing Now, Playlists, etc. are delivered to the interface by way of my home automation software through the MC Automation Interface through a polled-delta XML feed.  Anywho...

On my main Flash interface screen for Now Playing, I display the usual suspects... Track/Artist/Album/etc in addition to the Artist/Track Name of the next five items in Playing Now.  This has been working beautifully for the few weeks of testing.  I can move a track up/down in the "Next Up" list, remove tracks, add tracks into the "Next Up" list (queue) all from this interface.  All works great.... except one minor tiny part...

The current way I am retrivieving cover art to display is through the library server, executing a simple http request like this:

http://libraryserver/GetArt?Key=XXXXXX

Now, this does return applicable cover art... well, sometimes.  Realize that I am displaying cover art for the actual track now playing, in addition to the next five in the now playing playlist.  When the interface receives an XML update to any of the tracks displayed (either cause of a track change or rearrange or whatever), it updates the cover art appropriately.

Here is the problem I'm experiencing...

If my interface makes a request for all (in this case six) pieces of cover art at the same time (which usually happens after a complete playlist change), MC responds back with most of the six correctly, however some are sometimes either one of two things...

1) Completely Broken -- i.e. the JPG is only partially sent, so the covert art just stops at some point and rest of the square is just gray... or (even more strange)...
2) Sends Completely Wrong Cover Art -- This one is funky because it's not just a random piece of cover art... instead, it is actually cover art for one of the other tracks that was requested.

Take this example, where my interface all the sudden needs cover art for track A,B,C,D,E,F.  If all of these are requested at once, MC might respond like this (just an example):

A
B
C (Broken JPG)
A (Notice I needed art for track D, but MC gave me art for A again for some reason).
E
F

I know this is so trival, but I've tested it many times, and even sniffed the actual packets and that is exactly what MC is responding with, even though the requests are valid (and even MC's library server shows the correct requests for the appropriate art in it's log).  Also please note, that as a track changes, so that everything is essentially just shifting up one (so, say a new track will appear under F), my interface only requests this newest piece of art and MC always responds correctly and continues to from that point on.  Like I said, it's only when all these requests hit the library server at once.  It's almost as if the library server gets a little confused about which piece of art is actually supposed to deliver, sometimes even mid-stream (delivery).

Anywho, I know the library server was probably never supposed to be used this way, but, hey... it works, sorta... :-)  I can probably find some kind of work-around, like dumping all the cover art back out somewhere, but I like keeping things neat and tidy.

This is just what you guys get for giving us a product that is so ** flexible...    Love me some MC!

[John Gateley]

When you sniff the packets: are the requests pipelined? Or are they in separate TCP connections?

j

[Matt]

I'm guessing the automation functions for getting art are using a non-thread safe intermediate file.  If you hit it from multiple threads at once, each thread probably overwrites the same filename.

So it may be as simple as us making sure we use a thread-safe filename for temporary files in this case.  We'll take a look tomorrow.

[TreeFrog77]

Well, as far as the library server is concerned, it is just getting six requests for cover art through HTTP.  That is really separate from the MC automation interface that was used to deliver the keys to my flash program initially.  There is actually no MC client connected to the library server (unless I might have one open on another PC at the time, but not typical since the server is actually playing the music throughout the house).

I went down the path of exploring using the automation interface directly for retrieving the cover art somehow and channeling the response through the XML feed directly, but I'm just now really getting any experience with Flex (my old interface was written directly in flash), so the thought of doing it that kinda blew my mind at the moment, so just thought to go the easy way and "fake" a client through MC library server and grab cover art that way.  In addition, I'm trying to keep this polled-quasi-delta XML feed as "light" and fast as possible and let whatever clients are connected take care of themselves as far as their GUIs (in this case, covert art JPGs).

If I have a few minutes tomorrow, I'll see how the requests are being sent.  My initial guess is that they are completely separate simple tcp http requests, but I could be wrong.

You guys are the best.

PS... my flash interface has been on all day with MC playing the same playlist and it's returned covert art every time just fine... except the initial start of the playlist, when it requested all six.  And that was even with me directly in MC cleaning up and adding new cover art all the while....   

[John Gateley]

It could also be pipelining - Library Server does support this, and it may be a bug that only shows up when you get multiple requests before any responses have been sent. Let me know what the sniff says.

j

[Mr ChriZ]

This sounds like the bug that I pointed out ages ago.
You were going to look into it John, involving
the SDK.

http://yabb.jriver.com/interact/index.php?topic=40975.0

[cncb]

Interesting.  Can the library server be used to get other library data via http/XML (e.g. GetViewShemes, GetPlayingNow, Search, etc.)?

[TreeFrog77]

Okay, I think I've compiled some additional detail that may help.  I have attached (below) a simplified view of the sniff capture, MC library logs, and what was actually returned (what the pictures actually where).  To keep this simple (and go with my example originally), I have replaced the parts of the query string where MC's key would be with a letter, in addition to the corresponding filename in MC library server logs.  In the sniff capture, I also noted which stream each entry applied to (for the request, then the HTTP complete).

* Please note that each of the six requests for cover art were on separate ports on the client, so these were all sent in parallel (so, like, the request for A the client port was, say, 2270, the request for B, the client port was 2271, and so on).

** Also note that it looks like the entire time from the first request to the completion of the last JPG being delivered was only a little over 3/10 of a second.

Network Capture:
0.000566   A   GET /GetArt?Key=A HTTP/1.1
0.001162   B   GET /GetArt?Key=B HTTP/1.1
0.002814   C   GET /GetArt?Key=C HTTP/1.1
0.018489   D   GET /GetArt?Key=D HTTP/1.1
0.085461   A   HTTP/1.1 200 OK (JPEG JFIF image)
0.086866   E   GET /GetArt?Key=E HTTP/1.1
0.212758   B   HTTP/1.1 200 OK (JPEG JFIF image)
0.227762   C   HTTP/1.1 200 OK (JPEG JFIF image)
0.236566   D   HTTP/1.1 200 OK (JPEG JFIF image)
0.241119   F   GET /GetArt?Key=F HTTP/1.1
0.300603   E   HTTP/1.1 200 OK (JPEG JFIF image)
0.346579   F   HTTP/1.1 200 OK (JPEG JFIF image)


MC Library Server Log:
11/01/07 13:33:06 - Received request for cover art: A.mp3
11/01/07 13:33:06 - Received request for cover art: B.mp3
11/01/07 13:33:06 - Received request for cover art: C.mp3
11/01/07 13:33:06 - Received request for cover art: D.mp3
11/01/07 13:33:06 - Received request for cover art: E.mp3
11/01/07 13:33:06 - Received request for cover art: F.mp3


Result:
Requested A   Got Cover Art for A   CORRECT
Requested B   Got Cover Art for D   Corrupted (Partial JPEG Received)
Requested C   Got Cover Art for D   Corrupted (Partial JPEG Received)
Requested D   Got Cover Art for D   CORRECT
Requested E   Got Cover Art for E   CORRECT
Requested F   Got Cover Art for F   CORRECT


A note about the "corrupted" thing... understand that was just the way it was this time.  When my client gets back incorrect cover art, it is not always corrupted.  Sometimes it actually full gets delivered (or appears to be), just the wrong piece of art.

That's about everything I can think of.  I hope that helps you guys figure out where MC is getting confused.  Just to make sure, I manually did the HTTP query for each of these individually to MC and MC returned the cover art for all correctly.  I'm sure this really isn't a problem when the library server is being used as intended (by an official software instance of MC), as it would be rare to have, say, six clients all request cover art at the same time, but I would think it could potentially happen.

[TreeFrog77]

Interesting.  Can the library server be used to get other library data via http/XML (e.g. GetViewShemes, GetPlayingNow, Search, etc.)?

I'm really not sure... I'm just using it to grab cover art the same way an instance of a MC client would.  The XML feed I was referring to I developed myself and is served through a different conduit.

I think there is already a discussion about using the web server for other things here:
http://yabb.jriver.com/interact/index.php?topic=34916.0

[JimH]

Ron's license question was split and moved here:
http://yabb.jriver.com/interact/index.php?topic=46024.0