Charmed Quark Systems, Ltd. - Support Forums and Community
Android RIVA Client: taRiva - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forum)
+-- Forum: Third Party Development (https://www.charmedquark.com/vb_forum/forumdisplay.php?fid=8)
+--- Forum: Android Related Products (https://www.charmedquark.com/vb_forum/forumdisplay.php?fid=24)
+--- Thread: Android RIVA Client: taRiva (/showthread.php?tid=6721)



Android RIVA Client: taRiva - Fonceur - 03-04-2011

Tedp Wrote:Is that button only in your templates if so how did you acomplish it
No it's just an option of the media browser, but not enabled by default.


Android RIVA Client: taRiva - Tedp - 03-04-2011

Hmm where? Is it available in the my movies media repository? On the widget? I cant seem to find that option.

tks

Ted


Android RIVA Client: taRiva - batwater - 03-04-2011

Tedp Wrote:Hmm where? Is it available in the my movies media repository? On the widget? I cant seem to find that option.

tks

Ted

Ted,

For example when you add a new Media Repo Image widget you are given a choice of the attribute which includes Large cover art and Small cover art as choices. For the cover art browser you are given a choice to Use Large Image, default is off. In these cases You would select MyMovies as the repository and then set the attributes. Hope this helps.

-Ben


Android RIVA Client: taRiva - sic0048 - 03-04-2011

I think anything router Tomato or DD-WRT would be fine. Obviously there are more bells and whistles available now, but these firmwares are rock solid and provide Pro type capabilities and stability at consumer prices.


Android RIVA Client: taRiva - Bauer83 - 03-07-2011

brianmount Wrote:My experience (with the iPhone version only, admittedly) is that most of the slowness is due to images which are larger than they need to be. Sam Vimes' template routinely sends out 100K or even 400K images that occupy a 20-by-20 pixel square on the screen. That's 400 pixels, or 2K even with no compression. If we were able to get 2K of data instead of 100K, and pipeline the image fetching instead of waiting for one image fetch to complete before requesting the next, we would see a factor of 50 speedup, and everything would be fine, even with old networking hardware. To see if this is the case, I suggest running a test. Make two templates, one with the full-size cover art images, and one with the images scaled down in your favorite paint program so they're only as big as they need to be. Clear the client's cache, and load the two pages to see how long it takes. I suspect that you will see a marked improvement, even without changes to pipeline the image fetches.

With these small devices and slow network speeds, you can't cavalierly pump out full-size cover art to the client, and it seems like many of the CQC components (e.g. the Squeezebox interface) are doing that at the moment.

What is really confusing me about this, and forgive me for not quite understanding programming, is that if I were to use Splashtop to view the IV on my WHS or SqueezePad (to view music where most of my troubles lie) the speed of browsing my music is blazing fast.

Splashtop really confuses me, as for say a roll-out keyboard as part of Jkish's music templates the speed is decent, where as the iPad Riva app slows to a halt and doesn't even roll out. It takes almost 5-10 seconds for the keyboard to suddenly pop up.

I have even went to the point of removing all the cover images off my template, and still found the iPad Riva app to be sluggish and unreliable in comparison to Splashtop.

Please don't take this as an insult to the iPad CQC product, but I am just trying to see if we can get to a solution in which the iPad can become a completely reliable tool for CQC. I think that this would be a big step forward if we could have an iPad app that ran the IV as if it were on a computer. The networking comments just don't ring true to me as I can access the IV via a computer on wireless and have it work flawlessy, or I can use Splashtop and see the same performance.


Android RIVA Client: taRiva - wuench - 03-07-2011

The issues with image speed is due to the way that RIVA delivers the information to the client. While something like splashtop and the RIVA client are delivering basically the same information, they are doing it in different ways. Something like splashtop or RDP just stream the graphics image of an entire window likely with compression.

RIVA transfers images one at a time. This serialization does not allow RIVA to take full advantage of the bandwidth and higher latency (like wireless or cellular) will exaggerate the effect. I have noticed similar issues with the IV over wifi.

So if a trip takes 30ms on wifi (or 300ms on 3G), RIVA needs to make that trip for each image, that delay adds up. Other solutions will do it in one trip or stream it. Wired connections on a LAN are typically less than 1ms so wifi can be more than 30 times slower.

Now if the client caches these images after the first grab, then that should help resolve this. Of course new images won't be cached so they'll be slow the first time. So the only client solution available is to cache as much as possible and hopefully persist that between sessions.

As for animation, like rollouts, I don't think that is really supported under RIVA. That would need to be completely simulated on the client to be effective, not redrawn at every step. It just isn't going to work correctly over anything but wired latency. So RIVA would need to send some animation commands, not the actual image transitions. My recommendation would be not to use those effects. I don't know how things are on the taRIVA client, but on the IPhone there is even a noticeable delay is something like a button press. So animated effects are really not a good idea.

Also realize that things like splashtop and RDP have had several years of development behind them to work though these issues.


Android RIVA Client: taRiva - Bauer83 - 03-07-2011

wuench Wrote:The issues with image speed is due to the way that RIVA delivers the information to the client. While something like splashtop and the RIVA client are delivering basically the same information, they are doing it in different ways. Something like splashtop or RDP just stream the graphics image of an entire window likely with compression.

RIVA transfers images one at a time. This serialization does not allow RIVA to take full advantage of the bandwidth and higher latency (like wireless or cellular) will exaggerate the effect. I have noticed similar issues with the IV over wifi.

So if a trip takes 30ms on wifi (or 300ms on 3G), RIVA needs to make that trip for each image, that delay adds up. Other solutions will do it in one trip or stream it. Wired connections on a LAN are typically less than 1ms so wifi can be more than 30 times slower.

Now if the client caches these images after the first grab, then that should help resolve this. Of course new images won't be cached so they'll be slow the first time. So the only client solution available is to cache as much as possible and hopefully persist that between sessions.

As for animation, like rollouts, I don't think that is really supported under RIVA. That would need to be completely simulated on the client to be effective, not redrawn at every step. It just isn't going to work correctly over anything but wired latency. So RIVA would need to send some animation commands, not the actual image transitions. My recommendation would be not to use those effects. I don't know how things are on the taRIVA client, but on the IPhone there is even a noticeable delay is something like a button press. So animated effects are really not a good idea.

Also realize that things like splashtop and RDP have had several years of development behind them to work though these issues.

Thanks for the reply.

It seems to me some changes would then be needed to better use RIVA compatible tablets as full fledged interface viewers.

As this it the way most of the market is heading, would this not be a good path to start going down? The delays I have noticed as well, and it really creates a lack of polish (for lack of a better term).


Android RIVA Client: taRiva - Dean Roddey - 03-07-2011

It's not practical to try to host our full bore IV on these devices, but we'll continue to improve on the RIVA system. It does quite well on a wired network, but needs more changes to get it more performant on the small wireless systems.


Android RIVA Client: taRiva - AnthonyZ - 03-17-2011

I am struggling to get the RIVA to connect and draw an IV.

Currently using the free version (will upgrade once I see it working).

CQC is 3.4.8. TARiva is .99.

Log entry after attempting to connect is below...

LAUNCHER] flg=0x10200000 cmp=tallus.android.riva/.TARiva bnds=[243,338][317,424] }
03-17 05:09:05.142 D/dalvikvm( 6711): GC freed 1014 objects / 62280 bytes in 106ms
03-17 05:09:05.172 I/TARiva ( 6711): Starting TaRiva version 0.99
03-17 05:09:05.272 I/Panel ( 6711): Surface created
03-17 05:09:05.282 I/Panel ( 6711): Surface changed: 320x480, format: -1
03-17 05:09:05.282 I/Panel ( 6711): Resizing the canvas to 320x480
03-17 05:09:05.282 I/Panel ( 6711): DrawDitMap from Rect(0, 0 - 320, 320) to Rect(0, 80 - 320, 400)
03-17 05:09:05.312 I/ActivityManager( 87): Displayed activity tallus.android.riva/.TARiva: 393 ms (total 393 ms)
03-17 05:09:05.312 W/dalvikvm( 87): disableGcForExternalAlloc: false
03-17 05:09:05.332 I/TARiva ( 6711): Service bound
03-17 05:09:05.372 I/TARiva ( 6711): Selected client = 0
03-17 05:09:05.372 I/TARiva ( 6711): Orientation defined
03-17 05:09:05.502 I/RivaClient( 6711): Index set to 0
03-17 05:09:05.522 I/DisplayInformation( 6711): Discovering Graphical Environment
03-17 05:09:05.522 I/DisplayInformation( 6711): Discovered Screen Resolution: 320 X 480
03-17 05:09:05.522 I/DisplayInformation( 6711): Discovered Bit Depth: 8
03-17 05:09:05.662 D/dalvikvm( 159): GC freed 363 objects / 19392 bytes in 221ms
03-17 05:09:05.732 I/CQCNetwork( 6711): Initiating Connection Operation to Host: 192.168.0.240 on Port 13516
03-17 05:09:05.942 I/NetworkProcessor( 6711): Client connected to server.
03-17 05:09:05.942 I/NetworkProcessor( 6711): Sending Login Request.
03-17 05:09:05.942 I/CQCOut ( 6711): Transmitting Message Header: [Unsigned Byte: 2e, Unsigned Short: 1, Unsigned Short: 12, Unsigned Byte: 65, Unsigned Byte: f1]
03-17 05:09:06.082 I/CQCOut ( 6711): Transmitting Message Body: [Unsigned Byte: 8, Unsigned Short: 6, Unsigned Short: 140, Unsigned Short: 1e0, Unsigned Byte: 0, Unsigned Byte: 2, Unsigned Integer: 5, UTF8 String: Phone]
03-17 05:09:06.092 I/NetworkProcessor( 6711): Sent Login Request.
03-17 05:09:06.092 I/NetworkProcessor( 6711): Processing the challenge.
03-17 05:09:06.102 I/ReceiveHeader( 6711): Header ID = 1, length = 103, code = LOGIN_CHALLENGE
03-17 05:09:06.102 I/System.out( 6711): Error = 1
03-17 05:09:06.102 I/System.out( 6711): Error with the login response
03-17 05:09:06.102 I/CQCOut ( 6711): Transmitting Message Header: [Unsigned Byte: 2e, Unsigned Short: 2, Unsigned Short: 0, Unsigned Byte: 66, Unsigned Byte: f1]
03-17 05:09:06.112 I/CQCOut ( 6711): Transmitting Message Body: []
03-17 05:09:06.122 I/NetworkProcessor( 6711): Challenge processed.
03-17 05:09:06.122 I/NetworkProcessor( 6711): Processing the status.
03-17 05:09:06.132 E/NetworkDispatcher( 6711): Error Connecting to CQC Server: null

It seems that the service can "see" the server but that the user or password isn't processing correctly. I have tried with both user and LoginUser from the CQC Admin, User settings. Neither works.

Any ideas? Am I missing a simple step?


Android RIVA Client: taRiva - Fonceur - 03-17-2011

AnthonyZ Wrote:Any ideas? Am I missing a simple step?
Do you have an initial template associated with the account you are trying to use?