glynor, I think I will add this both ways you describe, so JRemote will remember the last zone for each server, but can be overriden by setting a "Use local player as default" or something like that.
That would work for me, so long as it remembers the last zone on a
per-server basis (with the Use Local Player override honored if it is enabled). That does seem to be what you meant, but just to be sure.
Just tried 2.0 for the first time (from home, no remote use yet).
I tried it out fairly extensively today remotely. Worked absolutely brilliantly for music playback, even over 3G. Track changes weren't "gapless" but they were VERY quick and smooth, even when I had somewhat less-than-perfect coverage. It auto-resumes properly when stopped/paused (and resumes correctly when connected to my car stereo).
All in all, very, very, very good. I would say it has exceeded my expectations in most ways (particularly when switching tracks).
I did notice a few things though...
Switching Connections (WiFi/3G):JRemote does seem to get a bit confused when your connection switches from 3G to Wifi (or the reverse). It doesn't throw an error or anything, but it just stops actually Playing anything (no matter how many times you tap the Play button).
I'm just guessing that it happens when you switch from 3G to Wifi and the reverse, honestly. In any case, 2-3 times today as I went in and out of my office, it got "confused" and would no longer play anything. I had to go back and reconnect to the server from the main page to get it to work again (and pick the Zone again). As I just drove around in my car and switched from cell tower to cell tower, though, it worked perfectly.
EDIT: To add a little clarity here... When I was coming into work (so my phone was on 3G), playback kept working as I entered the office. But I noticed that my phone's display never showed the WiFi indicator, and stayed "locked" on 3G. The "current track" kept playing until it was over. But, once it ended, Playback just stopped. I pulled out the phone and hit "Play" again, but nothing happened. The same thing happened when I was listening to something on the way out of the office. When I walked out of WiFi range, it kept playing as long as it could, but then it stopped. Once it stopped, though, you couldn't restart playback without reconnecting to the Server (killing JRemote completely, or going into the Servers list and picking the server and zone again). The UI remained responsive, but nothing "worked" until I reconnected.
That's fine, and I'd expect it to "error" and stop playing (though if you can switch seamlessly, even better) when switching connections. But, when I hit "Play" again to resume playback, it should fix itself. It just seems like it needs a connection sanity check: If the device's IP address changes, it needs to "reconnect" on its own and go back to where it was.
Using iCatcher as an example again... When I'm streaming a Podcast in iCatcher at the office via WiFi, and I walk out to the car (out of WiFi range), it will stop playing when it can't get the Wifi signal anymore. But, I can then pull out the phone and just hit the Play button and it starts back up where it left off. It would, of course, be better to not even have to pull it out and hit Play again (if it just stopped till it could reconnect and rebuffer), but that's a very small "polish" detail, and if it is difficult, it isn't that big of a deal.
Audiobook Playback:The behavior isn't ideal for Audiobook playback. The Track Forward/Back buttons still work as Track Forward/Back buttons. It would be much more convenient if, when an Audiobook (or Podcast too, I suppose), was playing if these would just switch to "Seek buttons". I prefer the "30-seconds-ahead, 10-seconds-back" style behavior, but 30/30 would do. In many cases when I'm listening to an Audiobook, I missed the last sentence or two as my mind wandered, and I need to be able to quickly skip back a few seconds. The Track Forward/Back buttons aren't useful, and using the scrub bar is too fiddly (especially while driving).
My podcast catcher app (iCatcher) does this, and it is nice. It even works with my car stereo's steering wheel "remote" (they properly do the 30-sec skips instead of Next/Prev Track).
I'm not sure if you can "detect" the [Media Sub Type] of the files via the Web API, but if so, it would be nice to handle Audiobooks and Podcasts in this way.
EDIT: I should make it clear, I'm NOT looking for separate 30-second seek buttons (because that would clutter up the UI on the small phone screen). If you can "tell" that the file playing is an Audiobook, just make the Next/Prev Track buttons act as seek buttons instead. If the user really wants to switch tracks/files, they can always just hit the back button to see the track listing again. I find when playing Audiobooks, I never (or very rarely) want to do a "real" Next/Prev Track. But I want to skip backwards a
lot.
Author
Topic: JRemote, a new native iOS remote for JRiver Media Center (Read 301773 times)