[herrnst]

First thing I noticed was that the brackets around the progressbar were gone. LCD/VFD uses brackets without the <progressbarsurroundings>on</progressbarsurroundings> tag. Than I notices that the this progressbar was much better - it shows the progress pixel by pixel. I started testing everything again but found a few new problems:

Well, that option and it's behaviour is wanted by some users, that's why it's there ;-) (could probably be moved to the GUI settings, though).

1. "LCD.PlayIcon" works but a "LCD.ProgressBar" in a line below does not work. If you use "LCD.ProgressBar" in a line befor "LCD.PlayIcon" everything is fine (does not have to be the first line when using a 4 line display).

Honestly I don't have a clue why this happens especially on RPi, I also don't have any such hardware at hands to test and/or reproduce (nor even fix) the problem. As I understand: It doesn't matter where the PlayIcon thingy and the following ProgressBar is placed. If the PlayIcon is placed _somewhere_ above the ProgressBar (e.g. Icon at Line 1, Bar at 4), the bar disappears. Is that right?

2. I have a 20x4 HD44780 display and "LCD.TimeWide21" and "LCD.TimeWide22" (and "LCD.Time21" and "LCD.Time22") always show a fullscreen clock using all 4 lines.

This is intended. script.xbmc.lcdproc doesn't draw any special text chars from the ROM charset (like "Has LCD/VFD" does). Rather, it utilises LCDproc's "num" widgets so that LCDproc takes care of putting the digits onto the display (it can do it best and automatically as it obviously knows best how to drive the attached display). This greatly improves compatibility with all sorts of display hardware regarding the bigdigit display (rather than having only garbage on non-HD44780 character rom displays). The (rather little) draw-back is that LCDproc "num"'s can't be mixed with something else.

3. I use the progressbar for video-playback. When I pause a film XBMC will start the screensaver after a few minutes and the display is configured to show the big clock in screensaver mode. Now only houres and minutes are shown and it is frozen (shows only the time the screensaver started). I understand why a big clock and the progressbar can't be used at the same time (in different lines) but here it switches from showing a film with progressbar to only showing a clock and nothing more. I think it is a bug.

Reproducable. From two text lines in <video> via pressing pause to the screensaver kicking in, it shows the (paused) playback time as big digits. Might need to take a look at the "isscreensaveractive+isplayingvideo" determination logic.

4. In some submenus the display gets darker. I still have to check if it is always the same menu or menu-level but right now I am not at home. All I can say right now is, that in some menus the display gets darker and going up a menu-level makes it brighter again. This never happened with LCD/VFD.

Now THAT one sounds extra-strange. Especially since a LCDproc client simply just can not - in no documented way - dim the display backlight "just a little". Backlight control from within a LCDproc client is binary - on or off (if interested, see the LCDproc dev guide regarding "screen_set -backlight").

Update:
I did some testing and I can reproduce the problem (only tested it with Confluence skin):
When I go to "System"->"Settings" and then to anything but "Add-ons" (because this menu looks different) I get to a menu with main options on the left and all the parameters on the right. When I go to the parameters on the right, the letters on the LCD get darker and it stays like this even when the navigation-screen changes to the general-screen and even the big clock of the screensaver-screen is darker (less contrast). As soon as I go back to the left side everything thing is back to normal.
I also found one other way to dim the letters (lower the contrast): When I go to "Videos" and thumbnail-view is active the letters get darker when I reach the most right thumbnail. Here the letters stay dark (even when I go to the left again) until I click a thumbnail or go back to the main menu.
Do you need pictures or can you understand what I try to say?

A video showing the XBMC screen and the display when toggling that effect would be very interesting. However (see above), I don't have a clue what could cause this or even be fixed (would really need such hardware to reproduce). Also, this is the first time I get a report of such an issue. Are you sure this ain't some sort of power issue?

Please excuse my poor english. It is not my mother tongue.

Interpolating from your forum nick: "Kein Problem, alles gut" ;-)

Regards,
nst