[herrnst]

i got

Code:

<tvshow>
<line>$INFO[LCD.TimeWide22]</line>
    </tvshow>

in my config. it shows again a half part of the Digit. The first liine is empty and on the second line there is a half digit display.
i also noticed the it does the same in the screensaver mode. only half of the digits

As I suspected. Please disable XBMC's internal LCD support before installing script.xbmc.lcdproc.

[Rorwin]

i disabled the internal support, deinstalled script,xbcm.lcdproc and reintalled it.
the result is still the same.

[herrnst]

Strange. Can you get me a debug log from a XBMC session where you trigger the effect?

[Rorwin]

i greped the LCDroc Messages of the xbmc.log file.

here is the the Link

[herrnst]

That stripped-down version doesn't help. Looking at the (remaining) path names in the log, you're running OpenELEC. If this is on Raspberry Pi: Someone in this thread had problems displaying certain stuff (widgets) in the bottom line of his HD44780, maybe LCDproc is hitting some generic problem on RPi here (the connector can possibly be ruled out, as mdm166a connects via USB AFAIK). If that's the case, the problem needs to be fixed inside LCDproc - script.xbmc.lcdproc cannot do anything regarding this.

nst

[Rorwin]

Ok thank you for your help.

[Cyberdyne_de]

@ALL: Did anyone else also experience such problems especially with HD44780-type displays?

I have the same problem!

I use this OpenELEC testbuild (XBMC Frodo 12.3):
http://forum.xbmc.org/showthread.php?tid...pid1604096
and I have a 20x4 HD44780 LCD display connected via GPIO and use XBMC LCDproc v2.3.2.

The tutorial I used to activate my display told me to switch on the build in LCD/VFD support and to deactivate the LCDproc-Plugin. So I first tried LCD/VFD but "LCD.PlayIcon", "LCD.TimeWide21", "LCD.TimeWide22", "LCD.Time41", ... and "LCD.AlignCenter" did not work at all. I didn't check everything but all the rest that I had tested worked inkluding the "LCD.ProgressBar". But this "LCD.ProgressBar" only used full blocks - every 5% an other full block was displayed. The bigest problem for me was, that LCD/VFD does not use the "TV-Show" section in lcd.xml.
So I deactivated LCD/VFD and gave XBMC LCDproc a chance:
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:

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).

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.

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.

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.
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 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?

Do you want me to test something or do you need more info about something? I will do my best to help!

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

[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

[Cyberdyne_de]

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).

I didn't know about the option till I found this thread. I realy like it but as a GUI setting it might be easier to find?! ;o)

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.

I do have some more HD44780 displays and I could make you a cabel with poti and GPIO connector but I only have one RPi and that is in daily use. Let me know if you need the LCD.

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?

No, it's the other way round! First the ProgressBar and below the PlayIcon works.
I don't realy care because I don't like the PlayIcan and I don't use it. I just wanted to let you know that there are more people with that problem and it might be a bug. As I said: I don't care but I would help with testing if you want to track down the problem. My first guess would be that is is the HD44780 display-driver for the RPi but I could be wrong like with the low-contrast problem - I will come to that later. ;o)

This is intended. script.xbmc.lcdproc doesn't draw any special text chars from the ROM charset (like "Has LCD/VFD" does).

It's strange that "LCD.Time2x" and "LCD.TimeWide2x" and so on didn't work at all when I used the build in LCD/VFD. Is it an RPi only problem? Again: Driver problem?

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.

Ahhhh! Now I understand why! Didn't know that the big clock is a LCDproc build in feature.

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.

Updated:
Four text lines not two but yes, your are right! I now tested pausing a film, a series and music. The file is playing, I press pause, wait (I think) 3 minutes and when the screensaver starts (the tv-screen gets dimmed) the LCD shows the paused playback time as big digits. When the file is longer than an houre it shows the time like this: 00:01:30 and when it is less than an houre it shows it like this: 01:30 followed by three BIG blanks. Does this help? Is it a RPi problem only again?

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").

It looks strange too! ;o)
I know that there is no such feature but I could see it. First I thought it must be the power supply but I could not remember such problems when using LCD/VFD and also it was reproduceable only happening in very special submenus.
I had an idea! When switching through the menus I noticed that on every update with a new contend the characters on the display got a bit darker for a millisecond. I thought it could be a problem that in some menus for some reason the contend of the display gets updated permanently (without contend change) and because the display is so slow you don't see flickering but it would cause the lower contrast. I was so wrong ...

A video showing the XBMC screen and the display when toggling that effect would be very interesting.

I made a video of the display and I can upload it if you are still interested. I used the handy cam so it is not a good quality but the effect is easy to see. But it is only for curiosity because the problem is solved ...

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?

To make it short: Yes, it was the power supply!
I tested an other PSU just to be sure and the effect is gone or at least only a very very tiny effect can still be seen.
Updated:
I tested LCD/VFD again and it shows the same effect. I will try to deactivate the dynamic overclocking (with overvoltage). Maybe the RPi thinks that it has to overclock in these menus?! ;o)

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

Richtig interpoliert! :o)

