Print

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

[Matt]

This is the latest version of Gizmo (JRiver's Android application).  Please post bugs here.  Please start a new thread for anything requiring discussion.  Non-bug posts will be deleted.

Download: http://jriver.com/install_gizmo.html

The build will move to the Play Store at a later date, after testing here.

19.0.41 / 80

NEW: Repeat mode is optional (in Menu > Options > Repeat mode).
Fixed: The list of zones would not appear with build 40.

19.0.40 / 79

Changed: Gizmo uses the mime type application/octet-stream for audio file transfers to avoid ISP or carrier blocking (requires MC 19.0.39 or newer).

19.0.39 / 78

NEW: Added lock screen controls while playing on the device.
NEW: Bluetooth track information is provided when playing on the device (using AVRCP).
NEW: Bluetooth controls work while the screen is off.
Fixed: Web radio streams that were stored in the library or playlists were not playable on the device.  
Faster: When clicking the header to switch modes while connected to a dead server, the menu of choices will appear much faster.
Fixed: In some cases 'Error communicating with server' could show incorrectly on the screen.

19.0.38 / 77 (September 12, 2013)

1. Fixed: The cache downloader could crash in some cases.

19.0.35 / 76 (September 4, 2013)

1. NEW: Added thumbnail size option (menu button at top right > Options).
2. NEW: Added a screen lock option to keep the screen on (dim or bright) while Gizmo is showing (useful for tablet installations).
3. Changed: The volume up and down commands work when playing on the device (for cases when there are no hardware volume buttons).
4. Changed: Bluetooth play and pause commands will trigger the play/pause button (for devices without a play/pause button).
5. Changed: Stopping playback stops the read-ahead caching system from working ahead.
6. Fixed: Playback stats are fired when playback starts instead of when the cache reads-ahead for a file (requires MC 19.0.35 or newer).
7. Fixed: When playing a video, playback would sit at a black screen instead of return to the browse screen in 19.0.32.

19.0.32 / 75 (August 28, 2013)

NEW: Added the ability to 'Play (with Play Doctor)' from anywhere in the audio browse tree.
NEW: When a server call fails, the program will retry a few times.
NEW: The program will attempt to automatically switch the server IP address as it transitions from wifi to data.
NEW: File playback caching uses ranged requests so an interrupted download is resumed instead of restarted.
Faster: When there is no wifi or ethernet, connecting to a server will skip local addresses.
Changed: Audio playback loops the playlist until stopped (unless the playlist is only one track).
Changed: Added a system so that partial cache entries (from a crash or other problem) will never get used.

19.0.31 / 74

NEW: Improved cache system so that the playback of the first file also plays from cache (but playback still starts immediately).

19.0.30 / 73

NEW: Playback on device uses a caching system that reads-ahead and keeps files between runs, increasing reliability with weak connections.
Faster: Browsing switches screens faster.
Faster: Android 4 devices load thumbnails concurrently for improved performance.
Faster: When connected to MC19, thumbnails load faster.  

18.0.180 / 72

Changed: Errors communicating with the server show an information bubble, but don't cause the program to automatically reconnect to the server.
Changed: When acting as a remote, an error communicating with the server to get information about what's playing will look more transparent.
Changed: When playing on the device, the program will retry for up to 10 minutes to open the URL to better handle sporadic connections.

18.0.171 / 71

NEW: Totally revised Theater View remote mode.
Changed: Requires Android 2.2 or newer.
Changed: Switched to newer more efficient networking API.
Changed: Connecting will wait less time waiting for each IP address, but will retry more times (should reduce connect time in many cases).
Changed: Tuned the default timeout for web service calls to wait a little longer (should help prevent reconnects with spotty coverage).

18.0.126 / 67

NEW: It is possible to connect using an IP address.

[InsaneRC]

Sweet works.

[MGD_King]

19.0.39 / 78
Fixed: In some cases 'Error communicating with server' could show incorrectly on the screen.

This is still happening on my device (Samsung Galaxy S4). It happens when I play a track that doesn't have a thumbnail image.

And I still cannot view videos with this build.

19.0.41 / 80

NEW: Repeat mode is optional (in Menu > Options > Repeat mode).

THANK YOU!!!!

[kensn]

Thanks for rezoning my zones and not zoning out....

[forbigd]

Yes, Play to... is fixed, thanks. But still no video in Gizmo for my S4.
It plays one, maybe two frames and quits back to the menu.

Don

[Matt]

Yes, Play to... is fixed, thanks. But still no video in Gizmo for my S4.

Did it ever work?

We've seen some Android devices that just don't support video nicely, and we could never figure out a workaround.

[MGD_King]

Did it ever work?

We've seen some Android devices that just don't support video nicely, and we could never figure out a workaround.

It worked on my Motorola Droid X, but to be honest, I never tried it here on my Galaxy S4 until I began testing the latest builds that were starting to come out.

[forbigd]

I was sure it worked on 18 with S4. Right now it doesn't work with 18 and S4. And I know it worked on my S3. It was a friend who just got his S4 complaining was when I first knew it didn't work, so I can't say for sure it worked with 19 on my S4. I use the "Play to" feature a lot, and it works fine on the S4.

The S4 on 19 plays a frame (you can see it) and goes back to the menu

In my test with 18 and the S4; it doesn't play a frame, it goes black and stays black. touching the screen shows a timeline with the video paused.

If the S4 sells as hot as the S3, there will be a few out there. I am no expert but a quick look showed 50 million S3 sold and 20 million S4s so far. If I can help try to fix it let me know. Honestly it is my buddy who wants the Video over Gizmo for his slow work. I don't really need the feature, but would be glad to help.


Android devices that just don't support video nicely
The Samsung is very good at it. It is very fast and has no problems rendering 1080p video.

Don

[chrisxyz]

First of all: Thank you very much for improving Gizmo!

* I have similar problems playing video on:
Sony Xperia Tablet lte (Android 4.2.2): preparing needs a lot of time, then it seems also to play only a frame and goes back
Samsung Galaxy Tab (Android 2.3.6): preparing needs also a lot of time, then it goes simply black
Unfortunately I do not know if it worked before.

* Sometimes I still get the  'Error communicating with server' message, but it seems that there is no problem.
* Viewing photos on both tabs ("playing here"): Everything is very fast, but touching the screen always moves to the next photo. Is there a possibility to move back?
* Using Gizmo as a media center remote: A very big improvement, very good and fast! Thank you!
* Thumbnails: Thumbs load faster than before, but it still needs a lot of time. Music now is cached, caching of thumbs would be great!
* More text (two lines) under thumbnails using small thumbs: I like it very much (more information is seen)! Could you also implement this feature for bigger thumbs? Maybe also with options for different font size? (I would decrease font size in order to see more information)

Chrisxyz

[forbigd]

Agreed, thanks for all your hard work, it is really cool.

Plus one for the longer names in gizmo.
Or a list mode so I can see the whole title.
"How I Met Your Mot...." Doesn't give me much detail.
They all are named that.

Don

[ShirazD]

Following these developments very closely. thanks Matt!

[stelfe]

Thank you very much for all these improvements, especially optional repeat mode!! 

[marko]

I'll quote comments I made about non-persistance of playing now and my bandwidth usage here too....

Sometimes, after eight or nine hours, I launch Gizmo and it has remembered the playing now list, sometimes it doesn't. I really wish that it would do so reliably, all the time.

With the read ahead cache, this is more important for me than ever now. Why? Because I predominantly use a random smartlist that picks me a selection of 60 tracks rated 4 or 5 that have not been played in the past seven days.
When I get home and press 'stop', there are 10 tracks downloaded, ready to play, so later, when returning to Gizmo, I should be good to carry on from there.
When playing now has been discarded, the chances of the new smartlist tracks being in the cache are slim to none, which is a waste.

I have an unlimited data plan with, allegedly, no 'fair use' policy attached, but even so, my usage would typically be around 2.5Gb/m and this month, I've already hit 3.5Gb and there's still 10 days to go yet!

Fixing the playing now issue would bring this figure down drastically.

-marko.

[connersw]

I am curious about this bandwidth issue as well.  Streaming Gizmo on my morning drive, my data usage was ~9MB.  After updating to MC19 (from MC17) and the newest Gizmo, my morning drive data usage jumped to ~60MB.  Unfortunately, I do not have an unlimited data plan, so streaming over 4G is now out of the question for me.  This was one of my main reasons in using Gizmo.  Is this related to the new cache?

[Matt]

I am curious about this bandwidth issue as well.  Streaming Gizmo on my morning drive, my data usage was ~9MB.  After updating to MC19 (from MC17) and the newest Gizmo, my morning drive data usage jumped to ~60MB.  Unfortunately, I do not have an unlimited data plan, so streaming over 4G is now out of the question for me.  This was one of my main reasons in using Gizmo.  Is this related to the new cache?

Gizmo reads ahead up to 10 files and keeps a cache.  This way, it works much better with a spotty connection since it works ahead when data is available and keeps playing when data is not available.

If you often play the same thing, it should use less total bandwidth this way once the cache has more in it.

[connersw]

Thanks Matt; however, I rarely listen to the same thing.  In fact, I go out of my way not too, so this feature is having the opposite effect. 

I read in another thread that there was discussion about making it optional (or at least limited); I hope that becomes the case because it is not working as intended.  I also read that it may not actually be capping correctly which could be compounding the problem.

[lepa]

Is there something you can do with subtitles synch when skipping onwards/backwards in the timeline? Subs always seem to start from the begin in such case.

[lepa]

Is there something you can do with subtitles synch when skipping onwards/backwards in the timeline? Subs always seem to start from the begin in such case.

Problem only seems to occur if subs are not embedded