LCDProc 0.5.4-dev

stephenw10

This was the behaviour the package had before, and I find it reasonable (if I stopped the service for some reason, it just stay stopped).
Do you agree with that?

Yes that seems reasonable and expected behaviour.
However I think that most users would expect the service to start if you tick the 'enable LCDproc' check box and then click save.
This is especially true just after installation when you have first setup the variables.
I think either it should instruct users to start the service manually or the service should start automatically.
Perhaps relabel the check box 'Enable LCDproc at boot time'?

@mdima:

Consider that the package can be run also from other parts, or from the interface, from a refresh, and so on, this "safe" code avoids to have more than one program running in the background!

I agree. :)

Steve

mdima

Hi Steve,

@stephenw10:

Perhaps relabel the check box 'Enable LCDproc at boot time'?

yes, I agree… you will find it the next release!

Ciao,
Michele

stephenw10

For further reducing user confusion you can include instructions using the <after_install_info>tag in pkg_config.8.xml. E.g.


 <after_install_info>Now configure your display in Services: LCDProc: then start the daemon in Status: Services:</after_install_info>

or something like that! ;)

Steve</after_install_info>

mdima

@stephenw10:

For further reducing user confusion you can include instructions using the <after_install_info>tag in pkg_config.8.xml. E.g.
 <after_install_info>Now configure your display in Services: LCDProc: then start the daemon in Status: Services:</after_install_info> 
or something like that! ;)
Steve</after_install_info>

yes, that's totally a good idea… you'll find it in the next release...

just a question (to you and to all): when do you think that we could replace the lcdproc package with the new lcdproc-dev package? I mean, to release it for real?

Thanks,
Michele

stephenw10

I would suggest we run both in parallel at least until 2.1 is released. At that point the package system is changing so work would be required to the old package which seems pointless if the dev package is relatively bug free.

Perhaps ask Seth Mos(databeestje)?

Steve

mdima

@stephenw10:

I would suggest we run both in parallel at least until 2.1 is released. At that point the package system is changing so work would be required to the old package which seems pointless if the dev package is relatively bug free.
Perhaps ask Seth Mos(databeestje)?
Steve

ok… I know that we are adding a lot of new features, but the "basic" features of lcdproc seem to be quite stable (I am running the service since days and days, with 1 second as refresh and it never hangs, while lcdproc 0.5.3.1 was hanging only after few days with a 5 seconds refresh). Actually I have no need to release it, but it would be great if also the other users could take advantage of this version, even if I don't have any number about the people that are using the package and their feedbacks.

Btw, before starting to put some work on the package, I tried to contact Seth Mos but the email was returning... but of course I will contact again before releasing the package on the "main" version...

Michele

fmertz

@mdima:

just a question (to you and to all): when do you think that we could replace the lcdproc package with the new lcdproc-dev package?

What is this package released against? A production pfSense release, or a development pfSense release? If it is development, I would say release it soon. This way, you can catch problems from users of other drivers before the package becomes production…

stephenw10

It would be very interesting to know how many people are using it.
I don't think we can ever hope to test everything before declaring it 'ready'.

I'm not sure really. :-\

Steve

mdima

@fmertz:

@mdima:

just a question (to you and to all): when do you think that we could replace the lcdproc package with the new lcdproc-dev package?

What is this package released against? A production pfSense release, or a development pfSense release? If it is development, I would say release it soon. This way, you can catch problems from users of other drivers before the package becomes production…

Hi fmertz,
I ment to release in production (replace the "lcdproc" package with the "lcdproc-dev" package)…

opinions opinions! ;)

Thanks,
Michele

mdima

@stephenw10:

It would be very interesting to know how many people are using it.
I don't think we can ever hope to test everything before declaring it 'ready'.
I'm not sure really. :-
Steve

me too… but also on the previous package, I think that there were a lot of "it works for me" parts of the code, and people has been using it for years (working)...
I would prefer that with a fresh install most people would use the "-dev" package in order to test it on as many systems as possible, but I really don't know how stable it is out of my environment...

stephenw10

I have found the strange behaviour from my box running v0.8 on pfSense 2.0.1.
Twice now I have found myself unable to log into the box either via http or ssh (ssh can login but then I get no console menu or command prompt).
Both times the problem has resolved itself when my WAN connection cycled causing packages to be reloaded.
It's hard to say at this point what is causing it, whether LCDproc is a cause or a symptom of something else.

What is certainly true is that I believe the php lcdproc client needs some better timeout code because when I look at the logs to try to determine what's happening all I see is:

Jan 13 08:37:43 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:42 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:32 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:30 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:20 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:19 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:09 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:08 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:57 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:56 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:46 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)