Thanks,
Cyberdyne

Edit:
How can I determine the version of the hd44780 driver? I took the driver from the tutorial and there was no info about it. Are there different drivers and which one should I use?

[herrnst]

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.

I do have some more HD44780 displays and I could make you a cabel with poti and GPIO connector but I only have one RPi and that is in daily use. Let me know if you need the LCD.

Thanks, but I would also need a RPi for this (so basically the full package ). But I think this would rather be something for someone more into low-level hardware access things, since the problem can safely be reproduced outside of the addon.

This is intended. script.xbmc.lcdproc doesn't draw any special text chars from the ROM charset (like "Has LCD/VFD" does).

It's strange that "LCD.Time2x" and "LCD.TimeWide2x" and so on didn't work at all when I used the build in LCD/VFD. Is it an RPi only problem? Again: Driver problem?

I'd rather suspect some sort of charmap setting in LCDd.conf. For the way bultin did things to work, charmap=none should be the way to go.

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.

Updated:
Four text lines not two but yes, your are right! I now tested pausing a film, a series and music. The file is playing, I press pause, wait (I think) 3 minutes and when the screensaver starts (the tv-screen gets dimmed) the LCD shows the paused playback time as big digits. When the file is longer than an houre it shows the time like this: 00:01:30 and when it is less than an houre it shows it like this: 01:30 followed by three BIG blanks. Does this help? Is it a RPi problem only again?

Nope, I reproduced this on my dev system using the x11-osd pseudo-driver, and clearly is caused by script.xbmc.lcdproc.

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?

To make it short: Yes, it was the power supply!
I tested an other PSU just to be sure and the effect is gone or at least only a very very tiny effect can still be seen.
Updated:
I tested LCD/VFD again and it shows the same effect. I will try to deactivate the dynamic overclocking (with overvoltage). Maybe the RPi thinks that it has to overclock in these menus?! ;o)

Ok In this case you might notice that effect happen more when going "the addon way", since LCD/VFD runs directly on the processor, while script.xbmc.lcdproc is a script, which by nature is slower and needs more processing power to do the same, so probably the Pi overclocks when the script evaluates new states (like changing the current menu item) and thus draws more power, which is then missing on the GPIO pins, and causes the contrast change.

How can I determine the version of the hd44780 driver? I took the driver from the tutorial and there was no info about it. Are there different drivers and which one should I use?

You're probably looking for the output of (example)

Code:

# LCDd -h
LCDd - LCDproc Server Daemon, 0.5.5

but that information can also be retrieved from xbmc.log (debug level):

Code:

17:14:52 T:140703385917184   DEBUG: ### [XBMC LCDproc] - Open 127.0.0.1:13666
17:14:52 T:140703385917184   DEBUG: ### [XBMC LCDproc] - Reply: connect LCDproc 0.5.5 protocol 0.3 lcd wid 16 hgt 2 cellwid 6 cellhgt 8

Some display drivers also deliver more details which are retrieved using the info command (those details are e.g. used to enable support for iMon/mdm166a extra display elements) which in some cases also can contain a driver version. That information is also written to xbmc.log (notice-level). Example:

Code:

17:14:52 T:140703385917184  NOTICE: ### [XBMC LCDproc] - Driver information reply: SoundGraph iMON LCD driver v0.6 : 15c2:ffdc and 15c2:0038

HTH,
nst

[Cyberdyne_de]

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.

I do have some more HD44780 displays and I could make you a cabel with poti and GPIO connector but I only have one RPi and that is in daily use. Let me know if you need the LCD.

Thanks, but I would also need a RPi for this (so basically the full package ). But I think this would rather be something for someone more into low-level hardware access things, since the problem can safely be reproduced outside of the addon.

Maybe I do some more testing with different drivers and see what happens. If you do want to try some low-level hardware access debugging please send me an PM. You are from Germany and maybe not to far away and the "Deutsche Post" is quit fast ...

This is intended. script.xbmc.lcdproc doesn't draw any special text chars from the ROM charset (like "Has LCD/VFD" does).

It's strange that "LCD.Time2x" and "LCD.TimeWide2x" and so on didn't work at all when I used the build in LCD/VFD. Is it an RPi only problem? Again: Driver problem?

I'd rather suspect some sort of charmap setting in LCDd.conf. For the way bultin did things to work, charmap=none should be the way to go.

I tested "none", "hd44780_default" and "hd44780_euro" and nothing worked. I think we can stop here. This thread is about your script and who really wants to use LCD/VFD when there is this great alternative?

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.

Updated:
Four text lines not two but yes, your are right! I now tested pausing a film, a series and music. The file is playing, I press pause, wait (I think) 3 minutes and when the screensaver starts (the tv-screen gets dimmed) the LCD shows the paused playback time as big digits. When the file is longer than an houre it shows the time like this: 00:01:30 and when it is less than an houre it shows it like this: 01:30 followed by three BIG blanks. Does this help? Is it a RPi problem only again?

Nope, I reproduced this on my dev system using the x11-osd pseudo-driver, and clearly is caused by script.xbmc.lcdproc.

