UMSPExtra: OSD enhancements for UMSP

[mad_ady]

[mad_ady]

Here are some screenshots from the currently available templates:

1. simple-wall: designed for MSHEETMODE='wall' view, list mode


2. simple-wall-overscan: designed for MSHEETMODE='wall' view, but with margins tweaked for TVs with overscan


3. simple-wall-icons: designed for MSHEETMODE='wall' view, icon mode


4. simple-wall-icons-overscan: designed for MSHEETMODE='wall' view, icon mode, but with margins tweaked for TVs with overscan

[DJArty]

Looking good (general that as an extended MSHEETMODE Wall) , but some IMHO:
1)Main thing its contact with pibos about finalize WDTVExt for 1.05.. Asking many times ..but no news.
2)Many peoples don't like if any USB stick inserted into the WD.. Why exactly WDTVExt need usb folder and not just use /tmp/..... (question to WDTVExt - not this enhancement).
3)(from 2) MSHHETMODE working out of the box - only WEC config flag needed so may be better way integrate main part (with 2-3 temlates) to firmware and only other templates via WDTVExt onscreen menu engine. Or even possibility to use concrete templates with concrete UMSP plugins if author need some special template. For many people hard to understand how to make screen like this via all this steps.
4)Need some config key for automatically turn main screen of UMSP plugins to icon mode as more comfortable. (UMSP 2.0 related)
5)"Back" problem its really problem )
6)What if description need really long? Now its done via many strings.. so need break to some strings to? (may be autoscroll.. ) )
7) ...forgot ...

[mad_ady]

I knew you'd be interested

1. Yes, I agree - support for 1.05 is a must. I'll probably try to contact pibos again once we have a firmware based on 1.06. Presumably WD has fixed a lot of things in this yet unreleased firmware. It might be worth it to port wdtvext to it instead of 1.05. It should be easier to port anyway since it's based on directfb, like 1.05.
2. Historical reason maybe? This question/enhancement should probably be discussed in a different thread (e.g. the plugins could be automatically downloaded like UMSP plugins).
3. I thought about this for a while, but I chose to leave it independent of any MSHEETMODE flag. The reason is because you may enable moviesheets only for Videos (Video -> Media Servers -> UMSP), or you may not have moviesheets enabled at all. I figured I would let the user decide how the display will look. If there is an easier way to integrate it with moviesheets and have everybody happy, I'm up for suggestions... But, despite all the text in my first post, the user just enables the plugin in the OSD, then selects the desired template in WEC, reboots and is good to go.
4. I'm not sure, but I think it gets saved as a variable in /conf. Would have to check a diff between each setting to isolate it, but I'm too lazy. The problem is - if you were to change it from UMSP, you would have to force DMAOSD to re-read it. I'm guessing DMAOSD will ignore it until the next reboot. Contact Markster - I think he did some DMAOSD tweaks that might help.
5. Yes, I know... But saving a long list of history files is not efficient either. I'm guessing most users will go forward anyway.
6. Actually the description is one string. DMAOSD handles the way it is displayed. You can specify the font size and the number of lines in the template, but you can't control it from the UMSP side (maybe the template doesn't display any description at all!). There might be a flag to have it autoscroll - but I doubt it will work on multiline entries. (P.S. One of the reasons I started this project was to be able to read the whole title of an entry without waiting for it to autoscroll. It drove me mad!)
7. It will come to you...

[jomjom79]

Looks promising!

As you im not too enthusiastic about how UMSP`s look today, i mean it is practical and does its job but it looks very simplistic.
I will definitely try this once wdtvext is out for 1.05.

Jomjom79

[mad_ady]

[KAD]

I'll be interested to look at the code you've done up on this,

but just initially, I'm wondering why we don't use WDTVext to force redraw the page,
it doesn't matter what DMAOSD cache's if we redraw the page

edit: if we force redraw, then the page should always use the current xml, not previous

[recliq]

[KAD]

that may be the case, it will be interesting to try

so the other way to do it
would be create variables in onpagecreated to hold the xml data

and on key press updatexmldata, can read the xml data and update the variables
either way, I think this is solvable

[mad_ady]

Wait, we're talking about two different caches
You are referring to the xml/image cache, I am talking about the UPNP cached responses. For instance, in the navigation example above, when the user presses Back on the remote, DMAOSD will no longer make a UPNP request to UMSP to get the Main Page. This is because it has been visited, and DMAOSD renders a cached version of it. If DMAOSD were to make the request again, then UMSP would know what page is visible onscreen and would have the necessary metadata. So, UMSP looses track of what the user is viewing...

I'm not sure how we could "poison" DMAOSD's cache to force it to make requests for every page, but the truth is this cache can be quite big (I was able to go back at least 7 levels without any request to UMSP).