The standard lcdproc client will timeout after 3 or 4 attempts and quit.
What do you think?

Steve

power_matz

Hi,

first I want to thank you for the great effort you made on this project.
It was very annoying installing the LCDproc manually every time after an update.

I am using a FireBox. I am wondering why the backlight isn't staying on. I configured that in the control panel and also with the buttons on the hardware.

Can you tell me what the correct way is?
I was using the SDEC driver some time ago. There you had to set this in the conf file.
But I think you write this with the control panel, right?

Matthias

stephenw10

The newest driver for the sdeclcd no longer gives you that option. This is because the lamp in the display has a half life of just 3000 hours! You do not want it on all the time.
However if enough people want it it could be reinstated I guess.

Steve

fmertz

@power_matz:

I am using a FireBox. I am wondering why the backlight isn't staying on. I configured that in the control panel and also with the buttons on the hardware.

The initial driver had the option of setting the backlight timer to zero to leave the light always on. I read the spec of the SDEC LCD and it mentions a "Half Lift" (not my typo) of "3,000 HR.". I am not a component engineer, but I read this to mean that if a sufficiently large number of these LCDs are turned on at a given time, half of them will be off (and dead) after 3,000 Hours, or 17 weeks. It seemed like a good enough reason to keep the light off as much as possible, unless someone was "there" to look at it. Barring the availability of a proximity sensor, I coded it so it stays on for 30 sec after a key is pressed. If another key is pressed, the light stays on for another 30 seconds. From memory, someone posted on this forum that his backlight was dead. I figured these boxes have seen some use before we get them, so who knows how much life is left in that light. Also, with the high fan noise level these boxes make, I figured most of them will be stashed somewhere where the LCD would not be directly visible. This is my reasoning, and why I am reluctant to give folks an option to kill that light prematurely.

The original thread for the code is here: http://forum.pfsense.org/index.php/topic,7920.0.html

stephenw10

Further to my previous post.
I again found that LCDd had crashed out though this time the box was still responsive. Nothing useful in the logs as they are completely filled with the lcdproc php client error.
However I restarted the service and:


Jan 14 01:11:52 pfsense LCDd: LCDd version 0.5.5 starting
Jan 14 01:11:52 pfsense LCDd: Using Configuration File: /usr/local/etc/LCDd.conf
Jan 14 01:11:52 pfsense LCDd: Listening for queries on 127.0.0.1:13666
Jan 14 01:11:53 pfsense LCDd: Connect from host 127.0.0.1:57448 on socket 11
Jan 14 01:11:54 pfsense LCDd: Connect from host 127.0.0.1:10311 on socket 13
Jan 14 01:11:55 pfsense LCDd: Connect from host 127.0.0.1:27771 on socket 14

There now seem to be three copies of the php client so it isn't correctly being killed by the rc file.

Steve

Cino

been running the 0.5.5 pkg for a couple of days now and no issues so far with the picolcd driver…

power_matz

@stephenw10:

The newest driver for the sdeclcd no longer gives you that option. This is because the lamp in the display has a half life of just 3000 hours! You do not want it on all the time.
However if enough people want it it could be reinstated I guess.

Steve

I was using a Firebox x700 over 1,5 years with the LCD light on. No issues.
I was using a Cobalt Raq 3i for 3 years. There the light is on by default all the time. No issues.

Where do you have this information. Is it really a LAMP? No LED?

ADD:

OK, I looked up the specs myself. There a two versions: EL and LED backlight.

If the backlight is a LED then the half life (means half the brightness as a new one) is 50.000 h. Thats over 5 years!

So, I don't see here an issue to enable the permanet backlight on, if it is made by LED.

fmertz

@power_matz:

Where do you have this information.

The code is based on this spec:

http://www.ktechs.net/pvt_filz/lcdproc/LMC-S2D20-01.pdf

A re-read shows both 3,000 hrs for the "EL" part, and 30,000 hrs for the "LED" part. The block diagram seems to show a LED back light. 30,000 Hrs is less than 3.5 years. Folks like us typically get these Fireboxes used, so knowing nothing of the Watchguard software, I have to assume these lights could have been on for the better part of their life. Therefore, little time may be left. I am trying to keep it safe here, I guess. What length of time would you prefer?

fmertz

Looks like the vbars were upside down (my goof). The driver with a fix is here:

https://github.com/downloads/fmertz/sdeclcd/sdeclcd.so

Anyone can test on pfSense? Seems to work on Linux…

If this works, I'll open a ticket with pfSense on github. Thanks.

power_matz

@fmertz:

What length of time would you prefer?

What will it "cost" to let the user decide if he wants the BL on permanantly or only for 30 sec after a button was pressed?