Overall, the new JRemote has been behaving pretty well for me. I've been using it a while and saving up my feedback, and now I think I have a good idea of what I'm seeing.
1. Occasional CrashinessI'm not going to go into this much. It crashes a little more often than the older version. Not absurdly crashy or anything though. I'm sure this will improve, and I didn't find any specific reproducible issues.
2. Longer-Running Smartlists/Views Take Multiple Tries to LoadThis is a bit more frustrating. I have a set of Mixes in MCWS that are build on-top-of Play Doctor saved lists. They're nice auto-shuffling "Playlists" that are in the Audio section of MCWS, so that they can be easily accessed. But, they take a little longer than a regular view to load. This delay is VERY slight in Standard and Theater Views on my computer, but is longer over MCWS. In any case, JRemote doesn't load them right. It seems like it just "gives up" too quickly. What happens is:
* I open one of these Views, and JRemote thinks for a bit...
* Around 1/3rd of the time when at home on my LAN, and basically ALL the time when away from home over my WAN, after a second or three it fails. This makes it show up empty.
* If I "close" (navigate away from) and reopen the view once or twice, then it does eventually fill with contents properly.
I assume it is just timing out a little quicker than I'd like. Interestingly, once it loads properly, then I can get new contents instantaneously by simply navigating away from the view and then back into it, as usual. These "refreshes" happen instantly, and don't ever time out. That might just be the result of the fact that the Smartlists these are built upon have a ~shuffle modifier, though. I've never checked all 100 tracks of one to see if they match perfectly aside from order.
But, if I force JRemote to close (or it disconnects/closes naturally) and then re-open the Views in question, they behave the same.
I realize it is probably just a timeout thing, but these lists are essentially the ONLY way my Wife uses JRemote (she loves Play Doctor) and she finds it incredibly frustrating. She just keeps telling me that they don't work (forgetting I showed her patience and to re-open them a few times before) and is annoyed at the new JRemote. Any way we can have a longer timeout? I think just another 2-3 seconds would cover the vast majority of my cases.
Or, even better would be some better messaging and an easier way to refresh it. You can tell the difference easily between a View that is really broken and contains no content and one of these timeout conditions because JRemote shows the "No Content Found" message instantly on any View that is actually broken (MCWS returns results, but really returns zero tracks), and one that timed out thinks about it for a while before giving the No Tracks guess. What is frustrating (to my wife) is that it just says "no tracks", and that you have to remember how to refresh it by going back > forward > back > forward a few times. Clearly, because of how it behaves, JRemote continues to listen for and process the results that come in after it times out (that's why the refresh the view dance eventually works, and the view loads instantly when it does). But, it doesn't fill itself when these results do eventually come in and you
have to do the dance to refresh it. If would be nice if it said something like: "View loading taking longer than expected. Press button to go back, or wait for results."
And then it actually filled in when the results come in automatically (currently, once you get the "No results" it won't refresh the view in JRemote until you close/reopen the view).
Also had a "circle arrow" button next to the "go back" button that manually requests a refresh (reload the whole thing from the Server).
More stuff in my next post.