Now I am happy! I found a bug and hope that you can fix it. I helped to make this thing even better! :o)

How can I determine the version of the hd44780 driver? I took the driver from the tutorial and there was no info about it. Are there different drivers and which one should I use?

You're probably looking for the output of (example)

Code:

# LCDd -h
LCDd - LCDproc Server Daemon, 0.5.5

but that information can also be retrieved from xbmc.log (debug level):

Code:

17:14:52 T:140703385917184   DEBUG: ### [XBMC LCDproc] - Open 127.0.0.1:13666
17:14:52 T:140703385917184   DEBUG: ### [XBMC LCDproc] - Reply: connect LCDproc 0.5.5 protocol 0.3 lcd wid 16 hgt 2 cellwid 6 cellhgt 8

Some display drivers also deliver more details which are retrieved using the info command (those details are e.g. used to enable support for iMon/mdm166a extra display elements) which in some cases also can contain a driver version. That information is also written to xbmc.log (notice-level). Example:

Code:

17:14:52 T:140703385917184  NOTICE: ### [XBMC LCDproc] - Driver information reply: SoundGraph iMON LCD driver v0.6 : 15c2:ffdc and 15c2:0038

That is all I got:

Code:

OpenELEC:~ # LCDd -h
LCDd - LCDproc Server Daemon, 0.5.6

and in the xbmc.log

Code:

18:11:12 T:2927772768  NOTICE: ### [XBMC LCDproc] - Connected to LCDd at 127.0.0.1:13666, Protocol version 0.3 - Geometry 20x4 characters (100x32 pixels, 5x8 pixels per character)
18:11:12 T:2927772768  NOTICE: ### [XBMC LCDproc] - Empty driver information reply

I already found three hd44780.so with different file-sizes but I would like to know the version of these drivers. :o(

To sum up the problems of my first posting:
1. PlayIcon/Progressbar -> It is a RPi only bug and needs further tests.
2. Time21, TimeWide21, ... always the same big-clock -> Let's say: It's not a bug - it' a feature! ;o)
3. Play/Pause/Scrennsaver-Clock -> It's a bug and hopefully you will fix it.
4. Low contrast in some submenus -> It's not a bug - I just need a better PSU!

[delinend]

Regarding LCDproc in many XBMC Gotham test builds....

I don't know, if this is the right place/Forum... But I always use a LCD (HD44780/display) via RPi/GPIO (Raspberry Pi), and always replays the hd44780.so driver, in my openELEC/Gotham test builds.
The official LCDproc build 0.5.6, is from 2012 (old), and without RPI/GPIO support.

Does anyone know, who we get the last version LCDproc permanent into XBMC Gotham builds, from Sourceforce, or must the build always use the official release ?
I looks like the official LCDproc release, has stopped.

Best regards.

[Cyberdyne_de]

But I always use a LCD (HD44780/display) via RPi/GPIO (Raspberry Pi), and always replays the hd44780.so driver, in my openELEC/Gotham test builds.

Which driver do you use (size and version if you know it)? Do you have the same problem with the right and wrong order of "PlayIcon" and "ProgressBar" mentioned in this thread? As you say that Gothem builds use the same LCDproc version (0.5.6) an update from Frodo will not change this problem but maybe it's the driver. Could you try the hd44780-driver I use and tell us if there is a difference to the driver you use.

Regarding LCDproc in many XBMC Gotham test builds....

Are there new Gothem builds without LCDproc? I think about testing a version patched by Milhouse. Do they have LCDproc included?

[delinend]

But I always use a LCD (HD44780/display) via RPi/GPIO (Raspberry Pi), and always replays the hd44780.so driver, in my openELEC/Gotham test builds.

Which driver do you use (size and version if you know it)? Do you have the same problem with the right and wrong order of "PlayIcon" and "ProgressBar" mentioned in this thread? As you say that Gothem builds use the same LCDproc version (0.5.6) an update from Frodo will not change this problem but maybe it's the driver. Could you try the hd44780-driver I use and tell us if there is a difference to the driver you use.

Regarding LCDproc in many XBMC Gotham test builds....

Are there new Gothem builds without LCDproc? I think about testing a version patched by Milhouse. Do they have LCDproc included?

I use the hd44780.so from here, to get my HD44780 display to work, with Rpi/GPIO. http://www.raspberrypi.org/phpBB3/viewtopic.php?t=15967

Yes, LCDproc is included in Gotham build from Milhouse, but it is the old offcial 0.5.6 version. That why, I always have to copy the new dh44780.so driver, into Gotham. It will be better, if XBMC/Gotham is using the last know LCDproc fix. But some one have to init the XBMC devel. to include the last LCDproc.

[herrnst]

3. Play/Pause/Scrennsaver-Clock -> It's a bug and hopefully you will fix it.

Please try out this branch and check if this works better for you (beware: If you're running Frodo, the branch will probably not work since deps are already bumped for gotham. You can however apply the diff of the top commit to your installed addon and test this way).

(somehow this next hackish attempt to achieve something must be one of the reasons the words "rewrite" and "refactor" are forming in big, clear letters in my head...)

Regards,
nst