Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official RIVA thread
brianmount Wrote:Also, the image files that templates ask me to draw are almost always many multiples of the size they really need to be.
I seem to remember the images already pre-scaled to multiple of 16 or so, at least for the Media browser when used in "small images" mode... Which is where most of those multiple images from bigger ones would happen... And I think Dean expanded the logic to the selected item from that Media browser.
Field Generator 0.65: Create CQC fields on the fly, from external applications.
Mobile templates 0.4: Main resolution of 320x480 with navigation side bars (384x544).
Sage Media Server 1.1.3 + Sage Player 2.7.8: Display and manipulate SageTV information or player.
TaRIVA 1.26: Android RIVA client.
Reply
Pehaps Commander Vimes can chime in on what he's using now. It's true that I used to get nice small media images for movie thumbnails. But now, due to whatever template he's using, I wind up getting Web image widgets that are very large. Maybe whatever produces those doesn't have the automatic scaling feature.
Reply
The CAB has a setting for large or small cover art. He may have it set to large and just needs to put it back to small. The Media Image widget also has a similar setting.
Dean Roddey
Explorans limites defectum
Reply
Web image widgets don't have a scaling option. That's only on the CAB.
Reply
Oh, so you are using the Sage thing or something like that? If so, it'll have to provide some sort of means to request small vs. large art.
Dean Roddey
Explorans limites defectum
Reply
It's the SqueezeServer driver. The author suggests centralizing/reusing the existing scaling functionality, since many drivers might want to use it...
Reply
So to move some general discussion over to here...

We have the issue of the RIVA clients and the fact that they only stay connected to the network for so long then they go to sleep. That drops the connection and the RIVA server drops the associated session. When the RIVA client wakes back up, it has to reconnect and it's back to the base template again.

This obviously isn't going to be acceptable long term, so something needs to be done. I made a suggestion which I think will deal with that cleanly, and it will dovetail nicely with the upcoming requirement to start enforcing the client counts and such. The idea is that the RIVA server will be explicitly configured to always be running some number of sessions.

The benefit is that it's always there. There's no need to crank it up with the RIVA client connects, and if the RIVA client drops the connection, the RIVA session on the server just stays where it is. When a RIVA client connects, the server just forces a screen redraw to make sure that the client is up to date, and that's it.

There are certain gotchas of course, since nothing is free. It does mean that you can't drive what's displayed based on the template configured in the user account that you use to log in. That will be part of the RIVA server configuration. As long as the RIVA client logs in under an account that is of sufficient privilege to run the base template (remember each template has a minimum privs level), then it will be allowed to connect to that already running session.

It also means that you cannot use environmental variables on the RIVA client to drive RTVs on the session, since the session is already running. So you would have to configure those environment RTVs as part of the RIVA server configuration when you set up each session.

There will stil be a one to one relationship. I.e. only one RIVA client at a time can connect to any given session. I'm assuming that the sessions will be named and you'll use the name in the login request to indicate which one you want to attach to. If it's alread in use, the login will be rejected as already in use.

There's no need to have any sort of 'session id' because the configured (and persistent) name will effectively provide that. It doesn't matter if the RIVA server goes down and comes back up while the RIVA client is asleep. The RIVA client will make no assumptions about what has happened while it is gone. When it connects, the RIVA server will force a redraw of the whole template, which will effectively make the RIVA client get back into sync with the state of the state and any images and so forth.

And of course since you are explicitly configuring all RIVA sessions, then we know how many client licenses are to be allocated to RIVA clients. This does though mean that those client licenses are always in use. Just because no client is currently connected, the session is always running, and will eat up a license slot. The payoff is that have quick reconnection and can pick right back up where you were before. And also you avoid any wierdness that would inevitably come with trying to dynamically allocate client slots based on what is actually connected at the time. It would be quite difficult to do in such a distributed system. For the pro folks that means that, though perhaps a somewhat higher cost, much more reliability and consistency.

The same sort of configuration may be done for IV clients as well. Not that they would all be pre-running sessions like with RIVA, but configuring which hosts you want to allow to connect as IV clients. Though it makes for a less dynamically configured system, it does provide some security benefits and centralized system configuration where it can be completely backed up and restored and again makes for a very comprehensible allocation of client license slots that is simple and easy to understand.


So, anyway, that's my suggestion. How does everyone feel about that?
Dean Roddey
Explorans limites defectum
Reply
Was there ever a decision made on passing web widget information over to the client. This way if I device is able to support it web widgets could be used. I am pretty sure that the iOS SDK allows you to embed web windows in apps
Reply
potts.mike Wrote:Was there ever a decision made on passing web widget information over to the client. This way if I device is able to support it web widgets could be used. I am pretty sure that the iOS SDK allows you to embed web windows in apps

That's not something immediately planned. We'd put any RIVA time for now into just making more basic improvements/changes, such as discussed above I'd imagine.
Dean Roddey
Explorans limites defectum
Reply
For what it's worth, I like and support the direction above.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Html 5 Riva potts.mike 9 14,203 09-15-2013, 04:22 AM
Last Post: bjkiller
  Thinking about the next step in RIVA Dean Roddey 6 11,337 01-22-2013, 06:15 AM
Last Post: brianmount
  .Net RIVA Client Dean Roddey 146 122,654 02-06-2012, 06:53 PM
Last Post: Dean Roddey
  Transparent images in RIVA? SamVimes2 36 49,730 02-05-2011, 04:34 PM
Last Post: Dean Roddey
  riva burkepaol4 1 8,492 12-17-2010, 11:39 AM
Last Post: Dean Roddey
  Riva screen blanker on CF.NET froop 3 8,383 08-06-2010, 10:34 PM
Last Post: froop
  RIVA Connection batwater 6 9,063 07-16-2010, 04:46 PM
Last Post: batwater
  Java based RIVA Client? batwater 10 13,401 04-03-2010, 05:35 AM
Last Post: wuench
  RIVA Client for Linux bryanb 22 21,042 07-16-2009, 09:11 PM
Last Post: bjkiller

Forum Jump:


Users browsing this thread: 1 Guest(s)