Display Images Associated with WebStreams

[ralphy]

As requested by Ubu, here's some thoughts on what I had in mind for displaying images that may be associated with webstreams.

Attached are some notes and a screen dump, a NineMSNDynSource.exe that requires a modified dynsource.dll, and some extremely crudely modified GBPvrUIElementExmaple.cs (with associated dll and skin) to give an example of how the images might look/work.

NineMSNDynSource will scrape the images and cache them in dynsource\_images\NineMSN. This dysource may not work with UbuStream 2.0/2.1, but is fine standalone.

Haven't managed to get the popup concept working yet, sinceC# knowledge is next to zero. :o

Oh, I just remembered, you'll need to have a file c:\temp\a.jpg for this crude prototype.

Over to you Ubu!

[ubu]

As requested by Ubu, here's some thoughts on what I had in mind for displaying images that may be associated with webstreams.

Hi ralphy,

I've read your document and your supporting comments but I haven't had a chance to test your prototype yet. Hopefully, I'll get to it tomorrow.

Initial thoughts: your approach is similar to what I had in mind but with some minor differences. Firstly, I think you are looking at this with a slight bias towards DynSource app usage. I think supporting image display for stations (and maybe groups) should be a global solution that will work for all kinds of UbuStream configurations, with Dynamic Source apps perhaps being a likely contender to get the most use out of the feature.

Given that the average station database is likely to have some stations with available images and some without, I'm not so keen on displaying them for every station in the list (as in your screen print). This could look kinda messy if there's a mix if stations with and without images on a single screen. There's also the real estate issue. I like to display as many stations as possible on a single screen to minimize having to scroll the list. For MVP users this is a very real issue since the response time on PgUp/Down and Scroll Up/Down button presses can be very sluggish.

However, I do really like your idea of a context sensitive pop-up effect that would display the station description and image, if available, when the station is highlighted in the list. This would be a variant on your design and would simply involve creating a custom SelectedItemImage definition (with room for extra text and a picture) in the skin file, while leaving the UnselectedItemImage as it is today. How this would impact response time when moving the selector up and down a list I'm not sure, but it would certainly look cool and it wouldn't "steal" real estate from the screen.

Another issue is the storage of the images. I had initially imagined simply storing the URI of the images (especially in the DynSource case). It looks like you were thinking the same thing at first (you named the new PLX file field URI=, for instance) but then switched to the notion of actually downloading the images to disk. This would most likely provide better run-time display speed but could also eat up a tidy piece of storage if people had a lot of stations or were running many DynSource apps.

If UbuStream is supposed to be providing an image solution for all stations than it should probably manage the image storage globally rather than have each DynSource app manage its own storage. That would include things like image creation/deletion, image rendering, etc. Then it could encompass non-DynSource image sources for the rest of the stations.

If the DynSource app would simply pass the URI of the image in the PLX file then UbuStream could have control over what to do with it, either storing the URI for future use or downloading the image to local storage, as part of a wider image management scheme. (Opens up possiblities such as maybe giving the user the option of whether to cache images or to retrieve them at run time).

So, for similar reasons, I would favour storing the images in a folder hanging off the plugins\UbuStream directory (perhaps with subfolders organized by group) rather than off the DynSource directory (with sub-folders for each DynSource).

For non-DynSource stations, this is going to be a bit like image support in the GB-PVR TV-Guide. You can set it up to use both station and program images but you have to provide the images yourself. I went through the whole production of downloading a zillion images and then setting up Tv_Guide to use them, only to find that I didn't like the way it looked, so I removed them. But other people, I know, really love that feature. So I think it'll be the same with UbuStream. Some people will spend a lot of time setting up images for each station (and group?) and others will simply not be bothered to spend the time, preferring to find new and interesting streams instead.

To implement all this is definitely going to require database changes (which usually gets ugly :eek: ) so we're talking the v2.2 release here. I really want to get v2.1 out of the door and give it a chance to stabilize a bit before I start any major surgery required for the next release.

Another idea I've been mulling over is whether to develop a completely separate UI (maybe a separate plugin) just for DynSource streams. This would be pitched at the lazy user who can't be arsed to set up stations using UbuStream but wouldn't mind watching some canned video streams if they were just a button press away. I developed UbuRadio for similar reasons. (I realize that, strange as it may seem, some people don't view scanning the web for new streams and searching through HTML for likely media URLs as "entertainment" ). This would lend itself better to your current screen design (with an image for every item) since DynSource apps are likely to be able to provide an image for each stream. However, this does assume that all DynSource authors would be prepared to re-work their code to add image URI retrieval.

I'll take a look at your prototype ASAP. When are you going to release the finished NineMSNDynSource app? Will I like it? Is the video as high quality as the OzABC streams?

[ralphy]

Firstly, I think you are looking at this with a slight bias towards DynSource app usage.

I think you're being kind by saying slight bias

Another issue is the storage of the images. I had initially imagined simply storing the URI of the images (especially in the DynSource case). It looks like you were thinking the same thing at first (you named the new PLX file field URI=, for instance) but then switched to the notion of actually downloading the images to disk. This would most likely provide better run-time display speed but could also eat up a tidy piece of storage if people had a lot of stations or were running many DynSource apps.

I figured the plx file would save the URI, but that this would be converted to the name of the stored file in the xml. Run time was the driver here, not file size. I think that the stored images size would be trivial compare to a video recording file size, but on small systems, every byte might count. I'd still go for the speed every time and buy more disk if I needed to. Internet connections can be a bit slow sometimes.

If UbuStream is supposed to be providing an image solution for all stations than it should probably manage the image storage globally rather than have each DynSource app manage its own storage. That would include things like image creation/deletion, image rendering, etc. Then it could encompass non-DynSource image sources for the rest of the stations.

This is why I used the URI in the plx file. UbuStream would read this and decide what to do with the file as it generates the xml. I had to use the dynsource app to do this for the prototype.

When are you going to release the finished NineMSNDynSource app? Will I like it? Is the video as high quality as the OzABC streams?

The NineMSNDynsource.exe included with the prototype will work (except it need the dynsource.dll mods). So you'll get to see them when you get around to looking at the prototype. Quality is quite good. (The prototype really doesn't do very much - I think you've got a good idea from the screen shot and the plx file as to how it might work.)

Thanks Ubu for your well considered response.