Random python errors

[07jetta]

Hi guys,

I'm still having a few problems with Pi stability throughout the day. What I've done is downloaded the latest Raspian Wheezy image and installed screenly onto that.

I've setup three Pi's today running this setup, two of them are fine (for the moment) but one has stopped working after 6 hours and come up with the error in the image provided.

I'm setting a Concerto Signage URL as an asset, setting the duration to 1800 (30 mins) and setting the start and end dates to last year and next year respectively.

1. Have I made some kind of installation error that has put faulty code/files on the Pi to make it produce this error?
2. Is my asset setup appropriate for the application? Its running 8 hours a day, 5 days a week, with the screen turning on and off on a timer.

EDIT: 2/3 Pi's have now come up with this issue, and just return to the splash screen and freeze.

[vpetersson]

Interesting. What kind of SD card are you running on (model, class, how new etc)?

From what I can read out, it looks like there's an issue with the browser. I've never used Concerto Signage, so I have no idea how the assets are looking. Yet, one theory is that they are so heavy that it crashes the browser/system due to memory usage or something similar.

[07jetta]

I'm using brand new Team brand Class 10 64GB SDxc cards (excessive, but it's all I had spare)

I have three screens displaying identical content, the first is a slightly older screenly image which has a load average of 0.35, and the two new images are at around 1.6 (slightly worrying) I also have a fourth Pi with the newest version, but with a very basic concerto screen, and it's running at a 1.09 load average

Also swapped out the Pis this morning to brand new ones, running the same SD cards as yesterday

If you want to test concerto, just set this URL as an asset http://demo.concerto-signage.com/?mac=AAA

EDIT: dates are wrong on screenshot, as the Pis cannot get NTP updates behind firewall

[vpetersson]

Ok, looking at the demo-page, I'm not surprised if you're having issues after a few hours of runtime.

I haven't looked to careful at the JavaScript code, but a quick glance of the functionality, I can certainly imagine that it causes the browser to crash on the Raspberry Pi if it isn't properly written in terms of memory management.

[07jetta]

This is the status page of one with a slightly older screenly image (noted from Update Available), running the same concerto screen as the others with the really high load average. I'll keep monitoring the new images today to see if I notice anything strange

[vpetersson]

I really wouldn't be concerned if the load average is less than ~2.0.

It could simply be that the new versions of the web browser are more vulnerable to this kind of operation.

[07jetta]

You're spot on, it's Midori that's causing issues. A few people around the Internet have said Chromium seems to work crash-free, so I'll run some tests today and see how it copes.

[vpetersson]

Actually, Screenly isn't using Midori (but rather UZBL). That said both are webkit-based, so that they might be affected by the same problem.

Replacing UZBL with Chromium isn't an option. Chromium is far too slow, and it also lacks the ability to be controlled remotely (which is something required for Screenly).

[07jetta]

Here's hoping the latest version of Concerto overcomes these issues, together they work really well, when they work

[reiabreu]

Viktor, even though Chromium can't be controlled remotely, I'm using it with Screenly OSE because I have particular needs of proxy and client side HTTPS. It adds the overload of having to create and kill a chromium instance for every URL because currently Chromium doesn't allow the re-use of an open instance, but it satisfies my needs for now. On 18 Sep 2013 09:28, "Viktor Petersson" notifications@github.com wrote:

Actually, Screenly isn't using Midori (but rather UZBL). That said both are webkit-based, so that they might be affected by the same problem.

Replacing UZBL with Chromium isn't an option. Chromium is far too slow, and it also lacks the ability to be controlled remotely (which is something required for Screenly).

— Reply to this email directly or view it on GitHubhttps://github.com/wireload/screenly-ose/issues/165#issuecomment-24648651 .

[vpetersson]

@xxyyzz Yeah, it's definitely possible to use Chromium that way, but the latency between each asset will be very significant.

[reiabreu]

Viktor, yes, the transition between every URL is noticeable, but as I said, I have a particular set of requirements that UZBL can't quite satisfy. For the general use, UZBL works just fine. On 18 Sep 2013 10:41, "Viktor Petersson" notifications@github.com wrote:

@xxyyzz https://github.com/xxyyzz Yeah, it's definitely possible to use Chromium that way, but the latency between each asset will be very significant.

— Reply to this email directly or view it on GitHubhttps://github.com/wireload/screenly-ose/issues/165#issuecomment-24652290 .

[vpetersson]

@xxyyzz Do you have a branch with your changes? Perhaps that would be useful for @07jetta.

[reiabreu]

I've created a branch but I still haven't commited the changes. I'll try to do it during the next days. On 18 Sep 2013 10:46, "Viktor Petersson" notifications@github.com wrote:

@xxyyzz https://github.com/xxyyzz Do you have a branch with your changes? Perhaps that would be useful for @07jettahttps://github.com/07jetta.

— Reply to this email directly or view it on GitHubhttps://github.com/wireload/screenly-ose/issues/165#issuecomment-24652589 .

[07jetta]

That would be rather handy, thanks.

From my point of view (all the way from Australia) a lot of our schools and businesses use proxy servers to filter content - if we can all somehow get this to mesh nicely with Concerto and proxies, there is a very large market over here for well priced signage that just works. The next best (rubbish) solution is $1500 per box behind the TV - our IT dept. got a sample unit from an unmentioned company, and the 3 IT staff couldn't even work out how to upload any kind of asset.

My in-progress deployment at my school is already drawing much positive attention from kids, parents and other visiting IT staff, who want similar systems at their school. Providing the proxy issue can be sorted out, and possibly a screenly pro education pricing scheme put in place just for basic web assets (no online storage, just Pi management) I know a lot of people in my regional area who would be extremely interested. The Pi itself is an excellent unit to market, and screenly pro+concerto could work extremely well for those on a tight budget. Personally, I love screenly, and I understand that downfalls of both screenly and concerto are causing me headaches, but I genuinely think this combination can work, and can be marketable.

Let me know what you think

[reiabreu]

I've pushed the changes to https://github.com/xxyyzz/screenly-ose. Please bear in mind that the code is very much experimental and that was made under the assumption that the computer is always behind a proxy server. I disabled lots of assets validations because of this. To make this work:

• Edit viewer.py and replace in the top of the file:

proxy="INSERT_YOUR_PROXY_HERE" no_proxy="INSERT_YOUR_PROXY_EXCEPTION_HERE"

• sudo apt-get install chromium

When I have some free time, I'll try to make improvements and code clean up.

Cheers

[reiabreu]

Please pay attention to the system's load average while using Chromium. It will go up, depending on the type of site you point Chromium at.

[vpetersson]

@07jetta

 Providing the proxy issue can be sorted out

We won't be able to support Proxies anytime soon in Screenly Pro. The reason is simply that the current wizard is designed to be hands-off and not require a keyboard, which is impossible if the user would have to enter the proxy (unless of course the proxy would be auto detectable).

Personally, I love screenly, and I understand that downfalls of both screenly and 
concerto are causing me headaches, but I genuinely think this combination can work, and can be marketable.

In order for that to fully work, Concerto would have to be rewritten to break apart each slide into an individual page. Otherwise, it will never fully work well (as you've seen).

I haven't looked at Concerto's code base at all, so I don't know how difficult such rewrite would be.

[07jetta]

I did try out screenly pro, and I thought the whole 'enter the code' system worked rather well, but from my perspective (not sure how other organisations run etc) it's generally the network/system admins that are installing the system, and have a clue with what they are doing - obviously it's not my product and I'm not designing it, but a few simple admin tools (static IP, proxy) combined with that simple 'one step code' system would be just about perfect to me if its as simple as just writing the SD card image to the SD card, plugging it in, setting a proxy or IP address if needed, and the system does the rest.

From our deployment, I can tell you first-hand that screenly can work beautifully with Concerto - all I've set mine to do is pull the URL, and it works fine. My record uptime is 2 months of smooth operation, but at the moment I'm hitting rocks with Concerto's memory management combined with UZBL - for some reason it can't handle a large amount of concerto 'feeds', but as far as displaying 300 photos, a clock, and a message ticker, it works like a charm when you keep the 'feeds' to a minimum.

[kfuglsang]

So, what do you reckon needs to be done to improve the stability of Screenly? I am running into the same reboot-issue quite frequently.

[07jetta]

@kfuglsang providing you are using Concerto, like I am, for some reason, as soon as you just add that little bit too much content to a screen, the load-average just starts going up exponentially. I have one screen that cycles through around 150 images that is completely stable, and one other with around 28 images that won't last a day. Don't ask me why or how this happens, but as soon as I get the time to play with Concerto v2, I'll see if the memory management is better.

[kfuglsang]

Thanks for the reply @07jetta. I don't use Concerto though. Only a few in-house websites that are not really that complex.

[vpetersson]

@07jetta My guess is that this isn't related to Screenly, but rather that the system gets too warm, which power cycles it.

[07jetta]

@vpetersson I find it doesn't power cycle, you just get that big error code that's in the first post on this thread, then the display itself just sits on the splash screen, showing the IP address. I've got two of my Pi's in a rather well-ventilated areas (outdoors, but undercover), one works fine, one doesn't. I've done temp checks using the command line, replaced both Pi's and their associated hardware, still both do the same thing.

From trying everything under the sun to fix it, all I can work out is there is something not playing nice with the browser side of things. As I mentioned before, I've got displays that work literally for months on end without even touching them, and ones that won't last an 8 hour day due to the load-average issue.

Don't get me wrong, I love screenly, but for the love of good things, I can't work out why it won't play nice on some screens.

[07jetta]

@kfuglsang could you wait for yours to crash/reboot and take a screenshot of the system info page? I wonder if we are getting the same error

[vpetersson]

Ah yes, sorry. I forgot to re-read the thread.

We pushed an update for that changes how we deal with sockets (which is the error you got) last week. Try updating and see if that resolves it.

[07jetta]

@vpetersson Thanks heaps, I won't be able to push it out till next week or so, but I'll see how it goes.

[kfuglsang]

@07jetta I'll try to grab some info next time it happens. Bought a few more Pi's today for use with Screenly so I'll have more possible victims :)

[Cyberprog]

I'd suggest maybe adding some better cooling to the Pi then - either through a heatsink and/or active cooling (fan).

http://www.raspberry-pi-case.com/ is a high-tech looking milled aluminium case with heatsink blobs to transmit heat to the case itself.

Alex Threlfall Cyberprog New Media www.cyberprog.net

-----Original Message----- From: Viktor Petersson [mailto:notifications@github.com] Sent: 30 October 2013 22:01 To: wireload/screenly-ose Subject: Re: [screenly-ose] Random python errors (#165)

@07jetta https://github.com/07jetta My guess is that this isn't related to Screenly, but rather that the system gets too warm, which power cycles it.

— Reply to this email directly or view it on GitHub https://github.com/wireload/screenly-ose/issues/165#issuecomment- 27443396 . https://github.com/notifications/beacon/RGfHRwpf7x89fZYIg1xxwaYGwCe R_oNguAKB_tOgjxRvdpprQX6oxfIuvDHssl8n.gif

[07jetta]

@kfuglsang sounds good - if you can get it to crash, try an update afterwards, as @vpetersson said, they have most likely fixed the bug I was having.

@Cyberprog sounds interesting - I've found mine sit at around 55 degrees Celsius, so I have been looking at heatsinks and whatnot to get them running a bit cooler. Thanks for the heads up

[Cyberprog]

@Cyberprog sounds interesting - I've found mine sit at around 55 degrees Celsius, so I have been looking at heatsinks and whatnot to get them running a bit cooler. Thanks for the heads up

Memory heatsinks can be adjusted cheaply also, and there are loads of heatsink kits (usually 3 in a pack for the 3 hottest chips) out there that are only a little more expensive than memory heatsinks. Obviously if you're doing a lot of Pi's doing some research will help your costs...

[vpetersson]

Closing out this issue as I think that has been sorted. @07jetta please let me know if there is anything actionable left here.

[07jetta]

Screenly is working fine now, seems to have been caused by memory leaks in poorly coded sites. Thanks

[vpetersson]

Cool. Thanks for the update, @07jetta.